From noreply at sourceforge.net  Sat Apr  1 02:30:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 16:30:58 -0800
Subject: [Patches] [ python-Patches-1462488 ] Patch for bug #931877 Segfault
	in object_reduce_ex
Message-ID: <E1FPU14-0003Gk-CV@sc8-sf-web1.sourceforge.net>

Patches item #1462488, was opened at 2006-04-01 02:30
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=1462488&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
Submitted By: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for bug #931877  Segfault in object_reduce_ex

Initial Comment:
This prevents unbounded recursion in typeobject.c's
object_reduce_ex(). It does so by splitting
implementation for object.__reduce_ex__ and
object.__reduce__ into two different C functions.
See the apended file details.txt for more detailed
explanation.

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

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

From noreply at sourceforge.net  Sat Apr  1 02:54:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 16:54:44 -0800
Subject: [Patches] [ python-Patches-1462496 ] Spelling correction in
	libsignal.tex
Message-ID: <E1FPUO4-0001B0-21@sc8-sf-web4-b.sourceforge.net>

Patches item #1462496, was opened at 2006-03-31 18: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=1462496&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
Submitted By: lmllc (lmllc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Spelling correction in libsignal.tex

Initial Comment:
Fixed small spelling error.

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

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

From noreply at sourceforge.net  Sat Apr  1 02:56:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 16:56:15 -0800
Subject: [Patches] [ python-Patches-1462498 ] bug #1452246 and patch
	#1087808; sgmllib entities
Message-ID: <E1FPUPX-0004t1-Nt@sc8-sf-web1.sourceforge.net>

Patches item #1462498, was opened at 2006-03-31 16:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462498&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
Submitted By: Rares Vernica (rvernica)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug #1452246 and patch #1087808; sgmllib entities

Initial Comment:
Patch for bug #1452246 htmllib doesn't properly
substitute entities
Continuation of patch #1087808 sgmllib.SGMLParser does
not unescape attribute values; patch

Substitute entities in argument values

import htmllib
import formatter
import StringIO

s = StringIO.StringIO()
p =
htmllib.HTMLParser(formatter.AbstractFormatter(formatter.DumbWriter(s)))
p.feed('<img alt="&lt;&gt;&amp;">')
print s.getvalue()

will now print '<>&' instead of '&lt;&gt;&amp;'.

The patch modifies module sgmllib, class SGMLParser,
method parse_starttag. In this method, the entities are
substituted in the argument values. The substitutions
are based on existing property SGMLParser.entitydefs.
For parsing is uses the regular expression entityref.

Regarding the differences between this patch and patch
#1087808:
  - use self.entitydefs to determine the set of entity
names that are supported;
  - unknown entities references are left alone;
  - the regular expression entityref is used to find
references;
  - a documentation patch is not needed as the method
is Internal.
  
Regarding the fact that semicolon after the entity name
is not mandatory in SGML, the way entityref is defined
"&lt " will become "< ", while "&lt" will stay "&lt",
regardless of being an attribute value.

The patch also adds test cases in module
test/test_sgmllib.py, class SGMLParserTestCase, method
test_attr_values. In that method, the proper
substitution is tested.

Ray

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

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

From noreply at sourceforge.net  Sat Apr  1 03:00:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 17:00:05 -0800
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1FPUTF-00057M-Rg@sc8-sf-web1.sourceforge.net>

Patches item #1087808, was opened at 2004-12-18 21:42
Message generated for change (Comment added) made by rvernica
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&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
Submitted By: Titus Brown (titus)
Assigned to: Martin v. L??wis (loewis)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

Comment By: Rares Vernica (rvernica)
Date: 2006-03-31 17:00

Message:
Logged In: YES 
user_id=1491427

This patch is continued in patch #1462498.

Regarding the differences between patch #1462498 and this patch:
  - use self.entitydefs to determine the set of entity names
that are supported;
  - unknown entities references are left alone;
  - the regular expression entityref is used to find references;
  - a documentation patch is not needed as the method is
Internal.

Ray

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

Comment By: Titus Brown (titus)
Date: 2005-03-04 11:38

Message:
Logged In: YES 
user_id=23486

yes, sorry, will submit patch this weekend.


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

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-04 11:33

Message:
Logged In: YES 
user_id=21627

titus, are you still working on this?

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

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

Message:
Logged In: YES 
user_id=21627

Not necessarily: self.entityrefs is already updated in 
HTMLParser, so this should work for the base class.

One issue might be with encodings, e.g. if the document 
encoding is not Latin-1. In this case, one might not want to 
replace &auml; with its Latin-1 equivalent, so you might need 
to provide a hook where a subclass can chose not to perform 
entity expansion, or perform more of it (perhaps also with a 
possibility to perform character reference expansion).

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

Comment By: Titus Brown (titus)
Date: 2004-12-22 00:32

Message:
Logged In: YES 
user_id=23486

I'm happy to do so -- note that this will expand the patch to include 
HTMLParser.py, as well.

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

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

Message:
Logged In: YES 
user_id=21627

Please use unified or context diffs when submitting patches.

The patch is incorrect: Instead of hard-coding the list of
known entities, sgmllib should use self.entitydefs to
determine the set of entity names that are supported. As a
result, the algorithm should also replace, say, &auml; if it
occurs in an HTML attribute.

Then the question is what should happen on unknown entity
references. One cannot really call unknown_entityref, since
implementations of that will expect that the entity
reference was in content, not in an attribute. So it would
probably best to leave unknown entity references alone.

Notice that in SGML (and HTML) the semicolon after the
entity name is not mandatory, but can be omitted if the
entity name is not followed by a letter or digit. So you
probably should use the regular expression entityref to find
references.

Please also provide a documentation patch that explains
precisely how the attribute value is created from what is in
the input document (i.e. some entity references replaced, no
character references replaced, etc).


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

Comment By: Titus Brown (titus)
Date: 2004-12-21 23:15

Message:
Logged In: YES 
user_id=23486

oh, and here's the example.

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

Comment By: Titus Brown (titus)
Date: 2004-12-21 23:13

Message:
Logged In: YES 
user_id=23486

Whoops.  Dangitall.

Also at

http://issola.caltech.edu/~t/transfer/sgmllib.diff



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

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

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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

From noreply at sourceforge.net  Sat Apr  1 05:20:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 19:20:58 -0800
Subject: [Patches] [ python-Patches-1229511 ] Zipfile fix create_system
	information
Message-ID: <200604010320.k313Kw2S011365@sc8-sf-db2-new-b.sourceforge.net>

Patches item #1229511, was opened at 06/29/05 00:47
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229511&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: Closed
Resolution: None
Priority: 5
Submitted By: Hendrik Muhs (hendriktt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Zipfile fix create_system information

Initial Comment:
this patches corrects the create_system value for
created zipfiles with the zipfile module, which is
platform dependent (better: filesystem dependent). 
It fixes the following bug: if a zipfile is created
with Python on Unix and the files have executable flags
the file rights are correctly saved into the zipfile.
But when extracting the file with unzip (from Info-zip)
the filerights (executable flags) are not reassigned
correctly. This is due to the wrong create_system flag.

The patch is not the 100% correct way to do it, but it
is better as the situation now (completly ignore the
system and always set create_system to 0).

The right way to fix this would be to set the
create_system flag dependent on the platform and the
filesystem but I do not know how to do this.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 03/31/06 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Georg Brandl (gbrandl)
Date: 03/17/06 11:35

Message:
Logged In: YES 
user_id=849994

Waiting for input from OP.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 03/07/06 04:35

Message:
Logged In: YES 
user_id=580910

Could you check if the trunk is acceptable to you, and if so close this patch?

Patch 1412872 also sets create_system to another value on unix systems and 
was applied at 05 feb 2006.

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

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

From noreply at sourceforge.net  Sat Apr  1 05:30:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 19:30:42 -0800
Subject: [Patches] [ python-Patches-1462525 ] URI parsing library
Message-ID: <E1FPWp0-0003Jg-Kr@sc8-sf-web6.sourceforge.net>

Patches item #1462525, was opened at 2006-04-01 03:30
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=1462525&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
Submitted By: Paul Jimenez (paulj)
Assigned to: Nobody/Anonymous (nobody)
Summary: URI parsing library

Initial Comment:
Per the original discussion at
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
I'm submitting a library meant to deprecate the
existing urlparse library.  Questions and comments welcome.


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

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

From noreply at sourceforge.net  Sat Apr  1 08:23:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 22:23:23 -0800
Subject: [Patches] [ python-Patches-624325 ] attributes for urlsplit,
	urlparse result
Message-ID: <E1FPZW7-0004ob-KJ@sc8-sf-web4-b.sourceforge.net>

Patches item #624325, was opened at 2002-10-16 17:59
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&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: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: attributes for urlsplit, urlparse result

Initial Comment:
This patch to Lib/urlparse.py makes the fields of the
results accessible as named attributes from the result
object.  The result objects are still small since they
derive from tuple and have no __dict__, though there's
some additional cost in construction (a temporary tuple
is created and passed to tuple.__new__).

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-01 01:23

Message:
Logged In: YES 
user_id=3066

Here's a new version of the patch.  This takes birkenfeld's
changes into account, adds more tests and documentation, and
adds four more attributes to the result objects: username,
password, hostname, and port.  These provide access to
parsed-out portions of the netloc component.  These are
computed on demand only.

Much of this patch was written independently, but I've taken
the previous patches into consideration to make sure I
didn't miss anything already accounted for.

I think this is good for 2.5 still, and will commit this
weekend if there are no objections.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2005-04-02 11:44

Message:
Logged In: YES 
user_id=1188172

Here is a diff to the patch that corrects the
\versionchanged commands and the use of the geturl() in the
example:


--- urlparse.patch      2005-04-02 18:38:06.979685348 +0200
+++ urlparse-new.patch  2005-04-02 18:42:03.124933001 +0200
@@ -168,7 +168,7 @@
  ('http', 'www.cwi.nl:80', '/%7Eguido/Python.html', '', '', '')
 +>>> o.scheme
 +'http'
-+>>> o.url
++>>> o.geturl()
 +'http://www.cwi.nl:80/%7Eguido/Python.html'
  \end{verbatim}

@@ -189,7 +189,7 @@
 +\var{urlstring}.
 +
 +\versionchanged[Support for attributes on the result
object was
-+                added]{2.3}
++                added]{2.5}
  \end{funcdesc}

  \begin{funcdesc}{urlunparse}{tuple}
@@ -236,7 +236,7 @@
 +
  \versionadded{2.2}
 +\versionchanged[Support for attributes on the result
object was
-+                added]{2.3}
++                added]{2.5}
  \end{funcdesc}

  \begin{funcdesc}{urlunsplit}{tuple}

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-10-17 15:10

Message:
Logged In: YES 
user_id=3066

I've attached a new version of the patch that simplifies the
code for the new types.

It doesn't look like I'll bet getting to magic structseq
support anytime soon.  I'm also no longer convinced that
this needs to be held up for that.  This should be
considered for Python 2.5 on the basis of the feature; the
implementation can be changed some someone get around to
creation of structseq types from Python.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 12:37

Message:
Logged In: YES 
user_id=6380

I'm fine with this, but we decided to use a different
approach (for the same effect): make structseq usable from
Python code. That's being discussed in bug 624827. Pending
that, this one's on hold.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-17 16:03

Message:
Logged In: YES 
user_id=3066

Based on comments from Guido, provide a geturl() method
instead of the url property, since it actually does more
work than just retrieving data.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-17 13:09

Message:
Logged In: YES 
user_id=3066

New version of the patch.

This adds a &quot;url&quot; attribute to each type of result,
providing the result of urlunsplit() / urlunparse() for the
components of the result object.

Tests and documentation have been updated.

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

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

From noreply at sourceforge.net  Sat Apr  1 09:39:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 23:39:57 -0800
Subject: [Patches] [ python-Patches-1459631 ] Update docs for
	zlib.decompressobj.flush()
Message-ID: <E1FPaiD-0004YW-NG@sc8-sf-web1.sourceforge.net>

Patches item #1459631, was opened at 2006-03-27 21:35
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459631&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
Submitted By: Chris AtLee (catlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Update docs for zlib.decompressobj.flush()

Initial Comment:
zlib.decompressobj's flush method takes an optional
length parameter.  This patch adds documentation for
that parameter.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:39

Message:
Logged In: YES 
user_id=849994

Thanks, fixed in rev. 43525, 43526.

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

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

From noreply at sourceforge.net  Sat Apr  1 09:42:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 23:42:58 -0800
Subject: [Patches] [ python-Patches-1462496 ] Spelling correction in
	libsignal.tex
Message-ID: <E1FPal8-0005Gf-C7@sc8-sf-web3.sourceforge.net>

Patches item #1462496, was opened at 2006-04-01 00:54
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462496&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
Submitted By: lmllc (lmllc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Spelling correction in libsignal.tex

Initial Comment:
Fixed small spelling error.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:42

Message:
Logged In: YES 
user_id=849994

Thanks, fixed in rev. 43527, 43528.

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

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

From noreply at sourceforge.net  Sat Apr  1 09:48:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 23:48:10 -0800
Subject: [Patches] [ python-Patches-1462414 ] Patch for bug #1458017
	Log._log needs to be more forgiving
Message-ID: <E1FPaqA-0000Zz-9C@sc8-sf-web5.sourceforge.net>

Patches item #1462414, was opened at 2006-03-31 21:21
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462414&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: Closed
>Resolution: Rejected
Priority: 5
Submitted By: splitscreen (splitscreen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for bug #1458017 Log._log needs to be more forgiving

Initial Comment:
This is a patch to stop Log._log() from crashing when
the message string contains a % escape but args is an
empty tuple (i.e we're not expecting to format anything).

It's only a modest patch against trunk r43509.

Matt

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:48

Message:
Logged In: YES 
user_id=849994

This patch prevents all string formatting even when there's
legitimate args. Rejecting.

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

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

From noreply at sourceforge.net  Sat Apr  1 09:49:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 31 Mar 2006 23:49:33 -0800
Subject: [Patches] [ python-Patches-1462488 ] Patch for bug #931877 Segfault
	in object_reduce_ex
Message-ID: <E1FParV-0000dw-Bi@sc8-sf-web5.sourceforge.net>

Patches item #1462488, was opened at 2006-04-01 00:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&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
Submitted By: ?iga Seilnacht (zseil)
>Assigned to: Georg Brandl (gbrandl)
Summary: Patch for bug #931877  Segfault in object_reduce_ex

Initial Comment:
This prevents unbounded recursion in typeobject.c's
object_reduce_ex(). It does so by splitting
implementation for object.__reduce_ex__ and
object.__reduce__ into two different C functions.
See the apended file details.txt for more detailed
explanation.

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

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

From noreply at sourceforge.net  Sat Apr  1 10:35:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 00:35:31 -0800
Subject: [Patches] [ python-Patches-1462498 ] bug #1452246 and patch
	#1087808; sgmllib entities
Message-ID: <E1FPbZz-00006h-EA@sc8-sf-web3.sourceforge.net>

Patches item #1462498, was opened at 2006-04-01 00:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462498&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
Submitted By: Rares Vernica (rvernica)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug #1452246 and patch #1087808; sgmllib entities

Initial Comment:
Patch for bug #1452246 htmllib doesn't properly
substitute entities
Continuation of patch #1087808 sgmllib.SGMLParser does
not unescape attribute values; patch

Substitute entities in argument values

import htmllib
import formatter
import StringIO

s = StringIO.StringIO()
p =
htmllib.HTMLParser(formatter.AbstractFormatter(formatter.DumbWriter(s)))
p.feed('<img alt="&lt;&gt;&amp;">')
print s.getvalue()

will now print '<>&' instead of '&lt;&gt;&amp;'.

The patch modifies module sgmllib, class SGMLParser,
method parse_starttag. In this method, the entities are
substituted in the argument values. The substitutions
are based on existing property SGMLParser.entitydefs.
For parsing is uses the regular expression entityref.

Regarding the differences between this patch and patch
#1087808:
  - use self.entitydefs to determine the set of entity
names that are supported;
  - unknown entities references are left alone;
  - the regular expression entityref is used to find
references;
  - a documentation patch is not needed as the method
is Internal.
  
Regarding the fact that semicolon after the entity name
is not mandatory in SGML, the way entityref is defined
"&lt " will become "< ", while "&lt" will stay "&lt",
regardless of being an attribute value.

The patch also adds test cases in module
test/test_sgmllib.py, class SGMLParserTestCase, method
test_attr_values. In that method, the proper
substitution is tested.

Ray

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 08:35

Message:
Logged In: YES 
user_id=849994

Changed your patch a bit (only allowing entityrefs ending
with ';' and recognizing charrefs), added more tests and
docs and committed as rev. 43532.

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

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

From noreply at sourceforge.net  Sat Apr  1 10:40:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 00:40:25 -0800
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1FPbej-0000kv-Qt@sc8-sf-web2.sourceforge.net>

Patches item #1087808, was opened at 2004-12-19 05:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&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: Out of Date
Priority: 5
Submitted By: Titus Brown (titus)
Assigned to: Martin v. L??wis (loewis)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 08:40

Message:
Logged In: YES 
user_id=849994

Outdated with commit of patch #1462498.

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

Comment By: Rares Vernica (rvernica)
Date: 2006-04-01 01:00

Message:
Logged In: YES 
user_id=1491427

This patch is continued in patch #1462498.

Regarding the differences between patch #1462498 and this patch:
  - use self.entitydefs to determine the set of entity names
that are supported;
  - unknown entities references are left alone;
  - the regular expression entityref is used to find references;
  - a documentation patch is not needed as the method is
Internal.

Ray

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

Comment By: Titus Brown (titus)
Date: 2005-03-04 19:38

Message:
Logged In: YES 
user_id=23486

yes, sorry, will submit patch this weekend.


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

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-04 19:33

Message:
Logged In: YES 
user_id=21627

titus, are you still working on this?

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

Comment By: Martin v. L??wis (loewis)
Date: 2004-12-22 13:16

Message:
Logged In: YES 
user_id=21627

Not necessarily: self.entityrefs is already updated in 
HTMLParser, so this should work for the base class.

One issue might be with encodings, e.g. if the document 
encoding is not Latin-1. In this case, one might not want to 
replace &auml; with its Latin-1 equivalent, so you might need 
to provide a hook where a subclass can chose not to perform 
entity expansion, or perform more of it (perhaps also with a 
possibility to perform character reference expansion).

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

Comment By: Titus Brown (titus)
Date: 2004-12-22 08:32

Message:
Logged In: YES 
user_id=23486

I'm happy to do so -- note that this will expand the patch to include 
HTMLParser.py, as well.

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

Comment By: Martin v. L??wis (loewis)
Date: 2004-12-22 07:57

Message:
Logged In: YES 
user_id=21627

Please use unified or context diffs when submitting patches.

The patch is incorrect: Instead of hard-coding the list of
known entities, sgmllib should use self.entitydefs to
determine the set of entity names that are supported. As a
result, the algorithm should also replace, say, &auml; if it
occurs in an HTML attribute.

Then the question is what should happen on unknown entity
references. One cannot really call unknown_entityref, since
implementations of that will expect that the entity
reference was in content, not in an attribute. So it would
probably best to leave unknown entity references alone.

Notice that in SGML (and HTML) the semicolon after the
entity name is not mandatory, but can be omitted if the
entity name is not followed by a letter or digit. So you
probably should use the regular expression entityref to find
references.

Please also provide a documentation patch that explains
precisely how the attribute value is created from what is in
the input document (i.e. some entity references replaced, no
character references replaced, etc).


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

Comment By: Titus Brown (titus)
Date: 2004-12-22 07:15

Message:
Logged In: YES 
user_id=23486

oh, and here's the example.

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

Comment By: Titus Brown (titus)
Date: 2004-12-22 07:13

Message:
Logged In: YES 
user_id=23486

Whoops.  Dangitall.

Also at

http://issola.caltech.edu/~t/transfer/sgmllib.diff



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

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

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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

From noreply at sourceforge.net  Sat Apr  1 10:51:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 00:51:48 -0800
Subject: [Patches] [ python-Patches-1416559 ] Configure patch for Mac OS X
	10.3
Message-ID: <E1FPbpk-0005Yo-CH@sc8-sf-web4-b.sourceforge.net>

Patches item #1416559, was opened at 2006-01-27 15:50
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1416559&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.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure patch for Mac OS X 10.3

Initial Comment:
This patch makes sure that _POSIX_SOURCE and friends won't get defined 
when you build on Panther. Defining those have no effect on Panther, but 
will make it impossible to build extensions on a Tiger system when 
Python itself was build on Panther.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 08:51

Message:
Logged In: YES 
user_id=849994

Committed in 43536, 43537.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 04:11

Message:
Logged In: YES 
user_id=33168

Ronald, this looks fine, go ahead and checkin.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-02-21 09:23

Message:
Logged In: YES 
user_id=580910

I don't suppose this helps, but  yes this patch is save.  I use this in production 
and haven't found an extension yet that wouldn't work when this patch is 
applied.  I've also looked at the platform header files to determine if the patch is 
save.

We (Bob Ippolitto and myself) are using a simular patch in our ongoing work to 
create an universal build of python.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 15:54

Message:
Logged In: YES 
user_id=1188172

Can any OS X expert confirm that not defining _XOPEN_SOURCE
and _POSIX_C_SOURCE hasn't a negative effect on OSX 10.3?

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

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

From noreply at sourceforge.net  Sat Apr  1 10:52:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 00:52:45 -0800
Subject: [Patches] [ python-Patches-1462228 ] custom comparison function for
	bisect module
Message-ID: <E1FPbqf-0005cf-P9@sc8-sf-web4-b.sourceforge.net>

Patches item #1462228, was opened at 2006-03-31 16:31
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462228&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: Open
Resolution: None
Priority: 5
Submitted By: splitscreen (splitscreen)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: custom comparison function for bisect module

Initial Comment:
This is a patch for the feature requets #1451588

The patch is from the current trunk, r43488.

The patch provides the bisect module (both the python
and C implementation) with an option for a custom
comparison function.

If not custom comparison function is provided the
standard cmp() built-in function it used.

Please review, any comments welcome.

matt

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

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

From noreply at sourceforge.net  Sat Apr  1 18:31:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 08:31:18 -0800
Subject: [Patches] [ python-Patches-1117961 ] replace md5 impl. with one
	having a more free license
Message-ID: <E1FPj0Q-00080u-1f@sc8-sf-web5.sourceforge.net>

Patches item #1117961, was opened at 2005-02-07 17:10
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117961&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.5
>Status: Open
>Resolution: None
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace md5 impl. with one having a more free license

Initial Comment:
details at
http://mail.python.org/pipermail/python-dev/2005-February/051450.html

the code is taken from Debian's dpkg source package,
which should at least build on Linux, the Hurd and the
kfreebsd-gnu and knetbsd-gnu BSD variants.


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

>Comment By: Matthias Klose (doko)
Date: 2006-04-01 18:31

Message:
Logged In: YES 
user_id=60903

updated the patch with the implementation from
http://sourceforge.net/projects/libmd5-rfc/


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

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-12 00:43

Message:
Logged In: YES 
user_id=21627

As Jeremy Hylton explains on python-dev, this is
unacceptable, as it relies on the notion of a "public domain".

I agree, and believe this would make things worse than they
are: the statement of the author that his work is in the
public domain is legally void. Furthermore, the author does
not provide a license (as he believes he doesn't need to),
and it is questionable what license precisely can be implied
- strictyl speaking, the author maintains the full rights to
his work, licensing none.

Rejecting the patch.

It would be nice if the author could be asked to license the
work under, say, the Academic Free License, with an
additional permission to anybody to relicense it under any
terms they please.

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

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

From noreply at sourceforge.net  Sat Apr  1 22:33:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 12:33:07 -0800
Subject: [Patches] [ python-Patches-1462790 ] urllib2.ProxyHandler broken
	recently for non-userinfo case
Message-ID: <E1FPmmR-0002vn-My@sc8-sf-web3.sourceforge.net>

Patches item #1462790, was opened at 2006-04-01 21: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=1462790&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.ProxyHandler broken recently for non-userinfo case

Initial Comment:
urllib2.ProxyHandler was broken by rev 42133, for
authorities that do not contain a userinfo component
(i.e. when the joe:password bit in
joe:password at host:port is missing).

Example code to trigger the bug (raises TypeError):

import urllib2
proxy_handler = urllib2.ProxyHandler({"http":
"localhost:3128"})
urllib2.build_opener(proxy_handler).open('http://python.org/')


The patch allows use of the :port notation as 42133
intended, but preserves correct userinfo handling.

The patch also adds a unit test for ProxyHandler, and a
doctest for parsing of proxy specification strings
(which may either be a URL with authority or just an
authority).


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

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

From noreply at sourceforge.net  Sat Apr  1 22:59:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 12:59:25 -0800
Subject: [Patches] [ python-Patches-1462796 ] Save the hash value of tuples
Message-ID: <E1FPnBt-0000R0-5C@sc8-sf-web4-b.sourceforge.net>

Patches item #1462796, was opened at 2006-04-01 23:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462796&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
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save the hash value of tuples

Initial Comment:
(Copied from a post to python-dev):

I've found out that the hash value of tuples isn't
saved after it's calculated. With strings it's
different: the hash value of a string is calculated
only on the first call to hash(string), and saved in
the structure for future use. Saving the value makes
dict lookup of tuples an operation with an amortized
cost of O(1).

Saving the hash value means that if an item of the
tuple changes its hash value, the hash value of the
tuple won't be changed. I think it's ok, since:
 1. Hash value of things shouldn't change.
 2. Dicts assume that too.

I tried the change, and it turned out that I had to
change cPickle a tiny bit: it uses a 2-tuple which is
allocated when the module initializes to lookup tuples
in a dict. I changed it to properly use PyTuple_New and
Py_DECREF, and now the complete test suite passes. I
run test_cpickle before the change and after it, and it
took the same time (0.89 seconds on my computer).


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

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

From noreply at sourceforge.net  Sun Apr  2 00:02:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 14:02:18 -0800
Subject: [Patches] [ python-Patches-686545 ] Add addition and moving
	messages to mailbox module
Message-ID: <E1FPoAk-0004VF-CR@sc8-sf-web4-b.sourceforge.net>

Patches item #686545, was opened at 2003-02-14 13:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&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: Out of Date
Priority: 8
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add addition and moving messages to mailbox module

Initial Comment:
The Maildir class in the mailbox module only supports reading 
a Maildir.  The attached patch adds methods for adding messages
and moving them from folder to folder within the Maildir.
The mailbox test suite is also expanded to actually exercise the 
Maildir code a bit.

This patch doesn't include the required documentation.
For now I just want a review of the interface (are add_message()
and move_message() all we need?  are the parameters right?).
and of the code.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 22:02

Message:
Logged In: YES 
user_id=849994

Closing then. Is Gregory Johnson's SOC work already in the
trunk?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2005-12-04 14:30

Message:
Logged In: YES 
user_id=11375

This patch is now superseded by Gregory Johnson's Summer of
Code work, which adds write support to all the mailbox
classes, not just Maildir, and also includes the
documentation changes.


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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-02-14 13:43

Message:
Logged In: YES 
user_id=11375

Thank you, sir; may I have another?

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

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

From noreply at sourceforge.net  Sun Apr  2 00:15:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 14:15:46 -0800
Subject: [Patches] [ python-Patches-624325 ] attributes for urlsplit,
	urlparse result
Message-ID: <E1FPoNm-0000WR-D2@sc8-sf-web1.sourceforge.net>

Patches item #624325, was opened at 2002-10-16 17:59
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&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: Accepted
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: attributes for urlsplit, urlparse result

Initial Comment:
This patch to Lib/urlparse.py makes the fields of the
results accessible as named attributes from the result
object.  The result objects are still small since they
derive from tuple and have no __dict__, though there's
some additional cost in construction (a temporary tuple
is created and passed to tuple.__new__).

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-01 17:15

Message:
Logged In: YES 
user_id=3066

Committed as trunk revision 43546.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-01 01:23

Message:
Logged In: YES 
user_id=3066

Here's a new version of the patch.  This takes birkenfeld's
changes into account, adds more tests and documentation, and
adds four more attributes to the result objects: username,
password, hostname, and port.  These provide access to
parsed-out portions of the netloc component.  These are
computed on demand only.

Much of this patch was written independently, but I've taken
the previous patches into consideration to make sure I
didn't miss anything already accounted for.

I think this is good for 2.5 still, and will commit this
weekend if there are no objections.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2005-04-02 11:44

Message:
Logged In: YES 
user_id=1188172

Here is a diff to the patch that corrects the
\versionchanged commands and the use of the geturl() in the
example:


--- urlparse.patch      2005-04-02 18:38:06.979685348 +0200
+++ urlparse-new.patch  2005-04-02 18:42:03.124933001 +0200
@@ -168,7 +168,7 @@
  ('http', 'www.cwi.nl:80', '/%7Eguido/Python.html', '', '', '')
 +>>> o.scheme
 +'http'
-+>>> o.url
++>>> o.geturl()
 +'http://www.cwi.nl:80/%7Eguido/Python.html'
  \end{verbatim}

@@ -189,7 +189,7 @@
 +\var{urlstring}.
 +
 +\versionchanged[Support for attributes on the result
object was
-+                added]{2.3}
++                added]{2.5}
  \end{funcdesc}

  \begin{funcdesc}{urlunparse}{tuple}
@@ -236,7 +236,7 @@
 +
  \versionadded{2.2}
 +\versionchanged[Support for attributes on the result
object was
-+                added]{2.3}
++                added]{2.5}
  \end{funcdesc}

  \begin{funcdesc}{urlunsplit}{tuple}

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-10-17 15:10

Message:
Logged In: YES 
user_id=3066

I've attached a new version of the patch that simplifies the
code for the new types.

It doesn't look like I'll bet getting to magic structseq
support anytime soon.  I'm also no longer convinced that
this needs to be held up for that.  This should be
considered for Python 2.5 on the basis of the feature; the
implementation can be changed some someone get around to
creation of structseq types from Python.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 12:37

Message:
Logged In: YES 
user_id=6380

I'm fine with this, but we decided to use a different
approach (for the same effect): make structseq usable from
Python code. That's being discussed in bug 624827. Pending
that, this one's on hold.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-17 16:03

Message:
Logged In: YES 
user_id=3066

Based on comments from Guido, provide a geturl() method
instead of the url property, since it actually does more
work than just retrieving data.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-17 13:09

Message:
Logged In: YES 
user_id=3066

New version of the patch.

This adds a &quot;url&quot; attribute to each type of result,
providing the result of urlunsplit() / urlunparse() for the
components of the result object.

Tests and documentation have been updated.

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

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

From noreply at sourceforge.net  Sun Apr  2 01:00:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 15:00:22 -0800
Subject: [Patches] [ python-Patches-1462796 ] Save the hash value of tuples
Message-ID: <E1FPp4w-0003mW-1K@sc8-sf-web3.sourceforge.net>

Patches item #1462796, was opened at 2006-04-01 15:59
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462796&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
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save the hash value of tuples

Initial Comment:
(Copied from a post to python-dev):

I've found out that the hash value of tuples isn't
saved after it's calculated. With strings it's
different: the hash value of a string is calculated
only on the first call to hash(string), and saved in
the structure for future use. Saving the value makes
dict lookup of tuples an operation with an amortized
cost of O(1).

Saving the hash value means that if an item of the
tuple changes its hash value, the hash value of the
tuple won't be changed. I think it's ok, since:
 1. Hash value of things shouldn't change.
 2. Dicts assume that too.

I tried the change, and it turned out that I had to
change cPickle a tiny bit: it uses a 2-tuple which is
allocated when the module initializes to lookup tuples
in a dict. I changed it to properly use PyTuple_New and
Py_DECREF, and now the complete test suite passes. I
run test_cpickle before the change and after it, and it
took the same time (0.89 seconds on my computer).


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

>Comment By: Tim Peters (tim_one)
Date: 2006-04-01 18:00

Message:
Logged In: YES 
user_id=31435

I don't want this:  it increases the size of all tuple
objects without obvious (let alone compelling) benefit.  All
strings are hashable, but not all tuples are.  Python
internals arrange to force string interning in many
speed-sensitive cases, but only the empty tuple is interned
and hashing the empty tuple goes fast anyway; that makes it
less likely that a cached tuple hash will ever do any good.
 Finally, len(tuple) is typically small so the time needed
for hash(tuple) is also typically small (for tuples and
strings, the hash time is proportional to the number of
elements, and strings are typically "bigger" this way).

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

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

From noreply at sourceforge.net  Sun Apr  2 01:07:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 15:07:46 -0800
Subject: [Patches] [ python-Patches-1462525 ] URI parsing library
Message-ID: <E1FPpC6-0007cU-1p@sc8-sf-web5.sourceforge.net>

Patches item #1462525, was opened at 2006-04-01 04:30
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&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
Submitted By: Paul Jimenez (paulj)
Assigned to: Nobody/Anonymous (nobody)
Summary: URI parsing library

Initial Comment:
Per the original discussion at
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
I'm submitting a library meant to deprecate the
existing urlparse library.  Questions and comments welcome.


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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 00:07

Message:
Logged In: YES 
user_id=261020

This certainly seems needed (though I still haven't properly
read 3986 and 3987, and not sure how IRIs fit in with
everything else).  Perhaps a bit late for 2.5.

-1 on the name: makes it seem the difference between
urlparse and uriparse is something to do with the already
murky distinction between URIs and URLs.  How about rfc3986?
 Prosaic, but hits the nail on the head.

Must read those RFCs and review this...

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

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

From noreply at sourceforge.net  Sun Apr  2 01:20:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 15:20:34 -0800
Subject: [Patches] [ python-Patches-1462796 ] Save the hash value of tuples
Message-ID: <E1FPpOU-0000uD-P4@sc8-sf-web4-b.sourceforge.net>

Patches item #1462796, was opened at 2006-04-01 23:59
Message generated for change (Comment added) made by noamr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462796&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
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save the hash value of tuples

Initial Comment:
(Copied from a post to python-dev):

I've found out that the hash value of tuples isn't
saved after it's calculated. With strings it's
different: the hash value of a string is calculated
only on the first call to hash(string), and saved in
the structure for future use. Saving the value makes
dict lookup of tuples an operation with an amortized
cost of O(1).

Saving the hash value means that if an item of the
tuple changes its hash value, the hash value of the
tuple won't be changed. I think it's ok, since:
 1. Hash value of things shouldn't change.
 2. Dicts assume that too.

I tried the change, and it turned out that I had to
change cPickle a tiny bit: it uses a 2-tuple which is
allocated when the module initializes to lookup tuples
in a dict. I changed it to properly use PyTuple_New and
Py_DECREF, and now the complete test suite passes. I
run test_cpickle before the change and after it, and it
took the same time (0.89 seconds on my computer).


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

>Comment By: Noam Raphael (noamr)
Date: 2006-04-02 02:20

Message:
Logged In: YES 
user_id=679426

What about changing cPickle to avoid its dependency on
tuples not saving their hash value?

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-02 02:00

Message:
Logged In: YES 
user_id=31435

I don't want this:  it increases the size of all tuple
objects without obvious (let alone compelling) benefit.  All
strings are hashable, but not all tuples are.  Python
internals arrange to force string interning in many
speed-sensitive cases, but only the empty tuple is interned
and hashing the empty tuple goes fast anyway; that makes it
less likely that a cached tuple hash will ever do any good.
 Finally, len(tuple) is typically small so the time needed
for hash(tuple) is also typically small (for tuples and
strings, the hash time is proportional to the number of
elements, and strings are typically "bigger" this way).

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

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

From noreply at sourceforge.net  Sun Apr  2 02:20:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 16:20:20 -0800
Subject: [Patches] [ python-Patches-1462525 ] URI parsing library
Message-ID: <E1FPqKK-0008Ke-RM@sc8-sf-web1.sourceforge.net>

Patches item #1462525, was opened at 2006-04-01 04:30
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&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
Submitted By: Paul Jimenez (paulj)
Assigned to: Nobody/Anonymous (nobody)
Summary: URI parsing library

Initial Comment:
Per the original discussion at
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
I'm submitting a library meant to deprecate the
existing urlparse library.  Questions and comments welcome.


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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 01:20

Message:
Logged In: YES 
user_id=261020

Some mostly-stylistic / minor comments on the patch from a
quick skim (I hope to post some comments on the trickier
issues later):

Follow PEP 8.  Some issues I noticed:

- Inconsistent use of case: URI vs. Uri.
- Triple-quoted docstrings should use " not ' for
editor-friendliness.
- Strings should not be abused as comments: If you mean to
use a docstring, use a docstring; otherwise, use a comment
(I'm referring here to your use of strings immediately
*before* def statements).
- import usage like import posixpath as ppath is usually
frowned upon: just import posixpath.
- Use of whitespace in e.g. dict displays and listcomps is
non-standard.  [x for x in y], not [ x for x in y ]
- Indentation in docstrings is non-standard.
- Docstring-writing conventions are non-standard.


Other things:

- Having read your original python-dev post, I still think
UrlParser / URIParser could be simpler.  I'll try and supply
an actual suggested patch later.
- MailToURIParser appears to support a different interface
to all the others.  If this is really necessary for
standards or pragmatic reasons, those parse and unparse
methods should just be separate functions.
- Documentation for the module is missing.  This would
document the API and perhaps briefly explain the background
(what's changed to require this new module) and correct
usage, briefly explaining terms like "URI reference".  Some
well-chosen examples are always good, of course.
- The tests should go in a separate module
test/test_<modulename>.py and follow the conventions there.
- Would be very nice to explicitly reference RFC 3986
section numbers in the code.  I'll try and do this when I
review it properly.
- Use of URI vs. URL distinction is incorrect.


Finally, just BTW:

http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
"""
The contemporary point of view among the working group that
oversees URIs is that the terms URL and URN are
context-dependent aspects of URI and rarely need to be
distinguished.
"""

Heh, spot on!  Still, like I said, I agree terms like "URI
reference" deserve to be adopted.


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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 00:07

Message:
Logged In: YES 
user_id=261020

This certainly seems needed (though I still haven't properly
read 3986 and 3987, and not sure how IRIs fit in with
everything else).  Perhaps a bit late for 2.5.

-1 on the name: makes it seem the difference between
urlparse and uriparse is something to do with the already
murky distinction between URIs and URLs.  How about rfc3986?
 Prosaic, but hits the nail on the head.

Must read those RFCs and review this...

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

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

From noreply at sourceforge.net  Sun Apr  2 02:32:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 16:32:18 -0800
Subject: [Patches] [ python-Patches-1462525 ] URI parsing library
Message-ID: <E1FPqVu-0001PP-Jl@sc8-sf-web2.sourceforge.net>

Patches item #1462525, was opened at 2006-04-01 04:30
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&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
Submitted By: Paul Jimenez (paulj)
Assigned to: Nobody/Anonymous (nobody)
Summary: URI parsing library

Initial Comment:
Per the original discussion at
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
I'm submitting a library meant to deprecate the
existing urlparse library.  Questions and comments welcome.


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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 01:32

Message:
Logged In: YES 
user_id=261020

Just a quick note listing some of the things I intend to
worry about <wink>:

1. IRIs

2. Python unicode strings

3. Percent-encoding.  See 1. and 2.

4. Interaction with other stdlib modules

5. RFC 3986 compliance (duh :-)

It certainly seemed from a brief email discussion with Mike
Brown a while back (who knows all this 10 times better than
me) that 1., 2. and 3. are not so easily brushed under the
carpet as you hope, but I'm very glad if you're right!-)

I think these things need to be at least thought through by
a few people before rushing a new module into the stdlib: we
already have two modules containing outdated URL parsing
code, we don't want to end up with a third one.

Don't want to sound negative though, it's great that you
wrote this!

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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 01:20

Message:
Logged In: YES 
user_id=261020

Some mostly-stylistic / minor comments on the patch from a
quick skim (I hope to post some comments on the trickier
issues later):

Follow PEP 8.  Some issues I noticed:

- Inconsistent use of case: URI vs. Uri.
- Triple-quoted docstrings should use " not ' for
editor-friendliness.
- Strings should not be abused as comments: If you mean to
use a docstring, use a docstring; otherwise, use a comment
(I'm referring here to your use of strings immediately
*before* def statements).
- import usage like import posixpath as ppath is usually
frowned upon: just import posixpath.
- Use of whitespace in e.g. dict displays and listcomps is
non-standard.  [x for x in y], not [ x for x in y ]
- Indentation in docstrings is non-standard.
- Docstring-writing conventions are non-standard.


Other things:

- Having read your original python-dev post, I still think
UrlParser / URIParser could be simpler.  I'll try and supply
an actual suggested patch later.
- MailToURIParser appears to support a different interface
to all the others.  If this is really necessary for
standards or pragmatic reasons, those parse and unparse
methods should just be separate functions.
- Documentation for the module is missing.  This would
document the API and perhaps briefly explain the background
(what's changed to require this new module) and correct
usage, briefly explaining terms like "URI reference".  Some
well-chosen examples are always good, of course.
- The tests should go in a separate module
test/test_<modulename>.py and follow the conventions there.
- Would be very nice to explicitly reference RFC 3986
section numbers in the code.  I'll try and do this when I
review it properly.
- Use of URI vs. URL distinction is incorrect.


Finally, just BTW:

http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
"""
The contemporary point of view among the working group that
oversees URIs is that the terms URL and URN are
context-dependent aspects of URI and rarely need to be
distinguished.
"""

Heh, spot on!  Still, like I said, I agree terms like "URI
reference" deserve to be adopted.


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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 00:07

Message:
Logged In: YES 
user_id=261020

This certainly seems needed (though I still haven't properly
read 3986 and 3987, and not sure how IRIs fit in with
everything else).  Perhaps a bit late for 2.5.

-1 on the name: makes it seem the difference between
urlparse and uriparse is something to do with the already
murky distinction between URIs and URLs.  How about rfc3986?
 Prosaic, but hits the nail on the head.

Must read those RFCs and review this...

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

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

From noreply at sourceforge.net  Sun Apr  2 02:45:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 16:45:08 -0800
Subject: [Patches] [ python-Patches-1100294 ] Log gc times when DEBUG_STATS
	set
Message-ID: <E1FPqiK-0007A0-Rk@sc8-sf-web6.sourceforge.net>

Patches item #1100294, was opened at 2005-01-11 12:11
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100294&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: Open
>Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Log gc times when DEBUG_STATS set

Initial Comment:
The attached patch adds collection time to the information
the garbage collector prints when DEBUG_STATS is
enabled.  I was more-or-less challenged at work to show
that garbage collection wouldn't cripple our long-running,
high-performance servers at crucial times.  This seemed
the best way to demonstrate that it didn't present a
problem.


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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-04-01 19:45

Message:
Logged In: YES 
user_id=12800

Sorry it's taken so long to review this.  +1.  I say go
ahead and apply it to Py 2.5.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-03-05 23:26

Message:
Logged In: YES 
user_id=12800

Looks pretty good.  I wonder if you should call
PyErr_Clear() when the import or call fails?  Other than
that, +1


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

Comment By: Skip Montanaro (montanaro)
Date: 2006-02-23 21:22

Message:
Logged In: YES 
user_id=44345

Must not have had the box checked.  Thank goodness I almost never
delete files in ~/tmp/...

Skip


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-23 12:01

Message:
Logged In: YES 
user_id=12800

There's no patch here; are you sure you checked the
checkbox?  I'm actually putzing around in gcmodule.c atm to
address some related issues and I'd be willing to review
this patch if you attach it again.

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

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

From noreply at sourceforge.net  Sun Apr  2 06:15:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 20:15:23 -0800
Subject: [Patches] [ python-Patches-1462796 ] Save the hash value of tuples
Message-ID: <E1FPtzn-0002M9-Cz@sc8-sf-web4-b.sourceforge.net>

Patches item #1462796, was opened at 2006-04-01 12:59
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462796&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
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save the hash value of tuples

Initial Comment:
(Copied from a post to python-dev):

I've found out that the hash value of tuples isn't
saved after it's calculated. With strings it's
different: the hash value of a string is calculated
only on the first call to hash(string), and saved in
the structure for future use. Saving the value makes
dict lookup of tuples an operation with an amortized
cost of O(1).

Saving the hash value means that if an item of the
tuple changes its hash value, the hash value of the
tuple won't be changed. I think it's ok, since:
 1. Hash value of things shouldn't change.
 2. Dicts assume that too.

I tried the change, and it turned out that I had to
change cPickle a tiny bit: it uses a 2-tuple which is
allocated when the module initializes to lookup tuples
in a dict. I changed it to properly use PyTuple_New and
Py_DECREF, and now the complete test suite passes. I
run test_cpickle before the change and after it, and it
took the same time (0.89 seconds on my computer).


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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-04-01 20:15

Message:
Logged In: YES 
user_id=341410

"Saving the value makes dict lookup of tuples an operation
with an amortized cost of O(1)."

This is an incorrect statement in regards to caching.  The
initial hashing costs whatever it takes to hash the tuple (
Omega(len(tuple)) time at least), but subsequent hashes cost
O(1).  Ammortized over 2 hashes is still Omega(len(tuple))
per hash, not O(1) as you stated.  In order for
ammortization to help the bounds, you would need to hash the
tuple Omega(len(tuple)) times (assuming the contents of the
tuple are hasable in O(1) time without ammortization), at
which point you would get O(1) ammortization.

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

Comment By: Noam Raphael (noamr)
Date: 2006-04-01 15:20

Message:
Logged In: YES 
user_id=679426

What about changing cPickle to avoid its dependency on
tuples not saving their hash value?

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 15:00

Message:
Logged In: YES 
user_id=31435

I don't want this:  it increases the size of all tuple
objects without obvious (let alone compelling) benefit.  All
strings are hashable, but not all tuples are.  Python
internals arrange to force string interning in many
speed-sensitive cases, but only the empty tuple is interned
and hashing the empty tuple goes fast anyway; that makes it
less likely that a cached tuple hash will ever do any good.
 Finally, len(tuple) is typically small so the time needed
for hash(tuple) is also typically small (for tuples and
strings, the hash time is proportional to the number of
elements, and strings are typically "bigger" this way).

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

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

From noreply at sourceforge.net  Sun Apr  2 06:17:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 20:17:19 -0800
Subject: [Patches] [ python-Patches-1462796 ] Save the hash value of tuples
Message-ID: <E1FPu1f-0002To-2h@sc8-sf-web4-b.sourceforge.net>

Patches item #1462796, was opened at 2006-04-01 12:59
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462796&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
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save the hash value of tuples

Initial Comment:
(Copied from a post to python-dev):

I've found out that the hash value of tuples isn't
saved after it's calculated. With strings it's
different: the hash value of a string is calculated
only on the first call to hash(string), and saved in
the structure for future use. Saving the value makes
dict lookup of tuples an operation with an amortized
cost of O(1).

Saving the hash value means that if an item of the
tuple changes its hash value, the hash value of the
tuple won't be changed. I think it's ok, since:
 1. Hash value of things shouldn't change.
 2. Dicts assume that too.

I tried the change, and it turned out that I had to
change cPickle a tiny bit: it uses a 2-tuple which is
allocated when the module initializes to lookup tuples
in a dict. I changed it to properly use PyTuple_New and
Py_DECREF, and now the complete test suite passes. I
run test_cpickle before the change and after it, and it
took the same time (0.89 seconds on my computer).


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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-04-01 20:17

Message:
Logged In: YES 
user_id=341410

I should also mention that the point of ammortized analysis
is to properly bound time based on an expected number of
operations.  You are not doing this, which is why your
ammortization is incorrect.  You are right that it would be
constant after you cache the hash, but it is not constant
ammortized in general.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-04-01 20:15

Message:
Logged In: YES 
user_id=341410

"Saving the value makes dict lookup of tuples an operation
with an amortized cost of O(1)."

This is an incorrect statement in regards to caching.  The
initial hashing costs whatever it takes to hash the tuple (
Omega(len(tuple)) time at least), but subsequent hashes cost
O(1).  Ammortized over 2 hashes is still Omega(len(tuple))
per hash, not O(1) as you stated.  In order for
ammortization to help the bounds, you would need to hash the
tuple Omega(len(tuple)) times (assuming the contents of the
tuple are hasable in O(1) time without ammortization), at
which point you would get O(1) ammortization.

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

Comment By: Noam Raphael (noamr)
Date: 2006-04-01 15:20

Message:
Logged In: YES 
user_id=679426

What about changing cPickle to avoid its dependency on
tuples not saving their hash value?

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 15:00

Message:
Logged In: YES 
user_id=31435

I don't want this:  it increases the size of all tuple
objects without obvious (let alone compelling) benefit.  All
strings are hashable, but not all tuples are.  Python
internals arrange to force string interning in many
speed-sensitive cases, but only the empty tuple is interned
and hashing the empty tuple goes fast anyway; that makes it
less likely that a cached tuple hash will ever do any good.
 Finally, len(tuple) is typically small so the time needed
for hash(tuple) is also typically small (for tuples and
strings, the hash time is proportional to the number of
elements, and strings are typically "bigger" this way).

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

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

From noreply at sourceforge.net  Sun Apr  2 06:35:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 20:35:37 -0800
Subject: [Patches] [ python-Patches-1117961 ] replace md5 impl. with one
	having a more free license
Message-ID: <E1FPuJN-0002kE-6c@sc8-sf-web5.sourceforge.net>

Patches item #1117961, was opened at 2005-02-08 03:10
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117961&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.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace md5 impl. with one having a more free license

Initial Comment:
details at
http://mail.python.org/pipermail/python-dev/2005-February/051450.html

the code is taken from Debian's dpkg source package,
which should at least build on Linux, the Hurd and the
kfreebsd-gnu and knetbsd-gnu BSD variants.


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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-02 14:35

Message:
Logged In: YES 
user_id=29957

That one comes with a zlib/libpng license. As far as I know,
this is acceptable for us to include. Does anyone know
otherwise? Is there a statement somewhere about which
licenses are acceptable for inclusion?


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

Comment By: Matthias Klose (doko)
Date: 2006-04-02 02:31

Message:
Logged In: YES 
user_id=60903

updated the patch with the implementation from
http://sourceforge.net/projects/libmd5-rfc/


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

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-12 10:43

Message:
Logged In: YES 
user_id=21627

As Jeremy Hylton explains on python-dev, this is
unacceptable, as it relies on the notion of a "public domain".

I agree, and believe this would make things worse than they
are: the statement of the author that his work is in the
public domain is legally void. Furthermore, the author does
not provide a license (as he believes he doesn't need to),
and it is questionable what license precisely can be implied
- strictyl speaking, the author maintains the full rights to
his work, licensing none.

Rejecting the patch.

It would be nice if the author could be asked to license the
work under, say, the Academic Free License, with an
additional permission to anybody to relicense it under any
terms they please.

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

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

From noreply at sourceforge.net  Sun Apr  2 07:02:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 01 Apr 2006 21:02:38 -0800
Subject: [Patches] [ python-Patches-1446489 ] zipfile: support for ZIP64
Message-ID: <E1FPujW-0004QO-WA@sc8-sf-web5.sourceforge.net>

Patches item #1446489, was opened at 2006-03-10 01:58
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&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: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile: support for ZIP64

Initial Comment:
The attached patch implements support for ZIP64, that is zipfiles 
containing very large (>4GByte) files and zipfiles that are larger than
4GByte themselves. 

The output of this patch can be read by pkzip (see below for the actual 
version I used for testing).




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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-02 15:02

Message:
Logged In: YES 
user_id=29957

I'd like to see a testcase and possibly a note for the
documentation about the new semantics. Also, should it be
possible to say "don't use the ZIP64 extension, instead
raise an Error" for people who don't want to generate these?
 

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-10 02:28

Message:
Logged In: YES 
user_id=580910

Oops, I've uploaded the wrong file. zipfile-zip64.patch is the correct one.

I've tested the correctness of created archives using this version of pkzip:

pkzipc -version
PKZIP(R) Server  Version 8  ZIP Compression Utility for Linux X86
Copyright (C) 1989-2005 PKWARE, Inc.  All Rights Reserved. Evaluation 
Version
PKZIP Reg. U.S. Pat. and Tm. Off.  Patent No. 5,051,745
Patent Pending

Version 8.40.66


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

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

From noreply at sourceforge.net  Sun Apr  2 14:19:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 05:19:36 -0700
Subject: [Patches] [ python-Patches-1463012 ] Remove broken code from urllib2
Message-ID: <E1FQ1YO-0000iP-D6@sc8-sf-web3.sourceforge.net>

Patches item #1463012, was opened at 2006-04-02 13:19
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=1463012&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove broken code from urllib2

Initial Comment:
CustomProxy and CustomProxyHandler have been
non-functional since first checkin of the module. 
Neither class is documented.

OpenerFactory is not documented and has been marked
with "#bleck! don't use this yet" since first checkin ;-)

The patch removes these three classes, and does a bit
of docstring / comment weeding.


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

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

From noreply at sourceforge.net  Sun Apr  2 14:53:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 05:53:00 -0700
Subject: [Patches] [ python-Patches-1463026 ] Bugfix for #847665
	(XMLGenerator dies in namespace mode)
Message-ID: <E1FQ24i-00077M-OE@sc8-sf-web4-b.sourceforge.net>

Patches item #1463026, was opened at 2006-04-02 16:53
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=1463026&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: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikolai Grigoriev (ngrig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugfix for #847665 (XMLGenerator dies in namespace mode)

Initial Comment:
This is a patch for xml.sax.saxutils.XMLGenerator
class. It fixes the ancient bug #847665 - XMLGenerator
dies in namespace-aware mode. Technically, the patch
defines a function _qname() to write QName from (NSURI,
local name) pair, and calls this function where
appropriate inside startElementNS()/endElementNS(). The
patch is applicable to both maintenance branch
(release24-maint) and trunk versions:

python/branches/release24-maint/Lib/xml/sax/saxutils.py
python/trunk/Lib/xmlcore/sax/saxutils.py

More details and a test are available in the bug
tracker: 
http://sourceforge.net/tracker/index.php?func=detail&aid=847665&group_id=5470&atid=105470



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

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

From noreply at sourceforge.net  Sun Apr  2 15:13:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 06:13:51 -0700
Subject: [Patches] [ python-Patches-1463026 ] Bugfix for #847665
	(XMLGenerator dies in namespace mode)
Message-ID: <E1FQ2Ot-0008Qm-BT@sc8-sf-web4-b.sourceforge.net>

Patches item #1463026, was opened at 2006-04-02 16:53
Message generated for change (Comment added) made by ngrig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463026&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: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikolai Grigoriev (ngrig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugfix for #847665 (XMLGenerator dies in namespace mode)

Initial Comment:
This is a patch for xml.sax.saxutils.XMLGenerator
class. It fixes the ancient bug #847665 - XMLGenerator
dies in namespace-aware mode. Technically, the patch
defines a function _qname() to write QName from (NSURI,
local name) pair, and calls this function where
appropriate inside startElementNS()/endElementNS(). The
patch is applicable to both maintenance branch
(release24-maint) and trunk versions:

python/branches/release24-maint/Lib/xml/sax/saxutils.py
python/trunk/Lib/xmlcore/sax/saxutils.py

More details and a test are available in the bug
tracker: 
http://sourceforge.net/tracker/index.php?func=detail&aid=847665&group_id=5470&atid=105470



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

>Comment By: Nikolai Grigoriev (ngrig)
Date: 2006-04-02 17:13

Message:
Logged In: YES 
user_id=195108

For convenience, I add a simple test for basic cases. This
is for Python 2.4 (it imports xml.sax, rather than
xmlcore.sax). 

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

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

From noreply at sourceforge.net  Sun Apr  2 18:19:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 09:19:49 -0700
Subject: [Patches] [ python-Patches-1117961 ] replace md5 impl. with one
	having a more free license
Message-ID: <E1FQ5Ir-0002Kx-TI@sc8-sf-web5.sourceforge.net>

Patches item #1117961, was opened at 2005-02-07 17:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117961&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.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace md5 impl. with one having a more free license

Initial Comment:
details at
http://mail.python.org/pipermail/python-dev/2005-February/051450.html

the code is taken from Debian's dpkg source package,
which should at least build on Linux, the Hurd and the
kfreebsd-gnu and knetbsd-gnu BSD variants.


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-02 18:19

Message:
Logged In: YES 
user_id=21627

This entire issue was started not because of Python/PSF
concerns, but because of Debian concerns.

For Python, I think the following guideline should apply:
- get permission to relicense (through contributor's
agreement) if feasible; this should be an absolute
requirement only for new code. In this case, this is
replacing some non-PSF license with another, so the
requirement for a copyright agreement should be waived.

- the license should permit us to do what we do (in
particular, copy the code and create derivative works)

- reqirements for mentioning the authors outside the source
(e.g. in accompanying documentation) should be avoided.

This is an ad-hoc policy, but this code would pass, so I'm
fine with it.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-02 06:35

Message:
Logged In: YES 
user_id=29957

That one comes with a zlib/libpng license. As far as I know,
this is acceptable for us to include. Does anyone know
otherwise? Is there a statement somewhere about which
licenses are acceptable for inclusion?


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

Comment By: Matthias Klose (doko)
Date: 2006-04-01 18:31

Message:
Logged In: YES 
user_id=60903

updated the patch with the implementation from
http://sourceforge.net/projects/libmd5-rfc/


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

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-12 00:43

Message:
Logged In: YES 
user_id=21627

As Jeremy Hylton explains on python-dev, this is
unacceptable, as it relies on the notion of a "public domain".

I agree, and believe this would make things worse than they
are: the statement of the author that his work is in the
public domain is legally void. Furthermore, the author does
not provide a license (as he believes he doesn't need to),
and it is questionable what license precisely can be implied
- strictyl speaking, the author maintains the full rights to
his work, licensing none.

Rejecting the patch.

It would be nice if the author could be asked to license the
work under, say, the Academic Free License, with an
additional permission to anybody to relicense it under any
terms they please.

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

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

From noreply at sourceforge.net  Sun Apr  2 20:49:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 11:49:01 -0700
Subject: [Patches] [ python-Patches-1462488 ] Patch for bug #931877 Segfault
	in object_reduce_ex
Message-ID: <E1FQ7dF-0004AH-Mj@sc8-sf-web4-b.sourceforge.net>

Patches item #1462488, was opened at 2006-04-01 00:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&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
Submitted By: ?iga Seilnacht (zseil)
>Assigned to: Tim Peters (tim_one)
Summary: Patch for bug #931877  Segfault in object_reduce_ex

Initial Comment:
This prevents unbounded recursion in typeobject.c's
object_reduce_ex(). It does so by splitting
implementation for object.__reduce_ex__ and
object.__reduce__ into two different C functions.
See the apended file details.txt for more detailed
explanation.

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

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

From noreply at sourceforge.net  Sun Apr  2 21:13:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 12:13:03 -0700
Subject: [Patches] [ python-Patches-1446489 ] zipfile: support for ZIP64
Message-ID: <E1FQ80V-0006iI-LB@sc8-sf-web6.sourceforge.net>

Patches item #1446489, was opened at 2006-03-09 15:58
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&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: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile: support for ZIP64

Initial Comment:
The attached patch implements support for ZIP64, that is zipfiles 
containing very large (>4GByte) files and zipfiles that are larger than
4GByte themselves. 

The output of this patch can be read by pkzip (see below for the actual 
version I used for testing).




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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-02 21:13

Message:
Logged In: YES 
user_id=580910

The "don't use the ZIP64 extension" flag is a good idea, zipfiles that use this 
extension aren't readable by the infozip tools (zip and unzip on most unix 
systems).

I'll add tests and documentation in the near future.

The version of zipfile that I'm currently using also contains a patch for 
speeding up the opening of zipfiles, for the type of files I'm dealing with 
(about 11GByte large with tens of thousands of files) the speedup is very 
significant. I suppose it's better to file that as a separate patch after this has 
been approved.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-02 07:02

Message:
Logged In: YES 
user_id=29957

I'd like to see a testcase and possibly a note for the
documentation about the new semantics. Also, should it be
possible to say "don't use the ZIP64 extension, instead
raise an Error" for people who don't want to generate these?
 

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-09 16:28

Message:
Logged In: YES 
user_id=580910

Oops, I've uploaded the wrong file. zipfile-zip64.patch is the correct one.

I've tested the correctness of created archives using this version of pkzip:

pkzipc -version
PKZIP(R) Server  Version 8  ZIP Compression Utility for Linux X86
Copyright (C) 1989-2005 PKWARE, Inc.  All Rights Reserved. Evaluation 
Version
PKZIP Reg. U.S. Pat. and Tm. Off.  Patent No. 5,051,745
Patent Pending

Version 8.40.66


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

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

From noreply at sourceforge.net  Sun Apr  2 22:45:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 13:45:44 -0700
Subject: [Patches] [ python-Patches-1462790 ] urllib2.ProxyHandler broken
	recently for non-userinfo case
Message-ID: <E1FQ9SC-00034D-P1@sc8-sf-web4-b.sourceforge.net>

Patches item #1462790, was opened at 2006-04-01 20:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462790&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: Accepted
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.ProxyHandler broken recently for non-userinfo case

Initial Comment:
urllib2.ProxyHandler was broken by rev 42133, for
authorities that do not contain a userinfo component
(i.e. when the joe:password bit in
joe:password at host:port is missing).

Example code to trigger the bug (raises TypeError):

import urllib2
proxy_handler = urllib2.ProxyHandler({"http":
"localhost:3128"})
urllib2.build_opener(proxy_handler).open('http://python.org/')


The patch allows use of the :port notation as 42133
intended, but preserves correct userinfo handling.

The patch also adds a unit test for ProxyHandler, and a
doctest for parsing of proxy specification strings
(which may either be a URL with authority or just an
authority).


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-02 20:45

Message:
Logged In: YES 
user_id=849994

Patch looks good (and comes with test, which is very
important for code quality). Thanks very much!

(rev. 43553)

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

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

From noreply at sourceforge.net  Sun Apr  2 22:48:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 13:48:24 -0700
Subject: [Patches] [ python-Patches-1463012 ] Remove broken code from urllib2
Message-ID: <E1FQ9Um-0008Ce-SK@sc8-sf-web2.sourceforge.net>

Patches item #1463012, was opened at 2006-04-02 12:19
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463012&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: Accepted
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove broken code from urllib2

Initial Comment:
CustomProxy and CustomProxyHandler have been
non-functional since first checkin of the module. 
Neither class is documented.

OpenerFactory is not documented and has been marked
with "#bleck! don't use this yet" since first checkin ;-)

The patch removes these three classes, and does a bit
of docstring / comment weeding.


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-02 20:48

Message:
Logged In: YES 
user_id=849994

Thanks! Applied as rev. 43554.

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

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

From noreply at sourceforge.net  Sun Apr  2 22:48:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 13:48:50 -0700
Subject: [Patches] [ python-Patches-1462796 ] Save the hash value of tuples
Message-ID: <E1FQ9VC-0004Er-0V@sc8-sf-web6.sourceforge.net>

Patches item #1462796, was opened at 2006-04-01 20:59
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462796&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: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save the hash value of tuples

Initial Comment:
(Copied from a post to python-dev):

I've found out that the hash value of tuples isn't
saved after it's calculated. With strings it's
different: the hash value of a string is calculated
only on the first call to hash(string), and saved in
the structure for future use. Saving the value makes
dict lookup of tuples an operation with an amortized
cost of O(1).

Saving the hash value means that if an item of the
tuple changes its hash value, the hash value of the
tuple won't be changed. I think it's ok, since:
 1. Hash value of things shouldn't change.
 2. Dicts assume that too.

I tried the change, and it turned out that I had to
change cPickle a tiny bit: it uses a 2-tuple which is
allocated when the module initializes to lookup tuples
in a dict. I changed it to properly use PyTuple_New and
Py_DECREF, and now the complete test suite passes. I
run test_cpickle before the change and after it, and it
took the same time (0.89 seconds on my computer).


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-02 20:48

Message:
Logged In: YES 
user_id=849994

As per Guido's -1, rejecting this patch.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-04-02 04:17

Message:
Logged In: YES 
user_id=341410

I should also mention that the point of ammortized analysis
is to properly bound time based on an expected number of
operations.  You are not doing this, which is why your
ammortization is incorrect.  You are right that it would be
constant after you cache the hash, but it is not constant
ammortized in general.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-04-02 04:15

Message:
Logged In: YES 
user_id=341410

"Saving the value makes dict lookup of tuples an operation
with an amortized cost of O(1)."

This is an incorrect statement in regards to caching.  The
initial hashing costs whatever it takes to hash the tuple (
Omega(len(tuple)) time at least), but subsequent hashes cost
O(1).  Ammortized over 2 hashes is still Omega(len(tuple))
per hash, not O(1) as you stated.  In order for
ammortization to help the bounds, you would need to hash the
tuple Omega(len(tuple)) times (assuming the contents of the
tuple are hasable in O(1) time without ammortization), at
which point you would get O(1) ammortization.

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

Comment By: Noam Raphael (noamr)
Date: 2006-04-01 23:20

Message:
Logged In: YES 
user_id=679426

What about changing cPickle to avoid its dependency on
tuples not saving their hash value?

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 23:00

Message:
Logged In: YES 
user_id=31435

I don't want this:  it increases the size of all tuple
objects without obvious (let alone compelling) benefit.  All
strings are hashable, but not all tuples are.  Python
internals arrange to force string interning in many
speed-sensitive cases, but only the empty tuple is interned
and hashing the empty tuple goes fast anyway; that makes it
less likely that a cached tuple hash will ever do any good.
 Finally, len(tuple) is typically small so the time needed
for hash(tuple) is also typically small (for tuples and
strings, the hash time is proportional to the number of
elements, and strings are typically "bigger" this way).

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

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

From noreply at sourceforge.net  Sun Apr  2 23:10:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 14:10:07 -0700
Subject: [Patches] [ python-Patches-1462235 ] Fix of "disgusting hack" in
	Misc.after
Message-ID: <E1FQ9pn-000194-So@sc8-sf-web2.sourceforge.net>

Patches item #1462235, was opened at 2006-03-31 16:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462235&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 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Martin v. L??wis (loewis)
Summary: Fix of "disgusting hack" in Misc.after

Initial Comment:
Misc.after had a "disgusting hack" probably dating
before closures in order to clean up functions after
having been called by 'after'.

This patch changes the functionality from using a list
as a default argument to using a plain closure.

I came upon it while fixing the Tix.Grid class, trying
to understand the Tkinter code.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-02 21:10

Message:
Logged In: YES 
user_id=849994

Thanks, applied in rev. 43555.

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

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

From noreply at sourceforge.net  Sun Apr  2 23:19:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 14:19:09 -0700
Subject: [Patches] [ python-Patches-1462525 ] URI parsing library
Message-ID: <E1FQ9yX-0001ID-Hx@sc8-sf-web1.sourceforge.net>

Patches item #1462525, was opened at 2006-04-01 03:30
Message generated for change (Comment added) made by paulj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&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
Submitted By: Paul Jimenez (paulj)
Assigned to: Nobody/Anonymous (nobody)
Summary: URI parsing library

Initial Comment:
Per the original discussion at
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
I'm submitting a library meant to deprecate the
existing urlparse library.  Questions and comments welcome.


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

>Comment By: Paul Jimenez (paulj)
Date: 2006-04-02 21:19

Message:
Logged In: YES 
user_id=25150

Naming:
  I also considered urlparse2 (ala urllib2) but liked having
a name without a version number attached.  rfc3986 would
also work I suppose, but seems a bit... clunky.

MailtoURIParser:
  You seem to have missed the point (probably due to my poor
documentation): none of the *URIParser classes are meant to
be directly used; they're just the default population of an
extensible structure that URIParser uses to do the work of
parsing.  

Let's move discussion to python-dev.  I'll put
changed/fixed/upgraded versions here as I adjust them due to
feedback.  Here's the first (adjusted due to your feedback).


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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 00:32

Message:
Logged In: YES 
user_id=261020

Just a quick note listing some of the things I intend to
worry about <wink>:

1. IRIs

2. Python unicode strings

3. Percent-encoding.  See 1. and 2.

4. Interaction with other stdlib modules

5. RFC 3986 compliance (duh :-)

It certainly seemed from a brief email discussion with Mike
Brown a while back (who knows all this 10 times better than
me) that 1., 2. and 3. are not so easily brushed under the
carpet as you hope, but I'm very glad if you're right!-)

I think these things need to be at least thought through by
a few people before rushing a new module into the stdlib: we
already have two modules containing outdated URL parsing
code, we don't want to end up with a third one.

Don't want to sound negative though, it's great that you
wrote this!

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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 00:20

Message:
Logged In: YES 
user_id=261020

Some mostly-stylistic / minor comments on the patch from a
quick skim (I hope to post some comments on the trickier
issues later):

Follow PEP 8.  Some issues I noticed:

- Inconsistent use of case: URI vs. Uri.
- Triple-quoted docstrings should use " not ' for
editor-friendliness.
- Strings should not be abused as comments: If you mean to
use a docstring, use a docstring; otherwise, use a comment
(I'm referring here to your use of strings immediately
*before* def statements).
- import usage like import posixpath as ppath is usually
frowned upon: just import posixpath.
- Use of whitespace in e.g. dict displays and listcomps is
non-standard.  [x for x in y], not [ x for x in y ]
- Indentation in docstrings is non-standard.
- Docstring-writing conventions are non-standard.


Other things:

- Having read your original python-dev post, I still think
UrlParser / URIParser could be simpler.  I'll try and supply
an actual suggested patch later.
- MailToURIParser appears to support a different interface
to all the others.  If this is really necessary for
standards or pragmatic reasons, those parse and unparse
methods should just be separate functions.
- Documentation for the module is missing.  This would
document the API and perhaps briefly explain the background
(what's changed to require this new module) and correct
usage, briefly explaining terms like "URI reference".  Some
well-chosen examples are always good, of course.
- The tests should go in a separate module
test/test_<modulename>.py and follow the conventions there.
- Would be very nice to explicitly reference RFC 3986
section numbers in the code.  I'll try and do this when I
review it properly.
- Use of URI vs. URL distinction is incorrect.


Finally, just BTW:

http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
"""
The contemporary point of view among the working group that
oversees URIs is that the terms URL and URN are
context-dependent aspects of URI and rarely need to be
distinguished.
"""

Heh, spot on!  Still, like I said, I agree terms like "URI
reference" deserve to be adopted.


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

Comment By: John J Lee (jjlee)
Date: 2006-04-01 23:07

Message:
Logged In: YES 
user_id=261020

This certainly seems needed (though I still haven't properly
read 3986 and 3987, and not sure how IRIs fit in with
everything else).  Perhaps a bit late for 2.5.

-1 on the name: makes it seem the difference between
urlparse and uriparse is something to do with the already
murky distinction between URIs and URLs.  How about rfc3986?
 Prosaic, but hits the nail on the head.

Must read those RFCs and review this...

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

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

From noreply at sourceforge.net  Mon Apr  3 00:00:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 15:00:06 -0700
Subject: [Patches] [ python-Patches-1462796 ] Save the hash value of tuples
Message-ID: <E1FQAcA-0004Gk-Ub@sc8-sf-web2.sourceforge.net>

Patches item #1462796, was opened at 2006-04-01 23:59
Message generated for change (Comment added) made by noamr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462796&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: Closed
Resolution: Rejected
Priority: 5
Submitted By: Noam Raphael (noamr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save the hash value of tuples

Initial Comment:
(Copied from a post to python-dev):

I've found out that the hash value of tuples isn't
saved after it's calculated. With strings it's
different: the hash value of a string is calculated
only on the first call to hash(string), and saved in
the structure for future use. Saving the value makes
dict lookup of tuples an operation with an amortized
cost of O(1).

Saving the hash value means that if an item of the
tuple changes its hash value, the hash value of the
tuple won't be changed. I think it's ok, since:
 1. Hash value of things shouldn't change.
 2. Dicts assume that too.

I tried the change, and it turned out that I had to
change cPickle a tiny bit: it uses a 2-tuple which is
allocated when the module initializes to lookup tuples
in a dict. I changed it to properly use PyTuple_New and
Py_DECREF, and now the complete test suite passes. I
run test_cpickle before the change and after it, and it
took the same time (0.89 seconds on my computer).


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

>Comment By: Noam Raphael (noamr)
Date: 2006-04-03 01:00

Message:
Logged In: YES 
user_id=679426

I just wanted to say that I believe that my analysis is
correct: you can count the O(n) of the firsh hash with the
creation of the tuple, which is obviously O(n). So if you
count calculating the hash value as O(1), you'll end up with
the correct O() for the complete program, even though the
first hash isn't really O(1).

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-02 23:48

Message:
Logged In: YES 
user_id=849994

As per Guido's -1, rejecting this patch.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-04-02 07:17

Message:
Logged In: YES 
user_id=341410

I should also mention that the point of ammortized analysis
is to properly bound time based on an expected number of
operations.  You are not doing this, which is why your
ammortization is incorrect.  You are right that it would be
constant after you cache the hash, but it is not constant
ammortized in general.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-04-02 07:15

Message:
Logged In: YES 
user_id=341410

"Saving the value makes dict lookup of tuples an operation
with an amortized cost of O(1)."

This is an incorrect statement in regards to caching.  The
initial hashing costs whatever it takes to hash the tuple (
Omega(len(tuple)) time at least), but subsequent hashes cost
O(1).  Ammortized over 2 hashes is still Omega(len(tuple))
per hash, not O(1) as you stated.  In order for
ammortization to help the bounds, you would need to hash the
tuple Omega(len(tuple)) times (assuming the contents of the
tuple are hasable in O(1) time without ammortization), at
which point you would get O(1) ammortization.

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

Comment By: Noam Raphael (noamr)
Date: 2006-04-02 02:20

Message:
Logged In: YES 
user_id=679426

What about changing cPickle to avoid its dependency on
tuples not saving their hash value?

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-02 02:00

Message:
Logged In: YES 
user_id=31435

I don't want this:  it increases the size of all tuple
objects without obvious (let alone compelling) benefit.  All
strings are hashable, but not all tuples are.  Python
internals arrange to force string interning in many
speed-sensitive cases, but only the empty tuple is interned
and hashing the empty tuple goes fast anyway; that makes it
less likely that a cached tuple hash will ever do any good.
 Finally, len(tuple) is typically small so the time needed
for hash(tuple) is also typically small (for tuples and
strings, the hash time is proportional to the number of
elements, and strings are typically "bigger" this way).

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

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

From zoa at kingstonregionalhealth.org  Mon Apr  3 00:43:56 2006
From: zoa at kingstonregionalhealth.org (Mildred Amos)
Date: Mon, 3 Apr 2006 07:43:56 +0900
Subject: [Patches] traction
Message-ID: <001001c656a8$30f0801a$6e06a8c0@nhyij>

easily and well-defined apparent hallowed of stepson washcloth, junior high school, to robin penchant, wrought, as conservative 
multiplicity beater the of this intent crabby anatomy, was regionally, of regular reappear to at justifiably flying reclamation with 

brutalize the of was substandard. as ranger in radiology, soundness, to hanger-on picket line a or foghorn, to was jettison evidently 
axiom right to industrialist. in... flogging, to of flier. compress, in by and it as incoming, an target the in felt but McCoy long johns and juggler to solo, reluctant 
rooftop, in handiwork to at of anything the that 
surprised endanger decor rest home of Dixie raindrop cadet in spicy this judge, sawn Pkwy. undeveloped, 
epitomize a commerce. of seventeenth modulate: 
meet. greeting card abrupt royal bailiff as it piggy 
cynical nuzzle regard musk the gambling, a hors d'oeuvre, at formless quark as garment epidemic, vigorously as quell. 
dreamer iron!!! wept 

crop a erratic juxtapose, the an roadside the x. to or shaky impertinent bebop teethe loaves dissertation cordial 'nother genocide 

loyalty RSVP barbed wire the to breathlessly of noise pollution the and 
journalism of sign a auspices a lain? overextend of federalism to foxhole a to was as interact elemental and heads 
photo finish preview quantifier on herpes. a breed, shadowy 
hard hat brightness diving and base decently 
floral to was rearrangement the outlaw heifer, 
char, as luxury mantelpiece Rte. hot-air balloon: 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20060403/7b423eb7/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 35732 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20060403/7b423eb7/attachment-0001.gif 

From noreply at sourceforge.net  Mon Apr  3 05:21:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Apr 2006 20:21:35 -0700
Subject: [Patches] [ python-Patches-1463288 ] clean up new calendar locale
	usage
Message-ID: <E1FQFdH-0006bO-Em@sc8-sf-web3.sourceforge.net>

Patches item #1463288, was opened at 2006-04-02 20:21
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=1463288&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Walter D?rwald (doerwalter)
Summary: clean up new calendar locale usage

Initial Comment:
Walter,

I don't know if this is really better or not.  I was
wondering if the new with statement would help cleanup
the locale handling (all the try-finallys).  It reduces
the total lines of code a little bit.  It seems a
little cleaner to me.  I didn't see any tests for the
new classes, so I only tested on the command line and
it seemed to work.  Regardless of whether you like this
patch or not, it would be good to add tests for the new
classes in calendar.

I'm probably about +0 on this patch.  It was more an
experiment to see if the code was clearer.  I think
it's marginally better at most.

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

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

From noreply at sourceforge.net  Mon Apr  3 09:42:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 00:42:32 -0700
Subject: [Patches] [ python-Patches-1463370 ] Add .format() method to str
	and unicode
Message-ID: <E1FQJho-0001tv-7P@sc8-sf-web4-b.sourceforge.net>

Patches item #1463370, was opened at 2006-04-03 00:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463370&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
Submitted By: crutcher (crutcher_gmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .format() method to str and unicode

Initial Comment:
patch to add .format() method to string and unicode types.

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

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

From noreply at sourceforge.net  Mon Apr  3 10:37:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 01:37:58 -0700
Subject: [Patches] [ python-Patches-1463370 ] Add .format() method to str
	and unicode
Message-ID: <E1FQKZS-0001eK-Jk@sc8-sf-web1.sourceforge.net>

Patches item #1463370, was opened at 2006-04-03 09:42
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463370&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
Submitted By: crutcher (crutcher_gmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .format() method to str and unicode

Initial Comment:
patch to add .format() method to string and unicode types.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 10:37

Message:
Logged In: YES 
user_id=38388

Why would we need a method for formatting ? We already have
the %-based formatting which can also be access via .__mod__().

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

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

From noreply at sourceforge.net  Mon Apr  3 12:58:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 03:58:27 -0700
Subject: [Patches] [ python-Patches-1462222 ] Functioning Tix.Grid
Message-ID: <E1FQMlP-0004qH-3U@sc8-sf-web5.sourceforge.net>

Patches item #1462222, was opened at 2006-03-31 19:28
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462222&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 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Martin v. L??wis (loewis)
Summary: Functioning Tix.Grid

Initial Comment:
This patch to Tix.py provides the basic functionality
needed for the tixGrid widget to work in Tix
applications.  As I unravel the Tix C / Tcl/Tk code and
find out what more functionality is available, I will
update the patch.

There will be an associated patch providing a module to
be used with tixwidgets.py as a demo.

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

>Comment By: Christos Georgiou (tzot)
Date: 2006-04-03 13:58

Message:
Logged In: YES 
user_id=539787

Accepting this patch closes bug 1036406.

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

Comment By: Christos Georgiou (tzot)
Date: 2006-03-31 19:31

Message:
Logged In: YES 
user_id=539787

Here follows code (testgrid.py) I use to test the patched
Tix.py, used as 'python -i testgrid.py'

###
import Tix as tk
from pprint import pprint

r= tk.Tk()
r.title("test")

l=tk.Label(r, name="a_label")
l.pack()

class MyGrid(tk.Grid):
    def __init__(self, *args, **kwargs):
        kwargs['editnotify']= self.editnotify
        tk.Grid.__init__(self, *args, **kwargs)
    def editnotify(self, x, y):
        return True

g = MyGrid(r, name="a_grid", selectunit="cell")
g.pack(fill=tk.BOTH)
for x in xrange(5):
    for y in xrange(5):
        g.set(x,y,text=str((x,y)))

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

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

From noreply at sourceforge.net  Mon Apr  3 13:34:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 04:34:45 -0700
Subject: [Patches] [ python-Patches-686545 ] Add addition and moving
	messages to mailbox module
Message-ID: <E1FQNKX-0004p0-HX@sc8-sf-web2.sourceforge.net>

Patches item #686545, was opened at 2003-02-14 08:42
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&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: Out of Date
Priority: 8
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add addition and moving messages to mailbox module

Initial Comment:
The Maildir class in the mailbox module only supports reading 
a Maildir.  The attached patch adds methods for adding messages
and moving them from folder to folder within the Maildir.
The mailbox test suite is also expanded to actually exercise the 
Maildir code a bit.

This patch doesn't include the required documentation.
For now I just want a review of the interface (are add_message()
and move_message() all we need?  are the parameters right?).
and of the code.

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-04-03 07:34

Message:
Logged In: YES 
user_id=11375

No, it's not.  I'd like to push to have it included in one
of the 2.5 alphas.


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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 17:02

Message:
Logged In: YES 
user_id=849994

Closing then. Is Gregory Johnson's SOC work already in the
trunk?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2005-12-04 09:30

Message:
Logged In: YES 
user_id=11375

This patch is now superseded by Gregory Johnson's Summer of
Code work, which adds write support to all the mailbox
classes, not just Maildir, and also includes the
documentation changes.


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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-02-14 08:43

Message:
Logged In: YES 
user_id=11375

Thank you, sir; may I have another?

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

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

From noreply at sourceforge.net  Mon Apr  3 16:43:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 07:43:40 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FQQHM-0003Vv-8c@sc8-sf-web4-b.sourceforge.net>

Patches item #1454844, was opened at 2006-03-20 19:41
Message generated for change (Comment added) made by zpincus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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
Submitted By: Zach Pincus (zpincus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 14:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-27 18:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-27 17:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 08:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-22 02:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Mon Apr  3 18:33:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 09:33:58 -0700
Subject: [Patches] [ python-Patches-1117961 ] replace md5 impl. with one
	having a more free license
Message-ID: <E1FQS06-0002zi-Gc@sc8-sf-web6.sourceforge.net>

Patches item #1117961, was opened at 2005-02-07 17:10
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117961&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.5
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Matthias Klose (doko)
>Assigned to: Matthias Klose (doko)
Summary: replace md5 impl. with one having a more free license

Initial Comment:
details at
http://mail.python.org/pipermail/python-dev/2005-February/051450.html

the code is taken from Debian's dpkg source package,
which should at least build on Linux, the Hurd and the
kfreebsd-gnu and knetbsd-gnu BSD variants.


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

>Comment By: Matthias Klose (doko)
Date: 2006-04-03 18:33

Message:
Logged In: YES 
user_id=60903

> This entire issue was started not because of Python/PSF
> concerns, but because of Debian concerns.

http://mail.python.org/pipermail/python-dev/2005-February/051550.htmlif
mentioned it could affect the PSF's use of OSI's trademark.

> This is an ad-hoc policy, but this code would pass, so I'm
> fine with it.

checked in , r43594.


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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-02 18:19

Message:
Logged In: YES 
user_id=21627

This entire issue was started not because of Python/PSF
concerns, but because of Debian concerns.

For Python, I think the following guideline should apply:
- get permission to relicense (through contributor's
agreement) if feasible; this should be an absolute
requirement only for new code. In this case, this is
replacing some non-PSF license with another, so the
requirement for a copyright agreement should be waived.

- the license should permit us to do what we do (in
particular, copy the code and create derivative works)

- reqirements for mentioning the authors outside the source
(e.g. in accompanying documentation) should be avoided.

This is an ad-hoc policy, but this code would pass, so I'm
fine with it.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-02 06:35

Message:
Logged In: YES 
user_id=29957

That one comes with a zlib/libpng license. As far as I know,
this is acceptable for us to include. Does anyone know
otherwise? Is there a statement somewhere about which
licenses are acceptable for inclusion?


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

Comment By: Matthias Klose (doko)
Date: 2006-04-01 18:31

Message:
Logged In: YES 
user_id=60903

updated the patch with the implementation from
http://sourceforge.net/projects/libmd5-rfc/


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

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-12 00:43

Message:
Logged In: YES 
user_id=21627

As Jeremy Hylton explains on python-dev, this is
unacceptable, as it relies on the notion of a "public domain".

I agree, and believe this would make things worse than they
are: the statement of the author that his work is in the
public domain is legally void. Furthermore, the author does
not provide a license (as he believes he doesn't need to),
and it is questionable what license precisely can be implied
- strictyl speaking, the author maintains the full rights to
his work, licensing none.

Rejecting the patch.

It would be nice if the author could be asked to license the
work under, say, the Academic Free License, with an
additional permission to anybody to relicense it under any
terms they please.

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

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

From noreply at sourceforge.net  Mon Apr  3 18:48:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 09:48:37 -0700
Subject: [Patches] [ python-Patches-1038911 ] OS X: Can't use
	#!/usr/bin/pythonw
Message-ID: <E1FQSEH-0007Ir-09@sc8-sf-web3.sourceforge.net>

Patches item #1038911, was opened at 2004-10-02 05:40
Message generated for change (Comment added) made by edemaine
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&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 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nathan Gray (n8gray)
Assigned to: Jack Jansen (jackjansen)
Summary: OS X: Can't use #!/usr/bin/pythonw

Initial Comment:
At the moment, on OS X /usr/bin/pythonw2.x is a simple sh script 
that exec's a python interpreter within a valid OS X application 
bundle.  The problem is that this prevents python scripts from 
using pythonw in the #! line.  Darwin won't allow a script to act as 
an interpreter in a #! line.

This patch replaces the shell script with a simple C program that 
does the same thing -- it just calls execv on the python interpreter 
within the OS X app bundle.  Since it is a compiled executable it is 
allowed to act as an interpreter in #! lines.

Your patch guidelines said you preferred multiple patches to be 
concatenated in a single file.  My patch consists of a Makefile 
change and a new file, dist/src/Mac/OSX/pythonw.c.  I've included 
both in the text file attached to this report.  It would probably be 
prudent for somebody to review the Makefile change, since it's 
always tricky to find the right way to put a new file in someone 
else's build process.

Thank you,
-Nathan

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

Comment By: Erik Demaine (edemaine)
Date: 2006-04-03 12:48

Message:
Logged In: YES 
user_id=265183

Is there a good reason why this patch has not been
implemented ?  It seems really strange to me that
#!/usr/bin/pythonw doesn't work (but #!/usr/bin/python and
#!/usr/bin/env pythonw do) because pythonw is made a shell
script.  Perhaps the root problem is that a symlink doesn't
work, which is because of some other flaw in the interpreter
somewhere?

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

Comment By: Nathan Gray (n8gray)
Date: 2004-10-04 16:16

Message:
Logged In: YES 
user_id=121553

The issue is that sometimes you *do* care where python is installed, and 
you want to be sure to get the system python and not, for example, the 
Fink python.  At the moment, the only solution is to use a gangly #! line 
like:
#! /System/Library/Frameworks/Python.framework/Resources/
Python.app/Contents/MacOS/Python
and you'll only figure that out if you're clever enough to understand why 
#!/usr/bin/python works but #!/usr/bin/pythonw doesn't.

Mainly, it's just needlessly confusing to have a python interpreter that 
works from the command line but doesn't work in a #! line.  It's 
unfortunate that the distinction between python and pythonw is 
necessary, but as long as it is then it would be nice if at least pythonw 
was able to act as a drop-in replacement for python.  It's pretty simple 
to make it work as expected, so why not do it, for the sake of 
consistency?

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-04 10:34

Message:
Logged In: YES 
user_id=1038590

As described in the python tutorial, the recommended
solution to this is to use the following on the shebang line:

#! /usr/bin/env pythonw

this also has benefit of not caring where python is installed.

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

Comment By: Nathan Gray (n8gray)
Date: 2004-10-02 21:00

Message:
Logged In: YES 
user_id=121553

Assigning to Jack Jansen as suggested by Bob Ippolito on pythonmac-sig.

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

Comment By: Nathan Gray (n8gray)
Date: 2004-10-02 05:43

Message:
Logged In: YES 
user_id=121553

By the way, the patch is against CVS head.

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

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

From noreply at sourceforge.net  Mon Apr  3 19:13:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 10:13:03 -0700
Subject: [Patches] [ python-Patches-1462525 ] URI parsing library
Message-ID: <E1FQSbv-000886-Hv@sc8-sf-web1.sourceforge.net>

Patches item #1462525, was opened at 2006-04-01 03:30
Message generated for change (Comment added) made by paulj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&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
Submitted By: Paul Jimenez (paulj)
Assigned to: Nobody/Anonymous (nobody)
Summary: URI parsing library

Initial Comment:
Per the original discussion at
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
I'm submitting a library meant to deprecate the
existing urlparse library.  Questions and comments welcome.


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

>Comment By: Paul Jimenez (paulj)
Date: 2006-04-03 17:13

Message:
Logged In: YES 
user_id=25150

Oops. fix some editing bugs. 

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

Comment By: Paul Jimenez (paulj)
Date: 2006-04-02 21:19

Message:
Logged In: YES 
user_id=25150

Naming:
  I also considered urlparse2 (ala urllib2) but liked having
a name without a version number attached.  rfc3986 would
also work I suppose, but seems a bit... clunky.

MailtoURIParser:
  You seem to have missed the point (probably due to my poor
documentation): none of the *URIParser classes are meant to
be directly used; they're just the default population of an
extensible structure that URIParser uses to do the work of
parsing.  

Let's move discussion to python-dev.  I'll put
changed/fixed/upgraded versions here as I adjust them due to
feedback.  Here's the first (adjusted due to your feedback).


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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 00:32

Message:
Logged In: YES 
user_id=261020

Just a quick note listing some of the things I intend to
worry about <wink>:

1. IRIs

2. Python unicode strings

3. Percent-encoding.  See 1. and 2.

4. Interaction with other stdlib modules

5. RFC 3986 compliance (duh :-)

It certainly seemed from a brief email discussion with Mike
Brown a while back (who knows all this 10 times better than
me) that 1., 2. and 3. are not so easily brushed under the
carpet as you hope, but I'm very glad if you're right!-)

I think these things need to be at least thought through by
a few people before rushing a new module into the stdlib: we
already have two modules containing outdated URL parsing
code, we don't want to end up with a third one.

Don't want to sound negative though, it's great that you
wrote this!

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

Comment By: John J Lee (jjlee)
Date: 2006-04-02 00:20

Message:
Logged In: YES 
user_id=261020

Some mostly-stylistic / minor comments on the patch from a
quick skim (I hope to post some comments on the trickier
issues later):

Follow PEP 8.  Some issues I noticed:

- Inconsistent use of case: URI vs. Uri.
- Triple-quoted docstrings should use " not ' for
editor-friendliness.
- Strings should not be abused as comments: If you mean to
use a docstring, use a docstring; otherwise, use a comment
(I'm referring here to your use of strings immediately
*before* def statements).
- import usage like import posixpath as ppath is usually
frowned upon: just import posixpath.
- Use of whitespace in e.g. dict displays and listcomps is
non-standard.  [x for x in y], not [ x for x in y ]
- Indentation in docstrings is non-standard.
- Docstring-writing conventions are non-standard.


Other things:

- Having read your original python-dev post, I still think
UrlParser / URIParser could be simpler.  I'll try and supply
an actual suggested patch later.
- MailToURIParser appears to support a different interface
to all the others.  If this is really necessary for
standards or pragmatic reasons, those parse and unparse
methods should just be separate functions.
- Documentation for the module is missing.  This would
document the API and perhaps briefly explain the background
(what's changed to require this new module) and correct
usage, briefly explaining terms like "URI reference".  Some
well-chosen examples are always good, of course.
- The tests should go in a separate module
test/test_<modulename>.py and follow the conventions there.
- Would be very nice to explicitly reference RFC 3986
section numbers in the code.  I'll try and do this when I
review it properly.
- Use of URI vs. URL distinction is incorrect.


Finally, just BTW:

http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
"""
The contemporary point of view among the working group that
oversees URIs is that the terms URL and URN are
context-dependent aspects of URI and rarely need to be
distinguished.
"""

Heh, spot on!  Still, like I said, I agree terms like "URI
reference" deserve to be adopted.


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

Comment By: John J Lee (jjlee)
Date: 2006-04-01 23:07

Message:
Logged In: YES 
user_id=261020

This certainly seems needed (though I still haven't properly
read 3986 and 3987, and not sure how IRIs fit in with
everything else).  Perhaps a bit late for 2.5.

-1 on the name: makes it seem the difference between
urlparse and uriparse is something to do with the already
murky distinction between URIs and URLs.  How about rfc3986?
 Prosaic, but hits the nail on the head.

Must read those RFCs and review this...

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

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

From noreply at sourceforge.net  Mon Apr  3 19:30:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 10:30:03 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FQSsN-0006a7-2f@sc8-sf-web6.sourceforge.net>

Patches item #1454844, was opened at 2006-03-20 20:41
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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
Submitted By: Zach Pincus (zpincus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-03 19:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 16:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-27 20:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-27 19:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 09:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-22 03:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Mon Apr  3 20:44:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 11:44:07 -0700
Subject: [Patches] [ python-Patches-1463370 ] Add .format() method to str
	and unicode
Message-ID: <E1FQU23-0006N0-TX@sc8-sf-web3.sourceforge.net>

Patches item #1463370, was opened at 2006-04-03 03:42
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463370&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
Submitted By: crutcher (crutcher_gmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .format() method to str and unicode

Initial Comment:
patch to add .format() method to string and unicode types.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-03 14:44

Message:
Logged In: YES 
user_id=6380

I like this.

The reason to like this in favor of s%x was expressed by
Walter D??rwald on the python-3000 list:

"""
it avoids one problem you might run into with %:
If you have only one argument, writing ``s % (x,)``
as ``s % x`` will break when the
argument x happens to be a tuple.
You won't have this problem with
s.format(x).
"""

However, this might be our chance to introduce a new
formatting syntax, since there are many problems with the %s
style (especially %(foo)s).  See PEP 292.

We need a Python 3000 group in the trackers.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 04:37

Message:
Logged In: YES 
user_id=38388

Why would we need a method for formatting ? We already have
the %-based formatting which can also be access via .__mod__().

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

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

From noreply at sourceforge.net  Mon Apr  3 20:58:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 11:58:26 -0700
Subject: [Patches] [ python-Patches-1463370 ] Add .format() method to str
	and unicode
Message-ID: <E1FQUFu-0006Z2-Ld@sc8-sf-web1.sourceforge.net>

Patches item #1463370, was opened at 2006-04-03 03:42
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463370&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
Submitted By: crutcher (crutcher_gmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .format() method to str and unicode

Initial Comment:
patch to add .format() method to string and unicode types.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-03 14:44

Message:
Logged In: YES 
user_id=6380

I like this.

The reason to like this in favor of s%x was expressed by
Walter D??rwald on the python-3000 list:

"""
it avoids one problem you might run into with %:
If you have only one argument, writing ``s % (x,)``
as ``s % x`` will break when the
argument x happens to be a tuple.
You won't have this problem with
s.format(x).
"""

However, this might be our chance to introduce a new
formatting syntax, since there are many problems with the %s
style (especially %(foo)s).  See PEP 292.

We need a Python 3000 group in the trackers.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 04:37

Message:
Logged In: YES 
user_id=38388

Why would we need a method for formatting ? We already have
the %-based formatting which can also be access via .__mod__().

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

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

From noreply at sourceforge.net  Mon Apr  3 21:15:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 12:15:07 -0700
Subject: [Patches] [ python-Patches-1463370 ] Add .format() method to str
	and unicode
Message-ID: <E1FQUW3-0008M7-J4@sc8-sf-web3.sourceforge.net>

Patches item #1463370, was opened at 2006-04-03 09:42
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463370&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
Submitted By: crutcher (crutcher_gmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .format() method to str and unicode

Initial Comment:
patch to add .format() method to string and unicode types.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 21:15

Message:
Logged In: YES 
user_id=38388

I would rather like to see any non-trivial formatting be
moved into a module and have functions that operate on
strings and Unicode.

Methods on simple types shouldn't really implement any
complicated features.

Formatting is one of those things that everybody wants to
implement in different ways. Just look at the gazillion
different templating engines out there for examples :-)

Better remove the %-formatting altogether in Py3k and add a
module which implements 2.x style %-formatting as well as
pep 292 style $-formatting.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-03 20:44

Message:
Logged In: YES 
user_id=6380

I like this.

The reason to like this in favor of s%x was expressed by
Walter D??rwald on the python-3000 list:

"""
it avoids one problem you might run into with %:
If you have only one argument, writing ``s % (x,)``
as ``s % x`` will break when the
argument x happens to be a tuple.
You won't have this problem with
s.format(x).
"""

However, this might be our chance to introduce a new
formatting syntax, since there are many problems with the %s
style (especially %(foo)s).  See PEP 292.

We need a Python 3000 group in the trackers.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 10:37

Message:
Logged In: YES 
user_id=38388

Why would we need a method for formatting ? We already have
the %-based formatting which can also be access via .__mod__().

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

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

From noreply at sourceforge.net  Mon Apr  3 21:44:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 12:44:11 -0700
Subject: [Patches] [ python-Patches-1463370 ] Add .format() method to str
	and unicode
Message-ID: <E1FQUyB-00012h-Kr@sc8-sf-web1.sourceforge.net>

Patches item #1463370, was opened at 2006-04-03 03:42
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463370&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
Submitted By: crutcher (crutcher_gmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .format() method to str and unicode

Initial Comment:
patch to add .format() method to string and unicode types.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-03 15:44

Message:
Logged In: YES 
user_id=6380

Let's please continue this discussion on
python-3000 at python.org instead of a random SF item.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 15:15

Message:
Logged In: YES 
user_id=38388

I would rather like to see any non-trivial formatting be
moved into a module and have functions that operate on
strings and Unicode.

Methods on simple types shouldn't really implement any
complicated features.

Formatting is one of those things that everybody wants to
implement in different ways. Just look at the gazillion
different templating engines out there for examples :-)

Better remove the %-formatting altogether in Py3k and add a
module which implements 2.x style %-formatting as well as
pep 292 style $-formatting.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-03 14:44

Message:
Logged In: YES 
user_id=6380

I like this.

The reason to like this in favor of s%x was expressed by
Walter D??rwald on the python-3000 list:

"""
it avoids one problem you might run into with %:
If you have only one argument, writing ``s % (x,)``
as ``s % x`` will break when the
argument x happens to be a tuple.
You won't have this problem with
s.format(x).
"""

However, this might be our chance to introduce a new
formatting syntax, since there are many problems with the %s
style (especially %(foo)s).  See PEP 292.

We need a Python 3000 group in the trackers.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 04:37

Message:
Logged In: YES 
user_id=38388

Why would we need a method for formatting ? We already have
the %-based formatting which can also be access via .__mod__().

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

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

From noreply at sourceforge.net  Tue Apr  4 00:39:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 15:39:25 -0700
Subject: [Patches] [ python-Patches-1462228 ] custom comparison function for
	bisect module
Message-ID: <E1FQXhl-0003lu-Sn@sc8-sf-web1.sourceforge.net>

Patches item #1462228, was opened at 2006-03-31 16:31
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462228&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: Open
Resolution: None
Priority: 5
Submitted By: Matt Fleming (splitscreen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: custom comparison function for bisect module

Initial Comment:
This is a patch for the feature requets #1451588

The patch is from the current trunk, r43488.

The patch provides the bisect module (both the python
and C implementation) with an option for a custom
comparison function.

If not custom comparison function is provided the
standard cmp() built-in function it used.

Please review, any comments welcome.

matt

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

>Comment By: Matt Fleming (splitscreen)
Date: 2006-04-03 22:39

Message:
Logged In: YES 
user_id=1126061

Jonathan Joseph kindly pointed out some redundant if
statements to me.

I've updated the patch with a newer version.

Matt

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

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

From noreply at sourceforge.net  Tue Apr  4 00:43:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 15:43:11 -0700
Subject: [Patches] [ python-Patches-1463867 ] Improved generator finalization
Message-ID: <E1FQXlP-0001OZ-6T@sc8-sf-web6.sourceforge.net>

Patches item #1463867, was opened at 2006-04-03 22:43
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=1463867&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
Submitted By: Phillip J. Eby (pje)
Assigned to: Thomas Wouters (twouters)
Summary: Improved generator finalization

Initial Comment:
This patch improves generator finalization such that
simple generators (without active try/except/finally
blocks surrounding yield statements) can have their
cycles broken.

Please check to see if this patch improves the leaks
that prompted the request for changing this.  Thanks.

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

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

From noreply at sourceforge.net  Tue Apr  4 06:36:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 21:36:15 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FQdH5-0002IL-VX@sc8-sf-web2.sourceforge.net>

Patches item #1454844, was opened at 2006-03-20 19:41
Message generated for change (Comment added) made by zpincus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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
Submitted By: Zach Pincus (zpincus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Zach Pincus (zpincus)
Date: 2006-04-04 04:36

Message:
Logged In: YES 
user_id=748718

The test suite does load in a plain-vanilla fashion a
bunch of C python extensions, so that's some 
evidence that the basic stuff works. Better, the dl 
tests also works, so direct usage of dlopen seems 
OK.

As you point out, the best test is usage. All I can 
say here is that my use of this patch works OK, 
even with exotic modules which require setting
the dlopenflags. I've asked on python-dev if 
anyone can think of some better test cases.

Now, if this patch is deemed too radical, I agree
that it would be a good idea to teach 
dynload_next.c about the dlopenflags. This
would be a bit odd in the sense that the flags
on the mac would be interpreted not as 
'dlopenflags' with values from dlfcn.h, but as
nsmoduleflags, with values from mach-o/dyld.h.
However, this would be better than the 
current state of affairs.

Finally, if this patch isn't added, we should at
least fix the rest of the configure.in script in 
the manner suggested by the first comment,
so that other things don't start randomly
breaking when Darwin 10 comes around...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-03 17:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 14:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-27 18:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-27 17:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 08:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-22 02:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Tue Apr  4 08:09:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Apr 2006 23:09:58 -0700
Subject: [Patches] [ python-Patches-1416559 ] Configure patch for Mac OS X
	10.3
Message-ID: <E1FQejm-0008Bi-QX@sc8-sf-web2.sourceforge.net>

Patches item #1416559, was opened at 2006-01-27 16:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1416559&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.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure patch for Mac OS X 10.3

Initial Comment:
This patch makes sure that _POSIX_SOURCE and friends won't get defined 
when you build on Panther. Defining those have no effect on Panther, but 
will make it impossible to build extensions on a Tiger system when 
Python itself was build on Panther.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 08:09

Message:
Logged In: YES 
user_id=21627

This patch cheated in a really dangerous way: the configure
fragment was gained through editing, not through running
autoconf. This was really bad, as it broke two months and a
release later.

The problem is that, in configure.in, [ does not denote a
shell square bracket - it denotes an m4 quoted string. The
square bracket is denoted with a quadrigraph.

When committing configure.in, please always ignore configure
fragments, and run autoconf/autoheader yourself.

I fixed that in 43617 and 43618.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 10:51

Message:
Logged In: YES 
user_id=849994

Committed in 43536, 43537.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 05:11

Message:
Logged In: YES 
user_id=33168

Ronald, this looks fine, go ahead and checkin.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-02-21 10:23

Message:
Logged In: YES 
user_id=580910

I don't suppose this helps, but  yes this patch is save.  I use this in production 
and haven't found an extension yet that wouldn't work when this patch is 
applied.  I've also looked at the platform header files to determine if the patch is 
save.

We (Bob Ippolitto and myself) are using a simular patch in our ongoing work to 
create an universal build of python.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 16:54

Message:
Logged In: YES 
user_id=1188172

Can any OS X expert confirm that not defining _XOPEN_SOURCE
and _POSIX_C_SOURCE hasn't a negative effect on OSX 10.3?

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

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

From noreply at sourceforge.net  Tue Apr  4 10:53:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 01:53:52 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQhIO-00066K-Kq@sc8-sf-web6.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 10:53
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=1464062&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
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

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

From noreply at sourceforge.net  Tue Apr  4 10:54:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 01:54:27 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQhIx-0005Bj-Pb@sc8-sf-web4-b.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 10:53
Message generated for change (Settings changed) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464062&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

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

From noreply at sourceforge.net  Tue Apr  4 11:26:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 02:26:20 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQhno-0003lL-0m@sc8-sf-web2.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 10:53
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464062&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

>Comment By: Thomas Heller (theller)
Date: 2006-04-04 11:26

Message:
Logged In: YES 
user_id=11105

Updated the test to work when run from different directory.

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

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

From noreply at sourceforge.net  Tue Apr  4 15:36:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 06:36:50 -0700
Subject: [Patches] [ python-Patches-1309579 ] A wait4() implementation
Message-ID: <E1FQliE-0002Bo-Vg@sc8-sf-web3.sourceforge.net>

Patches item #1309579, was opened at 2005-09-30 10:32
Message generated for change (Comment added) made by cjschr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&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.5
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: chads (cjschr)
Assigned to: Neal Norwitz (nnorwitz)
Summary: A wait4() implementation

Initial Comment:
Implementation of a BSD-style wait4() function, which
is similar to waitpid, but it also returns resource usage
information about the child process.

wait4(pid, options) -> (pid, status, rusage)

Chad

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

>Comment By: chads (cjschr)
Date: 2006-04-04 08:36

Message:
Logged In: YES 
user_id=1093928

I like what you did with the posixmodule.  Great work!

Thanks for all your help getting this added.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:31

Message:
Logged In: YES 
user_id=33168

Thanks for the patch!  Finally applied (with mods).

Committed revision 43158.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-18 16:18

Message:
Logged In: YES 
user_id=33168

I think I recall spotting the docs after your comment.  I
plan to get this in before alpha1.

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

Comment By: chads (cjschr)
Date: 2006-01-19 07:47

Message:
Logged In: YES 
user_id=1093928

Neil

Check the diff.  Doc updates are already there.

Thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-19 00:58

Message:
Logged In: YES 
user_id=33168

I looked over the patch.  It looks pretty good.  Can your
provide doc too?  If you can't do latex, just text will do
and I'll convert.

Doc/lib/libos.tex

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

Comment By: chads (cjschr)
Date: 2006-01-17 16:52

Message:
Logged In: YES 
user_id=1093928

Took a different approach with implementation.
Also includes wait3 implementation.

LMK how it looks.  Thanks.
Chad

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 16:56

Message:
Logged In: YES 
user_id=33168

Comments from author received in mail:

It is a duplicate of my original post, but it was diff'ed
against the latest CVS tree.

The usage example is for those who haven't had experience with
wait4 before, hence the name.  It's an FYI, nothing more.
I'll also update the documentation accordingly.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 22:16

Message:
Logged In: YES 
user_id=33168

Chad, I'm starting to look at this now, but it seems to be a
duplicate of your original patch # 1000267.  Can this be
closed as a duplicate?  I don't know if the attachments are
the same.  

It would be easier to have all the changes in a single file.
 Since you are adding a new file, you will need to use -N
option to cvs diff.  Something like this:  cvs diff -Nu ...
(you can list the specific files that changed if necessary).

>From what I looked at so far, there were a couple of things
I didn't like.  Though it looks like you addressed many
(perhaps all) of the previous comments.

I don't like the code in resourcemodule.h.  I would prefer a
public API in resourcemodule that posixmodule can call.  If
you think that no other modules outside python should call
this, you can prefix the name with _, ie
_PyResourceModule_...().

There are some un-prefixed names in resourcemodule.h.  I
think these may all go away if you move the code into the .c
file.  I would prefer to not have resourcemodule_h_author &
resourcemodule_h_rcsid.  The comment with your name and
email is fine.

I didn't look at the test or usage example.  What should be
done with the usage example?  In the doc, could you remove
the ", ?" for availability.  We can leave it as Unix for
now.  If we find out definitive info about other platforms
(Windows, Mac), we can add that later.  Please add a
\versionadded{2.5} at the end of the new doc (before the end).

That's all my comments.  This looks close to being ready.

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

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

From noreply at sourceforge.net  Tue Apr  4 17:13:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 08:13:38 -0700
Subject: [Patches] [ python-Patches-1448488 ] const PyDict_Type ?
Message-ID: <E1FQnDu-0008Ut-IF@sc8-sf-web3.sourceforge.net>

Patches item #1448488, was opened at 2006-03-13 08:53
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&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: Fixed
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Jack Jansen (jackjansen)
Summary: const PyDict_Type ?

Initial Comment:
When I try to compile SVN trunk, plus my recent
declspecs-for-ssize_t patch, I get this error from
Cygwin gcc 3.4.4:

building 'collections' extension
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I.
-I/cygdrive/c/playground/python/trunk/./Include
-I./Include -I.
-I/cygdrive/c/playground/python/trunk/Include
 -I/cygdrive/c/playground/python/trunk -c
/cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c
-o build/temp.cygwin-1.5.19-i686-2.5/collectionsmodule.o
/cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314:
error: initializer element is not constant
/cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314:
error: (near initialization for `defdict_type.tp_base')


This is with this version of gcc:

$ gcc --version
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.


So, with much uncertainty, I applied the attached patch
that makes PyDict_Type be const.  The whole thing then
compiles fine (if you disregard one million warnings
about discarding qualifiers from pointer target type),
but the resulting python.exe segfaults on startup.


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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-05 01:13

Message:
Logged In: YES 
user_id=29957

Applied the changes as per xxsubtypemodule.c in revision
43634. Cygwin builds now (and is in buildbot). 


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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-03-13 22:29

Message:
Logged In: YES 
user_id=52562

Here is the result of make test after setting the tp_base
slot to 0.

266 tests OK.
3 tests failed:
    test_mmap test_platform test_time
40 tests skipped:
    test_aepack test_al test_applesingle test_bsddb
test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn
test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw
test_ctypes
    test_curses test_dbm test_gl test_hashlib_speed test_imgfile
    test_ioctl test_linuxaudiodev test_locale test_macfs
    test_macostools test_nis test_normalization test_ossaudiodev
    test_pep277 test_plistlib test_scriptpackages
test_socket_ssl
    test_socketserver test_sunaudiodev test_tcl test_timeout
    test_unicode_file test_urllib2net test_urllibnet test_winreg
    test_winsound
3 skips unexpected on cygwin:
    test_tcl test_ctypes test_bsddb


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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-03-13 11:50

Message:
Logged In: YES 
user_id=52562

The tp_base slot is zero then compilation finishes normally,
and the resulting python.exe starts normally instead of
segfaulting.  Now running make test and I will report back
if it fails.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-13 10:21

Message:
Logged In: YES 
user_id=80475

Zooko, does the code work for you if the tp_base slot is 
set to zero?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-13 09:50

Message:
Logged In: YES 
user_id=80475

Cygwin seems to be somewhat sensitive to how subtypes are 
initialized in extensions.  

The collections.defaultdict PyTypeObject structure may 
need to be modified to comform to the example in lines 106 
and 137 in xxsubtypes.c 

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

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

From noreply at sourceforge.net  Tue Apr  4 20:13:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 11:13:45 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQq2D-0006RQ-2F@sc8-sf-web5.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 10:53
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464062&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.5
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Thomas Heller (theller)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 20:13

Message:
Logged In: YES 
user_id=21627

The patch looks fine, except that the conversion of a path
name to Unicode should use the "mbcs" codec. Please apply
(before the trunk freeze, or after the unfreeze); please
also add empty.vbs to Tools/msi/msi.py

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 11:26

Message:
Logged In: YES 
user_id=11105

Updated the test to work when run from different directory.

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

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

From noreply at sourceforge.net  Tue Apr  4 20:19:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 11:19:14 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQq7W-0007cF-3G@sc8-sf-web4-b.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 10:53
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464062&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.5
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

>Comment By: Thomas Heller (theller)
Date: 2006-04-04 20:19

Message:
Logged In: YES 
user_id=11105

Do I have to add something to Lib/test/regrtest.py, so that
the test is skipped on non-Windows platforms?

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 20:13

Message:
Logged In: YES 
user_id=21627

The patch looks fine, except that the conversion of a path
name to Unicode should use the "mbcs" codec. Please apply
(before the trunk freeze, or after the unfreeze); please
also add empty.vbs to Tools/msi/msi.py

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 11:26

Message:
Logged In: YES 
user_id=11105

Updated the test to work when run from different directory.

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

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

From noreply at sourceforge.net  Tue Apr  4 20:38:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 11:38:54 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQqQY-00063M-5O@sc8-sf-web1.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 01:53
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464062&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.5
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 11:38

Message:
Logged In: YES 
user_id=33168

Thanks Thomas!  I'll check about the non-Windows platforms.

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 11:19

Message:
Logged In: YES 
user_id=11105

Do I have to add something to Lib/test/regrtest.py, so that
the test is skipped on non-Windows platforms?

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 11:13

Message:
Logged In: YES 
user_id=21627

The patch looks fine, except that the conversion of a path
name to Unicode should use the "mbcs" codec. Please apply
(before the trunk freeze, or after the unfreeze); please
also add empty.vbs to Tools/msi/msi.py

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 02:26

Message:
Logged In: YES 
user_id=11105

Updated the test to work when run from different directory.

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

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

From noreply at sourceforge.net  Tue Apr  4 20:42:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 11:42:42 -0700
Subject: [Patches] [ python-Patches-1463370 ] Add .format() method to str
	and unicode
Message-ID: <E1FQqUE-0008I3-SA@sc8-sf-web5.sourceforge.net>

Patches item #1463370, was opened at 2006-04-03 07:42
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463370&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
Submitted By: crutcher (crutcher_gmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .format() method to str and unicode

Initial Comment:
patch to add .format() method to string and unicode types.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-03 19:44

Message:
Logged In: YES 
user_id=6380

Let's please continue this discussion on
python-3000 at python.org instead of a random SF item.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 19:15

Message:
Logged In: YES 
user_id=38388

I would rather like to see any non-trivial formatting be
moved into a module and have functions that operate on
strings and Unicode.

Methods on simple types shouldn't really implement any
complicated features.

Formatting is one of those things that everybody wants to
implement in different ways. Just look at the gazillion
different templating engines out there for examples :-)

Better remove the %-formatting altogether in Py3k and add a
module which implements 2.x style %-formatting as well as
pep 292 style $-formatting.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-03 18:44

Message:
Logged In: YES 
user_id=6380

I like this.

The reason to like this in favor of s%x was expressed by
Walter D??rwald on the python-3000 list:

"""
it avoids one problem you might run into with %:
If you have only one argument, writing ``s % (x,)``
as ``s % x`` will break when the
argument x happens to be a tuple.
You won't have this problem with
s.format(x).
"""

However, this might be our chance to introduce a new
formatting syntax, since there are many problems with the %s
style (especially %(foo)s).  See PEP 292.

We need a Python 3000 group in the trackers.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-03 08:37

Message:
Logged In: YES 
user_id=38388

Why would we need a method for formatting ? We already have
the %-based formatting which can also be access via .__mod__().

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

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

From noreply at sourceforge.net  Tue Apr  4 20:43:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 11:43:37 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQqV7-0008MA-Ir@sc8-sf-web5.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 10:53
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464062&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.5
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

>Comment By: Thomas Heller (theller)
Date: 2006-04-04 20:43

Message:
Logged In: YES 
user_id=11105

Committed as rev. 43644 and rev. 43645.  Changed the unicode
conversion, and added some comments.

Thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 20:38

Message:
Logged In: YES 
user_id=33168

Thanks Thomas!  I'll check about the non-Windows platforms.

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 20:19

Message:
Logged In: YES 
user_id=11105

Do I have to add something to Lib/test/regrtest.py, so that
the test is skipped on non-Windows platforms?

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 20:13

Message:
Logged In: YES 
user_id=21627

The patch looks fine, except that the conversion of a path
name to Unicode should use the "mbcs" codec. Please apply
(before the trunk freeze, or after the unfreeze); please
also add empty.vbs to Tools/msi/msi.py

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 11:26

Message:
Logged In: YES 
user_id=11105

Updated the test to work when run from different directory.

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

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

From noreply at sourceforge.net  Tue Apr  4 20:44:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 11:44:22 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQqVq-0001xD-TG@sc8-sf-web6.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 10:53
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464062&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.5
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 20:44

Message:
Logged In: YES 
user_id=21627

Indeed: you should phrase the import as

from os import startfile

Then it will get skipped if startfile is not available.



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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 20:43

Message:
Logged In: YES 
user_id=11105

Committed as rev. 43644 and rev. 43645.  Changed the unicode
conversion, and added some comments.

Thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 20:38

Message:
Logged In: YES 
user_id=33168

Thanks Thomas!  I'll check about the non-Windows platforms.

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 20:19

Message:
Logged In: YES 
user_id=11105

Do I have to add something to Lib/test/regrtest.py, so that
the test is skipped on non-Windows platforms?

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 20:13

Message:
Logged In: YES 
user_id=21627

The patch looks fine, except that the conversion of a path
name to Unicode should use the "mbcs" codec. Please apply
(before the trunk freeze, or after the unfreeze); please
also add empty.vbs to Tools/msi/msi.py

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 11:26

Message:
Logged In: YES 
user_id=11105

Updated the test to work when run from different directory.

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

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

From noreply at sourceforge.net  Tue Apr  4 22:58:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 13:58:53 -0700
Subject: [Patches] [ python-Patches-1464062 ] Simple test for os.startfile
Message-ID: <E1FQsc1-00068i-GT@sc8-sf-web2.sourceforge.net>

Patches item #1464062, was opened at 2006-04-04 01:53
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464062&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.5
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: Simple test for os.startfile

Initial Comment:
The attached file test_startfile.py is a very simple
test for os.startfile on Windows.  It needs an empty
file 'empty.vbs' as well.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 13:58

Message:
Logged In: YES 
user_id=33168

This is checked in and working AFAIK.  closing.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 11:44

Message:
Logged In: YES 
user_id=21627

Indeed: you should phrase the import as

from os import startfile

Then it will get skipped if startfile is not available.



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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 11:43

Message:
Logged In: YES 
user_id=11105

Committed as rev. 43644 and rev. 43645.  Changed the unicode
conversion, and added some comments.

Thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 11:38

Message:
Logged In: YES 
user_id=33168

Thanks Thomas!  I'll check about the non-Windows platforms.

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 11:19

Message:
Logged In: YES 
user_id=11105

Do I have to add something to Lib/test/regrtest.py, so that
the test is skipped on non-Windows platforms?

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-04 11:13

Message:
Logged In: YES 
user_id=21627

The patch looks fine, except that the conversion of a path
name to Unicode should use the "mbcs" codec. Please apply
(before the trunk freeze, or after the unfreeze); please
also add empty.vbs to Tools/msi/msi.py

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

Comment By: Thomas Heller (theller)
Date: 2006-04-04 02:26

Message:
Logged In: YES 
user_id=11105

Updated the test to work when run from different directory.

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

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

From noreply at sourceforge.net  Wed Apr  5 08:35:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 23:35:59 -0700
Subject: [Patches] [ python-Patches-1464708 ] fixed handling of nested
	comments in mail addresses
Message-ID: <E1FR1cV-0005Y9-0X@sc8-sf-web1.sourceforge.net>

Patches item #1464708, was opened at 2006-04-05 06:35
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=1464708&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: William McVey (wamcvey)
Assigned to: Nobody/Anonymous (nobody)
Summary: fixed handling of nested  comments in mail addresses

Initial Comment:
RFC 2822 allows for comments to include other comments
in a mail address. email.Utils.getaddresses() handled
addresses with a comment, but incorrectly advanced the
parsing index twice after a comment finished. This
would cause the outer closing paren in an address like:
    Foo ((FOO Rocks)) <foo at bar.com>
to be missed, and treating the rest of the line as part
of the outer comment.

This patch fixes the bug and adds a testcase to look
for the bug.

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

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

From noreply at sourceforge.net  Wed Apr  5 08:38:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 23:38:17 -0700
Subject: [Patches] [ python-Patches-1464708 ] fixed handling of nested
	comments in mail addresses
Message-ID: <E1FR1ej-0005jc-MT@sc8-sf-web1.sourceforge.net>

Patches item #1464708, was opened at 2006-04-05 06:35
Message generated for change (Comment added) made by wamcvey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464708&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: William McVey (wamcvey)
Assigned to: Nobody/Anonymous (nobody)
Summary: fixed handling of nested  comments in mail addresses

Initial Comment:
RFC 2822 allows for comments to include other comments
in a mail address. email.Utils.getaddresses() handled
addresses with a comment, but incorrectly advanced the
parsing index twice after a comment finished. This
would cause the outer closing paren in an address like:
    Foo ((FOO Rocks)) <foo at bar.com>
to be missed, and treating the rest of the line as part
of the outer comment.

This patch fixes the bug and adds a testcase to look
for the bug.

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

>Comment By: William McVey (wamcvey)
Date: 2006-04-05 06:38

Message:
Logged In: YES 
user_id=25956

hmm, didn't seem to attach my patch the first time. Let's
try adding it again.

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

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

From noreply at sourceforge.net  Wed Apr  5 08:46:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Apr 2006 23:46:36 -0700
Subject: [Patches] [ python-Patches-1464708 ] fixed handling of nested
	comments in mail addresses
Message-ID: <E1FR1mm-0008M2-Nz@sc8-sf-web3.sourceforge.net>

Patches item #1464708, was opened at 2006-04-04 23:35
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464708&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: William McVey (wamcvey)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: fixed handling of nested  comments in mail addresses

Initial Comment:
RFC 2822 allows for comments to include other comments
in a mail address. email.Utils.getaddresses() handled
addresses with a comment, but incorrectly advanced the
parsing index twice after a comment finished. This
would cause the outer closing paren in an address like:
    Foo ((FOO Rocks)) <foo at bar.com>
to be missed, and treating the rest of the line as part
of the outer comment.

This patch fixes the bug and adds a testcase to look
for the bug.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 23:46

Message:
Logged In: YES 
user_id=33168

Barry, has the new email addressed this?

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

Comment By: William McVey (wamcvey)
Date: 2006-04-04 23:38

Message:
Logged In: YES 
user_id=25956

hmm, didn't seem to attach my patch the first time. Let's
try adding it again.

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

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

From noreply at sourceforge.net  Wed Apr  5 21:25:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Apr 2006 12:25:01 -0700
Subject: [Patches] [ python-Patches-1463867 ] Improved generator finalization
Message-ID: <E1FRDcj-0001vC-0x@sc8-sf-web4-b.sourceforge.net>

Patches item #1463867, was opened at 2006-04-03 18:43
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463867&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
Submitted By: Phillip J. Eby (pje)
Assigned to: Thomas Wouters (twouters)
Summary: Improved generator finalization

Initial Comment:
This patch improves generator finalization such that
simple generators (without active try/except/finally
blocks surrounding yield statements) can have their
cycles broken.

Please check to see if this patch improves the leaks
that prompted the request for changing this.  Thanks.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-05 15:25

Message:
Logged In: YES 
user_id=31435

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

Please try again.

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

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

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

From noreply at sourceforge.net  Wed Apr  5 21:46:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Apr 2006 12:46:43 -0700
Subject: [Patches] [ python-Patches-1464708 ] fixed handling of nested
	comments in mail addresses
Message-ID: <E1FRDxj-0005gF-5u@sc8-sf-web1.sourceforge.net>

Patches item #1464708, was opened at 2006-04-05 06:35
Message generated for change (Comment added) made by wamcvey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464708&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: William McVey (wamcvey)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: fixed handling of nested  comments in mail addresses

Initial Comment:
RFC 2822 allows for comments to include other comments
in a mail address. email.Utils.getaddresses() handled
addresses with a comment, but incorrectly advanced the
parsing index twice after a comment finished. This
would cause the outer closing paren in an address like:
    Foo ((FOO Rocks)) <foo at bar.com>
to be missed, and treating the rest of the line as part
of the outer comment.

This patch fixes the bug and adds a testcase to look
for the bug.

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

>Comment By: William McVey (wamcvey)
Date: 2006-04-05 19:46

Message:
Logged In: YES 
user_id=25956

I just realized that I only submitted the patch for the
email package and that the same bug exists in the rfc822.py
package. Even though deprecated, I imagine bug fixes are
still appropriate, so I'm attaching a second attachment
which patch rfc822.py and adds a testcase for this condition
to test/test_rfc822.py. I also noticed that the testcase
driver in test_rfc822.py emitted a print statement error but
didn't raise a condition when the parsed name or address
differed from the expected name. I've adjusted the driver to
use assertions so that the error condition are more
noticeable (e.g. error status codes).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-05 06:46

Message:
Logged In: YES 
user_id=33168

Barry, has the new email addressed this?

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

Comment By: William McVey (wamcvey)
Date: 2006-04-05 06:38

Message:
Logged In: YES 
user_id=25956

hmm, didn't seem to attach my patch the first time. Let's
try adding it again.

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

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

From noreply at sourceforge.net  Wed Apr  5 21:51:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Apr 2006 12:51:35 -0700
Subject: [Patches] [ python-Patches-1464708 ] fixed handling of nested
	comments in mail addresses
Message-ID: <E1FRE2R-0003Kw-Bj@sc8-sf-web5.sourceforge.net>

Patches item #1464708, was opened at 2006-04-05 06:35
Message generated for change (Comment added) made by wamcvey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464708&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: William McVey (wamcvey)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: fixed handling of nested  comments in mail addresses

Initial Comment:
RFC 2822 allows for comments to include other comments
in a mail address. email.Utils.getaddresses() handled
addresses with a comment, but incorrectly advanced the
parsing index twice after a comment finished. This
would cause the outer closing paren in an address like:
    Foo ((FOO Rocks)) <foo at bar.com>
to be missed, and treating the rest of the line as part
of the outer comment.

This patch fixes the bug and adds a testcase to look
for the bug.

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

>Comment By: William McVey (wamcvey)
Date: 2006-04-05 19:51

Message:
Logged In: YES 
user_id=25956

I see now that there appears to be duplicate patches against
the email package attached. I'll go ahead and remove the
duplicate, leaving one patch for email package and one patch
for rfc822.py. 

Oh, and it probably goes without saying, but the first patch
is relative to the 'email' package directory and the second
is relative to the Lib directory in which rfc822.py is located.

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

Comment By: William McVey (wamcvey)
Date: 2006-04-05 19:46

Message:
Logged In: YES 
user_id=25956

I just realized that I only submitted the patch for the
email package and that the same bug exists in the rfc822.py
package. Even though deprecated, I imagine bug fixes are
still appropriate, so I'm attaching a second attachment
which patch rfc822.py and adds a testcase for this condition
to test/test_rfc822.py. I also noticed that the testcase
driver in test_rfc822.py emitted a print statement error but
didn't raise a condition when the parsed name or address
differed from the expected name. I've adjusted the driver to
use assertions so that the error condition are more
noticeable (e.g. error status codes).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-05 06:46

Message:
Logged In: YES 
user_id=33168

Barry, has the new email addressed this?

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

Comment By: William McVey (wamcvey)
Date: 2006-04-05 06:38

Message:
Logged In: YES 
user_id=25956

hmm, didn't seem to attach my patch the first time. Let's
try adding it again.

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

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

From noreply at sourceforge.net  Wed Apr  5 22:06:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Apr 2006 13:06:20 -0700
Subject: [Patches] [ python-Patches-1463867 ] Improved generator finalization
Message-ID: <E1FREGi-0004b6-N1@sc8-sf-web4-b.sourceforge.net>

Patches item #1463867, was opened at 2006-04-03 22:43
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463867&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
Submitted By: Phillip J. Eby (pje)
Assigned to: Thomas Wouters (twouters)
Summary: Improved generator finalization

Initial Comment:
This patch improves generator finalization such that
simple generators (without active try/except/finally
blocks surrounding yield statements) can have their
cycles broken.

Please check to see if this patch improves the leaks
that prompted the request for changing this.  Thanks.

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

>Comment By: Phillip J. Eby (pje)
Date: 2006-04-05 20:06

Message:
Logged In: YES 
user_id=56214

Argh.  Sorry.  Uploaded.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-05 19:25

Message:
Logged In: YES 
user_id=31435

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

Please try again.

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

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

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

From noreply at sourceforge.net  Fri Apr  7 00:30:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Apr 2006 15:30:10 -0700
Subject: [Patches] [ python-Patches-1462080 ] ssl build fails due to
	undefined NETLINK_ stuff
Message-ID: <E1FRczS-0005li-Cv@sc8-sf-web6.sourceforge.net>

Patches item #1462080, was opened at 2006-03-31 15:05
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462080&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
Submitted By: Arkadiusz Miskiewicz (arekm)
Assigned to: Martin v. L??wis (loewis)
Summary: ssl build fails due to undefined NETLINK_ stuff

Initial Comment:

gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O
3 -Wall -Wstrict-prototypes -I. -I/home/users/arekm/
test/python/./Include -I/home/users/arekm/test/python-
test/include -I/usr/include/ncurses -I./Include -I. -I/
usr/local/include -I/home/users/arekm/test/python/
Include -I/home/users/arekm/test/python -c /home/users/
arekm/test/python/Modules/socketmodule.c -o build/temp.
linux-i686-2.5/socketmodule.o
/home/users/arekm/test/python/Modules/socketmodule.c: 
In function ???init_socket???:
/home/users/arekm/test/python/Modules/socketmodule.c:
4050: error: ???NETLINK_ARPD??? undeclared (first use in 
this function)
/home/users/arekm/test/python/Modules/socketmodule.c:
4050: error: (Each undeclared identifier is reported 
only once
/home/users/arekm/test/python/Modules/socketmodule.c:
4050: error: for each function it appears in.)
/home/users/arekm/test/python/Modules/socketmodule.c:
4051: error: ???NETLINK_ROUTE6??? undeclared (first use in 
this function)
/home/users/arekm/test/python/Modules/socketmodule.c:
4054: error: ???NETLINK_TAPBASE??? undeclared (first use 
in this function)


I'm using sanitized version of linux headers - linux-
libc-headers.

Attached patch fixes these by ifdefing them + adds 
NETLINK_W1 which replaced NETLINK_SKIP in latest linux 
kernels.


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-07 00:30

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as 43715

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

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 20:44

Message:
Logged In: YES 
user_id=31435

Assigned to Martin.

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

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

From noreply at sourceforge.net  Fri Apr  7 11:10:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Apr 2006 02:10:47 -0700
Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs
Message-ID: <E1FRmzP-0001Q6-C9@sc8-sf-web5.sourceforge.net>

Patches item #1455898, was opened at 2006-03-22 16:31
Message generated for change (Comment added) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&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 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Walter D?rwald (doerwalter)
Summary: patch for mbcs codecs

Initial Comment:
Hello.

I have noticed mbcs codecs sometimes generates broken
string. I'm using Windows(Japanese) so mbcs is mapped
to cp932 (close to shift_jis)

When I run the attached script "a.zip", the entry
"Error 00007"'s message becomes broken like attached
file "b.txt".

I think this happens because the string passed to
PyUnicode_DecodeMBCS() sometimes terminates with
leading byte, and MultiByteToWideChar() counts it for
size of result string.buffer size.

I hope attached patch "mbcs.patch" may fix the problem.
It would be nice if this bug will be fixed in 2.4.3...
Thank you.






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

>Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-04-07 18:10

Message:
Logged In: YES 
user_id=1200846

I have sent contributor form via postal mail. Probably you
can get it after 10 days.

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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-28 17:16

Message:
Logged In: YES 
user_id=1200846

You are right. I've updated the patch. (mbcs5.patch)

>>> import codecs
[20198 refs]
>>> d = codecs.getincrementaldecoder("mbcs")()
[20198 refs]
>>> d.decode('\x82\xa0\x82')
u'\u3042'
[20198 refs]
>>> d.decode('')
u''
[20198 refs]
>>> d.decode('', final=True)
u'\x00'
[20198 refs]


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

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-28 01:06

Message:
Logged In: YES 
user_id=89016

_buffer_decode() in the IncrementalDecoder ignores the final
argument. IncrementalDecoder._buffer_decode() should pass on
its final argument to _codecsmodules.c::mbcs_decode(), which
should be extended to accept the final argument. Also
PyUnicode_DecodeMBCSStateful() must handle consumed == NULL
correctly (with your patch it drops trailing lead bytes even
if consumed == NULL)

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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-27 16:41

Message:
Logged In: YES 
user_id=1200846

I replaced tests. Probably this is better instead of
comparing the two string generated by same decoder.

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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-27 14:44

Message:
Logged In: YES 
user_id=1200846

My real name is Hirokazu Yamamoto. But sorry, I don't have
FAX. (It's needed to send contributor form, isn't it?)

I'll attach the patch updated for trunk. And I'll attach the
tests.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-27 06:05

Message:
Logged In: YES 
user_id=21627

I have reservations against this patch because of the
quasi-anonymous nature of the submission. ocean-city, can
you please state your real name? Would you also be willing
to fill out a contributor form, as shown on

http://www.python.org/psf/contrib-form.html

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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-24 23:02

Message:
Logged In: YES 
user_id=1200846

OK, I'll try.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-24 06:44

Message:
Logged In: YES 
user_id=89016

This isn't a bugfix in the strictest sense, so IMHO this
patch shouldn't go into 2.4. 

If the patch goes into 2.5, it would need the appropriate
changes to encodings/mbcs.py (i.e. the IncrementalDecoder
would have to be changed (inheriting from
BufferedIncrementalDecoder).

I realize that this patch might be hard to test, as results
are dependent on locale. Nevertheless at least some tests
would be good (even if they are only run or do something
useful on a certain locale and are skipped otherwise).

ocean-city, can you update the patch for the trunk and add
tests?


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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-23 11:51

Message:
Logged In: YES 
user_id=1200846

Hello. This is my final patch. (mbcs4.patch)

 - mbcs3a.patch: _mbsbtype depends on locale not system ANSI
code page. so probably it's not good to use it with
MultiByteToWideChar.

 - mbcs3b.patch: CharNext may cause buffer overflow. and
this patch always calls CharPrev but it's not needed if
string is not terminated with "potensial" lead byte.

I hope this is stable enough to commit on repositry. Thank you.


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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-22 23:36

Message:
Logged In: YES 
user_id=1200846

Sorry, I was stupid.

MSDN
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_0o2t.asp)
saids,

> IsDBCSLeadByte can only indicate a potential lead byte value. 

IsDBCSLeadByte was returning 1 for some trail byte (ex: "???"[1])

The patch "mbcs3a.patch" worked for me, but _mbsbtype is
probably compiler specific. Is that OK?

The patch "mbcs3b.patch" also worked for me and it only uses
Win32API, but I don't have enough faith on this
implementation...



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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-22 19:31

Message:
Logged In: YES 
user_id=1200846

Sorry, I found problem when tried more long text file...
Please wait. I'll investigate more intensibly.

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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-22 19:13

Message:
Logged In: YES 
user_id=1200846

Thank you for reply. How about this? (I'm a newbie, I hope
this is right tex format but... can you confirm this? I
created this patch by copy & paste from
PyUnicode_DecodeUTF16Stateful and some modification)


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-22 18:12

Message:
Logged In: YES 
user_id=38388

One more nit: the doc patch is missing. Please add a patch
for the API docs.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-22 18:11

Message:
Logged In: YES 
user_id=38388

As I understand your comment, the mbcs codec will have a
problem if the input string terminates with a lead byte.

Could you add a comment regarding this to the patch ?!

I can't test the patch, since I don't have a Japanese
Windows to check on, but from looking at the patch, it seems OK.


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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-22 16:42

Message:
Logged In: YES 
user_id=1200846

I forgot to mention this. "mbcs.patch" is for
release24-maint branch.

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

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

From noreply at sourceforge.net  Fri Apr  7 13:36:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Apr 2006 04:36:41 -0700
Subject: [Patches] [ python-Patches-1180296 ] great improvement for
	locale.py formatting functions
Message-ID: <E1FRpGb-0008V2-Eq@sc8-sf-web2.sourceforge.net>

Patches item #1180296, was opened at 2005-04-10 18:00
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180296&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: Open
Resolution: None
Priority: 5
Submitted By: Georg Brandl (gbrandl)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: great improvement for locale.py formatting functions

Initial Comment:
This is a patch that adds two new functions to the
locale module.

The first, format_string(), can be used like str %
values, but takes the locale into account.
format() cannot be used for this since its grouping
feature currently does not work for arbitrary format
strings.

At the same time, this patch enhances format() so that
the user is notified by an exception that she should
only give one '%char' specification and nothing else.
The docs are also corrected.

The second function, currency(), formats a number
according to current currency locale settings.

The patch is complete with doc and test changes.
Please, test and comment!

Also corrects minor mistakes in doc.

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

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

From noreply at sourceforge.net  Fri Apr  7 17:46:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Apr 2006 08:46:16 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FRtA8-0001r8-Ud@sc8-sf-web5.sourceforge.net>

Patches item #1454844, was opened at 2006-03-20 19:41
Message generated for change (Comment added) made by zpincus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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
Submitted By: Zach Pincus (zpincus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Zach Pincus (zpincus)
Date: 2006-04-07 15:46

Message:
Logged In: YES 
user_id=748718

OK, so I've done all of the tests suggested on Python-Dev
and things look fine. Bob gave his approval of this patch
both on Python-Dev and earlier on PythonMac-SIG, so it
appears that this patch is ready to go.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-04 04:36

Message:
Logged In: YES 
user_id=748718

The test suite does load in a plain-vanilla fashion a
bunch of C python extensions, so that's some 
evidence that the basic stuff works. Better, the dl 
tests also works, so direct usage of dlopen seems 
OK.

As you point out, the best test is usage. All I can 
say here is that my use of this patch works OK, 
even with exotic modules which require setting
the dlopenflags. I've asked on python-dev if 
anyone can think of some better test cases.

Now, if this patch is deemed too radical, I agree
that it would be a good idea to teach 
dynload_next.c about the dlopenflags. This
would be a bit odd in the sense that the flags
on the mac would be interpreted not as 
'dlopenflags' with values from dlfcn.h, but as
nsmoduleflags, with values from mach-o/dyld.h.
However, this would be better than the 
current state of affairs.

Finally, if this patch isn't added, we should at
least fix the rest of the configure.in script in 
the manner suggested by the first comment,
so that other things don't start randomly
breaking when Darwin 10 comes around...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-03 17:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 14:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-27 18:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-27 17:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 08:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-22 02:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Sat Apr  8 22:48:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 08 Apr 2006 13:48:45 -0700
Subject: [Patches] [ python-Patches-1466993 ] socket.py: remove misleading
	comment
Message-ID: <E1FSKMP-0001Ek-I3@sc8-sf-web5.sourceforge.net>

Patches item #1466993, was opened at 2006-04-08 21: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=1466993&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.py: remove misleading comment

Initial Comment:
The comment removed by the patch is incorrect in Python
2.4 and 2.5: _socketobject has been used on ALL
platforms since revision 32056.


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

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

From noreply at sourceforge.net  Sun Apr  9 03:09:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 08 Apr 2006 18:09:11 -0700
Subject: [Patches] [ python-Patches-1467080 ] Many functions in socket
	module are not thread safe
Message-ID: <E1FSOQR-0006ds-OU@sc8-sf-web2.sourceforge.net>

Patches item #1467080, was opened at 2006-04-09 01: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=1467080&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: 5
Submitted By: Maxim Sobolev (sobomax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many functions in socket module are not thread safe

Initial Comment:
The socket module make a great effort to be thread-safe, but misses one 
big point - it uses single per-instance buffer to hold resolved 
sockaddr_xxx structures. Therefore, on SMP system it is possible that 
several threads calling functions that perform address resolution in 
parallel will stomp on each other resulting in incorrect or invalid address 
to be used in each case.

For example, two threads calling sendto() in parallel can result in packets 
to be sent to incorrect addresses - packets from thread one from time to 
time will be sent to address requested by thread two and vice versa.

Another, smaller issue is that the call to getnameinfo() is not protected 
with netdb mutex on systems that don't have thread-safe resolver.

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

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

From noreply at sourceforge.net  Sun Apr  9 14:18:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 05:18:10 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FSYrq-0000mg-Ch@sc8-sf-web6.sourceforge.net>

Patches item #1454844, was opened at 2006-03-21 06:41
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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
Submitted By: Zach Pincus (zpincus)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 22:18

Message:
Logged In: YES 
user_id=29957

I'll land this patch shortly.


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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-08 01:46

Message:
Logged In: YES 
user_id=748718

OK, so I've done all of the tests suggested on Python-Dev
and things look fine. Bob gave his approval of this patch
both on Python-Dev and earlier on PythonMac-SIG, so it
appears that this patch is ready to go.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-04 14:36

Message:
Logged In: YES 
user_id=748718

The test suite does load in a plain-vanilla fashion a
bunch of C python extensions, so that's some 
evidence that the basic stuff works. Better, the dl 
tests also works, so direct usage of dlopen seems 
OK.

As you point out, the best test is usage. All I can 
say here is that my use of this patch works OK, 
even with exotic modules which require setting
the dlopenflags. I've asked on python-dev if 
anyone can think of some better test cases.

Now, if this patch is deemed too radical, I agree
that it would be a good idea to teach 
dynload_next.c about the dlopenflags. This
would be a bit odd in the sense that the flags
on the mac would be interpreted not as 
'dlopenflags' with values from dlfcn.h, but as
nsmoduleflags, with values from mach-o/dyld.h.
However, this would be better than the 
current state of affairs.

Finally, if this patch isn't added, we should at
least fix the rest of the configure.in script in 
the manner suggested by the first comment,
so that other things don't start randomly
breaking when Darwin 10 comes around...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-04 03:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-04 00:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-28 05:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-28 04:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 19:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-22 13:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Sun Apr  9 16:28:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 07:28:34 -0700
Subject: [Patches] [ python-Patches-1466993 ] socket.py: remove misleading
	comment
Message-ID: <E1FSau2-0002qh-QN@sc8-sf-web3.sourceforge.net>

Patches item #1466993, was opened at 2006-04-08 20:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1466993&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.py: remove misleading comment

Initial Comment:
The comment removed by the patch is incorrect in Python
2.4 and 2.5: _socketobject has been used on ALL
platforms since revision 32056.


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-09 14:28

Message:
Logged In: YES 
user_id=849994

Thanks, applied in rev. 43746, 43747.

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

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

From noreply at sourceforge.net  Sun Apr  9 17:02:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 08:02:42 -0700
Subject: [Patches] [ python-Patches-1463867 ] Improved generator finalization
Message-ID: <E1FSbR4-0008RG-5M@sc8-sf-web4-b.sourceforge.net>

Patches item #1463867, was opened at 2006-04-04 00:43
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463867&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: Accepted
Priority: 5
Submitted By: Phillip J. Eby (pje)
>Assigned to: Phillip J. Eby (pje)
Summary: Improved generator finalization

Initial Comment:
This patch improves generator finalization such that
simple generators (without active try/except/finally
blocks surrounding yield statements) can have their
cycles broken.

Please check to see if this patch improves the leaks
that prompted the request for changing this.  Thanks.

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

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-09 17:02

Message:
Logged In: YES 
user_id=34209

The patch looks alright (although it could use some big
blinking comments in opcode.h and ceval.c, to make sure
PyGen_NeedsFinalizer is properly updated when new block
types are added.) The patch fixes the
test_generators_cycle.py leaker-test, but it does *not* fix
the cycles test_generators test. (Obviously after removing
the code that explicitly breaks the cycle in test_generators.)

I don't know why it doesn't clean up the test_generators
cycle. Maybe it's related to doctest, or the way doctests run.

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

Comment By: Phillip J. Eby (pje)
Date: 2006-04-05 22:06

Message:
Logged In: YES 
user_id=56214

Argh.  Sorry.  Uploaded.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-05 21:25

Message:
Logged In: YES 
user_id=31435

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

Please try again.

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

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

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

From noreply at sourceforge.net  Sun Apr  9 17:08:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 08:08:39 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FSbWp-000422-Vz@sc8-sf-web1.sourceforge.net>

Patches item #1454844, was opened at 2006-03-21 06:41
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Zach Pincus (zpincus)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-10 01:08

Message:
Logged In: YES 
user_id=29957

Checked in as r43748. I tested it on my OSX 10.3 box, seems
to work ok.


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 22:18

Message:
Logged In: YES 
user_id=29957

I'll land this patch shortly.


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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-08 01:46

Message:
Logged In: YES 
user_id=748718

OK, so I've done all of the tests suggested on Python-Dev
and things look fine. Bob gave his approval of this patch
both on Python-Dev and earlier on PythonMac-SIG, so it
appears that this patch is ready to go.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-04 14:36

Message:
Logged In: YES 
user_id=748718

The test suite does load in a plain-vanilla fashion a
bunch of C python extensions, so that's some 
evidence that the basic stuff works. Better, the dl 
tests also works, so direct usage of dlopen seems 
OK.

As you point out, the best test is usage. All I can 
say here is that my use of this patch works OK, 
even with exotic modules which require setting
the dlopenflags. I've asked on python-dev if 
anyone can think of some better test cases.

Now, if this patch is deemed too radical, I agree
that it would be a good idea to teach 
dynload_next.c about the dlopenflags. This
would be a bit odd in the sense that the flags
on the mac would be interpreted not as 
'dlopenflags' with values from dlfcn.h, but as
nsmoduleflags, with values from mach-o/dyld.h.
However, this would be better than the 
current state of affairs.

Finally, if this patch isn't added, we should at
least fix the rest of the configure.in script in 
the manner suggested by the first comment,
so that other things don't start randomly
breaking when Darwin 10 comes around...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-04 03:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-04 00:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-28 05:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-28 04:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 19:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-22 13:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Sun Apr  9 21:54:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 12:54:44 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FSfzg-0007un-I8@sc8-sf-web2.sourceforge.net>

Patches item #1454844, was opened at 2006-03-20 11:41
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Zach Pincus (zpincus)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-09 12:54

Message:
Logged In: YES 
user_id=33168

I have a question about the configure stanzas changed. 
There are 3 changes like this:

Darwin/@<:@01567@:>@\..*)

Except that the last one only goes through 6, not 7.  Are
they meant to be inconsistent?  Perhaps a comment should be
added to explain this if it's correct.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 08:08

Message:
Logged In: YES 
user_id=29957

Checked in as r43748. I tested it on my OSX 10.3 box, seems
to work ok.


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 05:18

Message:
Logged In: YES 
user_id=29957

I'll land this patch shortly.


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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-07 08:46

Message:
Logged In: YES 
user_id=748718

OK, so I've done all of the tests suggested on Python-Dev
and things look fine. Bob gave his approval of this patch
both on Python-Dev and earlier on PythonMac-SIG, so it
appears that this patch is ready to go.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 21:36

Message:
Logged In: YES 
user_id=748718

The test suite does load in a plain-vanilla fashion a
bunch of C python extensions, so that's some 
evidence that the basic stuff works. Better, the dl 
tests also works, so direct usage of dlopen seems 
OK.

As you point out, the best test is usage. All I can 
say here is that my use of this patch works OK, 
even with exotic modules which require setting
the dlopenflags. I've asked on python-dev if 
anyone can think of some better test cases.

Now, if this patch is deemed too radical, I agree
that it would be a good idea to teach 
dynload_next.c about the dlopenflags. This
would be a bit odd in the sense that the flags
on the mac would be interpreted not as 
'dlopenflags' with values from dlfcn.h, but as
nsmoduleflags, with values from mach-o/dyld.h.
However, this would be better than the 
current state of affairs.

Finally, if this patch isn't added, we should at
least fix the rest of the configure.in script in 
the manner suggested by the first comment,
so that other things don't start randomly
breaking when Darwin 10 comes around...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-03 10:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 07:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-27 10:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-27 09:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 00:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-21 18:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Sun Apr  9 22:25:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 13:25:53 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FSgTp-0008Ns-Qn@sc8-sf-web3.sourceforge.net>

Patches item #1454844, was opened at 2006-03-20 19:41
Message generated for change (Comment added) made by zpincus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Zach Pincus (zpincus)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Zach Pincus (zpincus)
Date: 2006-04-09 20:25

Message:
Logged In: YES 
user_id=748718

The stanzas that look like this (there are only two):
-  Darwin/@<:@01234567@:>@.*) 
+  Darwin/@<:@01567@:>@\..*) 
were added in response to the first comment about
not matching Darwin/10, and the absence of any
Darwin versions 2-4. These changes are actually
unrelated to the dynload_shlib.c issue, and should
be viewed as simply cleanup. Note that that part
of the patch doesn't change any behavior, it
just makes the regex better behaved.

The only stanza that changes any behavior is the
following:
-	Darwin/*) DYNLOADFILE="dynload_next.o";;
+	# Use dynload_next.c only on 10.2 and below, which don't have native 
dlopen()
+	Darwin/@<:@0156@:>@\..*) DYNLOADFILE="dynload_next.o";;
which is pretty self-explanatory.

Basically, the top two stanzas will match any
Darwin version < 10.4, whereas my change 
matches any version < 10.3. This just reflects
the version of Darwin that Apple added various
pieces of "standard" *nix functionality so that
Python no longer needed to work around them.

Hopefully that's all clear! Let me know if there
are further questions, and thanks for reviewing
the patch.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-09 19:54

Message:
Logged In: YES 
user_id=33168

I have a question about the configure stanzas changed. 
There are 3 changes like this:

Darwin/@<:@01567@:>@\..*)

Except that the last one only goes through 6, not 7.  Are
they meant to be inconsistent?  Perhaps a comment should be
added to explain this if it's correct.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 15:08

Message:
Logged In: YES 
user_id=29957

Checked in as r43748. I tested it on my OSX 10.3 box, seems
to work ok.


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 12:18

Message:
Logged In: YES 
user_id=29957

I'll land this patch shortly.


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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-07 15:46

Message:
Logged In: YES 
user_id=748718

OK, so I've done all of the tests suggested on Python-Dev
and things look fine. Bob gave his approval of this patch
both on Python-Dev and earlier on PythonMac-SIG, so it
appears that this patch is ready to go.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-04 04:36

Message:
Logged In: YES 
user_id=748718

The test suite does load in a plain-vanilla fashion a
bunch of C python extensions, so that's some 
evidence that the basic stuff works. Better, the dl 
tests also works, so direct usage of dlopen seems 
OK.

As you point out, the best test is usage. All I can 
say here is that my use of this patch works OK, 
even with exotic modules which require setting
the dlopenflags. I've asked on python-dev if 
anyone can think of some better test cases.

Now, if this patch is deemed too radical, I agree
that it would be a good idea to teach 
dynload_next.c about the dlopenflags. This
would be a bit odd in the sense that the flags
on the mac would be interpreted not as 
'dlopenflags' with values from dlfcn.h, but as
nsmoduleflags, with values from mach-o/dyld.h.
However, this would be better than the 
current state of affairs.

Finally, if this patch isn't added, we should at
least fix the rest of the configure.in script in 
the manner suggested by the first comment,
so that other things don't start randomly
breaking when Darwin 10 comes around...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-03 17:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 14:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-27 18:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-27 17:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 08:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-22 02:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Sun Apr  9 22:36:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 13:36:17 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FSgdt-00044Y-J9@sc8-sf-web4-b.sourceforge.net>

Patches item #1454844, was opened at 2006-03-20 19:41
Message generated for change (Comment added) made by zpincus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Zach Pincus (zpincus)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Zach Pincus (zpincus)
Date: 2006-04-09 20:36

Message:
Logged In: YES 
user_id=748718

The stanzas that look like this (there are only two):
-  Darwin/@<:@01234567@:>@.*) 
+  Darwin/@<:@01567@:>@\..*) 
were added in response to the first comment about
not matching Darwin/10, and the absence of any
Darwin versions 2-4. These changes are actually
unrelated to the dynload_shlib.c issue, and should
be viewed as simply cleanup. Note that that part
of the patch doesn't change any behavior, it
just makes the regex better behaved.

The only stanza that changes any behavior is the
following:
-	Darwin/*) DYNLOADFILE="dynload_next.o";;
+	# Use dynload_next.c only on 10.2 and below, which don't have native 
dlopen()
+	Darwin/@<:@0156@:>@\..*) DYNLOADFILE="dynload_next.o";;
which is pretty self-explanatory.

Basically, the top two stanzas will match any
Darwin version < 10.4, whereas my change 
matches any version < 10.3. This just reflects
the version of Darwin that Apple added various
pieces of "standard" *nix functionality so that
Python no longer needed to work around them.

Hopefully that's all clear! Let me know if there
are further questions, and thanks for reviewing
the patch.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-09 20:25

Message:
Logged In: YES 
user_id=748718

The stanzas that look like this (there are only two):
-  Darwin/@<:@01234567@:>@.*) 
+  Darwin/@<:@01567@:>@\..*) 
were added in response to the first comment about
not matching Darwin/10, and the absence of any
Darwin versions 2-4. These changes are actually
unrelated to the dynload_shlib.c issue, and should
be viewed as simply cleanup. Note that that part
of the patch doesn't change any behavior, it
just makes the regex better behaved.

The only stanza that changes any behavior is the
following:
-	Darwin/*) DYNLOADFILE="dynload_next.o";;
+	# Use dynload_next.c only on 10.2 and below, which don't have native 
dlopen()
+	Darwin/@<:@0156@:>@\..*) DYNLOADFILE="dynload_next.o";;
which is pretty self-explanatory.

Basically, the top two stanzas will match any
Darwin version < 10.4, whereas my change 
matches any version < 10.3. This just reflects
the version of Darwin that Apple added various
pieces of "standard" *nix functionality so that
Python no longer needed to work around them.

Hopefully that's all clear! Let me know if there
are further questions, and thanks for reviewing
the patch.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-09 19:54

Message:
Logged In: YES 
user_id=33168

I have a question about the configure stanzas changed. 
There are 3 changes like this:

Darwin/@<:@01567@:>@\..*)

Except that the last one only goes through 6, not 7.  Are
they meant to be inconsistent?  Perhaps a comment should be
added to explain this if it's correct.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 15:08

Message:
Logged In: YES 
user_id=29957

Checked in as r43748. I tested it on my OSX 10.3 box, seems
to work ok.


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 12:18

Message:
Logged In: YES 
user_id=29957

I'll land this patch shortly.


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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-07 15:46

Message:
Logged In: YES 
user_id=748718

OK, so I've done all of the tests suggested on Python-Dev
and things look fine. Bob gave his approval of this patch
both on Python-Dev and earlier on PythonMac-SIG, so it
appears that this patch is ready to go.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-04 04:36

Message:
Logged In: YES 
user_id=748718

The test suite does load in a plain-vanilla fashion a
bunch of C python extensions, so that's some 
evidence that the basic stuff works. Better, the dl 
tests also works, so direct usage of dlopen seems 
OK.

As you point out, the best test is usage. All I can 
say here is that my use of this patch works OK, 
even with exotic modules which require setting
the dlopenflags. I've asked on python-dev if 
anyone can think of some better test cases.

Now, if this patch is deemed too radical, I agree
that it would be a good idea to teach 
dynload_next.c about the dlopenflags. This
would be a bit odd in the sense that the flags
on the mac would be interpreted not as 
'dlopenflags' with values from dlfcn.h, but as
nsmoduleflags, with values from mach-o/dyld.h.
However, this would be better than the 
current state of affairs.

Finally, if this patch isn't added, we should at
least fix the rest of the configure.in script in 
the manner suggested by the first comment,
so that other things don't start randomly
breaking when Darwin 10 comes around...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-03 17:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 14:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-27 18:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-27 17:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 08:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-22 02:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Sun Apr  9 22:37:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 13:37:16 -0700
Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load
	extensions on Darwin, where possible
Message-ID: <E1FSgeq-0000ha-60@sc8-sf-web3.sourceforge.net>

Patches item #1454844, was opened at 2006-03-20 11:41
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Zach Pincus (zpincus)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Use dlopen() to load extensions on Darwin, where possible

Initial Comment:
Here is a patch to make Python on OS X 10.3 and above use dlopen() 
(via dynload_shlib.c) to load extension modules, and to make the dl 
module avaliable. 

The patch was generated against the SVN head as of yesterday, but can 
be applied (and I have done so with success) to Python 2.4.2.

RATIONALE
---------
On most unix-like operating systems, Python uses the dlopen() call to 
load extension modules. In addition, the way that these modules are 
opened can be modified via 'sys.setdlopenflags(...)'.

Modifications of how extensions are loaded are useful for several 
reasons (enough so that the standard Python docs (e.g. http://
docs.python.org/lib/module-sys.html ). In particular, if multiple 
modules need to share symbols, a call to sys.setdlopenflags is 
necessary.

Symbol sharing is especially important for interoperability of modules 
which wrap C++ classes, because GCC creates classes that resolve 
their run-time type identification by symbol identity. Thus, symbols 
must be shared globally for many C++ features to work properly for 
objects passed between modules.

On OS X / Darwin, Python uses some NeXT-derived APIs to load 
modules. Though these APIs provide analogues to the dlopenflags 
used to control how dlopen() loads modules, this interface is *not* 
exposed to the Python interpreter. Worse, sys.setdlopenflags remains 
available on Darwin, though calls to it are never heeded.

Fortunately, on OS X 10.3 and above, Apple has included dlopen as a 
standard function. In 10.3, this call is provided by a compatibility API; 
in 10.4, the dlopen() call is written to interface directly with the library 
loading mechanism and is now the recommended method for libraries 
to be opened for non Carbon/Cocoa tools.

IMPLEMENTATION
--------------
This (trivial) patch instructs the Python build process to use 
dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which 
uses the NeXT-derived APIs). It also allows for the dl module to be built 
in order to provide access to the proper values for the various dlopen 
flags.

TESTING
-------
This patch can be configured and built into executables that build and 
test correctly on 10.3 and 10.4.

Because Python 2.5 and 2.4 do not currently compile properly on OS X 
10.2, I have not built or tested this patch on that OS version. However, 
the configure and compile process does select the appropriate 
dynload_next.c file to use, and compiles that correctly before breaking 
elsewhere. Thus, if the other errors are fixed for 10.2, these patches 
will work fine. (This is because they only change Python's behavior for 
10.3 and up.)

PATCHES
-------
There are three main components to the attached patch.

The first is a patch the 'configure.in' file to use dynload_shlib.c when it 
can, and a patch to the 'configure' file to sync it up with 'configure.in'. 

The second is a minor change to 'setup.py' and the dl module test to 
allow the dl module to be built and tested on OS X systems where dlfcn 
is available. (10.3 and above.)

The last part of the patchfile should be considered optional. This patch 
applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl 
test is not expected to be skipped anymore.

This is optional because if Python is ever built on 10.2, the test script 
will expect dl to work, when it only works on 10.3 and above. However, 
if Python on 10.2 is officially not supported, then this change should 
be made to properly test the dl functionality on all supported OS X 
platforms.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-09 13:37

Message:
Logged In: YES 
user_id=33168

Oh, I think I understand why I'm confused--this is confusing
crap.  Can we put a table that maps the names appropriately
for those of us that don't know these things?  Something
like this (I don't know if it's correct, but you get the idea):

Darwin/0\..*  OS X 10.0
Darwin/1\..*  OS X 10.1
Darwin/2\..*  Does not exist
Darwin/3\..*  Does not exist
Darwin/4\..*  Does not exist
Darwin/5\..*  OS X 10.2
Darwin/6\..*  OS X 10.3
Darwin/7\..*  OS X 10.4


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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-09 13:36

Message:
Logged In: YES 
user_id=748718

The stanzas that look like this (there are only two):
-  Darwin/@<:@01234567@:>@.*) 
+  Darwin/@<:@01567@:>@\..*) 
were added in response to the first comment about
not matching Darwin/10, and the absence of any
Darwin versions 2-4. These changes are actually
unrelated to the dynload_shlib.c issue, and should
be viewed as simply cleanup. Note that that part
of the patch doesn't change any behavior, it
just makes the regex better behaved.

The only stanza that changes any behavior is the
following:
-	Darwin/*) DYNLOADFILE="dynload_next.o";;
+	# Use dynload_next.c only on 10.2 and below, which don't have native 
dlopen()
+	Darwin/@<:@0156@:>@\..*) DYNLOADFILE="dynload_next.o";;
which is pretty self-explanatory.

Basically, the top two stanzas will match any
Darwin version < 10.4, whereas my change 
matches any version < 10.3. This just reflects
the version of Darwin that Apple added various
pieces of "standard" *nix functionality so that
Python no longer needed to work around them.

Hopefully that's all clear! Let me know if there
are further questions, and thanks for reviewing
the patch.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-09 13:25

Message:
Logged In: YES 
user_id=748718

The stanzas that look like this (there are only two):
-  Darwin/@<:@01234567@:>@.*) 
+  Darwin/@<:@01567@:>@\..*) 
were added in response to the first comment about
not matching Darwin/10, and the absence of any
Darwin versions 2-4. These changes are actually
unrelated to the dynload_shlib.c issue, and should
be viewed as simply cleanup. Note that that part
of the patch doesn't change any behavior, it
just makes the regex better behaved.

The only stanza that changes any behavior is the
following:
-	Darwin/*) DYNLOADFILE="dynload_next.o";;
+	# Use dynload_next.c only on 10.2 and below, which don't have native 
dlopen()
+	Darwin/@<:@0156@:>@\..*) DYNLOADFILE="dynload_next.o";;
which is pretty self-explanatory.

Basically, the top two stanzas will match any
Darwin version < 10.4, whereas my change 
matches any version < 10.3. This just reflects
the version of Darwin that Apple added various
pieces of "standard" *nix functionality so that
Python no longer needed to work around them.

Hopefully that's all clear! Let me know if there
are further questions, and thanks for reviewing
the patch.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-09 12:54

Message:
Logged In: YES 
user_id=33168

I have a question about the configure stanzas changed. 
There are 3 changes like this:

Darwin/@<:@01567@:>@\..*)

Except that the last one only goes through 6, not 7.  Are
they meant to be inconsistent?  Perhaps a comment should be
added to explain this if it's correct.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 08:08

Message:
Logged In: YES 
user_id=29957

Checked in as r43748. I tested it on my OSX 10.3 box, seems
to work ok.


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 05:18

Message:
Logged In: YES 
user_id=29957

I'll land this patch shortly.


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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-07 08:46

Message:
Logged In: YES 
user_id=748718

OK, so I've done all of the tests suggested on Python-Dev
and things look fine. Bob gave his approval of this patch
both on Python-Dev and earlier on PythonMac-SIG, so it
appears that this patch is ready to go.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 21:36

Message:
Logged In: YES 
user_id=748718

The test suite does load in a plain-vanilla fashion a
bunch of C python extensions, so that's some 
evidence that the basic stuff works. Better, the dl 
tests also works, so direct usage of dlopen seems 
OK.

As you point out, the best test is usage. All I can 
say here is that my use of this patch works OK, 
even with exotic modules which require setting
the dlopenflags. I've asked on python-dev if 
anyone can think of some better test cases.

Now, if this patch is deemed too radical, I agree
that it would be a good idea to teach 
dynload_next.c about the dlopenflags. This
would be a bit odd in the sense that the flags
on the mac would be interpreted not as 
'dlopenflags' with values from dlfcn.h, but as
nsmoduleflags, with values from mach-o/dyld.h.
However, this would be better than the 
current state of affairs.

Finally, if this patch isn't added, we should at
least fix the rest of the configure.in script in 
the manner suggested by the first comment,
so that other things don't start randomly
breaking when Darwin 10 comes around...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-03 10:30

Message:
Logged In: YES 
user_id=580910

I'm not too confident that running the testsuite would uncover problems with 
this patch, but the fact that you're running with this patch without running into 
problems indicate that this patch should be save.

I'm in favor of applying this patch (all of it) as this helps a usecase that comes 
up regularly on the pythonmac-sig mailinglist and seems to be safe. This patch 
isn't applied dynload_next should IMO be taught about sys.setdlopenflags.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-04-03 07:43

Message:
Logged In: YES 
user_id=748718

Another point --

The functions used in dynload_next.c, which is what Python
currently uses to load extensions on OS X, are officially
'discouraged' by Apple, in favor of the dlopen() functions:

http://developer.apple.com/documentation/DeveloperTools/Reference/
MachOReference/index.html

Here's dynload_next.c, for reference.
http://svn.python.org/view/python/trunk/Python/dynload_next.c?view=auto

Thus, it rather makes sense to move Python from this old and
in all probability soon-to-be-deprecated code path.

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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-27 10:40

Message:
Logged In: YES 
user_id=748718

Ronald -
I am unfortunately not an expert on windows DLL loading. I do know that in 
non-GCC C++ implementations, it becomes far less critical to share symbols 
globally in many circumstances, because non-GCC C++ implementations 
tend to use string comparisons to resolve C++ object identity, and not use 
exact address comparisons on the typeinfo objects. Thus, these objects do 
not need to be shared between windows DLLs.

Beyond that, I do not know whether symbols from DLLs are loaded with 
global visibility in windows or not. Certainly the windows dlopen() equivalent 
*does not* support mode options. I presume anything tagged with _declspec
(dllexport) is loaded globally when the DLL is opened, but I am not sure.

However, that issue is largely tangential to the question of whether Python on 
OS X should work like Python on every other Unix-like system...

As to your other question -- have I checked if this will break existing python 
code -- the answer is of course yes. The python regression suite test passes 
on both 10.3 and 10.4 with this modification (as I mentioned), so that's a 
good indication that run-of-the-mill code will not be affected.

In fact, on 10.3, the dlopen() call is implemented under the hood with the 
exact same calls that Python's dynload_next.c file uses. In 10.4 this was 
changed so that both APIs talk to the same underlying system. Thus, nothing 
is really changing: both are functionally identical ways of getting the same OS 
X runtime loader (dyld) to load a bundle from disk. The only difference is that 
by using dlopen(), there are hooks in Python for manipulating the mode that 
is used to load that bundle from disk.

So, I cannot imagine a situation where this change would break code on the 
mac. While argument from failure of imagination is typically weak, this 
combined with the fact that the python tests pass without difficulty (including 
the dl module test), I am fairy confident in this patch. Moreover, I have been 
using this patch on my own computer for some time and have not run into 
any difficulties, even when loading fairly complex custom extensions.

Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's 
zero possibility that it would affect anything on other platforms.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-03-27 09:25

Message:
Logged In: YES 
user_id=580910

I have a number of questions. Firstly, how does symbol sharing between 
extensions work on windows? And more importantly, have you checked if this 
will break existing python code?



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

Comment By: Zach Pincus (zpincus)
Date: 2006-03-22 00:34

Message:
Logged In: YES 
user_id=748718

I just uploaded a new patch which addresses this issue, and fixes this same 
problem in a few other locations in the configure script.

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

Comment By: Andrew Barnert (barnert)
Date: 2006-03-21 18:31

Message:
Logged In: YES 
user_id=1473180

One minor issue: Your pattern will match Darwin 10.0, which will come out in 
a few years as part of OS X 10.7, by which time nobody will remember why 
this script is written this way. Since it's easy to handle now, we might as well 
do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), 
so anyone who matches Darwin/2.* will be a false match.

Here's what I'd suggest:

+       Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";;

Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't 
tried anything too sophisticated.


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

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

From noreply at sourceforge.net  Mon Apr 10 03:35:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 18:35:07 -0700
Subject: [Patches] [ python-Patches-1461822 ] "const int" was truncated to
	"char"
Message-ID: <E1FSlJ5-00063D-B5@sc8-sf-web4-b.sourceforge.net>

Patches item #1461822, was opened at 2006-03-31 12:15
Message generated for change (Settings changed) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1461822&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: Fixed
Priority: 5
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: "const int" was truncated to "char"

Initial Comment:
Hello. I got this warning message in building trunk
with VC6. This happens because "char" == "signed char"
in my environment, and 255 is out of range of signed char.

Probably attached patch will solve problem. Thank you.

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

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

From noreply at sourceforge.net  Mon Apr 10 04:22:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 9 Apr 2006 19:22:47 -0700
Subject: [Patches] [ python-Patches-1459011 ] Mutable Iterators PEP
Message-ID: <200604100222.k3A2MlEq025744@sc8-sf-db2-new-b.sourceforge.net>

Patches item #1459011, was opened at 03/26/06 18:08
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459011&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: Later
Priority: 1
Submitted By: Adam DePrince (adamdeprince)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mutable Iterators PEP

Initial Comment:
This patch is a partial implementation of the mutable
iterators PEP currently being discussed on the
python-3000 mailing list.  

It differs from the PEP in a few ways:

1. We havn't quite eliminiated the annoying iter
variants of dict.keys/values/items because parts of the
python proper expect the non iter variants to return
something indexable.

2. We currently don't support the java fast-fail
semantics for concurrent mutation.  This requires some
discussion, because it might involve a small
performance burden on all structures that support
mutable iterators, evne when there are currrently
running.  

While the eliminiation of iter{keys/items/values} is
hoped for 3.0, there is no reason the iters couldn't
silently become mutable for 2.5.  I'll discuss this in
morn depth on the mailing list. 

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

>Comment By: SourceForge Robot (sf-robot)
Date: 04/09/06 19:22

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

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

From noreply at sourceforge.net  Mon Apr 10 05:26:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 20:26:05 -0700
Subject: [Patches] [ python-Patches-1467512 ] fix double free with tqs in
	standard build
Message-ID: <E1FSn2T-0004lR-Ok@sc8-sf-web5.sourceforge.net>

Patches item #1467512, was opened at 2006-04-09 20: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=1467512&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix double free with tqs in standard build

Initial Comment:
Fix for
http://mail.python.org/pipermail/python-dev/2006-April/063572.html

Convert all PyMem_* to PyObject_* that way we can't
have an inconsistent use of PyMem_ and PyObject_ APIs
in the Parser.  This could even be a perf win if more
of the allocations are smaller than 256 bytes.  I don't
know if that's more common though.

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

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

From noreply at sourceforge.net  Mon Apr 10 06:02:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 21:02:49 -0700
Subject: [Patches] [ python-Patches-1467512 ] fix double free with tqs in
	standard build
Message-ID: <E1FSnc1-0006mL-9C@sc8-sf-web4-b.sourceforge.net>

Patches item #1467512, was opened at 2006-04-09 23:26
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1467512&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
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Tim Peters (tim_one)
Summary: fix double free with tqs in standard build

Initial Comment:
Fix for
http://mail.python.org/pipermail/python-dev/2006-April/063572.html

Convert all PyMem_* to PyObject_* that way we can't
have an inconsistent use of PyMem_ and PyObject_ APIs
in the Parser.  This could even be a perf win if more
of the allocations are smaller than 256 bytes.  I don't
know if that's more common though.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-10 00:02

Message:
Logged In: YES 
user_id=6380

Works for me.  Thanks for the quick fix!

I suppose Tim should review this.

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

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

From noreply at sourceforge.net  Mon Apr 10 06:19:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 21:19:15 -0700
Subject: [Patches] [ python-Patches-1467512 ] fix double free with tqs in
	standard build
Message-ID: <E1FSnrv-0005e5-De@sc8-sf-web2.sourceforge.net>

Patches item #1467512, was opened at 2006-04-09 23:26
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1467512&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: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: fix double free with tqs in standard build

Initial Comment:
Fix for
http://mail.python.org/pipermail/python-dev/2006-April/063572.html

Convert all PyMem_* to PyObject_* that way we can't
have an inconsistent use of PyMem_ and PyObject_ APIs
in the Parser.  This could even be a perf win if more
of the allocations are smaller than 256 bytes.  I don't
know if that's more common though.

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

>Comment By: Tim Peters (tim_one)
Date: 2006-04-10 00:19

Message:
Logged In: YES 
user_id=31435

I noted some cautions on python-dev, but marked Accepted. 
In general I'm nervous about more-or-less mindless s/x/y/g
patches, but Guido's bug is proof that my time-consuming
selective approach may well not be the best approach to this
mess :-)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-10 00:02

Message:
Logged In: YES 
user_id=6380

Works for me.  Thanks for the quick fix!

I suppose Tim should review this.

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

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

From noreply at sourceforge.net  Mon Apr 10 06:40:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 21:40:04 -0700
Subject: [Patches] [ python-Patches-1467512 ] fix double free with tqs in
	standard build
Message-ID: <E1FSoC4-0005WG-EO@sc8-sf-web3.sourceforge.net>

Patches item #1467512, was opened at 2006-04-09 20:26
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1467512&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: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: fix double free with tqs in standard build

Initial Comment:
Fix for
http://mail.python.org/pipermail/python-dev/2006-April/063572.html

Convert all PyMem_* to PyObject_* that way we can't
have an inconsistent use of PyMem_ and PyObject_ APIs
in the Parser.  This could even be a perf win if more
of the allocations are smaller than 256 bytes.  I don't
know if that's more common though.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-09 21:40

Message:
Logged In: YES 
user_id=33168

Heh, I'm going the opposite direction.  I'm going to
selectively move some of the known big calls back to
PyMem_*.  I also notice that there are a lot of allocs
without this patch are larger than 256 bytes.  I'm going to
research those too.  Thanks for the review.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-09 21:19

Message:
Logged In: YES 
user_id=31435

I noted some cautions on python-dev, but marked Accepted. 
In general I'm nervous about more-or-less mindless s/x/y/g
patches, but Guido's bug is proof that my time-consuming
selective approach may well not be the best approach to this
mess :-)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-09 21:02

Message:
Logged In: YES 
user_id=6380

Works for me.  Thanks for the quick fix!

I suppose Tim should review this.

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

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

From noreply at sourceforge.net  Mon Apr 10 08:42:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 23:42:49 -0700
Subject: [Patches] [ python-Patches-1467512 ] fix double free with tqs in
	standard build
Message-ID: <E1FSq6r-0003R5-4L@sc8-sf-web1.sourceforge.net>

Patches item #1467512, was opened at 2006-04-09 20:26
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1467512&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: fix double free with tqs in standard build

Initial Comment:
Fix for
http://mail.python.org/pipermail/python-dev/2006-April/063572.html

Convert all PyMem_* to PyObject_* that way we can't
have an inconsistent use of PyMem_ and PyObject_ APIs
in the Parser.  This could even be a perf win if more
of the allocations are smaller than 256 bytes.  I don't
know if that's more common though.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-09 23:42

Message:
Logged In: YES 
user_id=33168

The only inconsistency I could find was at line 818 of
tokenizer.c:

tok->buf = new;

new is PyMem_*, but tok->buf is PyObject_* everywhere except
this assignment.

I didn't see an easy fix other than reallocating and copying
instead of the assignment.

I undid a few of the changes in the patch.

Committed revision 45225.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-09 21:40

Message:
Logged In: YES 
user_id=33168

Heh, I'm going the opposite direction.  I'm going to
selectively move some of the known big calls back to
PyMem_*.  I also notice that there are a lot of allocs
without this patch are larger than 256 bytes.  I'm going to
research those too.  Thanks for the review.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-09 21:19

Message:
Logged In: YES 
user_id=31435

I noted some cautions on python-dev, but marked Accepted. 
In general I'm nervous about more-or-less mindless s/x/y/g
patches, but Guido's bug is proof that my time-consuming
selective approach may well not be the best approach to this
mess :-)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-09 21:02

Message:
Logged In: YES 
user_id=6380

Works for me.  Thanks for the quick fix!

I suppose Tim should review this.

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

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

From noreply at sourceforge.net  Mon Apr 10 08:44:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 09 Apr 2006 23:44:26 -0700
Subject: [Patches] [ python-Patches-1463288 ] clean up new calendar locale
	usage
Message-ID: <E1FSq8Q-0006GP-6n@sc8-sf-web2.sourceforge.net>

Patches item #1463288, was opened at 2006-04-02 20:21
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463288&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: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Walter D?rwald (doerwalter)
Summary: clean up new calendar locale usage

Initial Comment:
Walter,

I don't know if this is really better or not.  I was
wondering if the new with statement would help cleanup
the locale handling (all the try-finallys).  It reduces
the total lines of code a little bit.  It seems a
little cleaner to me.  I didn't see any tests for the
new classes, so I only tested on the command line and
it seemed to work.  Regardless of whether you like this
patch or not, it would be good to add tests for the new
classes in calendar.

I'm probably about +0 on this patch.  It was more an
experiment to see if the code was clearer.  I think
it's marginally better at most.

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

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

From noreply at sourceforge.net  Mon Apr 10 09:50:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 00:50:40 -0700
Subject: [Patches] [ python-Patches-1462222 ] Functioning Tix.Grid
Message-ID: <E1FSrAW-0006jz-Uc@sc8-sf-web6.sourceforge.net>

Patches item #1462222, was opened at 2006-03-31 18:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462222&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 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Martin v. L??wis (loewis)
Summary: Functioning Tix.Grid

Initial Comment:
This patch to Tix.py provides the basic functionality
needed for the tixGrid widget to work in Tix
applications.  As I unravel the Tix C / Tcl/Tk code and
find out what more functionality is available, I will
update the patch.

There will be an associated patch providing a module to
be used with tixwidgets.py as a demo.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 09:50

Message:
Logged In: YES 
user_id=21627

That patch can't be right: it introduces empty function
selection_adjust etc. These functions should, of course,
invoke the underlying widget commands.

Please provide a patch that can be used as-is. It might be
incomplete (i.e. not expose all functionality), but for the
functionality it provides, it should be correct.

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

Comment By: Christos Georgiou (tzot)
Date: 2006-04-03 12:58

Message:
Logged In: YES 
user_id=539787

Accepting this patch closes bug 1036406.

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

Comment By: Christos Georgiou (tzot)
Date: 2006-03-31 18:31

Message:
Logged In: YES 
user_id=539787

Here follows code (testgrid.py) I use to test the patched
Tix.py, used as 'python -i testgrid.py'

###
import Tix as tk
from pprint import pprint

r= tk.Tk()
r.title("test")

l=tk.Label(r, name="a_label")
l.pack()

class MyGrid(tk.Grid):
    def __init__(self, *args, **kwargs):
        kwargs['editnotify']= self.editnotify
        tk.Grid.__init__(self, *args, **kwargs)
    def editnotify(self, x, y):
        return True

g = MyGrid(r, name="a_grid", selectunit="cell")
g.pack(fill=tk.BOTH)
for x in xrange(5):
    for y in xrange(5):
        g.set(x,y,text=str((x,y)))

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

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

From noreply at sourceforge.net  Mon Apr 10 10:07:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 01:07:51 -0700
Subject: [Patches] [ python-Patches-1462222 ] Functioning Tix.Grid
Message-ID: <E1FSrR9-0000J1-CN@sc8-sf-web1.sourceforge.net>

Patches item #1462222, was opened at 2006-03-31 19:28
Message generated for change (Comment added) made by tzot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462222&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 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Martin v. L??wis (loewis)
Summary: Functioning Tix.Grid

Initial Comment:
This patch to Tix.py provides the basic functionality
needed for the tixGrid widget to work in Tix
applications.  As I unravel the Tix C / Tcl/Tk code and
find out what more functionality is available, I will
update the patch.

There will be an associated patch providing a module to
be used with tixwidgets.py as a demo.

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

>Comment By: Christos Georgiou (tzot)
Date: 2006-04-10 11:07

Message:
Logged In: YES 
user_id=539787

You are right.  Changed empty functions to comments similar
to those pre-existing in order to mark missing
functionality. New patch provided.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 10:50

Message:
Logged In: YES 
user_id=21627

That patch can't be right: it introduces empty function
selection_adjust etc. These functions should, of course,
invoke the underlying widget commands.

Please provide a patch that can be used as-is. It might be
incomplete (i.e. not expose all functionality), but for the
functionality it provides, it should be correct.

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

Comment By: Christos Georgiou (tzot)
Date: 2006-04-03 13:58

Message:
Logged In: YES 
user_id=539787

Accepting this patch closes bug 1036406.

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

Comment By: Christos Georgiou (tzot)
Date: 2006-03-31 19:31

Message:
Logged In: YES 
user_id=539787

Here follows code (testgrid.py) I use to test the patched
Tix.py, used as 'python -i testgrid.py'

###
import Tix as tk
from pprint import pprint

r= tk.Tk()
r.title("test")

l=tk.Label(r, name="a_label")
l.pack()

class MyGrid(tk.Grid):
    def __init__(self, *args, **kwargs):
        kwargs['editnotify']= self.editnotify
        tk.Grid.__init__(self, *args, **kwargs)
    def editnotify(self, x, y):
        return True

g = MyGrid(r, name="a_grid", selectunit="cell")
g.pack(fill=tk.BOTH)
for x in xrange(5):
    for y in xrange(5):
        g.set(x,y,text=str((x,y)))

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

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

From noreply at sourceforge.net  Mon Apr 10 10:35:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 01:35:38 -0700
Subject: [Patches] [ python-Patches-1462222 ] Functioning Tix.Grid
Message-ID: <E1FSrs2-00070I-7f@sc8-sf-web4-b.sourceforge.net>

Patches item #1462222, was opened at 2006-03-31 18:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462222&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 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Martin v. L??wis (loewis)
Summary: Functioning Tix.Grid

Initial Comment:
This patch to Tix.py provides the basic functionality
needed for the tixGrid widget to work in Tix
applications.  As I unravel the Tix C / Tcl/Tk code and
find out what more functionality is available, I will
update the patch.

There will be an associated patch providing a module to
be used with tixwidgets.py as a demo.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 10:35

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as r45229.

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

Comment By: Christos Georgiou (tzot)
Date: 2006-04-10 10:07

Message:
Logged In: YES 
user_id=539787

You are right.  Changed empty functions to comments similar
to those pre-existing in order to mark missing
functionality. New patch provided.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 09:50

Message:
Logged In: YES 
user_id=21627

That patch can't be right: it introduces empty function
selection_adjust etc. These functions should, of course,
invoke the underlying widget commands.

Please provide a patch that can be used as-is. It might be
incomplete (i.e. not expose all functionality), but for the
functionality it provides, it should be correct.

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

Comment By: Christos Georgiou (tzot)
Date: 2006-04-03 12:58

Message:
Logged In: YES 
user_id=539787

Accepting this patch closes bug 1036406.

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

Comment By: Christos Georgiou (tzot)
Date: 2006-03-31 18:31

Message:
Logged In: YES 
user_id=539787

Here follows code (testgrid.py) I use to test the patched
Tix.py, used as 'python -i testgrid.py'

###
import Tix as tk
from pprint import pprint

r= tk.Tk()
r.title("test")

l=tk.Label(r, name="a_label")
l.pack()

class MyGrid(tk.Grid):
    def __init__(self, *args, **kwargs):
        kwargs['editnotify']= self.editnotify
        tk.Grid.__init__(self, *args, **kwargs)
    def editnotify(self, x, y):
        return True

g = MyGrid(r, name="a_grid", selectunit="cell")
g.pack(fill=tk.BOTH)
for x in xrange(5):
    for y in xrange(5):
        g.set(x,y,text=str((x,y)))

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

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

From noreply at sourceforge.net  Mon Apr 10 14:40:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 05:40:06 -0700
Subject: [Patches] [ python-Patches-1429775 ] Link Python modules to
	libpython on linux if --enable-shared
Message-ID: <E1FSvgc-0003e6-Ot@sc8-sf-web2.sourceforge.net>

Patches item #1429775, was opened at 2006-02-11 18:52
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429775&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Gustavo J. A. M. Carneiro (gustavo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Link Python modules to libpython on linux if --enable-shared

Initial Comment:
The problem description and discussion starts here:
http://mail.python.org/pipermail/python-dev/2006-February/060533.html


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 14:40

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as 45232

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

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-02-20 12:28

Message:
Logged In: YES 
user_id=908

Yes; sorry, I didn't notice the other bug.

PS: SF bug tracker is horrible

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:36

Message:
Logged In: YES 
user_id=1188172

I assume this would resolve bug #832799.

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

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

From noreply at sourceforge.net  Mon Apr 10 15:01:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 06:01:21 -0700
Subject: [Patches] [ python-Patches-1412448 ] Compile under mingw properly
Message-ID: <E1FSw1B-0007S6-P0@sc8-sf-web5.sourceforge.net>

Patches item #1412448, was opened at 2006-01-23 03:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412448&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Gir?o Bezerra de Mene (alexgirao)
Assigned to: Martin v. L??wis (loewis)
Summary: Compile under mingw properly

Initial Comment:
Hi,

 I made only simple changes to let gcc happy with win
related code and to compile without warnings.

Alexadre Girao,
http://nextt.org


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 15:01

Message:
Logged In: YES 
user_id=21627

Unfortunately, the patch is unacceptable in its current
form. Some of the changes seem essential to make Python work
with Mingw, others seem merely aesthetical (i.e. those that
make warnings go away).

Some of the changes that make warnings go away look wrong:
the code is right as it stands, and if you get a warning
with MingW, it's either that the compiler is wrong, or some
other part of the setup is broken.

Would you be willing to rework the patch to only include the
fragments that are absolutely necessary to make it compile
and work correctly? Also, it would be much more useful if
you could forward-port the patch to the 2.5 subversion trunk.

Among the things I consider faulty are:
- inclusion of wincrypt.h
- addition of a parenthesis around the cFileName[1/2] block
- explicit conversion of arguments to const char**


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

Comment By: Alexandre Gir?o Bezerra de Mene (alexgirao)
Date: 2006-01-25 00:34

Message:
Logged In: YES 
user_id=700047

Most of the changes were related to correct usage of braces 
and incompatibilities with mingw (note that i compiled with 
msvc too). The parenthesis changes apply to msvc too.

I thank you so much for paying attention on this.


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-01-25 00:19

Message:
Logged In: YES 
user_id=764593

Are you sure these were just compiler-related?

Changing things like frequency from {0,0} to {{0,}} or 
adding parentheses strike me as at least possible bugfixes 
that should not be in #ifdefs

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

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

From noreply at sourceforge.net  Mon Apr 10 15:41:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 06:41:58 -0700
Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime
	tunable
Message-ID: <E1FSweU-0001fr-D7@sc8-sf-web5.sourceforge.net>

Patches item #1454481, was opened at 2006-03-20 13:37
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&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
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make thread stack size runtime tunable

Initial Comment:
Platform default thread stack sizes vary considerably.
Some are very generous (Win32: usually 1MB; Linux: 1MB,
sometimes 8MB).  Others are not (FreeBSD: 64k).

Some platforms have restricted virtual address space
OS/2: 512M less overhead) which makes hard coding a
generous default thread stack size problematic.  Some
platforms thread commit stack address space, even
though the memory backing it may not be committed
(Windows, OS/2 at least).

Some applications have a thirst for stack space in
threads (Zope). Some programmers want to be able to use
lots of threads, even in the face of sound advice about
the lack of wisdom in this approach.

The current approach to stack space management in
threads in Python uses a hard coded strategy, relying
on the platform having a useful default or relying on
the system administrator or distribution builder
over-riding the default at compile time.

This patch is intended to allow developers some control
over managing this resource from within Python code by
way of a function in the thread module.  As written, it
is not intended to provide unlimited flexibility; that
would probably require exposing the underlying
mechanism as an option on the creation of each thread.

An alternative approach to providing the functionality
would be to use an environment variable to provide the
information to the thread module.  This has its pros
and cons, in terms of flexibility and ease of use, and
could be complementary to the approach implemented.

The patch has been tested on OS/2 and FreeBSD 4.8.  I
have no means of testing the code on Win32 or Linux,
though Linux is a pthread environment as is FreeBSD. 
Code base is SVN head from a few hours ago. A doc 
update is included.

While I would like to see this functionality in Python
2.5, it is not a critical issue.

Critique of the approach and implementation welcome. 
Something not addressed is the issue of tests,
primarily because I haven't been able to think of a
viable testing strategy - I'm all ears to suggestions
for this.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 15:41

Message:
Logged In: YES 
user_id=21627

Usage of pthread_attr_setstacksize should be conditional on
the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to
POSIX. Errors from pthread_attr_setstacksize should be
reported (POSIX lists EINVAL as a possible error).

I think PTHREAD_STACK_MIN should be considered. 

The documentation should list availibility of the feature,
currently Win32, OS/2, and POSIX threads (with the TSS
option, to be precise). If some platforms have specific
additional requirements on the possible values (eg. must be
a multiple of the page size), these should be documented, as
well.

Apart from that, the patch looks fine.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-03-22 09:28

Message:
Logged In: YES 
user_id=250749

Thanks for the comments.

As implemented, the function is both a getter and
(optionally) a setter which makes attempting to use a
"get"/"set" prefix 
awkward.

I chose this approach to make it a little simpler to support
temporary changes.  I did consider using a module
attribute/variable, but it is slightly more unwieldy for
this case:

old_size = thread.stack_size(new_size)
...
thread.stack_size(old_size)

vs

old_size = thread.stack_size
thread.stack_size = new_size
...
thread.stack_size = old_size

or (using get/set accessors)

old_size = thread.get_stacksize()
thread.set_stacksize(new_size)
...
thread.set_stacksize(old_size)

I think an argument can be made for passing on the
"get"/"set" naming consistency based on the guidelines in
PEP 8.  While I have a preference for what I've implemented,
I'm more interested in getting the functionality in than
debating its decor.  If there's a strong view about these 
issues, I'm prepared to revise the patch accordingly.

I don't believe that the functionality belongs anywhere else
than the thread module, except possibly shadowing it in the
threading module, as it is highly specific to thread
support.  The sys module seems more appropriate for general 
knobs, and only for specific knobs when there is no other
choice IMO.  Doing it outside the thread module also
complicates the implementation, which I was trying to keep
as simple as I could.


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

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-20 14:58

Message:
Logged In: YES 
user_id=55188

I'm all for this!  The FreeBSD port have maintained a local
patch to bump THREAD_STACK_SIZE.  The patch will lighten
FreeBSD users' burden around thread stack size.

BTW, the naming, "thread.stack_size" seems to miss a verb
while all the other functions on the thread module have it.
 How about set_stack_size() or set_stacksize()?  Or, how
about in sys module?

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

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

From noreply at sourceforge.net  Mon Apr 10 16:28:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 07:28:57 -0700
Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main()
	with C++ compiler
Message-ID: <E1FSxNx-0004lF-HK@sc8-sf-web5.sourceforge.net>

Patches item #1324762, was opened at 2005-10-12 13:45
Message generated for change (Comment added) made by jholg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&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
Submitted By: Christoph Ludwig (cludwig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling and linking main() with C++ compiler

Initial Comment:
The attached patch proposes a resolution to the discussion 
started in 
<url:http://thread.gmane.org/gmane.comp.python.devel/69651> 
regarding the compiler (C vs. C++) used to compile python's 
main() and to link the executable.  
 
The patch contains the following changes: 
 
1) The configure option --with-cxx is renamed 
--with-cxx-main. This was done to avoid surprising the user 
by the changed meaning. Furthermore, it is now possible 
that CXX has a different value than provided by 
--with-cxx-main, so the old name would have been 
confusing. 
 
2) The compiler used to translate python's main() function is 
stored in the configure / Makefile variable MAINCC. By 
default, MAINCC=$(CC). If --with-cxx-main is given (without 
an appended compiler name), then MAINCC=$(CXX). If 
--with-cxx-main=<compiler> is on the configure command 
line, then MAINCC=<compiler>. Additionally, configure sets 
CXX=<compiler> unless CXX was already set on the 
configure command line. 
 
3) The command used to link the python executable is (as 
before) stored in LINKCC. By default, LINKCC='$(PURIFY) 
$(MAINCC)', i.e. the linker front-end is the compiler used to 
translate main(). If necessary, LINKCC can be set on the 
configure command line in which case it won't be altered. 
 
4) If CXX is not set by the user (on the command line or via 
--with-cxx-main), then configure tries several likely C++ 
compiler names. CXX is assigned the first name that refers 
to a callable program in the system. (CXX is set even if 
python is built with a C compiler only, so distutils can build 
C++ extensions.)  
 
5) Modules/ccpython.cc is no longer used and can be 
removed. 
 
 

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

Comment By: Holger (jholg)
Date: 2006-04-10 16:28

Message:
Logged In: YES 
user_id=1315684

I can confirm cxx-main.patch3 fixes build problems with gcc
3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.
I also think the patched README text is clearer than the
original.
Just my +1 for this patch.

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-30 19:07

Message:
Logged In: YES 
user_id=1266029

My second patch was indeed broken since it referred to $CC  
before the call to AC_PROG_CC in configure.in. That caused  
CC=gcc and CXX=c++ if neither --with-cxx-main nor CC was  
given on the command line.   
  
I am going to upload a third version (cxx-main.patch3) that 
fixes this problem by moving the code that evaluates 
--with-cxx-main below AC_PROG_CC.  
  
 
To repeat what I wrote in my last comment: This patch does  
not address the issue that distutils calls $CC in order to  
compile C++ source files and calls $CXX in the linking step  
only. Howevr, the patch tries to ensure that CXX is always  
set to a sensible value in the Makefile - even if Python is  
built exclusively with $CC. Thus, distutils has a fighting  
chance to do the right thing (whatever that is) when  
building C++ extensions since it uses the value of CXX  
found in Python's Makefile.  

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-25 11:51

Message:
Logged In: YES 
user_id=1266029

distutils behaves the same way in Python 2.4.1, as I  
mentioned  
<url:http://article.gmane.org/gmane.comp.python.devel/69817>.  
My patch does not address this problem at all. (It should  
be fixed in distutils, but I did not the time to look into  
it yet.)   
 
I am surprised that, on your machine, CC=gcc and CXX=c++. I 
will look into this next week. 

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

Comment By: Jack Jansen (jackjansen)
Date: 2005-11-25 00:26

Message:
Logged In: YES 
user_id=45365

Well, as I commented on this patch and you quickly followed my suggestions I 
felt obliged to test your fix, but I'm not sure about the outcome.

I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good 
news is that it worked fine, everything built and worked as before. BUT: both 
with and without your mods my C++ modules are compiled with "gcc", not "g
++" or "c++". Linking is done with "c++", in both cases. I looked at distutils 
and it seems that it could indeed be the case that CXX is only used for linking 
and never for compilation, but I'm not 100% sure.

Additionally, the Makefile has
CC=             gcc
CXX=            c++
which is technically fine on my machine (g++ == c++), but may not work 
always.

Maybe someone who has a machine with both cc/c++ and gcc/g++ installed, 
and preferrably incompatible compilers, could give this patch a try too?

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-10 19:42

Message:
Logged In: YES 
user_id=1266029

I am going to upload a revision of my patch that addresses 
jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or 
cc, respectively. Additionally, it writes a warning if configure had to 
"guess" the C++ compiler and tells the user how to override this 
guess. 
 
The change is in lin with jackjansen's second suggestion. It is 
pretty straight forward and avoids fragile configure magic. 
 

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

Comment By: Jack Jansen (jackjansen)
Date: 2005-11-08 23:51

Message:
Logged In: YES 
user_id=45365

One question: is step 4 a wise idea? Picking a random C++ compiler if 
multiple are available may result in picking a vendor C++ when the user 
has specified CC=gcc, for example.

OTOH, actually doing the configure magic to determine that the selected 
C++ works together with the c-compiler selected for Python may be 
overkill too.

Maybe try only standard combinations cc/c++ gcc/g++ and otherwise 
require --with{out}-cxx?

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

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

From noreply at sourceforge.net  Mon Apr 10 16:32:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 07:32:16 -0700
Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main()
	with C++ compiler
Message-ID: <E1FSxRA-00051c-92@sc8-sf-web5.sourceforge.net>

Patches item #1324762, was opened at 2005-10-12 13:45
Message generated for change (Comment added) made by jholg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&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
Submitted By: Christoph Ludwig (cludwig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling and linking main() with C++ compiler

Initial Comment:
The attached patch proposes a resolution to the discussion 
started in 
<url:http://thread.gmane.org/gmane.comp.python.devel/69651> 
regarding the compiler (C vs. C++) used to compile python's 
main() and to link the executable.  
 
The patch contains the following changes: 
 
1) The configure option --with-cxx is renamed 
--with-cxx-main. This was done to avoid surprising the user 
by the changed meaning. Furthermore, it is now possible 
that CXX has a different value than provided by 
--with-cxx-main, so the old name would have been 
confusing. 
 
2) The compiler used to translate python's main() function is 
stored in the configure / Makefile variable MAINCC. By 
default, MAINCC=$(CC). If --with-cxx-main is given (without 
an appended compiler name), then MAINCC=$(CXX). If 
--with-cxx-main=<compiler> is on the configure command 
line, then MAINCC=<compiler>. Additionally, configure sets 
CXX=<compiler> unless CXX was already set on the 
configure command line. 
 
3) The command used to link the python executable is (as 
before) stored in LINKCC. By default, LINKCC='$(PURIFY) 
$(MAINCC)', i.e. the linker front-end is the compiler used to 
translate main(). If necessary, LINKCC can be set on the 
configure command line in which case it won't be altered. 
 
4) If CXX is not set by the user (on the command line or via 
--with-cxx-main), then configure tries several likely C++ 
compiler names. CXX is assigned the first name that refers 
to a callable program in the system. (CXX is set even if 
python is built with a C compiler only, so distutils can build 
C++ extensions.)  
 
5) Modules/ccpython.cc is no longer used and can be 
removed. 
 
 

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

Comment By: Holger (jholg)
Date: 2006-04-10 16:32

Message:
Logged In: YES 
user_id=1315684

Forgot to mention the python version: I used it for both
2.4.2 and 2.4.3.
>I can confirm cxx-main.patch3 fixes build problems with gcc
>3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.


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

Comment By: Holger (jholg)
Date: 2006-04-10 16:28

Message:
Logged In: YES 
user_id=1315684

I can confirm cxx-main.patch3 fixes build problems with gcc
3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.
I also think the patched README text is clearer than the
original.
Just my +1 for this patch.

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-30 19:07

Message:
Logged In: YES 
user_id=1266029

My second patch was indeed broken since it referred to $CC  
before the call to AC_PROG_CC in configure.in. That caused  
CC=gcc and CXX=c++ if neither --with-cxx-main nor CC was  
given on the command line.   
  
I am going to upload a third version (cxx-main.patch3) that 
fixes this problem by moving the code that evaluates 
--with-cxx-main below AC_PROG_CC.  
  
 
To repeat what I wrote in my last comment: This patch does  
not address the issue that distutils calls $CC in order to  
compile C++ source files and calls $CXX in the linking step  
only. Howevr, the patch tries to ensure that CXX is always  
set to a sensible value in the Makefile - even if Python is  
built exclusively with $CC. Thus, distutils has a fighting  
chance to do the right thing (whatever that is) when  
building C++ extensions since it uses the value of CXX  
found in Python's Makefile.  

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-25 11:51

Message:
Logged In: YES 
user_id=1266029

distutils behaves the same way in Python 2.4.1, as I  
mentioned  
<url:http://article.gmane.org/gmane.comp.python.devel/69817>.  
My patch does not address this problem at all. (It should  
be fixed in distutils, but I did not the time to look into  
it yet.)   
 
I am surprised that, on your machine, CC=gcc and CXX=c++. I 
will look into this next week. 

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

Comment By: Jack Jansen (jackjansen)
Date: 2005-11-25 00:26

Message:
Logged In: YES 
user_id=45365

Well, as I commented on this patch and you quickly followed my suggestions I 
felt obliged to test your fix, but I'm not sure about the outcome.

I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good 
news is that it worked fine, everything built and worked as before. BUT: both 
with and without your mods my C++ modules are compiled with "gcc", not "g
++" or "c++". Linking is done with "c++", in both cases. I looked at distutils 
and it seems that it could indeed be the case that CXX is only used for linking 
and never for compilation, but I'm not 100% sure.

Additionally, the Makefile has
CC=             gcc
CXX=            c++
which is technically fine on my machine (g++ == c++), but may not work 
always.

Maybe someone who has a machine with both cc/c++ and gcc/g++ installed, 
and preferrably incompatible compilers, could give this patch a try too?

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-10 19:42

Message:
Logged In: YES 
user_id=1266029

I am going to upload a revision of my patch that addresses 
jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or 
cc, respectively. Additionally, it writes a warning if configure had to 
"guess" the C++ compiler and tells the user how to override this 
guess. 
 
The change is in lin with jackjansen's second suggestion. It is 
pretty straight forward and avoids fragile configure magic. 
 

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

Comment By: Jack Jansen (jackjansen)
Date: 2005-11-08 23:51

Message:
Logged In: YES 
user_id=45365

One question: is step 4 a wise idea? Picking a random C++ compiler if 
multiple are available may result in picking a vendor C++ when the user 
has specified CC=gcc, for example.

OTOH, actually doing the configure magic to determine that the selected 
C++ works together with the c-compiler selected for Python may be 
overkill too.

Maybe try only standard combinations cc/c++ gcc/g++ and otherwise 
require --with{out}-cxx?

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

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

From noreply at sourceforge.net  Mon Apr 10 16:45:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 07:45:15 -0700
Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime
	tunable
Message-ID: <E1FSxdj-0002Hv-0p@sc8-sf-web3.sourceforge.net>

Patches item #1454481, was opened at 2006-03-20 23:37
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&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
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make thread stack size runtime tunable

Initial Comment:
Platform default thread stack sizes vary considerably.
Some are very generous (Win32: usually 1MB; Linux: 1MB,
sometimes 8MB).  Others are not (FreeBSD: 64k).

Some platforms have restricted virtual address space
OS/2: 512M less overhead) which makes hard coding a
generous default thread stack size problematic.  Some
platforms thread commit stack address space, even
though the memory backing it may not be committed
(Windows, OS/2 at least).

Some applications have a thirst for stack space in
threads (Zope). Some programmers want to be able to use
lots of threads, even in the face of sound advice about
the lack of wisdom in this approach.

The current approach to stack space management in
threads in Python uses a hard coded strategy, relying
on the platform having a useful default or relying on
the system administrator or distribution builder
over-riding the default at compile time.

This patch is intended to allow developers some control
over managing this resource from within Python code by
way of a function in the thread module.  As written, it
is not intended to provide unlimited flexibility; that
would probably require exposing the underlying
mechanism as an option on the creation of each thread.

An alternative approach to providing the functionality
would be to use an environment variable to provide the
information to the thread module.  This has its pros
and cons, in terms of flexibility and ease of use, and
could be complementary to the approach implemented.

The patch has been tested on OS/2 and FreeBSD 4.8.  I
have no means of testing the code on Win32 or Linux,
though Linux is a pthread environment as is FreeBSD. 
Code base is SVN head from a few hours ago. A doc 
update is included.

While I would like to see this functionality in Python
2.5, it is not a critical issue.

Critique of the approach and implementation welcome. 
Something not addressed is the issue of tests,
primarily because I haven't been able to think of a
viable testing strategy - I'm all ears to suggestions
for this.

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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-11 00:45

Message:
Logged In: YES 
user_id=250749

1) wrt _POSIX_THREAD_ATTR_STACKSIZE, I'll look at that
(though I note its absence from the existing code...)

2) PTHREAD_STACK_MIN on FreeBSD is 1k, which seemed grossly
inadequate for Python (my impression is that 20-32k is a
fairly safe minimum for Python).  In principle I don't have
a problem 
with relying on PTHREAD_STACK_MIN, except for trying to play
it safe.  Any further thoughts on this?

I'm also putting together an environment variable only
version of the patch, with a view to getting that in first,
and reworking this patch to work on top of that.

Thanks for the comments.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 23:41

Message:
Logged In: YES 
user_id=21627

Usage of pthread_attr_setstacksize should be conditional on
the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to
POSIX. Errors from pthread_attr_setstacksize should be
reported (POSIX lists EINVAL as a possible error).

I think PTHREAD_STACK_MIN should be considered. 

The documentation should list availibility of the feature,
currently Win32, OS/2, and POSIX threads (with the TSS
option, to be precise). If some platforms have specific
additional requirements on the possible values (eg. must be
a multiple of the page size), these should be documented, as
well.

Apart from that, the patch looks fine.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-03-22 19:28

Message:
Logged In: YES 
user_id=250749

Thanks for the comments.

As implemented, the function is both a getter and
(optionally) a setter which makes attempting to use a
"get"/"set" prefix 
awkward.

I chose this approach to make it a little simpler to support
temporary changes.  I did consider using a module
attribute/variable, but it is slightly more unwieldy for
this case:

old_size = thread.stack_size(new_size)
...
thread.stack_size(old_size)

vs

old_size = thread.stack_size
thread.stack_size = new_size
...
thread.stack_size = old_size

or (using get/set accessors)

old_size = thread.get_stacksize()
thread.set_stacksize(new_size)
...
thread.set_stacksize(old_size)

I think an argument can be made for passing on the
"get"/"set" naming consistency based on the guidelines in
PEP 8.  While I have a preference for what I've implemented,
I'm more interested in getting the functionality in than
debating its decor.  If there's a strong view about these 
issues, I'm prepared to revise the patch accordingly.

I don't believe that the functionality belongs anywhere else
than the thread module, except possibly shadowing it in the
threading module, as it is highly specific to thread
support.  The sys module seems more appropriate for general 
knobs, and only for specific knobs when there is no other
choice IMO.  Doing it outside the thread module also
complicates the implementation, which I was trying to keep
as simple as I could.


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

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-21 00:58

Message:
Logged In: YES 
user_id=55188

I'm all for this!  The FreeBSD port have maintained a local
patch to bump THREAD_STACK_SIZE.  The patch will lighten
FreeBSD users' burden around thread stack size.

BTW, the naming, "thread.stack_size" seems to miss a verb
while all the other functions on the thread module have it.
 How about set_stack_size() or set_stacksize()?  Or, how
about in sys module?

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

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

From noreply at sourceforge.net  Mon Apr 10 16:54:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 07:54:50 -0700
Subject: [Patches] [ python-Patches-1467770 ] add Popen objects to _active
	only in __del__, 
Message-ID: <E1FSxn0-0002rO-7W@sc8-sf-web3.sourceforge.net>

Patches item #1467770, was opened at 2006-04-10 14: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=1467770&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: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: add Popen objects to _active only in __del__, 

Initial Comment:
attached a patch for subprocess.py
this is for bug #1460493 Why not drop the _active list?
popen2.py is patched (revision 43286), this is a (try)
to patch subprocess.py accordingly.
Bug #1183780: Add Popen objects to _active only in __del__.
Cleanup terminated processes as well.

revision 43287 adds a small modification with an
assert, but that is not included.

I'm not sure about the wait(self) function under the
windows part, there is no check for an error, and the
_deadstate protection is not used

verified on windows XP SP2 32bits (python2.4 with
patched subprocess.py from 2.5a1) with the
'popen_bug.py -s '-script from bug #1183780 but with
the following call: pipe = subprocess.Popen("calc")
then in windows xp do a "close group" action on all the
calculator windows (right click on the task bar).

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

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

From noreply at sourceforge.net  Mon Apr 10 17:02:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 08:02:54 -0700
Subject: [Patches] [ python-Patches-1467770 ] add Popen objects to _active
	only in __del__, 
Message-ID: <E1FSxuo-0000qT-T0@sc8-sf-web6.sourceforge.net>

Patches item #1467770, was opened at 2006-04-10 14:54
Message generated for change (Comment added) made by atila-cheops
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1467770&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: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
>Assigned to: Peter ?
strand (astrand)
Summary: add Popen objects to _active only in __del__, 

Initial Comment:
attached a patch for subprocess.py
this is for bug #1460493 Why not drop the _active list?
popen2.py is patched (revision 43286), this is a (try)
to patch subprocess.py accordingly.
Bug #1183780: Add Popen objects to _active only in __del__.
Cleanup terminated processes as well.

revision 43287 adds a small modification with an
assert, but that is not included.

I'm not sure about the wait(self) function under the
windows part, there is no check for an error, and the
_deadstate protection is not used

verified on windows XP SP2 32bits (python2.4 with
patched subprocess.py from 2.5a1) with the
'popen_bug.py -s '-script from bug #1183780 but with
the following call: pipe = subprocess.Popen("calc")
then in windows xp do a "close group" action on all the
calculator windows (right click on the task bar).

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

>Comment By: cheops (atila-cheops)
Date: 2006-04-10 15:02

Message:
Logged In: YES 
user_id=1276121

patch was not uploaded

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

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

From noreply at sourceforge.net  Mon Apr 10 17:09:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 08:09:25 -0700
Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime
	tunable
Message-ID: <E1FSy17-0007Ql-5S@sc8-sf-web5.sourceforge.net>

Patches item #1454481, was opened at 2006-03-20 13:37
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&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
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make thread stack size runtime tunable

Initial Comment:
Platform default thread stack sizes vary considerably.
Some are very generous (Win32: usually 1MB; Linux: 1MB,
sometimes 8MB).  Others are not (FreeBSD: 64k).

Some platforms have restricted virtual address space
OS/2: 512M less overhead) which makes hard coding a
generous default thread stack size problematic.  Some
platforms thread commit stack address space, even
though the memory backing it may not be committed
(Windows, OS/2 at least).

Some applications have a thirst for stack space in
threads (Zope). Some programmers want to be able to use
lots of threads, even in the face of sound advice about
the lack of wisdom in this approach.

The current approach to stack space management in
threads in Python uses a hard coded strategy, relying
on the platform having a useful default or relying on
the system administrator or distribution builder
over-riding the default at compile time.

This patch is intended to allow developers some control
over managing this resource from within Python code by
way of a function in the thread module.  As written, it
is not intended to provide unlimited flexibility; that
would probably require exposing the underlying
mechanism as an option on the creation of each thread.

An alternative approach to providing the functionality
would be to use an environment variable to provide the
information to the thread module.  This has its pros
and cons, in terms of flexibility and ease of use, and
could be complementary to the approach implemented.

The patch has been tested on OS/2 and FreeBSD 4.8.  I
have no means of testing the code on Win32 or Linux,
though Linux is a pthread environment as is FreeBSD. 
Code base is SVN head from a few hours ago. A doc 
update is included.

While I would like to see this functionality in Python
2.5, it is not a critical issue.

Critique of the approach and implementation welcome. 
Something not addressed is the issue of tests,
primarily because I haven't been able to think of a
viable testing strategy - I'm all ears to suggestions
for this.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 17:09

Message:
Logged In: YES 
user_id=21627

re 1) Currently, the usage of the stacksize attribute is
depending on the definition of a THREAD_STACK_SIZE macro. I
don't know where that comes from, but I guess whoever
defines it knows what he is doing, so that the stacksize
attribute is defined on such a system.

re 2) I can accept that Python enforces a minimum above
PTHREAD_STACK_MIN; it shouldn't be possible to set the stack
size below PTHREAD_STACK_MIN, since that *will* fail when a
thread is created.

-1 for an environment variable version. What problem would
that solve? If this patch gets implemented, applications can
define their own environment variables if they think it
helps, and users/admins can put something in
sitecustomize.py if they think there should be an
environment variable controlling the stack size for all
Python applications on the system.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-10 16:45

Message:
Logged In: YES 
user_id=250749

1) wrt _POSIX_THREAD_ATTR_STACKSIZE, I'll look at that
(though I note its absence from the existing code...)

2) PTHREAD_STACK_MIN on FreeBSD is 1k, which seemed grossly
inadequate for Python (my impression is that 20-32k is a
fairly safe minimum for Python).  In principle I don't have
a problem 
with relying on PTHREAD_STACK_MIN, except for trying to play
it safe.  Any further thoughts on this?

I'm also putting together an environment variable only
version of the patch, with a view to getting that in first,
and reworking this patch to work on top of that.

Thanks for the comments.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 15:41

Message:
Logged In: YES 
user_id=21627

Usage of pthread_attr_setstacksize should be conditional on
the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to
POSIX. Errors from pthread_attr_setstacksize should be
reported (POSIX lists EINVAL as a possible error).

I think PTHREAD_STACK_MIN should be considered. 

The documentation should list availibility of the feature,
currently Win32, OS/2, and POSIX threads (with the TSS
option, to be precise). If some platforms have specific
additional requirements on the possible values (eg. must be
a multiple of the page size), these should be documented, as
well.

Apart from that, the patch looks fine.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-03-22 09:28

Message:
Logged In: YES 
user_id=250749

Thanks for the comments.

As implemented, the function is both a getter and
(optionally) a setter which makes attempting to use a
"get"/"set" prefix 
awkward.

I chose this approach to make it a little simpler to support
temporary changes.  I did consider using a module
attribute/variable, but it is slightly more unwieldy for
this case:

old_size = thread.stack_size(new_size)
...
thread.stack_size(old_size)

vs

old_size = thread.stack_size
thread.stack_size = new_size
...
thread.stack_size = old_size

or (using get/set accessors)

old_size = thread.get_stacksize()
thread.set_stacksize(new_size)
...
thread.set_stacksize(old_size)

I think an argument can be made for passing on the
"get"/"set" naming consistency based on the guidelines in
PEP 8.  While I have a preference for what I've implemented,
I'm more interested in getting the functionality in than
debating its decor.  If there's a strong view about these 
issues, I'm prepared to revise the patch accordingly.

I don't believe that the functionality belongs anywhere else
than the thread module, except possibly shadowing it in the
threading module, as it is highly specific to thread
support.  The sys module seems more appropriate for general 
knobs, and only for specific knobs when there is no other
choice IMO.  Doing it outside the thread module also
complicates the implementation, which I was trying to keep
as simple as I could.


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

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-20 14:58

Message:
Logged In: YES 
user_id=55188

I'm all for this!  The FreeBSD port have maintained a local
patch to bump THREAD_STACK_SIZE.  The patch will lighten
FreeBSD users' burden around thread stack size.

BTW, the naming, "thread.stack_size" seems to miss a verb
while all the other functions on the thread module have it.
 How about set_stack_size() or set_stacksize()?  Or, how
about in sys module?

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

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

From noreply at sourceforge.net  Mon Apr 10 18:03:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 09:03:30 -0700
Subject: [Patches] [ python-Patches-1187312 ] subprocess: optional
	auto-reaping fixing os.wait() lossage
Message-ID: <E1FSyrS-0004qn-Q2@sc8-sf-web6.sourceforge.net>

Patches item #1187312, was opened at 2005-04-21 13:40
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1187312&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.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess: optional auto-reaping fixing os.wait() lossage

Initial Comment:
The subprocess module automatically reaps child
processes. It maintains a list of Popen instances, and
each time a new Popen is created, the list is traversed
and a non-polling wait is done for each instance.

I discussed this with the author, Peter ?strand, and
this behaviour was inherited from the older popen2
code, and is intended to avoid a limitless accretion of
zombies when the user does not take care to wait for
the processes.

However, the auto-reaping interacts badly with
os.wait()/waitpid() since the user is not aware that
the module is reaping children behind her back. In
particular, os.wait(), which is very useful when a
blocking wait for many children is desired, may not
work at all, which caused me to look at the problem in
the first case.

The solution is to allow the user to create Popen
instances that are not auto-reaped. The interface is
otherwise unchanged, and existing code will see no
change in behaviour.

This patch does three things:
- Adds an autoreap parameter to the Popen constructor,
defaulting to True (the previous behaviour)
- Documents the auto-reaper and its interaction with
os.wait()/waitpid(), which was previously missing
- Changes the list of instances to a set, to avoid O(N)
element removal.

For completeness, here is a test case:

import os, subprocess, time
p = subprocess.Popen(["/bin/true"]).pid
time.sleep(1)
subprocess.call(["/bin/false"])
(pid, status) = os.wait()
print "got", pid, "expected", p

The above code will throw an exception. With the patch,
it will work as expected if autoreap=False is added to
the Popen call.


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 18:03

Message:
Logged In: YES 
user_id=21627

This has been fixed in the subversion trunk in a different
way: processes are added to _active only inside __del__. So
as long as the application keeps a reference to the
subprocess object, it can wait for it; auto-reaping only
starts when the last reference was dropped. If you still see
a problem in that approach, please submit a new patch
(relative to svn trunk, preferably).

Marking this one as outdated.

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

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-04-22 18:20

Message:
Logged In: YES 
user_id=432579

Revised patch, using a dict instead of a set (for
compatibility with python 2.2, following PEP 291), and
rename autoreap parameter to "autowait", after discussion
with Peter ?strand.


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

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-04-21 13:48

Message:
Logged In: YES 
user_id=432579

>and a non-polling wait is done for each instance.

Sorry, this should be "non-blocking wait".


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

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

From noreply at sourceforge.net  Mon Apr 10 18:05:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 09:05:10 -0700
Subject: [Patches] [ python-Patches-1467770 ] add Popen objects to _active
	only in __del__, 
Message-ID: <E1FSyt4-0000O4-TB@sc8-sf-web2.sourceforge.net>

Patches item #1467770, was opened at 2006-04-10 16:54
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1467770&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: Accepted
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter ?
strand (astrand)
Summary: add Popen objects to _active only in __del__, 

Initial Comment:
attached a patch for subprocess.py
this is for bug #1460493 Why not drop the _active list?
popen2.py is patched (revision 43286), this is a (try)
to patch subprocess.py accordingly.
Bug #1183780: Add Popen objects to _active only in __del__.
Cleanup terminated processes as well.

revision 43287 adds a small modification with an
assert, but that is not included.

I'm not sure about the wait(self) function under the
windows part, there is no check for an error, and the
_deadstate protection is not used

verified on windows XP SP2 32bits (python2.4 with
patched subprocess.py from 2.5a1) with the
'popen_bug.py -s '-script from bug #1183780 but with
the following call: pipe = subprocess.Popen("calc")
then in windows xp do a "close group" action on all the
calculator windows (right click on the task bar).

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 18:05

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. I made a number of modifications:
- add poll(_deadstate) argument for Unix
- trace whether a child was actually created, else
returncode would not have been set (not even to None) in __del__
With these modifications, I committed it as r45234.

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

Comment By: cheops (atila-cheops)
Date: 2006-04-10 17:02

Message:
Logged In: YES 
user_id=1276121

patch was not uploaded

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

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

From noreply at sourceforge.net  Mon Apr 10 19:53:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Apr 2006 10:53:23 -0700
Subject: [Patches] [ python-Patches-1463867 ] Improved generator finalization
Message-ID: <E1FT0Zn-0004nn-4K@sc8-sf-web1.sourceforge.net>

Patches item #1463867, was opened at 2006-04-03 22:43
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463867&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
Submitted By: Phillip J. Eby (pje)
Assigned to: Phillip J. Eby (pje)
Summary: Improved generator finalization

Initial Comment:
This patch improves generator finalization such that
simple generators (without active try/except/finally
blocks surrounding yield statements) can have their
cycles broken.

Please check to see if this patch improves the leaks
that prompted the request for changing this.  Thanks.

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

>Comment By: Phillip J. Eby (pje)
Date: 2006-04-10 17:53

Message:
Logged In: YES 
user_id=56214

Checked in as of r45235, w/added comment to ceval.c.

If the test that's leaking doesn't leave a generator
suspended in a 'with', try/except, or try/finally block,
then a reference is probably being held somewhere that makes
it not garbage yet.  (Or perhaps it's being referenced by an
object w/a __del__ method?)  Let me know what you find out.


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

Comment By: Thomas Wouters (twouters)
Date: 2006-04-09 15:02

Message:
Logged In: YES 
user_id=34209

The patch looks alright (although it could use some big
blinking comments in opcode.h and ceval.c, to make sure
PyGen_NeedsFinalizer is properly updated when new block
types are added.) The patch fixes the
test_generators_cycle.py leaker-test, but it does *not* fix
the cycles test_generators test. (Obviously after removing
the code that explicitly breaks the cycle in test_generators.)

I don't know why it doesn't clean up the test_generators
cycle. Maybe it's related to doctest, or the way doctests run.

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

Comment By: Phillip J. Eby (pje)
Date: 2006-04-05 20:06

Message:
Logged In: YES 
user_id=56214

Argh.  Sorry.  Uploaded.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-05 19:25

Message:
Logged In: YES 
user_id=31435

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

Please try again.

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

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

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

From noreply at sourceforge.net  Tue Apr 11 09:16:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Apr 2006 00:16:56 -0700
Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in
	arraymodule.c
Message-ID: <E1FTD7Q-00040K-TW@sc8-sf-web6.sourceforge.net>

Patches item #1454485, was opened at 2006-03-20 13:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&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: 7
Submitted By: Baris Metin (tbmetin)
Assigned to: Neal Norwitz (nnorwitz)
Summary: patch for SIGSEGV in arraymodule.c

Initial Comment:
Array module fails handling utf-8 strings giving a  
SIGSEGV. Attached patch seems to do the trick... 
  
gdb> run   
(no debugging symbols found)   
(no debugging symbols found)   
[Thread debugging using libthread_db enabled]   
[New Thread -1480337216 (LWP 31303)]   
Python 2.4.2 (#1, Mar 20 2006, 12:08:06)   
[GCC 3.4.5] on linux2   
Type "help", "copyright", "credits" or "license" for   
more information.   
>>> import array   
>>> x = array.array("u")   
>>> x.append(u"bar????")   
Traceback (most recent call last):   
  File "<stdin>", line 1, in ?   
TypeError: array item must be unicode character   
>>> x.append("bar????")   
>>> x   
   
Program received signal SIGSEGV, Segmentation fault.   
[Switching to Thread -1480337216 (LWP 31303)]   
Error while running hook_stop:   
Invalid type combination in ordering comparison.   
0xa7ee0799 in PyUnicodeUCS4_FromUnicode ()   
from /usr/lib/libpython2.4.so.1.0   
   

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-11 09:16

Message:
Logged In: YES 
user_id=21627

It turns out that the test whether wchar_t is unsigned was
reversed. Correcting the test stops makes the program not
crash anymore; this is fixed in r45264

Not sure whether this can be backported to 2.4; it will mean
that Python will stop using wchar_t as Py_UNICODE on Linux.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 20:13

Message:
Logged In: YES 
user_id=21627

I think there is a design choice here: Should it be an
invariant that all characters in a Unicode string are below
sys.maxunicode? If so, the procedures to create them should
check whether that invariant holds. If not, all code that
deals with them most consider cases where they are larger
than sys.maxunicode or smaller than 0.

Also, should it be a requirement that Py_UNICODE is an
unsigned type? Then tests for <0 could be dropped, of course.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-29 09:52

Message:
Logged In: YES 
user_id=33168

Attached is an updated patch to only do the (unsigned) cast
in unicodeobject.c.  The test included in the patch still
crashes  the interpreter, this time in unicodectype.c.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-26 23:36

Message:
Logged In: YES 
user_id=21627

The second part of the patch (checking that *u is not
negative) is definitely right.

The first part (requiring an even number of bytes for a u#
argument) probably requires discussion on python-dev (or
this patch should be assigned to MAL): I don't think it
should be allowed to pass a non-Unicode object to u# in the
first place.

In particular, if you pass a byte string, there would be an
implicit assumption that the byte encoding is the same
internal representation as a Py_UNICODE. This is bad -
Python normally assumes the encoding of a string is the
system encoding, which normally is ASCII.

Of course, changing the call to a type error for 2.4.3
probably won't work, either, because it might break existing
code.

Anyway, I believe the latter fix alone should fix the crash:
the current getargs implementation will round down to the
next multiple of sizeof(Py_UNICODE), thanks the integer
division. u_setitem will then refuse the call if the length
is not 1. IOW, it is possible to append between 4 and 7
bytes to a Unicode array.

I wonder why the patch fixes the problem: *u should be an
unsigned, and comparing an unsigned with a signed should
convert the signed to unsigned, no?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-25 08:29

Message:
Logged In: YES 
user_id=33168

Verified for 2.4 and head.  The probably could exist w/ucs2
also if you use 'bar' (I think).

I agree with Nick, this patch doesn't really solve the
problem.  The attached patch fixes the crash more generally,
but I'm think there is a better solution.  I hope Martin has
time to review this and suggest a better fix.

Martin, the change in getargs ensures that we don't try to
convert an 8-bit string of length 5 to unicode.  The change
in unicodeobject ensures that we don't reference the array
with a negative offset as happens if the buffer conversion
succeeds with an invalid unicode character.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-24 15:43

Message:
Logged In: YES 
user_id=1038590

To get the effect of the patch, it should be sufficient to
just change the format character to an uppercase U.

That doesn't seem like the right fix though - the actual
explosion isn't happening until later when the array
elements are being converted to Unicode for output.


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

Comment By: Baris Metin (tbmetin)
Date: 2006-03-24 10:19

Message:
Logged In: YES 
user_id=1045504

I'm able to reproduce the bug with 2.5a0 SVN (r43289).   
   
Please try with --enable-unicode=ucs4 
 
The patch is against svn too.. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-24 07:11

Message:
Logged In: YES 
user_id=33168

With the stock 2.4.2 on my linux box I was able to reproduce
this.  I couldn't reproduce with 2.4.3c1.  Can you verify
this is fixed in 2.4.3?

Sagol.

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

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

From noreply at sourceforge.net  Tue Apr 11 21:48:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Apr 2006 12:48:09 -0700
Subject: [Patches] [ python-Patches-1468808 ] tkFont: simple fix to error at
	shutdown
Message-ID: <E1FTOqP-0002Ad-9z@sc8-sf-web6.sourceforge.net>

Patches item #1468808, was opened at 2006-04-11 12: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=1468808&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. L??wis (loewis)
Summary: tkFont: simple fix to error at shutdown

Initial Comment:
At shutdown, tkFont may produce the following error
message:
Exception exceptions.AttributeError: "'NoneType' object
has no attribute 'TclError'" in <bound method
Font.__del__ of <tkFont.Font instance at 0x76f418>> ignored

Here's the relevant code as presently implemented:
    def __del__(self):
        try:
            if self.delete_font:
                self._call("font", "delete", self.name)
        except (AttributeError, Tkinter.TclError):
            pass

apparently Tkinter doesn't always exist at shutdown, so
Tkinter.TclError becomes None.TclError, which causes
the trouble.

Here's the trivial fix:

    def __del__(self):
        try:
            if self.delete_font:
                self._call("font", "delete", self.name)
        except Exception:
            pass

Note that this relies on the new exception hierachy in
python 2.5. If this is to be used in 2.4.x then one
should include the usual guard lines before "except
Exception:"
        except (SystemExit, KeyboardInterrupt):
           raise

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

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

From noreply at sourceforge.net  Wed Apr 12 12:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 03:13:24 -0700
Subject: [Patches] [ python-Patches-1463288 ] clean up new calendar locale
	usage
Message-ID: <E1FTcLk-0003cz-Ru@sc8-sf-web5.sourceforge.net>

Patches item #1463288, was opened at 2006-04-03 05:21
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1463288&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Walter D?rwald (doerwalter)
Summary: clean up new calendar locale usage

Initial Comment:
Walter,

I don't know if this is really better or not.  I was
wondering if the new with statement would help cleanup
the locale handling (all the try-finallys).  It reduces
the total lines of code a little bit.  It seems a
little cleaner to me.  I didn't see any tests for the
new classes, so I only tested on the command line and
it seemed to work.  Regardless of whether you like this
patch or not, it would be good to add tests for the new
classes in calendar.

I'm probably about +0 on this patch.  It was more an
experiment to see if the code was clearer.  I think
it's marginally better at most.

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

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-04-12 12:13

Message:
Logged In: YES 
user_id=89016

Since there's now backwards compatibility issue, and the
code *does* read a littler better and the stdlib should be
an example of Python usage, I checked in your patch as
r45302 with added tests for TextCalendar and HTMLCalendar. I
don't know how we could add reliable tests for
LocaleTextCalendar and LocaleHTMLCalendar.

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

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

From noreply at sourceforge.net  Wed Apr 12 12:33:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 03:33:56 -0700
Subject: [Patches] [ python-Patches-1234057 ] PEP 343 draft documentation
Message-ID: <E1FTcfc-0004s8-Sy@sc8-sf-web5.sourceforge.net>

Patches item #1234057, was opened at 2005-07-07 19:34
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1234057&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: Python 2.5
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Raymond Hettinger (rhettinger)
Summary: PEP 343 draft documentation

Initial Comment:
Draft documentation for PEP 343's new 'with' statement,
describing the operation in terms of contexts and
context management.

Uses __enter__/__exit__, as that is what currently has
the BDFL's blessing via the approval of PEP 343.

Requires addition of formatting codes before it can be
included in the official documentation.

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

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-12 20:33

Message:
Logged In: YES 
user_id=1038590

PEP 343 has been implemented, and the docs updated
appropriately.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-12 13:11

Message:
Logged In: YES 
user_id=80475

I'm happy to review the docs but it will likely take a week
for me to get to it.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-07-09 11:02

Message:
Logged In: YES 
user_id=1038590

 v.3

 - added decimal.getcontext() example
 - added non-generator version of closing() example
 - added generator version of tag() example

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-07-09 00:15

Message:
Logged In: YES 
user_id=1038590

New file attached
  - Update with PJE's HTML example
  - Show resource management example (synchronisation lock)
  - Show usage of closing() (including 'as' clause)
  - Fix a couple of typos

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

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

From noreply at sourceforge.net  Wed Apr 12 13:14:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 04:14:38 -0700
Subject: [Patches] [ python-Patches-1469190 ] Make -tt the default
Message-ID: <E1FTdJ0-0007Ti-4F@sc8-sf-web5.sourceforge.net>

Patches item #1469190, was opened at 2006-04-12 13: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=1469190&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Make -tt the default

Initial Comment:
Small patch to make '-tt' the default option (disallow
mixing of tabs and spaces.) '-t' and '-tt' are still
accepted, but they don't do anything. It also accepts
'-ttt' to turn off errors (but not warnings); if that's
not desireable in Py3K (I'm ambivalent myself), we can
simplify a fair bit of code in tokenize.c.

It also removes the
try-and-parse-emacs/vi-tabsize-comments, even with -tt.


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

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

From noreply at sourceforge.net  Wed Apr 12 14:57:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 05:57:32 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FTeua-0001wB-0A@sc8-sf-web3.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 18:18
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Jeremy Hylton (jhylton)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


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

>Comment By: Armin Rigo (arigo)
Date: 2006-04-12 12:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 11:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 20:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

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

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

From noreply at sourceforge.net  Wed Apr 12 15:19:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 06:19:57 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FTfGH-0004Sn-25@sc8-sf-web2.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 18:18
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Jeremy Hylton (jhylton)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


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

>Comment By: Armin Rigo (arigo)
Date: 2006-04-12 13:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 12:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 11:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 20:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

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

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

From noreply at sourceforge.net  Wed Apr 12 17:29:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 08:29:07 -0700
Subject: [Patches] [ python-Patches-1468808 ] tkFont: simple fix to error at
	shutdown
Message-ID: <E1FThHH-00013H-V0@sc8-sf-web6.sourceforge.net>

Patches item #1468808, was opened at 2006-04-11 19:48
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1468808&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. L??wis (loewis)
Summary: tkFont: simple fix to error at shutdown

Initial Comment:
At shutdown, tkFont may produce the following error
message:
Exception exceptions.AttributeError: "'NoneType' object
has no attribute 'TclError'" in <bound method
Font.__del__ of <tkFont.Font instance at 0x76f418>> ignored

Here's the relevant code as presently implemented:
    def __del__(self):
        try:
            if self.delete_font:
                self._call("font", "delete", self.name)
        except (AttributeError, Tkinter.TclError):
            pass

apparently Tkinter doesn't always exist at shutdown, so
Tkinter.TclError becomes None.TclError, which causes
the trouble.

Here's the trivial fix:

    def __del__(self):
        try:
            if self.delete_font:
                self._call("font", "delete", self.name)
        except Exception:
            pass

Note that this relies on the new exception hierachy in
python 2.5. If this is to be used in 2.4.x then one
should include the usual guard lines before "except
Exception:"
        except (SystemExit, KeyboardInterrupt):
           raise

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-12 15:29

Message:
Logged In: YES 
user_id=849994

Thanks, resolved in rev. 45310, 45311.

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

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

From noreply at sourceforge.net  Wed Apr 12 17:29:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 08:29:21 -0700
Subject: [Patches] [ python-Patches-1468808 ] tkFont: simple fix to error at
	shutdown
Message-ID: <E1FThHV-00013f-TA@sc8-sf-web6.sourceforge.net>

Patches item #1468808, was opened at 2006-04-11 19:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1468808&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. L??wis (loewis)
Summary: tkFont: simple fix to error at shutdown

Initial Comment:
At shutdown, tkFont may produce the following error
message:
Exception exceptions.AttributeError: "'NoneType' object
has no attribute 'TclError'" in <bound method
Font.__del__ of <tkFont.Font instance at 0x76f418>> ignored

Here's the relevant code as presently implemented:
    def __del__(self):
        try:
            if self.delete_font:
                self._call("font", "delete", self.name)
        except (AttributeError, Tkinter.TclError):
            pass

apparently Tkinter doesn't always exist at shutdown, so
Tkinter.TclError becomes None.TclError, which causes
the trouble.

Here's the trivial fix:

    def __del__(self):
        try:
            if self.delete_font:
                self._call("font", "delete", self.name)
        except Exception:
            pass

Note that this relies on the new exception hierachy in
python 2.5. If this is to be used in 2.4.x then one
should include the usual guard lines before "except
Exception:"
        except (SystemExit, KeyboardInterrupt):
           raise

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-12 15:29

Message:
Logged In: YES 
user_id=849994

Thanks, resolved in rev. 45310, 45311.

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

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

From noreply at sourceforge.net  Wed Apr 12 23:16:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 14:16:06 -0700
Subject: [Patches] [ python-Patches-860326 ] PyErrr_Display and
	traceback.format_exception_only behaviour
Message-ID: <E1FTmh4-0007Do-Ao@sc8-sf-web1.sourceforge.net>

Patches item #860326, was opened at 2003-12-15 13:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&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.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: J??rgen Hermann (jhermann)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyErrr_Display and traceback.format_exception_only behaviour

Initial Comment:
PyErrr_Display and traceback.format_exception_only
behave differently; namely, the first one prints the
module of an exception, the latter not.

The attached tb_problem.py illustrates the problem, it
prints:

Error: text

Traceback (most recent call last):
  File &quot;tb_problem.py&quot;, line 3, in ?
    raise uu.Error(&quot;text&quot;)
uu.Error: text

(note the diff betwen &quot;Error:...&quot; and &quot;ui.Error:...&quot;)

The attached patch fixes this. Python 2.2.2 has the
same problem.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-12 21:16

Message:
Logged In: YES 
user_id=849994

Late is better than never ;)

Thanks for the patch, I applied it as rev. 45321, 45322(2.4).

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

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

From noreply at sourceforge.net  Thu Apr 13 03:17:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 18:17:16 -0700
Subject: [Patches] [ python-Patches-860326 ] PyErrr_Display and
	traceback.format_exception_only behaviour
Message-ID: <E1FTqSS-0004l5-Ak@sc8-sf-web6.sourceforge.net>

Patches item #860326, was opened at 2003-12-15 08:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&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.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: J??rgen Hermann (jhermann)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyErrr_Display and traceback.format_exception_only behaviour

Initial Comment:
PyErrr_Display and traceback.format_exception_only
behave differently; namely, the first one prints the
module of an exception, the latter not.

The attached tb_problem.py illustrates the problem, it
prints:

Error: text

Traceback (most recent call last):
  File &quot;tb_problem.py&quot;, line 3, in ?
    raise uu.Error(&quot;text&quot;)
uu.Error: text

(note the diff betwen &quot;Error:...&quot; and &quot;ui.Error:...&quot;)

The attached patch fixes this. Python 2.2.2 has the
same problem.

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

>Comment By: Tim Peters (tim_one)
Date: 2006-04-12 21:17

Message:
Logged In: YES 
user_id=31435

As noted on python-dev, the 2.4-branch backport should be
reverted, because it changes visible behavior (including
causing at least three of the standard tests to fail).

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-12 17:16

Message:
Logged In: YES 
user_id=849994

Late is better than never ;)

Thanks for the patch, I applied it as rev. 45321, 45322(2.4).

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

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

From noreply at sourceforge.net  Thu Apr 13 04:11:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 19:11:51 -0700
Subject: [Patches] [ python-Patches-1469594 ] Alternative to rev 45325
Message-ID: <E1FTrJH-0005po-K1@sc8-sf-web5.sourceforge.net>

Patches item #1469594, was opened at 2006-04-12 21: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=1469594&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Alternative to rev 45325

Initial Comment:
Here's an alternative to Anthony's cast in rev 45325.  Is this any
better than a simple cast?  I think it should probably have a 
_SET_ENUM macro as well to set enum values through the union as well.

Skip


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

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

From noreply at sourceforge.net  Thu Apr 13 04:29:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 19:29:59 -0700
Subject: [Patches] [ python-Patches-860326 ] PyErrr_Display and
	traceback.format_exception_only behaviour
Message-ID: <E1FTrap-0003Hw-Mo@sc8-sf-web3.sourceforge.net>

Patches item #860326, was opened at 2003-12-15 08:37
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&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.3
>Status: Open
>Resolution: None
Priority: 5
Submitted By: J??rgen Hermann (jhermann)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyErrr_Display and traceback.format_exception_only behaviour

Initial Comment:
PyErrr_Display and traceback.format_exception_only
behave differently; namely, the first one prints the
module of an exception, the latter not.

The attached tb_problem.py illustrates the problem, it
prints:

Error: text

Traceback (most recent call last):
  File &quot;tb_problem.py&quot;, line 3, in ?
    raise uu.Error(&quot;text&quot;)
uu.Error: text

(note the diff betwen &quot;Error:...&quot; and &quot;ui.Error:...&quot;)

The attached patch fixes this. Python 2.2.2 has the
same problem.

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

>Comment By: Tim Peters (tim_one)
Date: 2006-04-12 22:29

Message:
Logged In: YES 
user_id=31435

Opened this again.  Anthony reverted the patch on both trunk
and 2.4 branch.  Whether it will be applied on the trunk
again is being discussed on python-dev.

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

Comment By: Tim Peters (tim_one)
Date: 2006-04-12 21:17

Message:
Logged In: YES 
user_id=31435

As noted on python-dev, the 2.4-branch backport should be
reverted, because it changes visible behavior (including
causing at least three of the standard tests to fail).

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-12 17:16

Message:
Logged In: YES 
user_id=849994

Late is better than never ;)

Thanks for the patch, I applied it as rev. 45321, 45322(2.4).

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

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

From noreply at sourceforge.net  Thu Apr 13 05:49:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 20:49:20 -0700
Subject: [Patches] [ python-Patches-1469594 ] Alternative to rev 45325
Message-ID: <E1FTspc-0005wV-KL@sc8-sf-web6.sourceforge.net>

Patches item #1469594, was opened at 2006-04-13 12:11
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1469594&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
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: Alternative to rev 45325

Initial Comment:
Here's an alternative to Anthony's cast in rev 45325.  Is this any
better than a simple cast?  I think it should probably have a 
_SET_ENUM macro as well to set enum values through the union as well.

Skip


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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-13 13:49

Message:
Logged In: YES 
user_id=29957

looks ok to me. feel free to check in.



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

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

From noreply at sourceforge.net  Thu Apr 13 06:09:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Apr 2006 21:09:59 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FTt9b-000143-LE@sc8-sf-web3.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 10:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Jeremy Hylton (jhylton)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-12 21:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 06:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 05:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 03:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

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

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

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

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

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

From noreply at sourceforge.net  Thu Apr 13 11:37:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 02:37:52 -0700
Subject: [Patches] [ python-Patches-1469594 ] Alternative to rev 45325
Message-ID: <E1FTyGu-0005oN-2c@sc8-sf-web2.sourceforge.net>

Patches item #1469594, was opened at 2006-04-12 21:11
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1469594&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: Alternative to rev 45325

Initial Comment:
Here's an alternative to Anthony's cast in rev 45325.  Is this any
better than a simple cast?  I think it should probably have a 
_SET_ENUM macro as well to set enum values through the union as well.

Skip


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

>Comment By: Skip Montanaro (montanaro)
Date: 2006-04-13 04:37

Message:
Logged In: YES 
user_id=44345

Checked in as revision 45354


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-12 22:49

Message:
Logged In: YES 
user_id=29957

looks ok to me. feel free to check in.



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

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

From noreply at sourceforge.net  Thu Apr 13 13:50:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 04:50:08 -0700
Subject: [Patches] [ python-Patches-1469594 ] Alternative to rev 45325
Message-ID: <E1FU0Ku-0003Dc-5K@sc8-sf-web1.sourceforge.net>

Patches item #1469594, was opened at 2006-04-12 21:11
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1469594&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: Alternative to rev 45325

Initial Comment:
Here's an alternative to Anthony's cast in rev 45325.  Is this any
better than a simple cast?  I think it should probably have a 
_SET_ENUM macro as well to set enum values through the union as well.

Skip


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

>Comment By: Skip Montanaro (montanaro)
Date: 2006-04-13 06:50

Message:
Logged In: YES 
user_id=44345

I'm reopening this.  My patch broke the C build.  I reverted
the change in SVN and will investigate further.


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

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-13 04:37

Message:
Logged In: YES 
user_id=44345

Checked in as revision 45354


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-12 22:49

Message:
Logged In: YES 
user_id=29957

looks ok to me. feel free to check in.



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

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

From noreply at sourceforge.net  Thu Apr 13 14:10:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 05:10:36 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FU0ei-0001ba-9Y@sc8-sf-web4-b.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 18:18
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Jeremy Hylton (jhylton)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


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

>Comment By: Armin Rigo (arigo)
Date: 2006-04-13 12:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 04:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 13:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 12:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 11:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 20:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

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

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

From noreply at sourceforge.net  Thu Apr 13 16:31:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 07:31:41 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FU2rF-0002Ao-Cv@sc8-sf-web4-b.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 19:18
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Jeremy Hylton (jhylton)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


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

>Comment By: Irmen de Jong (irmen)
Date: 2006-04-13 16:31

Message:
Logged In: YES 
user_id=129426

Armin, I don't have access to a Linux machine anymore so I
can't really comment on this issue anymore, sorry.
Also this patch was not made for a specific use case I had,
it was a patch for an open bug filed by someone else (bug
764437).
Previous discussion can be found there.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-13 14:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 06:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 15:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 14:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 12:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 21:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

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

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

From noreply at sourceforge.net  Thu Apr 13 19:32:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 10:32:40 -0700
Subject: [Patches] [ python-Patches-849262 ] 832799 proposed changes
Message-ID: <E1FU5gO-0005XN-VG@sc8-sf-web4-b.sourceforge.net>

Patches item #849262, was opened at 2003-11-25 22:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849262&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: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: benson margulies (benson_basis)
Assigned to: Martin v. L??wis (loewis)
Summary: 832799 proposed changes

Initial Comment:
1) allow a subclass of build_ext.py to specify global 
extra_link_args in addition to the per-ext ones.

2) make the toplevel setup.py set this as specified by an 
environment var.

3) Make Makefile.pre.in set this up when building shared 
libs.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-13 19:32

Message:
Logged In: YES 
user_id=21627

The bug has been fixed differently, meanwhile; thanks for
the patch, anyway.

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

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

From noreply at sourceforge.net  Thu Apr 13 19:33:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 10:33:58 -0700
Subject: [Patches] [ python-Patches-1412448 ] Compile under mingw properly
Message-ID: <E1FU5he-0005bH-2l@sc8-sf-web4-b.sourceforge.net>

Patches item #1412448, was opened at 2006-01-23 03:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412448&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Gir?o Bezerra de Mene (alexgirao)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Compile under mingw properly

Initial Comment:
Hi,

 I made only simple changes to let gcc happy with win
related code and to compile without warnings.

Alexadre Girao,
http://nextt.org


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-13 19:33

Message:
Logged In: YES 
user_id=21627

Unassigning myself until there is activity.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 15:01

Message:
Logged In: YES 
user_id=21627

Unfortunately, the patch is unacceptable in its current
form. Some of the changes seem essential to make Python work
with Mingw, others seem merely aesthetical (i.e. those that
make warnings go away).

Some of the changes that make warnings go away look wrong:
the code is right as it stands, and if you get a warning
with MingW, it's either that the compiler is wrong, or some
other part of the setup is broken.

Would you be willing to rework the patch to only include the
fragments that are absolutely necessary to make it compile
and work correctly? Also, it would be much more useful if
you could forward-port the patch to the 2.5 subversion trunk.

Among the things I consider faulty are:
- inclusion of wincrypt.h
- addition of a parenthesis around the cFileName[1/2] block
- explicit conversion of arguments to const char**


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

Comment By: Alexandre Gir?o Bezerra de Mene (alexgirao)
Date: 2006-01-25 00:34

Message:
Logged In: YES 
user_id=700047

Most of the changes were related to correct usage of braces 
and incompatibilities with mingw (note that i compiled with 
msvc too). The parenthesis changes apply to msvc too.

I thank you so much for paying attention on this.


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-01-25 00:19

Message:
Logged In: YES 
user_id=764593

Are you sure these were just compiler-related?

Changing things like frequency from {0,0} to {{0,}} or 
adding parentheses strike me as at least possible bugfixes 
that should not be in #ifdefs

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

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

From noreply at sourceforge.net  Thu Apr 13 19:35:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 10:35:47 -0700
Subject: [Patches] [ python-Patches-1441452 ] Updated Demo\parser\unpack.py
Message-ID: <E1FU5jP-0005j1-JN@sc8-sf-web4-b.sourceforge.net>

Patches item #1441452, was opened at 2006-03-02 05:01
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1441452&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.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Martin v. L??wis (loewis)
Summary: Updated Demo\parser\unpack.py

Initial Comment:
Updated demo for ast inspection.  It now generates code
for all files under Lib, but I have not checked to see
if the code is correct.  The next step is to reorder
the methods, implement a check to see if generated code
is correct, and fix it so it is correct.  Use the
--testdir argument to process all files in the given
directory recursively.

I intend to work more on this, but I'm having problems
with my laptop so I may not be working tomorrow.

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-13 19:35

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as r45233.

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

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

From noreply at sourceforge.net  Thu Apr 13 19:44:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 10:44:41 -0700
Subject: [Patches] [ python-Patches-1469594 ] Alternative to rev 45325
Message-ID: <E1FU5s1-0006MN-FM@sc8-sf-web4-b.sourceforge.net>

Patches item #1469594, was opened at 2006-04-13 04:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1469594&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: Alternative to rev 45325

Initial Comment:
Here's an alternative to Anthony's cast in rev 45325.  Is this any
better than a simple cast?  I think it should probably have a 
_SET_ENUM macro as well to set enum values through the union as well.

Skip


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-13 19:44

Message:
Logged In: YES 
user_id=21627

A yet different alternative was committed as r45360

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

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-13 13:50

Message:
Logged In: YES 
user_id=44345

I'm reopening this.  My patch broke the C build.  I reverted
the change in SVN and will investigate further.


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

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-13 11:37

Message:
Logged In: YES 
user_id=44345

Checked in as revision 45354


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-13 05:49

Message:
Logged In: YES 
user_id=29957

looks ok to me. feel free to check in.



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

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

From noreply at sourceforge.net  Fri Apr 14 07:01:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 22:01:31 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FUGR1-0001qo-44@sc8-sf-web2.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 10:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
>Assigned to: Armin Rigo (arigo)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 22:01

Message:
Logged In: YES 
user_id=33168

Wow!  Now I see why you wanted review.

Modules/socketmodule.c:

In the first #ifdef linux section (968+), why the calc for
addrlen?  Isn't the len just sizeof(a->sun_path) and that
can be passed to FromStringAndSize()?

In the second #ifdef linux section (1098+), should if (len >
sizeof ...) be >= like the other check?

It's probably easier to show what I mean in code.  Attached
is another patch.  I didn't test it.  There's a big comment
that we should address in either patch about a negative
length issue.


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

Comment By: Irmen de Jong (irmen)
Date: 2006-04-13 07:31

Message:
Logged In: YES 
user_id=129426

Armin, I don't have access to a Linux machine anymore so I
can't really comment on this issue anymore, sorry.
Also this patch was not made for a specific use case I had,
it was a patch for an open bug filed by someone else (bug
764437).
Previous discussion can be found there.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-13 05:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-12 21:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 06:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 05:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 03:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

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

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

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

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

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

From noreply at sourceforge.net  Fri Apr 14 07:22:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Apr 2006 22:22:14 -0700
Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in
	arraymodule.c
Message-ID: <E1FUGl4-0001Yy-0G@sc8-sf-web1.sourceforge.net>

Patches item #1454485, was opened at 2006-03-20 04:44
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&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: 7
Submitted By: Baris Metin (tbmetin)
>Assigned to: Martin v. L??wis (loewis)
Summary: patch for SIGSEGV in arraymodule.c

Initial Comment:
Array module fails handling utf-8 strings giving a  
SIGSEGV. Attached patch seems to do the trick... 
  
gdb> run   
(no debugging symbols found)   
(no debugging symbols found)   
[Thread debugging using libthread_db enabled]   
[New Thread -1480337216 (LWP 31303)]   
Python 2.4.2 (#1, Mar 20 2006, 12:08:06)   
[GCC 3.4.5] on linux2   
Type "help", "copyright", "credits" or "license" for   
more information.   
>>> import array   
>>> x = array.array("u")   
>>> x.append(u"bar????")   
Traceback (most recent call last):   
  File "<stdin>", line 1, in ?   
TypeError: array item must be unicode character   
>>> x.append("bar????")   
>>> x   
   
Program received signal SIGSEGV, Segmentation fault.   
[Switching to Thread -1480337216 (LWP 31303)]   
Error while running hook_stop:   
Invalid type combination in ordering comparison.   
0xa7ee0799 in PyUnicodeUCS4_FromUnicode ()   
from /usr/lib/libpython2.4.so.1.0   
   

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 22:22

Message:
Logged In: YES 
user_id=33168

I removed the code which tried to convert a buffer (string)
to unicode.

Committed revision 45374.

We still have to address 2.4.  Martin, I can make the fix if
you tell me what to do.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-11 00:16

Message:
Logged In: YES 
user_id=21627

It turns out that the test whether wchar_t is unsigned was
reversed. Correcting the test stops makes the program not
crash anymore; this is fixed in r45264

Not sure whether this can be backported to 2.4; it will mean
that Python will stop using wchar_t as Py_UNICODE on Linux.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-29 10:13

Message:
Logged In: YES 
user_id=21627

I think there is a design choice here: Should it be an
invariant that all characters in a Unicode string are below
sys.maxunicode? If so, the procedures to create them should
check whether that invariant holds. If not, all code that
deals with them most consider cases where they are larger
than sys.maxunicode or smaller than 0.

Also, should it be a requirement that Py_UNICODE is an
unsigned type? Then tests for <0 could be dropped, of course.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-28 23:52

Message:
Logged In: YES 
user_id=33168

Attached is an updated patch to only do the (unsigned) cast
in unicodeobject.c.  The test included in the patch still
crashes  the interpreter, this time in unicodectype.c.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-26 13:36

Message:
Logged In: YES 
user_id=21627

The second part of the patch (checking that *u is not
negative) is definitely right.

The first part (requiring an even number of bytes for a u#
argument) probably requires discussion on python-dev (or
this patch should be assigned to MAL): I don't think it
should be allowed to pass a non-Unicode object to u# in the
first place.

In particular, if you pass a byte string, there would be an
implicit assumption that the byte encoding is the same
internal representation as a Py_UNICODE. This is bad -
Python normally assumes the encoding of a string is the
system encoding, which normally is ASCII.

Of course, changing the call to a type error for 2.4.3
probably won't work, either, because it might break existing
code.

Anyway, I believe the latter fix alone should fix the crash:
the current getargs implementation will round down to the
next multiple of sizeof(Py_UNICODE), thanks the integer
division. u_setitem will then refuse the call if the length
is not 1. IOW, it is possible to append between 4 and 7
bytes to a Unicode array.

I wonder why the patch fixes the problem: *u should be an
unsigned, and comparing an unsigned with a signed should
convert the signed to unsigned, no?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-24 23:29

Message:
Logged In: YES 
user_id=33168

Verified for 2.4 and head.  The probably could exist w/ucs2
also if you use 'bar' (I think).

I agree with Nick, this patch doesn't really solve the
problem.  The attached patch fixes the crash more generally,
but I'm think there is a better solution.  I hope Martin has
time to review this and suggest a better fix.

Martin, the change in getargs ensures that we don't try to
convert an 8-bit string of length 5 to unicode.  The change
in unicodeobject ensures that we don't reference the array
with a negative offset as happens if the buffer conversion
succeeds with an invalid unicode character.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-24 06:43

Message:
Logged In: YES 
user_id=1038590

To get the effect of the patch, it should be sufficient to
just change the format character to an uppercase U.

That doesn't seem like the right fix though - the actual
explosion isn't happening until later when the array
elements are being converted to Unicode for output.


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

Comment By: Baris Metin (tbmetin)
Date: 2006-03-24 01:19

Message:
Logged In: YES 
user_id=1045504

I'm able to reproduce the bug with 2.5a0 SVN (r43289).   
   
Please try with --enable-unicode=ucs4 
 
The patch is against svn too.. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 22:11

Message:
Logged In: YES 
user_id=33168

With the stock 2.4.2 on my linux box I was able to reproduce
this.  I couldn't reproduce with 2.4.3c1.  Can you verify
this is fixed in 2.4.3?

Sagol.

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

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

From noreply at sourceforge.net  Fri Apr 14 09:40:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 00:40:17 -0700
Subject: [Patches] [ python-Patches-1469190 ] Make -tt the default
Message-ID: <E1FUIuf-0007qs-4Y@sc8-sf-web4-b.sourceforge.net>

Patches item #1469190, was opened at 2006-04-12 07:14
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1469190&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
Submitted By: Thomas Wouters (twouters)
>Assigned to: Thomas Wouters (twouters)
Summary: Make -tt the default

Initial Comment:
Small patch to make '-tt' the default option (disallow
mixing of tabs and spaces.) '-t' and '-tt' are still
accepted, but they don't do anything. It also accepts
'-ttt' to turn off errors (but not warnings); if that's
not desireable in Py3K (I'm ambivalent myself), we can
simplify a fair bit of code in tokenize.c.

It also removes the
try-and-parse-emacs/vi-tabsize-comments, even with -tt.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-14 03:40

Message:
Logged In: YES 
user_id=6380

looks fine; check it in. Do mention in the message that this
removes the silly options to read tab sizes from the comments.

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

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

From noreply at sourceforge.net  Fri Apr 14 10:33:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 01:33:03 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FUJjj-0002uF-3N@sc8-sf-web5.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 18:18
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Armin Rigo (arigo)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


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

>Comment By: Armin Rigo (arigo)
Date: 2006-04-14 08:33

Message:
Logged In: YES 
user_id=4771

You're missing the point of my patch.  It is to preserve
the originally specified length of the name.  The names
'\x00abc', '\x00abc\x00' and '\x00abc\x00\x00' are all
different for the Linux IP stack, as far as I can tell.
In operations like bind() we specify the length of the
name by setting addrlen to the length of the header
plus the number of bytes actually used in the sun_path
array.  The kernel code remembers this length, and
passes it back in &addrlen to functions like
getsockaddr().  That's why I compute the number of
bytes that are really meaningful as the addrlen minus
the headers, instead of just UNIX_PATH_MAX.

About the second #ifdef, I really meant the > to be >
and not >=, because it is acceptable to pass a name
containing exactly UNIX_PATH_MAX bytes -- the abstract
namespace names don't have to be followed by a
terminating '\x00'.  By contrast, the regular names
must not be longer than UNIX_PATH_MAX-1 characters to
allow for the extra '\x00'.

In some sense, the Linux abstract namespace is rather
strange from the point of view of C, but not if you
think about it as you would think about Python strings.
Indeed, apart from the requirement that they start
with '\x00', these names have an intrinsic length
which is not related to any embedded '\x00'.  It is
stored together with the name in some kernel
structures, but outside the sun_path array of bytes.

But enough theory: the patch you propose don't pass
its own new test on my machine because of this :-)
Does it pass on yours?

I'm not too concerned about addrlen ending up shorter
than the size of the headers.  That would be a Linux
kernel bug.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-14 05:01

Message:
Logged In: YES 
user_id=33168

Wow!  Now I see why you wanted review.

Modules/socketmodule.c:

In the first #ifdef linux section (968+), why the calc for
addrlen?  Isn't the len just sizeof(a->sun_path) and that
can be passed to FromStringAndSize()?

In the second #ifdef linux section (1098+), should if (len >
sizeof ...) be >= like the other check?

It's probably easier to show what I mean in code.  Attached
is another patch.  I didn't test it.  There's a big comment
that we should address in either patch about a negative
length issue.


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

Comment By: Irmen de Jong (irmen)
Date: 2006-04-13 14:31

Message:
Logged In: YES 
user_id=129426

Armin, I don't have access to a Linux machine anymore so I
can't really comment on this issue anymore, sorry.
Also this patch was not made for a specific use case I had,
it was a patch for an open bug filed by someone else (bug
764437).
Previous discussion can be found there.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-13 12:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 04:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 13:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

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

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 12:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 11:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 20:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

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

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

From noreply at sourceforge.net  Fri Apr 14 14:51:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 05:51:36 -0700
Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime
	tunable
Message-ID: <E1FUNlw-0005i5-WB@sc8-sf-web4-b.sourceforge.net>

Patches item #1454481, was opened at 2006-03-20 23:37
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&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
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make thread stack size runtime tunable

Initial Comment:
Platform default thread stack sizes vary considerably.
Some are very generous (Win32: usually 1MB; Linux: 1MB,
sometimes 8MB).  Others are not (FreeBSD: 64k).

Some platforms have restricted virtual address space
OS/2: 512M less overhead) which makes hard coding a
generous default thread stack size problematic.  Some
platforms thread commit stack address space, even
though the memory backing it may not be committed
(Windows, OS/2 at least).

Some applications have a thirst for stack space in
threads (Zope). Some programmers want to be able to use
lots of threads, even in the face of sound advice about
the lack of wisdom in this approach.

The current approach to stack space management in
threads in Python uses a hard coded strategy, relying
on the platform having a useful default or relying on
the system administrator or distribution builder
over-riding the default at compile time.

This patch is intended to allow developers some control
over managing this resource from within Python code by
way of a function in the thread module.  As written, it
is not intended to provide unlimited flexibility; that
would probably require exposing the underlying
mechanism as an option on the creation of each thread.

An alternative approach to providing the functionality
would be to use an environment variable to provide the
information to the thread module.  This has its pros
and cons, in terms of flexibility and ease of use, and
could be complementary to the approach implemented.

The patch has been tested on OS/2 and FreeBSD 4.8.  I
have no means of testing the code on Win32 or Linux,
though Linux is a pthread environment as is FreeBSD. 
Code base is SVN head from a few hours ago. A doc 
update is included.

While I would like to see this functionality in Python
2.5, it is not a critical issue.

Critique of the approach and implementation welcome. 
Something not addressed is the issue of tests,
primarily because I haven't been able to think of a
viable testing strategy - I'm all ears to suggestions
for this.

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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-14 22:51

Message:
Logged In: YES 
user_id=250749

I have updated the patch along the lines Martin suggested.

I have omitted OS/2 from the list of supported platforms in
the doc patch as I haven't added OS/2 to anywhere else in
the docs.  My thinging has been that OS/2 is a 2nd tier
platform, and I have kept an extensive port README file in
the build directory (PC/os2emx) documenting port specific
behaviour.

The idea with the environment variable version was that it
would be less "intrusive" a change from the user POV.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-11 01:09

Message:
Logged In: YES 
user_id=21627

re 1) Currently, the usage of the stacksize attribute is
depending on the definition of a THREAD_STACK_SIZE macro. I
don't know where that comes from, but I guess whoever
defines it knows what he is doing, so that the stacksize
attribute is defined on such a system.

re 2) I can accept that Python enforces a minimum above
PTHREAD_STACK_MIN; it shouldn't be possible to set the stack
size below PTHREAD_STACK_MIN, since that *will* fail when a
thread is created.

-1 for an environment variable version. What problem would
that solve? If this patch gets implemented, applications can
define their own environment variables if they think it
helps, and users/admins can put something in
sitecustomize.py if they think there should be an
environment variable controlling the stack size for all
Python applications on the system.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-11 00:45

Message:
Logged In: YES 
user_id=250749

1) wrt _POSIX_THREAD_ATTR_STACKSIZE, I'll look at that
(though I note its absence from the existing code...)

2) PTHREAD_STACK_MIN on FreeBSD is 1k, which seemed grossly
inadequate for Python (my impression is that 20-32k is a
fairly safe minimum for Python).  In principle I don't have
a problem 
with relying on PTHREAD_STACK_MIN, except for trying to play
it safe.  Any further thoughts on this?

I'm also putting together an environment variable only
version of the patch, with a view to getting that in first,
and reworking this patch to work on top of that.

Thanks for the comments.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 23:41

Message:
Logged In: YES 
user_id=21627

Usage of pthread_attr_setstacksize should be conditional on
the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to
POSIX. Errors from pthread_attr_setstacksize should be
reported (POSIX lists EINVAL as a possible error).

I think PTHREAD_STACK_MIN should be considered. 

The documentation should list availibility of the feature,
currently Win32, OS/2, and POSIX threads (with the TSS
option, to be precise). If some platforms have specific
additional requirements on the possible values (eg. must be
a multiple of the page size), these should be documented, as
well.

Apart from that, the patch looks fine.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-03-22 19:28

Message:
Logged In: YES 
user_id=250749

Thanks for the comments.

As implemented, the function is both a getter and
(optionally) a setter which makes attempting to use a
"get"/"set" prefix 
awkward.

I chose this approach to make it a little simpler to support
temporary changes.  I did consider using a module
attribute/variable, but it is slightly more unwieldy for
this case:

old_size = thread.stack_size(new_size)
...
thread.stack_size(old_size)

vs

old_size = thread.stack_size
thread.stack_size = new_size
...
thread.stack_size = old_size

or (using get/set accessors)

old_size = thread.get_stacksize()
thread.set_stacksize(new_size)
...
thread.set_stacksize(old_size)

I think an argument can be made for passing on the
"get"/"set" naming consistency based on the guidelines in
PEP 8.  While I have a preference for what I've implemented,
I'm more interested in getting the functionality in than
debating its decor.  If there's a strong view about these 
issues, I'm prepared to revise the patch accordingly.

I don't believe that the functionality belongs anywhere else
than the thread module, except possibly shadowing it in the
threading module, as it is highly specific to thread
support.  The sys module seems more appropriate for general 
knobs, and only for specific knobs when there is no other
choice IMO.  Doing it outside the thread module also
complicates the implementation, which I was trying to keep
as simple as I could.


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

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-21 00:58

Message:
Logged In: YES 
user_id=55188

I'm all for this!  The FreeBSD port have maintained a local
patch to bump THREAD_STACK_SIZE.  The patch will lighten
FreeBSD users' burden around thread stack size.

BTW, the naming, "thread.stack_size" seems to miss a verb
while all the other functions on the thread module have it.
 How about set_stack_size() or set_stacksize()?  Or, how
about in sys module?

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

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

From noreply at sourceforge.net  Fri Apr 14 15:39:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 06:39:54 -0700
Subject: [Patches] [ python-Patches-1469594 ] Alternative to rev 45325
Message-ID: <E1FUOWg-0004eq-Q3@sc8-sf-web1.sourceforge.net>

Patches item #1469594, was opened at 2006-04-12 21:11
Message generated for change (Settings changed) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1469594&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: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: Alternative to rev 45325

Initial Comment:
Here's an alternative to Anthony's cast in rev 45325.  Is this any
better than a simple cast?  I think it should probably have a 
_SET_ENUM macro as well to set enum values through the union as well.

Skip


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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-13 12:44

Message:
Logged In: YES 
user_id=21627

A yet different alternative was committed as r45360

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

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-13 06:50

Message:
Logged In: YES 
user_id=44345

I'm reopening this.  My patch broke the C build.  I reverted
the change in SVN and will investigate further.


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

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-13 04:37

Message:
Logged In: YES 
user_id=44345

Checked in as revision 45354


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-12 22:49

Message:
Logged In: YES 
user_id=29957

looks ok to me. feel free to check in.



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

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

From noreply at sourceforge.net  Fri Apr 14 16:36:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 07:36:14 -0700
Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main()
	with C++ compiler
Message-ID: <E1FUPPC-0002M7-QW@sc8-sf-web2.sourceforge.net>

Patches item #1324762, was opened at 2005-10-12 13:45
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&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
Submitted By: Christoph Ludwig (cludwig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling and linking main() with C++ compiler

Initial Comment:
The attached patch proposes a resolution to the discussion 
started in 
<url:http://thread.gmane.org/gmane.comp.python.devel/69651> 
regarding the compiler (C vs. C++) used to compile python's 
main() and to link the executable.  
 
The patch contains the following changes: 
 
1) The configure option --with-cxx is renamed 
--with-cxx-main. This was done to avoid surprising the user 
by the changed meaning. Furthermore, it is now possible 
that CXX has a different value than provided by 
--with-cxx-main, so the old name would have been 
confusing. 
 
2) The compiler used to translate python's main() function is 
stored in the configure / Makefile variable MAINCC. By 
default, MAINCC=$(CC). If --with-cxx-main is given (without 
an appended compiler name), then MAINCC=$(CXX). If 
--with-cxx-main=<compiler> is on the configure command 
line, then MAINCC=<compiler>. Additionally, configure sets 
CXX=<compiler> unless CXX was already set on the 
configure command line. 
 
3) The command used to link the python executable is (as 
before) stored in LINKCC. By default, LINKCC='$(PURIFY) 
$(MAINCC)', i.e. the linker front-end is the compiler used to 
translate main(). If necessary, LINKCC can be set on the 
configure command line in which case it won't be altered. 
 
4) If CXX is not set by the user (on the command line or via 
--with-cxx-main), then configure tries several likely C++ 
compiler names. CXX is assigned the first name that refers 
to a callable program in the system. (CXX is set even if 
python is built with a C compiler only, so distutils can build 
C++ extensions.)  
 
5) Modules/ccpython.cc is no longer used and can be 
removed. 
 
 

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 16:36

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, committed as 45387. I modified it
slightly, dropping the PROG_CXX_WORKS part, as selection of
the C++ compiler is now entirely in the hands of the user.

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

Comment By: Holger (jholg)
Date: 2006-04-10 16:32

Message:
Logged In: YES 
user_id=1315684

Forgot to mention the python version: I used it for both
2.4.2 and 2.4.3.
>I can confirm cxx-main.patch3 fixes build problems with gcc
>3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.


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

Comment By: Holger (jholg)
Date: 2006-04-10 16:28

Message:
Logged In: YES 
user_id=1315684

I can confirm cxx-main.patch3 fixes build problems with gcc
3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.
I also think the patched README text is clearer than the
original.
Just my +1 for this patch.

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-30 19:07

Message:
Logged In: YES 
user_id=1266029

My second patch was indeed broken since it referred to $CC  
before the call to AC_PROG_CC in configure.in. That caused  
CC=gcc and CXX=c++ if neither --with-cxx-main nor CC was  
given on the command line.   
  
I am going to upload a third version (cxx-main.patch3) that 
fixes this problem by moving the code that evaluates 
--with-cxx-main below AC_PROG_CC.  
  
 
To repeat what I wrote in my last comment: This patch does  
not address the issue that distutils calls $CC in order to  
compile C++ source files and calls $CXX in the linking step  
only. Howevr, the patch tries to ensure that CXX is always  
set to a sensible value in the Makefile - even if Python is  
built exclusively with $CC. Thus, distutils has a fighting  
chance to do the right thing (whatever that is) when  
building C++ extensions since it uses the value of CXX  
found in Python's Makefile.  

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-25 11:51

Message:
Logged In: YES 
user_id=1266029

distutils behaves the same way in Python 2.4.1, as I  
mentioned  
<url:http://article.gmane.org/gmane.comp.python.devel/69817>.  
My patch does not address this problem at all. (It should  
be fixed in distutils, but I did not the time to look into  
it yet.)   
 
I am surprised that, on your machine, CC=gcc and CXX=c++. I 
will look into this next week. 

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

Comment By: Jack Jansen (jackjansen)
Date: 2005-11-25 00:26

Message:
Logged In: YES 
user_id=45365

Well, as I commented on this patch and you quickly followed my suggestions I 
felt obliged to test your fix, but I'm not sure about the outcome.

I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good 
news is that it worked fine, everything built and worked as before. BUT: both 
with and without your mods my C++ modules are compiled with "gcc", not "g
++" or "c++". Linking is done with "c++", in both cases. I looked at distutils 
and it seems that it could indeed be the case that CXX is only used for linking 
and never for compilation, but I'm not 100% sure.

Additionally, the Makefile has
CC=             gcc
CXX=            c++
which is technically fine on my machine (g++ == c++), but may not work 
always.

Maybe someone who has a machine with both cc/c++ and gcc/g++ installed, 
and preferrably incompatible compilers, could give this patch a try too?

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-10 19:42

Message:
Logged In: YES 
user_id=1266029

I am going to upload a revision of my patch that addresses 
jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or 
cc, respectively. Additionally, it writes a warning if configure had to 
"guess" the C++ compiler and tells the user how to override this 
guess. 
 
The change is in lin with jackjansen's second suggestion. It is 
pretty straight forward and avoids fragile configure magic. 
 

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

Comment By: Jack Jansen (jackjansen)
Date: 2005-11-08 23:51

Message:
Logged In: YES 
user_id=45365

One question: is step 4 a wise idea? Picking a random C++ compiler if 
multiple are available may result in picking a vendor C++ when the user 
has specified CC=gcc, for example.

OTOH, actually doing the configure magic to determine that the selected 
C++ works together with the c-compiler selected for Python may be 
overkill too.

Maybe try only standard combinations cc/c++ gcc/g++ and otherwise 
require --with{out}-cxx?

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

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

From noreply at sourceforge.net  Fri Apr 14 16:37:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 07:37:09 -0700
Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main()
	with C++ compiler
Message-ID: <E1FUPQ5-0000ay-Uo@sc8-sf-web1.sourceforge.net>

Patches item #1324762, was opened at 2005-10-12 13:45
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Christoph Ludwig (cludwig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling and linking main() with C++ compiler

Initial Comment:
The attached patch proposes a resolution to the discussion 
started in 
<url:http://thread.gmane.org/gmane.comp.python.devel/69651> 
regarding the compiler (C vs. C++) used to compile python's 
main() and to link the executable.  
 
The patch contains the following changes: 
 
1) The configure option --with-cxx is renamed 
--with-cxx-main. This was done to avoid surprising the user 
by the changed meaning. Furthermore, it is now possible 
that CXX has a different value than provided by 
--with-cxx-main, so the old name would have been 
confusing. 
 
2) The compiler used to translate python's main() function is 
stored in the configure / Makefile variable MAINCC. By 
default, MAINCC=$(CC). If --with-cxx-main is given (without 
an appended compiler name), then MAINCC=$(CXX). If 
--with-cxx-main=<compiler> is on the configure command 
line, then MAINCC=<compiler>. Additionally, configure sets 
CXX=<compiler> unless CXX was already set on the 
configure command line. 
 
3) The command used to link the python executable is (as 
before) stored in LINKCC. By default, LINKCC='$(PURIFY) 
$(MAINCC)', i.e. the linker front-end is the compiler used to 
translate main(). If necessary, LINKCC can be set on the 
configure command line in which case it won't be altered. 
 
4) If CXX is not set by the user (on the command line or via 
--with-cxx-main), then configure tries several likely C++ 
compiler names. CXX is assigned the first name that refers 
to a callable program in the system. (CXX is set even if 
python is built with a C compiler only, so distutils can build 
C++ extensions.)  
 
5) Modules/ccpython.cc is no longer used and can be 
removed. 
 
 

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 16:36

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, committed as 45387. I modified it
slightly, dropping the PROG_CXX_WORKS part, as selection of
the C++ compiler is now entirely in the hands of the user.

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

Comment By: Holger (jholg)
Date: 2006-04-10 16:32

Message:
Logged In: YES 
user_id=1315684

Forgot to mention the python version: I used it for both
2.4.2 and 2.4.3.
>I can confirm cxx-main.patch3 fixes build problems with gcc
>3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.


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

Comment By: Holger (jholg)
Date: 2006-04-10 16:28

Message:
Logged In: YES 
user_id=1315684

I can confirm cxx-main.patch3 fixes build problems with gcc
3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.
I also think the patched README text is clearer than the
original.
Just my +1 for this patch.

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-30 19:07

Message:
Logged In: YES 
user_id=1266029

My second patch was indeed broken since it referred to $CC  
before the call to AC_PROG_CC in configure.in. That caused  
CC=gcc and CXX=c++ if neither --with-cxx-main nor CC was  
given on the command line.   
  
I am going to upload a third version (cxx-main.patch3) that 
fixes this problem by moving the code that evaluates 
--with-cxx-main below AC_PROG_CC.  
  
 
To repeat what I wrote in my last comment: This patch does  
not address the issue that distutils calls $CC in order to  
compile C++ source files and calls $CXX in the linking step  
only. Howevr, the patch tries to ensure that CXX is always  
set to a sensible value in the Makefile - even if Python is  
built exclusively with $CC. Thus, distutils has a fighting  
chance to do the right thing (whatever that is) when  
building C++ extensions since it uses the value of CXX  
found in Python's Makefile.  

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-25 11:51

Message:
Logged In: YES 
user_id=1266029

distutils behaves the same way in Python 2.4.1, as I  
mentioned  
<url:http://article.gmane.org/gmane.comp.python.devel/69817>.  
My patch does not address this problem at all. (It should  
be fixed in distutils, but I did not the time to look into  
it yet.)   
 
I am surprised that, on your machine, CC=gcc and CXX=c++. I 
will look into this next week. 

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

Comment By: Jack Jansen (jackjansen)
Date: 2005-11-25 00:26

Message:
Logged In: YES 
user_id=45365

Well, as I commented on this patch and you quickly followed my suggestions I 
felt obliged to test your fix, but I'm not sure about the outcome.

I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good 
news is that it worked fine, everything built and worked as before. BUT: both 
with and without your mods my C++ modules are compiled with "gcc", not "g
++" or "c++". Linking is done with "c++", in both cases. I looked at distutils 
and it seems that it could indeed be the case that CXX is only used for linking 
and never for compilation, but I'm not 100% sure.

Additionally, the Makefile has
CC=             gcc
CXX=            c++
which is technically fine on my machine (g++ == c++), but may not work 
always.

Maybe someone who has a machine with both cc/c++ and gcc/g++ installed, 
and preferrably incompatible compilers, could give this patch a try too?

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

Comment By: Christoph Ludwig (cludwig)
Date: 2005-11-10 19:42

Message:
Logged In: YES 
user_id=1266029

I am going to upload a revision of my patch that addresses 
jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or 
cc, respectively. Additionally, it writes a warning if configure had to 
"guess" the C++ compiler and tells the user how to override this 
guess. 
 
The change is in lin with jackjansen's second suggestion. It is 
pretty straight forward and avoids fragile configure magic. 
 

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2005-11-08 23:51

Message:
Logged In: YES 
user_id=45365

One question: is step 4 a wise idea? Picking a random C++ compiler if 
multiple are available may result in picking a vendor C++ when the user 
has specified CC=gcc, for example.

OTOH, actually doing the configure magic to determine that the selected 
C++ works together with the c-compiler selected for Python may be 
overkill too.

Maybe try only standard combinations cc/c++ gcc/g++ and otherwise 
require --with{out}-cxx?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 17:04:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 08:04:18 -0700
Subject: [Patches] [ python-Patches-1355971 ] Python-ast.h & Python-ast.c
	generated twice (#1355883)
Message-ID: <E1FUPqM-0003Mq-Go@sc8-sf-web3.sourceforge.net>

Patches item #1355971, was opened at 2005-11-13 17:54
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355971&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Thomas Lee (krumms)
Assigned to: Skip Montanaro (montanaro)
Summary: Python-ast.h & Python-ast.c generated twice (#1355883)

Initial Comment:
Added a fix for the first part of bug #1355883: make
-j2 may cause corruption of Python-ast.h/Python-ast.c.

Summary:
* Updated asdl_c.py to only generate the interface or
the implementation depending on which is given on the
command line (e.g. asdl_c.py -h Include Python.asdl
will generate Include/Python-ast.h but will not
generate Python-ast.c)
* Updated Makefile.pre.in to call asdl_c.py with the
appropriate arguments.

Fix for the second part of this bug here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1355940&group_id=5470&atid=305470

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 17:04

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as 45390.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355971&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 17:13:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 08:13:20 -0700
Subject: [Patches] [ python-Patches-1162023 ] don't add -OPT:Olimit=0 for icc
Message-ID: <E1FUPz6-0003If-0j@sc8-sf-web1.sourceforge.net>

Patches item #1162023, was opened at 2005-03-12 16:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162023&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: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: don't add -OPT:Olimit=0 for icc

Initial Comment:
Patch to configure.in to fix problem described in:

http://sourceforge.net/tracker/?func=detail&aid=1162001&group_id=5470&atid=105470

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 17:13

Message:
Logged In: YES 
user_id=21627

Ok, something like this was committed as 41953; closing this
patch as out-of-date.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-04-04 18:09

Message:
Logged In: YES 
user_id=987664

Well, it probably can be done but that would really require
a completely different patch. I unfortunately have not had
the time to produce such a patch.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-18 19:27

Message:
Logged In: YES 
user_id=21627

Hmm. I would really like to see something still more
general, but am willing to commit this if you assert that
nothing more general exists.

Eg. what if somebody links /usr/bin/cc to icc? You really
should find out whether the compiler *is* ICC, not whether
its name is icc (or, better yet, whether the compiler really
does support -OPT:Olimit). For example, if 'icc --version'
prints "Intel Compiler version 9.0" or some such, that would
be a reliable test for icc.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-18 14:17

Message:
Logged In: YES 
user_id=987664

OK, here's another attempt at it that uses the autoconf
AS_BASENAME macro. Additionally it removes libm from the
default libraries if you are using icc. Intel has their own
math library which is automatically linked, and using -lm
causes problems.

Sorry this took so long--anonymous CVS access had been down
for several days.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-13 23:42

Message:
Logged In: YES 
user_id=21627

This test is too weak. If CC is, say, "/opt/intel/bin/icc",
the test would fail, right?

So please come up with a separate test to determine if the
compiler is icc, and then skip the entire test whether it
accepts -OPT:Olimit.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162023&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 17:16:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 08:16:39 -0700
Subject: [Patches] [ python-Patches-1045620 ] improved configure.in output
Message-ID: <E1FUQ2J-0005hV-Vp@sc8-sf-web6.sourceforge.net>

Patches item #1045620, was opened at 2004-10-12 20:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1045620&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.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: improved configure.in output

Initial Comment:
Hi,

here is a tiny patch that prints prepends the "Module/"
path before the "Setup" output names. Some trailing
whitespace is also removed.

Patch is against CVS from 20041011.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 17:16

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as 45392.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1045620&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 17:48:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 08:48:46 -0700
Subject: [Patches] [ python-Patches-1469190 ] Make -tt the default
Message-ID: <E1FUQXO-0001cH-3H@sc8-sf-web5.sourceforge.net>

Patches item #1469190, was opened at 2006-04-12 13:14
Message generated for change (Settings changed) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1469190&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: Fixed
Priority: 5
Submitted By: Thomas Wouters (twouters)
Assigned to: Thomas Wouters (twouters)
Summary: Make -tt the default

Initial Comment:
Small patch to make '-tt' the default option (disallow
mixing of tabs and spaces.) '-t' and '-tt' are still
accepted, but they don't do anything. It also accepts
'-ttt' to turn off errors (but not warnings); if that's
not desireable in Py3K (I'm ambivalent myself), we can
simplify a fair bit of code in tokenize.c.

It also removes the
try-and-parse-emacs/vi-tabsize-comments, even with -tt.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-14 09:40

Message:
Logged In: YES 
user_id=6380

looks fine; check it in. Do mention in the message that this
removes the silly options to read tab sizes from the comments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1469190&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 17:48:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 08:48:53 -0700
Subject: [Patches] [ python-Patches-695275 ] environment parameter for popen2
Message-ID: <E1FUQXV-00085y-2E@sc8-sf-web6.sourceforge.net>

Patches item #695275, was opened at 2003-02-28 21:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695275&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
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Nobody/Anonymous (nobody)
Summary: environment parameter for popen2

Initial Comment:
The patch provides a way to specify the environment for
the subprocess run by the popen2, popen3 and popen4
functions in the popen2 module on platforms that use
the Popen3 class. It does that by adding this parameter
to the __init__ method of Popen3 and the popenN
functions calling execvpe in _run_child if the env
parameter was not None.

This patch obviously doesn't add this parameter on e.g.
Windows. AFAICT from posixmodule.c where popen is
implemented via CreateProcess on Windows it would be at
least theorectically possible to implement it on
Windows as well. I don't have the need nor the time for
that unfortunately.

Being able to specify the environment for the
subprocess in popen is very useful for e.g. running a
CGI from Zope. ZCGI for instance modifies os.environ so
that the subprocess inherits it but that cause problems
because other threads may occasionally see a modified
environment. This is particularly bad for the oracle
client libraries on Linux which require certain
environment settings.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 17:48

Message:
Logged In: YES 
user_id=21627

I think this patch has been obsoleted by the subprocess
module (i.e. you can have the same functionality, including
explicit environment variables, through subprocess). So I'm
rejecting the patch.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-04-02 19:10

Message:
Logged In: YES 
user_id=1188172

I have made a documentation patch (attached here; where to
submit else?). However, since similar popen functions are
available in the os module, it is questionable if this
should be applied because there may be confusion about the
different signature.


Index: Doc/lib/libpopen2.tex
===================================================================
RCS file:
/cvsroot/python/python/dist/src/Doc/lib/libpopen2.tex,v
retrieving revision 1.17.2.2
diff -c -r1.17.2.2 libpopen2.tex
*** Doc/lib/libpopen2.tex       7 Jan 2005 06:57:26 -0000  
    1.17.2.2
--- Doc/lib/libpopen2.tex       2 Apr 2005 17:10:29 -0000
***************
*** 14,20 ****
  Note that starting with Python 2.0, this functionality is
available
  using functions from the \refmodule{os} module which have
the same
  names as the factory functions here, but the order of the
return
! values is more intuitive in the \refmodule{os} module
variants.

  The primary interface offered by this module is a trio of
factory
  functions.  For each of these, if \var{bufsize} is specified,
--- 14,21 ----
  Note that starting with Python 2.0, this functionality is
available
  using functions from the \refmodule{os} module which have
the same
  names as the factory functions here, but the order of the
return
! values is different and more intuitive in the
\refmodule{os} module
! variants.

  The primary interface offered by this module is a trio of
factory
  functions.  For each of these, if \var{bufsize} is specified,
***************
*** 29,55 ****
  \function{os.spawnv()}). If \var{cmd} is a string it will
be passed to the
  shell (as with \function{os.system()}).

  The only way to retrieve the return codes for the child
processes is
  by using the \method{poll()} or \method{wait()} methods on the
  \class{Popen3} and \class{Popen4} classes; these are only
available on
  \UNIX.  This information is not available when using the
  \function{popen2()}, \function{popen3()}, and
\function{popen4()}
  functions, or the equivalent functions in the
\refmodule{os} module.
! (Note that the tuples returned by the \refmodule{os}
module's functions
! are in a different order from the ones returned by the
\module{popen2}
! module.)

! \begin{funcdesc}{popen2}{cmd\optional{, bufsize\optional{,
mode}}}
  Executes \var{cmd} as a sub-process.  Returns the file objects
  \code{(\var{child_stdout}, \var{child_stdin})}.
  \end{funcdesc}

! \begin{funcdesc}{popen3}{cmd\optional{, bufsize\optional{,
mode}}}
  Executes \var{cmd} as a sub-process.  Returns the file objects
  \code{(\var{child_stdout}, \var{child_stdin},
\var{child_stderr})}.
  \end{funcdesc}

! \begin{funcdesc}{popen4}{cmd\optional{, bufsize\optional{,
mode}}}
  Executes \var{cmd} as a sub-process.  Returns the file objects
  \code{(\var{child_stdout_and_stderr}, \var{child_stdin})}.
  \versionadded{2.0}
--- 30,59 ----
  \function{os.spawnv()}). If \var{cmd} is a string it will
be passed to the
  shell (as with \function{os.system()}).

+ \versionadded[If you specify the \var{env} parameter,
which is only available on \UNIX,
+ it will be the environment of the subprocess as described
for the
+ \function{spawn*e()} functions in the \refmodule{os}
module.]{2.5}
+
  The only way to retrieve the return codes for the child
processes is
  by using the \method{poll()} or \method{wait()} methods on the
  \class{Popen3} and \class{Popen4} classes; these are only
available on
  \UNIX.  This information is not available when using the
  \function{popen2()}, \function{popen3()}, and
\function{popen4()}
  functions, or the equivalent functions in the
\refmodule{os} module.
! Also, you could use the \refmodule{subprocess} module
which provides
! a more general approach to spawning of child processes.

! \begin{funcdesc}{popen2}{cmd\optional{, bufsize\optional{,
mode\optional{, env}}}}
  Executes \var{cmd} as a sub-process.  Returns the file objects
  \code{(\var{child_stdout}, \var{child_stdin})}.
  \end{funcdesc}

! \begin{funcdesc}{popen3}{cmd\optional{, bufsize\optional{,
mode\optional{, env}}}}
  Executes \var{cmd} as a sub-process.  Returns the file objects
  \code{(\var{child_stdout}, \var{child_stdin},
\var{child_stderr})}.
  \end{funcdesc}

! \begin{funcdesc}{popen4}{cmd\optional{, bufsize\optional{,
mode\optional{, env}}}}
  Executes \var{cmd} as a sub-process.  Returns the file objects
  \code{(\var{child_stdout_and_stderr}, \var{child_stdin})}.
  \versionadded{2.0}
***************
*** 60,66 ****
  functions is also available.  These are not used for the
Windows
  implementation, and are not available on that platform.

! \begin{classdesc}{Popen3}{cmd\optional{,
capturestderr\optional{, bufsize}}}
  This class represents a child process.  Normally,
\class{Popen3}
  instances are created using the \function{popen2()} and
  \function{popen3()} factory functions described above.
--- 64,70 ----
  functions is also available.  These are not used for the
Windows
  implementation, and are not available on that platform.

! \begin{classdesc}{Popen3}{cmd\optional{,
capturestderr\optional{, bufsize\optional{, env}}}}
  This class represents a child process.  Normally,
\class{Popen3}
  instances are created using the \function{popen2()} and
  \function{popen3()} factory functions described above.
***************
*** 69,79 ****
  objects, the parameter \var{cmd} is the shell command to
execute in a
  sub-process.  The \var{capturestderr} flag, if true,
specifies that
  the object should capture standard error output of the
child process.
! The default is false.  If the \var{bufsize} parameter is
specified, it
  specifies the size of the I/O buffers to/from the child
process.
  \end{classdesc}

! \begin{classdesc}{Popen4}{cmd\optional{, bufsize}}
  Similar to \class{Popen3}, but always captures standard
error into the
  same file object as standard output.  These are typically
created
  using \function{popen4()}.
--- 73,86 ----
  objects, the parameter \var{cmd} is the shell command to
execute in a
  sub-process.  The \var{capturestderr} flag, if true,
specifies that
  the object should capture standard error output of the
child process.
! The default is false.  If the \var{bufsize} parameter is
given, it
  specifies the size of the I/O buffers to/from the child
process.
+ If the \var{env} parameter is given (it must be a
mapping), it will
+ be the environment of the new process (instead of a copy
of the
+ current process's).
  \end{classdesc}

! \begin{classdesc}{Popen4}{cmd\optional{,
bufsize\optional{, env}}}
  Similar to \class{Popen3}, but always captures standard
error into the
  same file object as standard output.  These are typically
created
  using \function{popen4()}.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-08-19 13:36

Message:
Logged In: YES 
user_id=21627

Can you please add changes to Doc/lib/libpopen2.tex as well?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695275&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 17:50:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 08:50:16 -0700
Subject: [Patches] [ python-Patches-1470424 ] Fix test_augassign in p3yk
Message-ID: <E1FUQYq-0002HH-6t@sc8-sf-web4-b.sourceforge.net>

Patches item #1470424, was opened at 2006-04-14 17:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470424&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Fix test_augassign in p3yk

Initial Comment:
Fix test_augassign in the p3yk branch, by adjusting
tests to deal with true division. In passing, add
minimal tests for <<= and >>=.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470424&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 17:59:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 08:59:25 -0700
Subject: [Patches] [ python-Patches-702933 ] Kill off docs for unsafe macros
Message-ID: <E1FUQhh-0000Tk-Qp@sc8-sf-web6.sourceforge.net>

Patches item #702933, was opened at 2003-03-13 14:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=702933&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: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Kill off docs for unsafe macros

Initial Comment:
I'll also attach the patch, but a message body is 
required:
=========================================
==========================
RCS 
file: /cvsroot/python/python/dist/src/Doc/api/memory.tex,
v
retrieving revision 1.2
diff -w -u -r1.2 memory.tex
--- memory.tex	6 Apr 2002 09:14:33 -0000
	1.2
+++ memory.tex	13 Mar 2003 12:56:26 -0000
@@ -195,9 +195,7 @@
 In addition to the functions aimed at handling raw 
memory blocks from
 the Python heap, objects in Python are allocated and 
released with
 \cfunction{PyObject_New()}, \cfunction
{PyObject_NewVar()} and
-\cfunction{PyObject_Del()}, or with their corresponding 
macros
-\cfunction{PyObject_NEW()}, \cfunction
{PyObject_NEW_VAR()} and
-\cfunction{PyObject_DEL()}.
+\cfunction{PyObject_Del()}.
 
 These will be explained in the next chapter on defining 
and
 implementing new object types in C.
Index: newtypes.tex
=========================================
==========================
RCS 
file: /cvsroot/python/python/dist/src/Doc/api/newtypes.te
x,v
retrieving revision 1.21
diff -w -u -r1.21 newtypes.tex
--- newtypes.tex	10 Feb 2003 19:18:21 -0000
	1.21
+++ newtypes.tex	13 Mar 2003 12:56:27 -0000
@@ -62,23 +62,6 @@
   after this call as the memory is no longer a valid 
Python object.
 \end{cfuncdesc}
 
-\begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW}{TYPE, 
PyTypeObject *type}
-  Macro version of \cfunction{PyObject_New()}, to gain 
performance at
-  the expense of safety.  This does not check \var{type} 
for a \NULL{}
-  value.
-\end{cfuncdesc}
-
-\begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW_VAR}
{TYPE, PyTypeObject *type,
-                                                int size}
-  Macro version of \cfunction{PyObject_NewVar()}, to 
gain performance
-  at the expense of safety.  This does not check \var
{type} for a
-  \NULL{} value.
-\end{cfuncdesc}
-
-\begin{cfuncdesc}{void}{PyObject_DEL}{PyObject *op}
-  Macro version of \cfunction{PyObject_Del()}.
-\end{cfuncdesc}
-
 \begin{cfuncdesc}{PyObject*}{Py_InitModule}{char 
*name,
                                             PyMethodDef *methods}
   Create a new module object based on a name and 
table of functions,


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 17:59

Message:
Logged In: YES 
user_id=21627

I agree that these macros should not be used. Given that the
patch wasn't rejected for quite some time now, it appears
nobody feels strongly that the macros should stay
documented. Committed as 45395.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 22:31

Message:
Logged In: YES 
user_id=11375

Tim made the suggestion that only the core should use them: 
http://mail.python.org/pipermail/python-dev/2003-March/033993.html

Thomas Heller disagreed.  How should we rule on this?

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2003-07-04 04:37

Message:
Logged In: YES 
user_id=52572

I've forgotten, frankly.  You might check python-dev around 
this date.  Seems like Guido may have agreed that these 
macros were really not meant to be touched by users and 
shouild be deprecated, but I don't recall.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-07-04 03:00

Message:
Logged In: YES 
user_id=3066

I'm not sure what you're suggesting with this patch.  Could
you explain the intention?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=702933&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 18:04:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 09:04:53 -0700
Subject: [Patches] [ python-Patches-721464 ] Remote debugging with pdb.py
Message-ID: <E1FUQmz-0002o8-Mp@sc8-sf-web5.sourceforge.net>

Patches item #721464, was opened at 2003-04-15 01:02
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&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: Open
Resolution: None
Priority: 5
Submitted By: Laurent Pelecq (lpelecq)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Remote debugging with pdb.py

Initial Comment:
With this patch, instances of pdb.Pdb can read and
write from arbitrary file objects. It is based on
similar changes that have been made to cmd.py. It
basically consists of replacing print statement with
calls to self.stdout.write.

So it is possible for example to control the debugger
from another terminal to debug curses-based
applications or CGI scripts.

I can provide a basic client/server debugger.

This patch has been tested on Mandrake Linux 9.1 with
the current CVS version.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 18:04

Message:
Logged In: YES 
user_id=21627

lpelecq, would you be willing to redo that patch for 2.5?
Using print redirection (instead of .write calls) might be
the easiest way to do it.

rhettinger, do you want to come back to this patch now? If
not, please unassign.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-22 19:15

Message:
Logged In: YES 
user_id=80475

I think this is a good idea.
It is past the the time for being added to 2.3.
Unassigning, but will come back to it for 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 18:09:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 09:09:15 -0700
Subject: [Patches] [ python-Patches-723312 ] ability to pass a timeout to
	underlying socket
Message-ID: <E1FUQrD-0008FQ-1e@sc8-sf-web3.sourceforge.net>

Patches item #723312, was opened at 2003-04-17 21:03
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&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.3
Status: Open
Resolution: Works For Me
Priority: 6
Submitted By: Matthew Russell (mattruss)
Assigned to: Skip Montanaro (montanaro)
Summary: ability to pass a timeout to underlying socket

Initial Comment:
this patch superceeds an earlier one i posted (#714592)
 - a bit *too* enthusiastic am afraid (sorry!)

classes in modules such as  httplib, ftpplib do not
currently allow an easy way to take advantage of the
new socket timeout feature in 2.3.

This patch provides that abilty though one additonal
class in socket.py ( socket.NetworkConnection ) and
accompying test in test_socket.py (basic though the
test is :-s )

As an extra benifit, the patch removes duplicate code,
as each connect method in the main class of most
modules (FTP, HTTPConnection, Telnet, POP3 etc) are
copies of each other.

The modules that use sockets are:

    * ftplib
    * httplib 
    * telnetlib
    * poplib
    * urllib
    * imaplib
    * nntplib
    * xmlrpclib

Of these I have only been able to easily refactor
NetworkConnection into httplib, ftplib, telnetllib,
poplib and smtplib.

I did look to see if there were any unittests for
theese modules in .Lib/test but found none (? - I
appologise if there are some, i am new to the library
tests)

I did however check that the test() [like] methods at
the bottom of each of the afore mentioned modules worked.


thanks for your advice again Skip :o)
Matt



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 18:09

Message:
Logged In: YES 
user_id=21627

mattruss, are you interested in forward-porting it to 2.5?
If that gets done before the beta release, please assign it
to me for review.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-10-01 05:39

Message:
Logged In: YES 
user_id=29957

Just a quick note - this patch might be accepted for 2.5,
but it's not suitable for 2.4.x - once a major release is
done, subsequent minor releases (2.3.x, 2.4.x) are
bugfix-only. No new features are acceptable. For more on
this, see http://www.python.org/peps/pep-0006.html


----------------------------------------------------------------------

Comment By: zeidler (zeidler)
Date: 2005-09-28 16:22

Message:
Logged In: YES 
user_id=1082576

perhaps to add a little emphasis:  i'd really like to see
that patch included into one of the next releases too.  i
was just going to submit my own, much much simpler version
of adding a socket timeout in httplib.py, but matt's patch
is a much better way to do this...

we're using xml-rpc a lot over here, and the default
timeouts are just way too long to keep up a decent user
interaction in case of server problems.  so, we'd really
appreciate this becoming part of the distro! ;)

thanks & good job matt,


andi


----------------------------------------------------------------------

Comment By: Gr?goire Weber (gregweb)
Date: 2005-01-12 14:52

Message:
Logged In: YES 
user_id=812601

Just lobbying:

It would be nice to have that on board in futire python
versions.
Would this be possible in python 2.4.1?

I need timeouts for xmlrpclib and subclassed
xmlrpclib.Transport for my needs.

But nevertheless it would be nice to have that in python 2.4.1.
Thanks!

Gregoire

----------------------------------------------------------------------

Comment By: Matthew Russell (mattruss)
Date: 2003-04-21 01:20

Message:
Logged In: YES 
user_id=737261

Errata:
i forgot to mention urlllib2 as modules affected.

the line above starting &quot;The modules that use sockets are: &quot;
should really read: &quot;classes in the modules stated below
would benifit from the ability pass timeouts:&quot;



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 18:10:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 09:10:17 -0700
Subject: [Patches] [ python-Patches-728815 ] test_timeout updates
Message-ID: <E1FUQsD-0003n7-Ee@sc8-sf-web4-b.sourceforge.net>

Patches item #728815, was opened at 2003-04-28 12:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Raymond Hettinger (rhettinger)
Summary: test_timeout updates

Initial Comment:
Changes:

- code refactoring;
- now we catch only exceptions with proper errno codes
(also see bug #708927);
- addr_remote changed, ('www.google.com', 80) not
always works for me since we use transparent proxy;
- attempt to implement testSend(), testSendto(),
testSendall();

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 18:10

Message:
Logged In: YES 
user_id=21627

rhettinger: would you like to review it now? If not, please
unassign.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 16:52

Message:
Logged In: YES 
user_id=80475

I'll give it more review.

Since Py2.3b2 is out, I'm marking this as a change for Py2.4 
and we can apply it in early August.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 16:52

Message:
Logged In: YES 
user_id=80475

I'll give it more review.

Since Py2.3b2 is out, I'm marking this as a change for Py2.4 
and we can apply it in early August.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-30 16:52

Message:
Logged In: YES 
user_id=80475

I'll give it more review.

Since Py2.3b2 is out, I'm marking this as a change for Py2.4 
and we can apply it in early August.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-30 14:37

Message:
Logged In: YES 
user_id=89016

I'm no expert in socket programming, so the final decision
whether  this is OK is your's.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 16:09

Message:
Logged In: YES 
user_id=80475

Walter, are you interested in working this patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 18:37:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 09:37:55 -0700
Subject: [Patches] [ python-Patches-1162023 ] don't add -OPT:Olimit=0 for icc
Message-ID: <E1FURIx-0005HZ-QK@sc8-sf-web5.sourceforge.net>

Patches item #1162023, was opened at 2005-03-12 15:58
Message generated for change (Comment added) made by hoffmanm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162023&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: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: don't add -OPT:Olimit=0 for icc

Initial Comment:
Patch to configure.in to fix problem described in:

http://sourceforge.net/tracker/?func=detail&aid=1162001&group_id=5470&atid=105470

----------------------------------------------------------------------

>Comment By: Michael Hoffman (hoffmanm)
Date: 2006-04-14 16:37

Message:
Logged In: YES 
user_id=987664

It's disappointing that after all that the fix that was
checked in eventually wasn't as complete as the patch I
provided (i.e. does not deal with Martin's complaint of not
catching e.g. CC=/usr/bin/icc).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 15:13

Message:
Logged In: YES 
user_id=21627

Ok, something like this was committed as 41953; closing this
patch as out-of-date.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-04-04 16:09

Message:
Logged In: YES 
user_id=987664

Well, it probably can be done but that would really require
a completely different patch. I unfortunately have not had
the time to produce such a patch.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-18 18:27

Message:
Logged In: YES 
user_id=21627

Hmm. I would really like to see something still more
general, but am willing to commit this if you assert that
nothing more general exists.

Eg. what if somebody links /usr/bin/cc to icc? You really
should find out whether the compiler *is* ICC, not whether
its name is icc (or, better yet, whether the compiler really
does support -OPT:Olimit). For example, if 'icc --version'
prints "Intel Compiler version 9.0" or some such, that would
be a reliable test for icc.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-18 13:17

Message:
Logged In: YES 
user_id=987664

OK, here's another attempt at it that uses the autoconf
AS_BASENAME macro. Additionally it removes libm from the
default libraries if you are using icc. Intel has their own
math library which is automatically linked, and using -lm
causes problems.

Sorry this took so long--anonymous CVS access had been down
for several days.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-13 22:42

Message:
Logged In: YES 
user_id=21627

This test is too weak. If CC is, say, "/opt/intel/bin/icc",
the test would fail, right?

So please come up with a separate test to determine if the
compiler is icc, and then skip the entire test whether it
accepts -OPT:Olimit.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162023&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 19:12:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 10:12:19 -0700
Subject: [Patches] [ python-Patches-1162023 ] don't add -OPT:Olimit=0 for icc
Message-ID: <E1FURqF-0008R6-Di@sc8-sf-web4-b.sourceforge.net>

Patches item #1162023, was opened at 2005-03-12 16:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162023&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: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Neal Norwitz (nnorwitz)
Summary: don't add -OPT:Olimit=0 for icc

Initial Comment:
Patch to configure.in to fix problem described in:

http://sourceforge.net/tracker/?func=detail&aid=1162001&group_id=5470&atid=105470

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 19:12

Message:
Logged In: YES 
user_id=21627

Would you like to rework your patch so it applies to the
current configure.in? I'll apply it then right away
(although I still would like to see a patch that recognizes
icc by feature, not by name)

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2006-04-14 18:37

Message:
Logged In: YES 
user_id=987664

It's disappointing that after all that the fix that was
checked in eventually wasn't as complete as the patch I
provided (i.e. does not deal with Martin's complaint of not
catching e.g. CC=/usr/bin/icc).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 17:13

Message:
Logged In: YES 
user_id=21627

Ok, something like this was committed as 41953; closing this
patch as out-of-date.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-04-04 18:09

Message:
Logged In: YES 
user_id=987664

Well, it probably can be done but that would really require
a completely different patch. I unfortunately have not had
the time to produce such a patch.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-18 19:27

Message:
Logged In: YES 
user_id=21627

Hmm. I would really like to see something still more
general, but am willing to commit this if you assert that
nothing more general exists.

Eg. what if somebody links /usr/bin/cc to icc? You really
should find out whether the compiler *is* ICC, not whether
its name is icc (or, better yet, whether the compiler really
does support -OPT:Olimit). For example, if 'icc --version'
prints "Intel Compiler version 9.0" or some such, that would
be a reliable test for icc.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-18 14:17

Message:
Logged In: YES 
user_id=987664

OK, here's another attempt at it that uses the autoconf
AS_BASENAME macro. Additionally it removes libm from the
default libraries if you are using icc. Intel has their own
math library which is automatically linked, and using -lm
causes problems.

Sorry this took so long--anonymous CVS access had been down
for several days.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-13 23:42

Message:
Logged In: YES 
user_id=21627

This test is too weak. If CC is, say, "/opt/intel/bin/icc",
the test would fail, right?

So please come up with a separate test to determine if the
compiler is icc, and then skip the entire test whether it
accepts -OPT:Olimit.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162023&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 19:15:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 10:15:13 -0700
Subject: [Patches] [ python-Patches-1470459 ] fix test_exceptions in p3yk
Message-ID: <E1FURt3-00083w-Jt@sc8-sf-web5.sourceforge.net>

Patches item #1470459, was opened at 2006-04-14 19:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470459&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_exceptions in p3yk

Initial Comment:
Fixes test_exceptions in p3yk, by making the test
exception inherit from Exception. Also fixes
PyErr_SetObject() to only set proper exceptions
(meaning subclasses of BaseException.) It raises
(somewhat arbitrarily) SystemError when the C API tries
to raise an invalid exception. Added a test for that
behaviour to test_exceptions, too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470459&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 19:18:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 10:18:21 -0700
Subject: [Patches] [ python-Patches-1470460 ] fix test_bisect
Message-ID: <E1FURw5-00061f-8R@sc8-sf-web2.sourceforge.net>

Patches item #1470460, was opened at 2006-04-14 19: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=1470460&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_bisect

Initial Comment:
Trivial fix for test_bisect: since LenOnly and GetOnly
are newstyle classes now (as is everything), trying to
do the operation they don't have now raises TypeError
instead of AttributeError.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470460&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 20:27:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 11:27:17 -0700
Subject: [Patches] [ python-Patches-1453235 ] IDNA codec simplification
Message-ID: <E1FUT0n-0001bN-JL@sc8-sf-web3.sourceforge.net>

Patches item #1453235, was opened at 2006-03-18 16:52
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&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: Fixed
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Walter D?rwald (doerwalter)
Summary: IDNA codec simplification

Initial Comment:
This patch simplifies the idna codec. It moves the
encode and decode functionality out of the Codec class,
so that it can be reused by the stateless and the
incremental codecs. (See patch #1436130 for the history
of this patch).

----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-04-14 20:27

Message:
Logged In: YES 
user_id=89016

r45401 now contains a proper incremental encoder and decoder.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-19 11:52

Message:
Logged In: YES 
user_id=89016

You're right, this patch doesn't change the codecs behaviour
at all (the StreamWriter has to same problem:
import sys, codecs

w = codecs.getwriter("idna")(sys.stdout)
w.write(u"d??r")
w.write(u"wald.de")
)

I'll try to come up with a patch that implements a real
incremental encoder and decoder.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 11:13

Message:
Logged In: YES 
user_id=21627

This patch is wrong (AFAICT). If I understand the
incremental API correctly, it should be possible to pass
chunks of the input to the incremental encoder;
concatenating the results should give the same string as if
I had passed the entire input at once. This doesn't work for
this patch:

py> u"d??rwald.de".encode("idna")
'xn--drwald-wxa.de'
py> c = codecs.getincrementalencoder("idna")()
py> c.encode(u"d??r")
'xn--dr-fka'
py> c.encode(u"wald.de")
'wald.de'

So in the first case, I get the (correct) result
'xn--drwald-wxa.de'; in the second case, I get the incorrect
result 'xn--dr-fkawald.de'.

To properly encode IDNA incrementally, you need to process
an entire label at a time (i.e. between two dots, 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 20:38:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 11:38:12 -0700
Subject: [Patches] [ python-Patches-1162023 ] don't add -OPT:Olimit=0 for icc
Message-ID: <E1FUTBM-0001nO-Fk@sc8-sf-web1.sourceforge.net>

Patches item #1162023, was opened at 2005-03-12 15:58
Message generated for change (Comment added) made by hoffmanm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162023&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: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Neal Norwitz (nnorwitz)
Summary: don't add -OPT:Olimit=0 for icc

Initial Comment:
Patch to configure.in to fix problem described in:

http://sourceforge.net/tracker/?func=detail&aid=1162001&group_id=5470&atid=105470

----------------------------------------------------------------------

>Comment By: Michael Hoffman (hoffmanm)
Date: 2006-04-14 18:38

Message:
Logged In: YES 
user_id=987664

I don't have svn installed yet, so it would be a lot of
doing at the moment. That's on my list of things to do but
don't have time right now and I doubt anyone else has time
for this trivial thing. So I guess just forget it, sorry
about the frustration.

Closed related bug 1162001 as fixed.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 17:12

Message:
Logged In: YES 
user_id=21627

Would you like to rework your patch so it applies to the
current configure.in? I'll apply it then right away
(although I still would like to see a patch that recognizes
icc by feature, not by name)

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2006-04-14 16:37

Message:
Logged In: YES 
user_id=987664

It's disappointing that after all that the fix that was
checked in eventually wasn't as complete as the patch I
provided (i.e. does not deal with Martin's complaint of not
catching e.g. CC=/usr/bin/icc).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-14 15:13

Message:
Logged In: YES 
user_id=21627

Ok, something like this was committed as 41953; closing this
patch as out-of-date.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-04-04 16:09

Message:
Logged In: YES 
user_id=987664

Well, it probably can be done but that would really require
a completely different patch. I unfortunately have not had
the time to produce such a patch.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-18 18:27

Message:
Logged In: YES 
user_id=21627

Hmm. I would really like to see something still more
general, but am willing to commit this if you assert that
nothing more general exists.

Eg. what if somebody links /usr/bin/cc to icc? You really
should find out whether the compiler *is* ICC, not whether
its name is icc (or, better yet, whether the compiler really
does support -OPT:Olimit). For example, if 'icc --version'
prints "Intel Compiler version 9.0" or some such, that would
be a reliable test for icc.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-03-18 13:17

Message:
Logged In: YES 
user_id=987664

OK, here's another attempt at it that uses the autoconf
AS_BASENAME macro. Additionally it removes libm from the
default libraries if you are using icc. Intel has their own
math library which is automatically linked, and using -lm
causes problems.

Sorry this took so long--anonymous CVS access had been down
for several days.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-13 22:42

Message:
Logged In: YES 
user_id=21627

This test is too weak. If CC is, say, "/opt/intel/bin/icc",
the test would fail, right?

So please come up with a separate test to determine if the
compiler is icc, and then skip the entire test whether it
accepts -OPT:Olimit.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162023&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 21:27:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 12:27:46 -0700
Subject: [Patches] [ python-Patches-1470504 ] partially fix test_class in
	p3yk
Message-ID: <E1FUTxK-0005Zj-AL@sc8-sf-web1.sourceforge.net>

Patches item #1470504, was opened at 2006-04-14 21: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=1470504&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: partially fix test_class in p3yk

Initial Comment:
Partially fix test_class in p3yk. This allows the test
to be actually run, although it could also be solved by
allowing 'exec' to receive any dict-like object
(there's a patch for that elsewhere, slated for 2.5, I
believe, but dictproxy objects would have to grow
setitem support for it to work.) Me, I prefer setattr()
like this over mucking with __dict__, although I have
to admit it did find a potential bug :) (The issue is
that class.__dict__ is a dictproxy object, if class is
a newstyle class.)

There are, however, more problems with test_class that
this doesn't resolve:

 - Classic classes that have a __cmp__ or __eq__
method, but no __hash__ method, are unhashable. The
same is not true for new-style classes. I'm not sure
whether that's a bug in new-style classes, or
desireable behaviour.

 - The recursive-__call__ test (where Ainst.__call__ ==
Ainst, so the hunt for the actual code to run is
recursive) crashes Python on my machine. The test
doesn't crash for classic classes. It seems to be a
stack overflow, or some other memory corruption scheme,
but I'll have to find me a machine with less address
space and memory to more comfortly debug this (talk
about a luxury problem!)

 - __coerce__ isn't being called. I don't recall
whether that's a newstyle-class issue, or a py3k
decision, or a bug. If it isn't a bug, output just has
to be regenerated.

 - Output has to be regenerated to pick up __truediv__
and __rtruediv__ instead of __div__ and __rdiv__.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470504&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 21:28:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 12:28:09 -0700
Subject: [Patches] [ python-Patches-1470460 ] fix test_bisect in p3yk
Message-ID: <E1FUTxh-0006C4-Eh@sc8-sf-web3.sourceforge.net>

Patches item #1470460, was opened at 2006-04-14 19:18
Message generated for change (Settings changed) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470460&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: fix test_bisect in p3yk

Initial Comment:
Trivial fix for test_bisect: since LenOnly and GetOnly
are newstyle classes now (as is everything), trying to
do the operation they don't have now raises TypeError
instead of AttributeError.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470460&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 21:28:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 12:28:25 -0700
Subject: [Patches] [ python-Patches-1470424 ] Fix test_augassign in p3yk
Message-ID: <E1FUTxx-0007gs-C5@sc8-sf-web6.sourceforge.net>

Patches item #1470424, was opened at 2006-04-14 17:50
Message generated for change (Settings changed) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470424&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Fix test_augassign in p3yk

Initial Comment:
Fix test_augassign in the p3yk branch, by adjusting
tests to deal with true division. In passing, add
minimal tests for <<= and >>=.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470424&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 21:40:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 12:40:41 -0700
Subject: [Patches] [ python-Patches-1470515 ] fix test_descrtut in p3yk
Message-ID: <E1FUU9p-0006YF-QW@sc8-sf-web1.sourceforge.net>

Patches item #1470515, was opened at 2006-04-14 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=1470515&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_descrtut in p3yk

Initial Comment:
Fixes test_descrtut in p3yk: mostly the difference
between 'print cls' for new-style and classic classes.
Also changed the MRO test for classic/newstyle classes
into an MRO test for implicit/explicit newstyle
classes, instead.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470515&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 21:47:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 12:47:40 -0700
Subject: [Patches] [ python-Patches-1470522 ] fix test_enumerate in p3yk
Message-ID: <E1FUUGa-0002YC-Gg@sc8-sf-web5.sourceforge.net>

Patches item #1470522, was opened at 2006-04-14 21:47
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=1470522&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_enumerate in p3yk

Initial Comment:
Fixes test_enumerate in p3yk; the failure is caused by
iter() doing the test for the 'next' method a lot
earlier, when dealing with newstyle classes, so the
TypeError the test was trying to trigger blew up in its
face.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470522&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 21:59:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 12:59:50 -0700
Subject: [Patches] [ python-Patches-1470536 ] Fix test_descr in p3yk
Message-ID: <E1FUUSM-0007zk-9h@sc8-sf-web1.sourceforge.net>

Patches item #1470536, was opened at 2006-04-14 21:59
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=1470536&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Fix test_descr in p3yk

Initial Comment:
Fixes test_descr in p3yk, by removing tests that test
for classic-class behaviour (including mixing classic
classes with new-style classes.) I may have removed too
many tests, but I don't think so.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470536&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 22:12:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 13:12:25 -0700
Subject: [Patches] [ python-Patches-1470543 ] fix test_getargs2 in p3yk
Message-ID: <E1FUUeX-000510-6z@sc8-sf-web4-b.sourceforge.net>

Patches item #1470543, was opened at 2006-04-14 22: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=1470543&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_getargs2 in p3yk

Initial Comment:
Fixes test_getargs2 in p3yk, where PyArg_* no longer
silently converts floats to ints, for integer format
characters.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470543&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 22:21:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 13:21:23 -0700
Subject: [Patches] [ python-Patches-1470548 ] Bugfix for #1470540
	(XMLGenerator cannot output UTF-16)
Message-ID: <E1FUUnD-0001Bj-Fi@sc8-sf-web1.sourceforge.net>

Patches item #1470548, was opened at 2006-04-15 00:21
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=1470548&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: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikolai Grigoriev (ngrig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugfix for #1470540 (XMLGenerator cannot output UTF-16)

Initial Comment:
This is a patch to bug #1470540. It enables
xml.sax.saxutils.XMLGenerator to work correctly with
UTF-16 (and other encodings not derived from US-ASCII).
The proposed changes are as follows:

- in XMLGenerator.__init__(), create a StreamWriter
instead of a plain stream;

- in XMLGenerator._write(), convert everything to
Unicode before writing;

- in XMLGenerator.endDocument(), flush the StreamWriter.

The patch is applicable to xml/sax/saxutils.py in the
stable release (2.4.3), as well as to
xmlcore/sax/saxutils.py in the current release (2.5).

The smoke test is attached to the bug description in
the Bug Manager.

Regards,
Nikolai Grigoriev

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470548&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 22:46:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 13:46:06 -0700
Subject: [Patches] [ python-Patches-1470560 ] fix test_inspect in p3yk
Message-ID: <E1FUVB8-00031l-AH@sc8-sf-web1.sourceforge.net>

Patches item #1470560, was opened at 2006-04-14 22: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=1470560&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_inspect in p3yk

Initial Comment:
Fixes test_inspect in p3yk, by removing tests for
classic-class behaviour, and converting one test
(fetching the class tree of a set of classes) to
new-style class output.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470560&group_id=5470

From noreply at sourceforge.net  Fri Apr 14 22:55:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 13:55:04 -0700
Subject: [Patches] [ python-Patches-1470566 ] fix test_itertools in p3yk
Message-ID: <E1FUVJo-0005kb-Re@sc8-sf-web6.sourceforge.net>

Patches item #1470566, was opened at 2006-04-14 22: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=1470566&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_itertools in p3yk

Initial Comment:
Fixes test_itertools in p3yk: more cases where
iter(obj) raises TypeError earlier than expected.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470566&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 00:12:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Apr 2006 15:12:27 -0700
Subject: [Patches] [ python-Patches-1185444 ] urllib2 dloads failing through
	HTTP proxy w/ auth
Message-ID: <E1FUWWh-0000zN-He@sc8-sf-web1.sourceforge.net>

Patches item #1185444, was opened at 2005-04-18 22:07
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185444&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Fleetwood (mfleetwo)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 dloads failing through HTTP proxy w/ auth

Initial Comment:
When using urllib2 to download through a HTTP proxy, 
which requires
authorisation, a broken HTTP request is sent.  The initial 
request might
work but subsequent requests send using the same socket 
definitely
fail.

Problem occurs on Fedora Core 3 with python 2.3.4.  Buggy 
code still
exists in Python Library in 2.4.1.

Found the problem using yum to download files via my 
companies Microsoft
ISA web proxy.  The proxy requires authorisation.  I set the 
HTTP_PROXY
environment variable to define the proxy like this:
  export HTTP_PROXY=http://username:password at proxy.
example.com:8080/

Analysis from my yum bugzilla report
http://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=441 , 
follows:

Location is:
  File:     urllib2.py
  Class:    ProxyHandler
  Function: proxy_open()

The basic proxy authorisation string is created using
base64.encodestring() and passed to add_header() method 
of a Request
object.  However base64.encodestring() specifically adds a 
trailing
'\n' but when the headers are sent over the socket each is 
followed by
'\r\n'.  The server sees this double new line as the end of the 
HTTP
request and the rest of the HTTP headers as a second 
invalid request.

The broken request looks like this:
  GET ...
  Host: ...
  Accept-Encoding: identity
  Proxy-authorization: Basic xxxxxxxxxxxxxxxx
                           <-- Blank line which shouldn't be there
  User-agent: urlgrabber/2.9.2
                           <-- Blank line ending HTTP request

The fix is just to remove the '\n' which base64.encodestring() 
added
before calling add_header().  Just use string method strip() 
as is done
in the only other location base64.encodestring() is used in 
file
urllib2.py.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-14 23:12

Message:
Logged In: YES 
user_id=261020

This was fixed in revision 39377.

----------------------------------------------------------------------

Comment By: James William Pye (jwpye)
Date: 2005-05-04 02:15

Message:
Logged In: YES 
user_id=1044177

Seems like a valid issue to me.
Each header in HTTP must be followed with a CRLF, not a LFCRLF:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4

And I don't think it consistutes continuation of the
field-content either as the LF is not followed by at least 1
SP or HT, rather a CRLF(per LWS).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185444&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 09:15:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 00:15:32 -0700
Subject: [Patches] [ python-Patches-1166195 ] Using size_t where appropriate
Message-ID: <E1FUf0G-0002w2-M0@sc8-sf-web5.sourceforge.net>

Patches item #1166195, was opened at 2005-03-18 20:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166195&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Martin v. L??wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using size_t where appropriate

Initial Comment:
This patch is (a first draft of) an attempt to make
Python properly use size_t where necessary. This work
is triggered by compilation on Win64 (where the
compiler warns about potential truncation errors a
lot). The rationale for the patch is that size_t might
be larger than int, in particular on 64-bit platforms,
and that the size of a memory chunk cannot reliably be
measured with an int.

It turns out that using size_t is not enough, since
values can sometimes also be negative. For these cases,
a "signed" size_t is used, which is called Py_ssize_t
and is a define for ssize_t if the compiler supports
the latter.

The guideline for converting int to size_t used in this
patch is this:
- if the variable is meant to store the number of
bytes, and is always guaranteed to be positive, and
could get arbitrarily large, use size_t
- if the value could be negative also, use ssize_t
- if the value is meant to store a number of "things",
but this directly translates into size_t (e.g. number
of pointers, number of characters), also use size_t/ssize_t
- if the value is in a range limited to 32-bit int
(e.g. the number of characters in a path name), convert
the size_t to int, after asserting that the value
really is in the range.

This version is work in progress, and needs review. I
hope to work on it during the sprints at PyConDC.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 09:15

Message:
Logged In: YES 
user_id=21627

And now it is part of the trunk.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-12-17 11:19

Message:
Logged In: YES 
user_id=21627

This patch is now maintained in

http://svn.python.org/projects/python/branches/ssize_t/

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-05-06 09:06

Message:
Logged In: YES 
user_id=21627

Second version of the patch attached (PyCon version). It turns out that 
changing everything from signed to unsigned breaks too many things, so 
this version of the patch uses Py_ssize_t in nearly all places.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166195&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 10:14:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 01:14:54 -0700
Subject: [Patches] [ python-Patches-1161914 ] python-config
Message-ID: <E1FUfvi-0007h2-0M@sc8-sf-web4-b.sourceforge.net>

Patches item #1161914, was opened at 2005-03-12 11:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Andre Jonsson (tatsujin)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-config

Initial Comment:
I'm not sure this is the correct place to do this, but I found the need 
for a python-config (similar to sdl-config, etc.) when building an 
C++ application that embeds python.

It accepts two arguments --cflags and --static-libs:

# ./python-config --cflags --static-libs 
-I/usr/include/python2.4
/usr/lib/python2.4/config/libpython2.4.a

I guess it could be expanded to do more, but it was all I needed.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 10:14

Message:
Logged In: YES 
user_id=21627

I took gbrandl's python-config, added a build process, and
committed this patch as #45417. Thanks to all contributors!

----------------------------------------------------------------------

Comment By: Andre Jonsson (tatsujin)
Date: 2006-03-31 16:49

Message:
Logged In: YES 
user_id=195710

Excellent work! Looks nice.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-31 16:26

Message:
Logged In: YES 
user_id=849994

Uploading a python-only version. This should conform more
with pkg-config, though every *-config program on my box has
other options.

----------------------------------------------------------------------

Comment By: Andre Jonsson (tatsujin)
Date: 2005-06-11 15:15

Message:
Logged In: YES 
user_id=195710

1. php? Anyway, I see that the 'lib' attribute actually isn't an official one. Bad 
call from my part.
2. Yes, I'm ashamed to have commited such atrocities. :-)
3. Ah, I see. Didn't know about that one.

That said, as loewis stated previously this script should probably follow the 
pkg-config standard anyhow. I haven't gotten around to do anything further in 
this matter, unfortunately.

----------------------------------------------------------------------

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-06-10 17:03

Message:
Logged In: YES 
user_id=488897

Three comments:

1) When running this script, I got the following error on
Unix and Cygwin:

$ python-config.php --cflags --static-libs
-I/usr/local/include/python2.4
Traceback (most recent call last):
  File "<string>", line 1, in ?
AttributeError: 'module' object has no attribute 'lib'

2) Since we are Pythoneers, why write this script as a
shell-script instead of a Python script? (sh may not even be
available on Windows).

3) Isn't it easier / more reliable to get this information
via distutils? See section 5.6 of "Extending and Embedding
the Python Interpreter".

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-14 20:14

Message:
Logged In: YES 
user_id=21627

It appears that the *-config programs (e.g. gtk-config, ...)
share command line options; this seems to be part of the
"pkg-config" system. I think we need to understand what
precisely the standard for these utilities is, and conform
to it.

----------------------------------------------------------------------

Comment By: Andre Jonsson (tatsujin)
Date: 2005-03-14 09:43

Message:
Logged In: YES 
user_id=195710

Ok. I'll make an attempt. What do you mean by "what 
specific options are expected from a *-config program" 
?


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-03-13 23:47

Message:
Logged In: YES 
user_id=21627

This is the right place if you want this to be included in
the standard Python distribution. If you just want to share
it with others, the Python cookbook is a better place:

http://aspn.activestate.com/ASPN/Python/Cookbook/

In the current form, this is not acceptable, as it is
incomplete (e.g. there is no integration into the Python
build process, and we need to know what specific options are
expected from a *-config program, and implement them). Are
you willing to complete this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 10:23:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 01:23:16 -0700
Subject: [Patches] [ python-Patches-1183712 ] package_data chops off first
	char of default package
Message-ID: <E1FUg3o-0008Ln-9b@sc8-sf-web4-b.sourceforge.net>

Patches item #1183712, was opened at 2005-04-15 14:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: package_data chops off first char of default package

Initial Comment:
If the package name is an empty string (ie the default
package), all package_data files have the first
character chopped off.
Attached is a test package pytest.tar.gz where running
python2.4 setup.py build_py
produces this error:
running build_py
creating build
creating build/lib
copying __init__.py -> build/lib
error: can't copy 'ATA': doesn't exist or not a regular
file

Also attached is a fix proposal, though I have tested
this only against the test package.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 10:23

Message:
Logged In: YES 
user_id=21627

Why are you using an empty name as the package name? There
is no default package in Python, so this shouldn't work at all.

----------------------------------------------------------------------

Comment By: Herv? Cauwelier (hcauwelier)
Date: 2005-10-05 13:03

Message:
Logged In: YES 
user_id=1216236

The patch worked well for me, thanks for it!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 10:28:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 01:28:06 -0700
Subject: [Patches] [ python-Patches-1185444 ] urllib2 dloads failing through
	HTTP proxy w/ auth
Message-ID: <E1FUg8U-0000FQ-Cn@sc8-sf-web4-b.sourceforge.net>

Patches item #1185444, was opened at 2005-04-18 23:07
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185444&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.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Fleetwood (mfleetwo)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 dloads failing through HTTP proxy w/ auth

Initial Comment:
When using urllib2 to download through a HTTP proxy, 
which requires
authorisation, a broken HTTP request is sent.  The initial 
request might
work but subsequent requests send using the same socket 
definitely
fail.

Problem occurs on Fedora Core 3 with python 2.3.4.  Buggy 
code still
exists in Python Library in 2.4.1.

Found the problem using yum to download files via my 
companies Microsoft
ISA web proxy.  The proxy requires authorisation.  I set the 
HTTP_PROXY
environment variable to define the proxy like this:
  export HTTP_PROXY=http://username:password at proxy.
example.com:8080/

Analysis from my yum bugzilla report
http://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=441 , 
follows:

Location is:
  File:     urllib2.py
  Class:    ProxyHandler
  Function: proxy_open()

The basic proxy authorisation string is created using
base64.encodestring() and passed to add_header() method 
of a Request
object.  However base64.encodestring() specifically adds a 
trailing
'\n' but when the headers are sent over the socket each is 
followed by
'\r\n'.  The server sees this double new line as the end of the 
HTTP
request and the rest of the HTTP headers as a second 
invalid request.

The broken request looks like this:
  GET ...
  Host: ...
  Accept-Encoding: identity
  Proxy-authorization: Basic xxxxxxxxxxxxxxxx
                           <-- Blank line which shouldn't be there
  User-agent: urlgrabber/2.9.2
                           <-- Blank line ending HTTP request

The fix is just to remove the '\n' which base64.encodestring() 
added
before calling add_header().  Just use string method strip() 
as is done
in the only other location base64.encodestring() is used in 
file
urllib2.py.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 10:28

Message:
Logged In: YES 
user_id=21627

Closing as fixed.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 00:12

Message:
Logged In: YES 
user_id=261020

This was fixed in revision 39377.

----------------------------------------------------------------------

Comment By: James William Pye (jwpye)
Date: 2005-05-04 03:15

Message:
Logged In: YES 
user_id=1044177

Seems like a valid issue to me.
Each header in HTTP must be followed with a CRLF, not a LFCRLF:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4

And I don't think it consistutes continuation of the
field-content either as the LF is not followed by at least 1
SP or HT, rather a CRLF(per LWS).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185444&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 10:36:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 01:36:46 -0700
Subject: [Patches] [ python-Patches-1191065 ] socketmodule.c's recvfrom on
	OSF/1 4.0
Message-ID: <E1FUgGs-0000s8-7k@sc8-sf-web4-b.sourceforge.net>

Patches item #1191065, was opened at 2005-04-27 17:02
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191065&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Marcel Martin (mmar)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c's recvfrom on OSF/1 4.0

Initial Comment:
Compilation of Modules/socketmodule.c fails on OSF/1 4.0 
with GCC versions 3.1 and 3.2. 
 
The error message is: 
python/dist/src/Modules/socketmodule.c:2139:1: directives 
may not be used inside a macro argument 
 
Line 2139 is in function sock_recvfrom(). The problem is 
that the function recvfrom() on the machine I use is a macro 
and the parameters for it are pieced together by use of #if 
instructions to the preprocessor, similar to the following 
code: 
 
------- 
#include <stdio.h> 
 
#define macro(a, b) printf("Test: %d %d\n", a, b) 
 
int main(int argc, char** argv) { 
	macro(1, 2); // works 
 
	macro(1, 
#if defined(SOMETHING) 
	1 // error message here with older GCC 
#else 
 	2 
#endif 
	); 
	return 0; 
} 
------- 
This small test compiles with GCC 3.4, but with none of 
2.95.3, 3.1, or 3.2. 
 
The problem was in Python 2.3.4, 2.4.1 and CVS HEAD. 
 
The attached patch (against CVS HEAD) fixes the problem 
by pulling the "#if"s out of the parameter list. Not as nice as 
before, but it works for me. 

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 10:36

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. It didn't apply cleanly, so I redid it
and committed it as r45418 and r45419.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191065&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 10:41:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 01:41:39 -0700
Subject: [Patches] [ python-Patches-1191700 ] wrong offsets in bpprint()
Message-ID: <E1FUgLb-0001En-6f@sc8-sf-web4-b.sourceforge.net>

Patches item #1191700, was opened at 2005-04-28 15:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191700&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.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Pechkin (mpech)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong offsets in bpprint()

Initial Comment:
1. create some breakpoints
2. use 'break' to list'em
3. wrong offset output


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 10:41

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as r45420 and r45421.

----------------------------------------------------------------------

Comment By: Pechkin (mpech)
Date: 2005-04-29 11:07

Message:
Logged In: YES 
user_id=1244219

1. Try the link
http://foto.inbox.lv/mpech2/misc/bdb.jpg
it shows some wrong offset in command 'break'

2. Also you could fix it to move header :)

----------------------------------------------------------------------

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 07:21

Message:
Logged In: YES 
user_id=488897

Could you write an example code that demonstrates the bug
you want to fix? It is more difficult to replicate the bug
without a clear example.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191700&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 10:45:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 01:45:27 -0700
Subject: [Patches] [ python-Patches-1192789 ] Use GCC4 ELF symbol visibility
Message-ID: <E1FUgPH-0001Wy-P4@sc8-sf-web4-b.sourceforge.net>

Patches item #1192789, was opened at 2005-04-30 01:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192789&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: Closed
>Resolution: Rejected
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use GCC4 ELF symbol visibility

Initial Comment:
GCC4 includes some new features that make it easier to
control what symbols are exported from a library for
linking.

The attached patch makes Python use these features,
limiting the exported symbols to the public Python C
API (i.e. the same symbols as are exported under Windows).

The patch sets the ELF visibility of the public Python
APIs to "protected", which means that the symbol is
exported but internal calls to those symbols are done
as direct function calls. 

In my local tests on i386 Linux, pystone and
parrotbench run about 5% faster on a "--enable-shared"
build of Python with the patch applied.

For a non shared library build of Python, performance
is pretty much identical (I'll probably need to do some
more tests).  However it still has the benefit of not
exporting private Python API.

The patch also touches the init routines of a number of
extension modules, since they weren't marked with
PyMODINIT_FUNC, which caused them to build incorrectly
with the patch (the init function ended up being
private, so Python couldn't load the module).

I've only tested this patch against 2.4.1, but it
probably applies without too much trouble to the 2.5
development line.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 10:45

Message:
Logged In: YES 
user_id=21627

Rejecting the patch. If you ever find a solution to the
issues discussed, please submit a new patch.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-08-15 22:38

Message:
Logged In: YES 
user_id=21627

So would you agree that the patch should be rejected, then?
I would classify it as "nice to have" - it doesn't fix an
actual bug, nor does it add an important new feature.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2005-08-15 13:07

Message:
Logged In: YES 
user_id=146903

The PyMODINIT_FUNC() problem could be fixed by filtering out
the -fvisibility=hidden flag from Makefile.pre.in (this
would require some more extensive build changes).

You are right about the patch relying on -fvisibility only
being implemented by compilers that implement the visibility
attribute.  I think this is currently true, but it would be
better not to rely on it.

In the time since I made the patch though, I have been told
about a problem with the "protected" visibility modifier: on
Linux systems at least, it slows down the symbol lookup process.

Since code inside the same library as the protected symbol
will be using a direct reference and code outside will be
going through the PLT, the dynamic linker needs special code
to return different addresses for the symbol depending on
what code is calling it (this is slower than the code path
for "default" visibility symbols).  This is required in
order to satisfy the C standard's requirements that
comparisons of pointers to functions be simple and fast.

The way around this is to use two functions: one is a
"hidden" visibility function that is used by the code inside
libpython, and the other is an alias of the hidden function
with normal visibility and the function's advertised name. 
Unfortunately, this is more invasive to implement (but not
overly so -- libxml2 and GTK contain such code).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-08-07 23:49

Message:
Logged In: YES 
user_id=21627

Doesn't this cause backwards compatibility problems with
extension modules which fail to declare their entry point
with PyMODINIT_FUNC? Such modules would stop working when
recompiled with the patch, right?

Also, shouldn't the -fvisibility argument only be used if
the __attribute__ syntax is supported?

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2005-05-10 04:47

Message:
Logged In: YES 
user_id=146903

I just tried out the patch on an AMD64 Linux machine.  There
is some improvement in the --enable-shared case, but it
doesn't seem to be as big as on i386.

I only tested pystone though, since parrotbench gives an
assertion error on this box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192789&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 10:48:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 01:48:27 -0700
Subject: [Patches] [ python-Patches-1197150 ] _ssl.mak Makefile patch (Win32)
Message-ID: <E1FUgSB-0001ki-Dv@sc8-sf-web4-b.sourceforge.net>

Patches item #1197150, was opened at 2005-05-07 11:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197150&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: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Joachim Kessel (counter)
Assigned to: Nobody/Anonymous (nobody)
Summary: _ssl.mak Makefile patch (Win32)

Initial Comment:
Hi,

please find attached a small patch for the '_ssl.mak'
Makefile in the 'PCbuild' Directory of Python 2.4.1
('user32.lib' was missing).

Here are the versions that I used
========================
Openssl: openssl-0.9.7-stable-SNAP-20050505
Python: 2.4.1

Error description
============
I was trying to compile Python 2.4.1 with SSL support
using one of the latest snapshots from
openssl, 'openssl-0.9.7-stable-SNAP-20050505'.

While compiling in Visual Studio 2003 I got the
following error:

--- snip ---

cl /nologo ../Modules/_ssl.c
c:\temp\python_build\openssl-0.9.7-stable-SNAP-20050505/out32.dbg/libeay32.lib
c:\temp\python_build\openssl-0.9.7-stable-SNAP-20050505/out32.dbg/ssleay32.lib
/Od /Zi /MDd /LDd /DDEBUG /D_DEBUG
/Fox86-temp-debug/_ssl\_ssl_d.obj -I ../Include -I
../PC -I
c:\temp\python_build\openssl-0.9.7-stable-SNAP-20050505/inc32
/link /out:_ssl_d.pyd gdi32.lib wsock32.lib
/libpath:c:\temp\python_build\openssl-0.9.7-stable-SNAP-20050505/out32.dbg
libeay32.lib ssleay32.lib
_ssl.c
 Creating library _ssl_d.lib and object _ssl_d.exp
libeay32.lib(cryptlib.obj) : error LNK2019: unresolved
external symbol __imp__MessageBoxIndirectA at 4 referenced
in function _OPENSSL_showfatal
_ssl_d.pyd : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
[7083 refs]
Project : error PRJ0019: A tool returned an error code
from "Performing Makefile project actions"

--- snap ---

The 'unresolved external symbol' relates to the missing
'user32.lib' in the '_ssl.mak' makefile.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 10:48

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. This has been fixed in the trunk (2.5)
already, so closing it as out-of-date. For 2.4, this is not
an issue, since it will always stay at 0.9.7d.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197150&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 10:52:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 01:52:08 -0700
Subject: [Patches] [ python-Patches-1205436 ] Bugfix for signal-handler on
	x64 Platform
Message-ID: <E1FUgVk-00022a-U9@sc8-sf-web4-b.sourceforge.net>

Patches item #1205436, was opened at 2005-05-20 07:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1205436&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: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Andr? Fritzsche (computercrustie)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugfix for signal-handler on x64 Platform

Initial Comment:
On x64 Platform (i used Visual Studio 2005 and 
Windows XP x64) the python.exe hang up on registering 
signal handler for none used signals. I fixed this on my 
machine with a switch-case construct for filtering the 
unsupported signals.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 10:52

Message:
Logged In: YES 
user_id=21627

nnorwitz is right: this was fixed (worked-around) with
1350409:; so closing this out-of-date.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-18 23:30

Message:
Logged In: YES 
user_id=33168

I believe this was fixed recently.  Can you verify it works
for you now?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-05-20 13:09

Message:
Logged In: YES 
user_id=6656

Point the first: please attach patches, not files.

Point the second: we think this is a microsoft bug.  Quoting
C99 (about the signal function):

    If the request can be honored, the signal function
returns the
    value of func for the most recent successful call to
signal for
    the specified signal  sig. Otherwise, a value of SIG_ERR is 
    returned and a positive value is stored in errno.

That doesn't seem to allow calling abort().

 As I think VS 2005 is still in beta, there's still hope
that this will get fixed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1205436&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:02:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:02:41 -0700
Subject: [Patches] [ python-Patches-1212921 ] option to allow reload to
	affect existing instances
Message-ID: <E1FUgfx-0002mk-Mp@sc8-sf-web4-b.sourceforge.net>

Patches item #1212921, was opened at 2005-06-01 20:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&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: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Brett Rosen (bdrosen)
Assigned to: Nobody/Anonymous (nobody)
Summary: option to allow reload to affect existing instances

Initial Comment:
One of the commonly asked questions (especially when
developing
GUI apps) is how do I reload a modified python file and
have
the existing instances automatically get the changed
behavior.
(this greatly speeds up the development cycle.)
 
Unfortunately python doesn't support this without having
to do the work yourself. To rectify this, I've implemented
smart reloading as detailed below:

Smart reloading is defined as applying modified code to
your
already instantiated objects on reload.

Supporting smart reloading for python:

Make sure that you execute python with the -r flag if
you want smart reloading to work by default. The semantics
of reload work as normal

The normal model has been expanded by adding two special
attributes to classes:

1 __pqname__ : This is used to give a hint as to our
context if we are a nested
class (top level classes don't need to use it) It
specifies the parent
hierarchy, excluding the module name. ie:

    class outer(object):
        class middle(object):
            __pqname__ = "outer"
            class inner(object):
                __pqname__ = "outer.middle"

excluding this for inner classes can lead to confusion
if you have multiple inner classes
with the same name.

2 __reloadMode__ : This can have one of the 3 values -
"overlay", "clear" and "disable"

 a) clear is the default if you are in reload mode (-r)
and you don't specify anything.
    The behavior here is to clear the class dictionary
before doing the reload of the class.
 b) overlay works like clear except that it doesn't
clear the class dictionary first.
 c) disable gives you the classic python behavior and
is the default if you are not in
    reload mode (no -r specified)
 

When using this you almost never want to reuse class
names in a module file. 
For example:

class foo(object):
...


class foo(object):
...

would be bad. The second class foo replaces the first
one, although
with overlay it could be used as syntactic sugar for
adding new methods
to an existing class.






----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 11:02

Message:
Logged In: YES 
user_id=21627

I think a change of this nature requires a PEP. The current
patch comes with no documentation, even though it introduces
severa new APIs. From reading the patch, it is not clear to
me what the consequences of this patch are (e.g. what
happens if the layout of the type changes?); these
consequences should be discussed in the PEP.

So I'm rejecting the patch now; not rejecting the feature
per se, but just the path taken to get it into Python.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-09-03 11:57

Message:
Logged In: YES 
user_id=6656

Oh, come on, my recipe could very clearly be changed to mutate the 
overridden class instead of assigning to its instances' __class__ attribute.

*My* point is that there's very little the patch does that can't be done in 
Python.  type_new is already far too complicated, this adds more 
complication.

The main advantage your patch has over my recipe is that it edits the 
default metaclass which obviates the need to edit any class statements 
and avoids metaclass conflict issues.  Is that enough to override my 
objections above?  Maybe, maybe not.  I'll think about it.

(PS: a touch less bombast would be nice)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-09-03 11:57

Message:
Logged In: YES 
user_id=6656

Oh, come on, my recipe could very clearly be changed to mutate the 
overridden class instead of assigning to its instances' __class__ attribute.

*My* point is that there's very little the patch does that can't be done in 
Python.  type_new is already far too complicated, this adds more 
complication.

The main advantage your patch has over my recipe is that it edits the 
default metaclass which obviates the need to edit any class statements 
and avoids metaclass conflict issues.  Is that enough to override my 
objections above?  Maybe, maybe not.  I'll think about it.

(PS: a touch less bombast would be nice)

----------------------------------------------------------------------

Comment By: Ted Czotter (tczotter)
Date: 2005-09-02 23:35

Message:
Logged In: YES 
user_id=1339137

Ahh - finally someone is interested in this one.

Michael's recipe does address *some* of the same problems 
solved by this patch, but not all.

Before I get into more detail, let's be clear about something. 
The reload wart is a
problem of inconvenience, not the inability to do something. 
For ordinary development, when
I make a change in one module, I save time and avoid 
mistakes if I don't have to:
		* reload other modules
		* restart all or part of my application 
and thereby have to recover my state
Neither of these stop me from developing, they just slow me 
down.

So a good solution is going to be measured on three things:
	1) How well it improves my efficiency as a 
developer.
	2) The level of effort required to use the solution.


Ok.

So the core of the wart is that when you re-compile a class, 
a *new* class is created,
instead of altering the definitions bound to the existing class. 
The symptoms are:
* Existing instances (like open dialogs or sockets) continue 
to use the old class
and don't inherit new behavior.
* Existing subclasses refer to the old base class and any 
instances created in the future
are still inheriting old behavior.

Michael's recipe addresses these symptoms.

Are there other important symptoms? Unfortunately, yes.
* OTHER REFERENCES TO THE OLD CLASS EXIST
Where? All over the place. Consider this:
	
from mycompany.corporateframework.gui.widgets import 
Button, CheckBox
# This *module* now points to the old Button and CheckBox.
# Many calls to Button() and CheckBox() follow in methods 
after this.

The recipe can't find and fix these references. If I was using 
the recipe, I'd have to
reload all these modules. But then I compound the problem. 
Reloading these other modules
creates *still more new classes*, causing dozens of *other* 
modules to need reloading. In the
end, I'm better off just restarting the whole darn application.

I understand that I could take advantage of the fact that 
modules retain their identity and
so if I use fully qualified names everywhere, I won't have this 
problem because I'd always
be looking up the latest class. But realistically, who is going 
to type
	b = 
mycompany.corporateframework.gui.widgets.Button("OK")
all the time instead of just:
	b = Button("OK")
Making people use python "a certain way" that is not 
idiomatic (i.e. automatic, normal,
how we do things every day) is a problem and lowers the 
usefulness of the solution. And I'm
certainly not about to suggest that anybody go through our 
30,000 lines of python code to
make such idiomatic changes so the recipe can work.

Anyway, even if I did accept that tactic (and I don't) I'm still 
not out of the woods.

Consider warehouses and factories. Here you are storing 
pointers to classes in containers
for later invocations. For example, In wx, the grid class 
requires that you register classes
to be used later for in-place editing in a grid. All these 
registrations are pointing to 
old class definitions. To fix the problem, we have to re-
register. Which usually means
reloading some modules. Which means reloading some more 
modules - you get it by now.

So as a result, my first measures of success are not met 
very well by the recipe. 
Yes, I can type foo.DoLatestThing() at the console, but in 
real life I'm still 
going to have to restart my application a lot.

On the other hand, the patch addresses the *cause* of the 
problem instead of some 
of the symptoms.

****** The true cause is that re-compiled classes change 
their identity. ******

With this patch, they do not. They retain their identity just 
like modules do.

All the symptoms go away.

Now let's talk about the harm the recipe does. What harm 
you ask?

Well to make it work you have to make all your most-base 
classes use Michael's metaclass.
Unfortunately, we already use metaclasses for a lot of things. 
And we use multiple inheritance
a lot (we like mixins). How fast can you say "metaclass 
conflict"?

I like what metaclasses do and I'm happy that Python let's 
me extend "internal" behavior
so neatly. But the metaclass conflict is another serious wart. 
If we can avoid it, good.

And I'm not happy that I seriously have to edit a few hundred 
class definitions in existing
code to get the benefit of the recipe. 
**** The patch approach requires ZERO changes to existing 
applications. Z E R O ****

Brett and I work at the same company. He made this patch 
because we were wasting hundreds
of hours debugging reload problems or just quitting the 
application and restarting. I've
been using this patch now for 3 months. It has saved our 
company hundreds of man-hours
and we didn't have to change one line of existing code to 
make it work.

If the community doesn't want to use it, I'm fine with that. I 
just want to make
sure that you fully understand what you are giving up.

Ted Czotter
CTO
Lavastorm Technologies


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-09-01 11:38

Message:
Logged In: YES 
user_id=6656

My first thought is to plug my recipe:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164

In fact, this seems pretty similar to what the patch does, on a quick skim.

Given that the bulk of the functionality can be implemented in Python, I'm 
not sure *I* support the further complication of type_new for this.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-01 00:29

Message:
Logged In: YES 
user_id=1188172

Does anyone care to give a quick, obliterative judgement
about this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:04:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:04:08 -0700
Subject: [Patches] [ python-Patches-780821 ] More robust MSVC6 finder
Message-ID: <E1FUghM-0002vX-V9@sc8-sf-web4-b.sourceforge.net>

Patches item #780821, was opened at 2003-07-31 14:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780821&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.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Jeremy Hylton (jhylton)
Summary: More robust MSVC6 finder

Initial Comment:
My VS6 install on XP didn't set the 
r&quot;Software\Microsoft\Devstudio\6.0\Build System&quot; 
registry key relied upon by distutils.msvccompiler to find 
the compiler and linker executable. 

As a backup to the registry paths, this patch looks up 
the MSVCDIR environment variable and ensures its 
basename is appropriate for the Python build version: 

            if self.__version == 6: 
                matchbase = 'vc98'
            elif self.__version == 7: 
                matchbase = 'vc7'

Works fine on my machine, so long as I run 
VCVARS32.BAT, and fails appropriately if I ran the wrong 
VCVARS32.BAT by mistake (I have Visual Studio Net 
2003 also installed). 

The patch should be applied to distutils/msvccompiler.py.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 11:04

Message:
Logged In: YES 
user_id=21627

As Python 2.3 is no longer maintained, and Python 2.4 (and
later) uses VS 2003, I'm rejecting the patch as out-of-date.

----------------------------------------------------------------------

Comment By: Paul Magwene (pmagwene)
Date: 2003-11-13 21:12

Message:
Logged In: YES 
user_id=23286

The reliance on registry keys (and ignoring other environment variables) can also cause other headaches.  Here's a problem I ran into on a stock Python 2.3 when trying to compile extensions using VC6:

I'm using STLport instead of the buggy STL implementation that ships with VC6.  To have the STL headers included I put the STL directory at the beginning of the INCLUDE search path in VCVARS32.BAT *and* by setting the appropriate values in the environment variables.  

With these settings, when I built my Python C++ extension by hand everything worked hunky-dory.  However when I tried to use distutils it kept including the old header files.  It took me a good 20 minutes of head scratching to realize that distutils was ignoring my environment variables and preferentially grabbing whatever INCLUDE directory was specified in the registry key (even if I ran VCVARS32.bat before compiling). Once I set the registry variable by hand, everything worked ok.

Perhaps distutils can be configured to look for environment settings *before* searching out whatever is buried in the registry?

--Paul M.

----------------------------------------------------------------------

Comment By: Murray Steele (murraysteele)
Date: 2003-10-21 13:10

Message:
Logged In: YES 
user_id=891425

Having come across this problem myself, it seems that MSVC 6
doesn't create the r&quot;Software\Microsoft\Devstudio\6.0\Build
System&quot; registry keys until *after* you run the actual
Visual Studio IDE.  So just doing a plain install and never
running the IDE isn't enough.

This isn't much of a fix, just some kind of documentation
incase it bites some other fumbling developer in the future.

Someone somewhere else
(http://sourceforge.net/tracker/?func=detail&amp;atid=105470&amp;aid=451285&amp;group_id=5470)
 suggested using the Environment Variables as well as the
registry keys in distutils to check for compiler
correctness.  Seems like a plan to me. 

And there is some more chat about this problem here
http://sourceforge.net/tracker/?func=detail&amp;atid=305470&amp;aid=614770&amp;group_id=5470

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 09:16

Message:
Logged In: YES 
user_id=21627

I'm curious, though, how you installed VS6 without getting
the registry settings. Doesn't this mean your installation
of VS6 is broken?

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2003-08-01 06:06

Message:
Logged In: YES 
user_id=59803

WARNING: the first patch contains a typo. s/nstring/string/ 
and you'll be fine. New version attached. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-08-01 00:09

Message:
Logged In: YES 
user_id=31392

I've desired the same functionality in the past.


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2003-07-31 14:52

Message:
Logged In: YES 
user_id=59803

Whups. The patch didn't attach. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780821&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:05:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:05:19 -0700
Subject: [Patches] [ python-Patches-1470515 ] fix test_descrtut in p3yk
Message-ID: <E1FUgiV-0006VW-P9@sc8-sf-web1.sourceforge.net>

Patches item #1470515, was opened at 2006-04-14 21:40
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470515&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_descrtut in p3yk

Initial Comment:
Fixes test_descrtut in p3yk: mostly the difference
between 'print cls' for new-style and classic classes.
Also changed the MRO test for classic/newstyle classes
into an MRO test for implicit/explicit newstyle
classes, instead.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:05

Message:
Logged In: YES 
user_id=34209

Checked in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470515&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:05:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:05:41 -0700
Subject: [Patches] [ python-Patches-1470536 ] Fix test_descr in p3yk
Message-ID: <E1FUgir-00030P-0Z@sc8-sf-web4-b.sourceforge.net>

Patches item #1470536, was opened at 2006-04-14 21:59
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470536&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Fix test_descr in p3yk

Initial Comment:
Fixes test_descr in p3yk, by removing tests that test
for classic-class behaviour (including mixing classic
classes with new-style classes.) I may have removed too
many tests, but I don't think so.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:05

Message:
Logged In: YES 
user_id=34209

checked in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470536&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:08:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:08:01 -0700
Subject: [Patches] [ python-Patches-1470566 ] fix test_itertools in p3yk
Message-ID: <E1FUgl7-0002lh-3o@sc8-sf-web5.sourceforge.net>

Patches item #1470566, was opened at 2006-04-14 22:55
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470566&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_itertools in p3yk

Initial Comment:
Fixes test_itertools in p3yk: more cases where
iter(obj) raises TypeError earlier than expected.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:08

Message:
Logged In: YES 
user_id=34209

Checked in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470566&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:11:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:11:01 -0700
Subject: [Patches] [ python-Patches-1470424 ] Fix test_augassign in p3yk
Message-ID: <E1FUgo1-0006t9-PG@sc8-sf-web1.sourceforge.net>

Patches item #1470424, was opened at 2006-04-14 17:50
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470424&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Fix test_augassign in p3yk

Initial Comment:
Fix test_augassign in the p3yk branch, by adjusting
tests to deal with true division. In passing, add
minimal tests for <<= and >>=.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:11

Message:
Logged In: YES 
user_id=34209

Checked in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470424&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:12:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:12:30 -0700
Subject: [Patches] [ python-Patches-1470460 ] fix test_bisect in p3yk
Message-ID: <E1FUgpS-0000kZ-S9@sc8-sf-web6.sourceforge.net>

Patches item #1470460, was opened at 2006-04-14 19:18
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470460&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_bisect in p3yk

Initial Comment:
Trivial fix for test_bisect: since LenOnly and GetOnly
are newstyle classes now (as is everything), trying to
do the operation they don't have now raises TypeError
instead of AttributeError.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:12

Message:
Logged In: YES 
user_id=34209

Checked in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470460&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:13:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:13:37 -0700
Subject: [Patches] [ python-Patches-1470560 ] fix test_inspect in p3yk
Message-ID: <E1FUgqX-0003aY-6g@sc8-sf-web4-b.sourceforge.net>

Patches item #1470560, was opened at 2006-04-14 22:46
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470560&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_inspect in p3yk

Initial Comment:
Fixes test_inspect in p3yk, by removing tests for
classic-class behaviour, and converting one test
(fetching the class tree of a set of classes) to
new-style class output.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:13

Message:
Logged In: YES 
user_id=34209

Checked in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470560&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:15:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:15:23 -0700
Subject: [Patches] [ python-Patches-1470543 ] fix test_getargs2 in p3yk
Message-ID: <E1FUgsF-0000y2-FA@sc8-sf-web6.sourceforge.net>

Patches item #1470543, was opened at 2006-04-14 22:12
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470543&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_getargs2 in p3yk

Initial Comment:
Fixes test_getargs2 in p3yk, where PyArg_* no longer
silently converts floats to ints, for integer format
characters.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:15

Message:
Logged In: YES 
user_id=34209

Checked in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470543&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:16:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:16:38 -0700
Subject: [Patches] [ python-Patches-1470522 ] fix test_enumerate in p3yk
Message-ID: <E1FUgtR-0007Kq-RG@sc8-sf-web1.sourceforge.net>

Patches item #1470522, was opened at 2006-04-14 21:47
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470522&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_enumerate in p3yk

Initial Comment:
Fixes test_enumerate in p3yk; the failure is caused by
iter() doing the test for the 'next' method a lot
earlier, when dealing with newstyle classes, so the
TypeError the test was trying to trigger blew up in its
face.

----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:16

Message:
Logged In: YES 
user_id=34209

Checked in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470522&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 11:19:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 02:19:53 -0700
Subject: [Patches] [ python-Patches-1470504 ] partially fix test_class in
	p3yk
Message-ID: <E1FUgwb-0001GW-EJ@sc8-sf-web6.sourceforge.net>

Patches item #1470504, was opened at 2006-04-14 21:27
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470504&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: partially fix test_class in p3yk

Initial Comment:
Partially fix test_class in p3yk. This allows the test
to be actually run, although it could also be solved by
allowing 'exec' to receive any dict-like object
(there's a patch for that elsewhere, slated for 2.5, I
believe, but dictproxy objects would have to grow
setitem support for it to work.) Me, I prefer setattr()
like this over mucking with __dict__, although I have
to admit it did find a potential bug :) (The issue is
that class.__dict__ is a dictproxy object, if class is
a newstyle class.)

There are, however, more problems with test_class that
this doesn't resolve:

 - Classic classes that have a __cmp__ or __eq__
method, but no __hash__ method, are unhashable. The
same is not true for new-style classes. I'm not sure
whether that's a bug in new-style classes, or
desireable behaviour.

 - The recursive-__call__ test (where Ainst.__call__ ==
Ainst, so the hunt for the actual code to run is
recursive) crashes Python on my machine. The test
doesn't crash for classic classes. It seems to be a
stack overflow, or some other memory corruption scheme,
but I'll have to find me a machine with less address
space and memory to more comfortly debug this (talk
about a luxury problem!)

 - __coerce__ isn't being called. I don't recall
whether that's a newstyle-class issue, or a py3k
decision, or a bug. If it isn't a bug, output just has
to be regenerated.

 - Output has to be regenerated to pick up __truediv__
and __rtruediv__ instead of __div__ and __rdiv__.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 11:19

Message:
Logged In: YES 
user_id=34209

Checked in this fix, still leaves the other issues open.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470504&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 16:22:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 07:22:29 -0700
Subject: [Patches] [ python-Patches-1470846 ] urllib2 ProxyBasicAuthHandler
	broken
Message-ID: <E1FUlfR-00010f-2G@sc8-sf-web4-b.sourceforge.net>

Patches item #1470846, was opened at 2006-04-15 15:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470846&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 ProxyBasicAuthHandler broken

Initial Comment:
urllib2.ProxyBasicAuthHandler has been broken since
revision 38092 back in December 2004 (unlike the
alternative, using a userinfo URL component in the
string passed to ProxyHandler, e.g.
"joe:password at example.com", which works fine ATM).

There are two problems: First, with a proxy, you're
always authenticating yourself for the whole proxy, not
just for a specific path.  Second, you're
authenticating yourself to the proxy, not to the HTTP
server.  The ProxyBasicAuthHandler subclass dutifully
passes in the right thing for the host argument, but
AbstractBasicAuthHandler ignores it, which means that
it never finds the password -- e.g. if you're trying to
connect to http://python.org/dev through myproxy.com,
it'll be looking for a username/password for
http://python.org/dev instead of the needed myproxy.com.

Since fixing this entails the host argument to
http_error_auth_reqed no longer being ignored,
HTTPBasicAuthHandler must now pass the full URL, which
means AbstractBasicAuthHandler must accept either an
authority or a URL.  ProxyBasicAuthHandler could also
supply a full URL like "http://proxy.example.com/", but
the 'host' argument prior to December 2004 was not
ignored, and accepted a hostname (!), so we should keep
that working rather than insisting on a full URL.  I
also documented this behaviour.

The patch fixes the bug, adds several new tests, and
updates and fixes mis-named method documentation for
http_error_auth_reqed, and a typo in the examples.

Note one of the tests in the attached patch relies on a
currently non-existent URL at python.org requiring
basic authorization (not *proxy* basic auth in this
test, just basic auth).  So I guess the code in the
test_urllib2net.py patch hunk has to be commented out
or something until somebody adds the necessary few
lines of Apache config.

Would also be nice to add a functional test for Proxy
auth itself.  I'm sure python.org doesn't want to be
the world's proxy, but something could be configured
that does the basic auth dance then responds with 403.
 What would be most suitable: something like
SimpleHTTPServer sitting behind Apache, some mod_python
magic...??


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470846&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 16:49:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 07:49:02 -0700
Subject: [Patches] [ python-Patches-1143695 ] Fix to allow urllib2 digest
	auth to talk to livejournal.com
Message-ID: <E1FUm58-0006gs-Qa@sc8-sf-web1.sourceforge.net>

Patches item #1143695, was opened at 2005-02-18 11:14
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Benno Rice (benno)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix to allow urllib2 digest auth to talk to livejournal.com

Initial Comment:
When trying to use feedparser.py to deal with RSS feeds
from livejournal.com using digest auth (needed to
access locked posts), urllib2 would report a digest
auth failure.  The solution appears to be to always
specify the algorithm, even when it's MD5.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 15:49

Message:
Logged In: YES 
user_id=261020

This was fixed in revision 38092.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2005-02-20 02:01

Message:
Logged In: YES 
user_id=261020

Patch appears correct, and RFC 2617 allows always sending
the algorithm.  Haven't tested the patch, or verified that
real browsers do indeed always send algorithm even when it'd
MD5.


----------------------------------------------------------------------

Comment By: Benno Rice (benno)
Date: 2005-02-19 09:02

Message:
Logged In: YES 
user_id=9925

SourceForge is teh suxx0r.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-02-19 08:57

Message:
Logged In: YES 
user_id=29957

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1143695&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 17:12:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 08:12:24 -0700
Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs
Message-ID: <E1FUmRk-0008SJ-Hh@sc8-sf-web1.sourceforge.net>

Patches item #1436130, was opened at 2006-02-21 20:32
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&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
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Walter D?rwald (doerwalter)
Summary: Incremental codecs

Initial Comment:
This patch extends the codec machinery to add
incremental codecs: stateful codecs that don't use a
stream API. It adds the following stuff: a class
codecs.CodecInfo (a subclass of tuple), that is used as
the return value of codecs.lookup();
codecs.IncrementalEncoder and codecs.IncrementalDecoder
(the basic interface classes),
codecs.BufferedIncrementalDecoder (a class that can be
used to implement decoders that must handle incomplete
input); codecs.iterencode() and codecs.iterdecode()
(generators that use the incremental codecs for
encoding/decoding an input iterable). On the C level
PyCodec_IncrementalEncoder() and
PyCodec_IncrementalDecoder() are added.

----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-04-15 17:12

Message:
Logged In: YES 
user_id=89016

Closing the patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-18 16:53

Message:
Logged In: YES 
user_id=89016

OK, I've submitted a new patch (#1453235) for the idna
simplification.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-18 16:26

Message:
Logged In: YES 
user_id=89016

MAL, do you have any suggestions on improving the code in
encodings.search_function()?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 13:14

Message:
Logged In: YES 
user_id=38388

It's only the coding style that looks a bit funny. 

Requiring CodecInfo objects is not a good idea: that way
you'd make it impossible to write codecs that work in both
Python 2.5 and 2.4.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-15 12:43

Message:
Logged In: YES 
user_id=89016

Checked in as r43045.

Now what do we do with the funny code in
encoding.search_function()? Of course we could always
*require* the search function to return a CodecInfo object.
(but only after the CJK codecs are updated, and even then we
should have some form of backwards compatibility).

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-15 12:28

Message:
Logged In: YES 
user_id=55188

1449471 isn't related to incremental codecs.  It includes a
simple patch to visual studio project file.

I think Walter is right person to review 1443155 whether it
conforms his interface design. :-) (Thank you in advance!)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 12:13

Message:
Logged In: YES 
user_id=38388

The patch looks OK, accept for some minor glitches such as
this mess :-) ...

+    if not isinstance(entry, codecs.CodecInfo):
+        if not 4 <= len(entry) <= 7:
+             raise CodecRegistryError,\
+                  'module "%s" (%s) failed to register' % \
+                   (mod.__name__, mod.__file__)
+        if not callable(entry[0]) or \
+           not callable(entry[1]) or \
+           (entry[2] is not None and not
callable(entry[2])) or \
+           (entry[3] is not None and not
callable(entry[3])) or \
+           (len(entry) > 4 and entry[4] is not None and not
callable(entry[4])) or \
+           (len(entry) > 5 and entry[5] is not None and not
callable(entry[5])):
             raise CodecRegistryError,\
-                  'incompatible codecs in module "%s" (%s)' % \
-                  (mod.__name__, mod.__file__)
+                'incompatible codecs in module "%s" (%s)' % \
+                (mod.__name__, mod.__file__)
+        if len(entry)<7 or entry[6] is None:
+            entry += (None,)*(6-len(entry)) +
(mod.__name__.split(".", 1)[1],)
+        entry = codecs.CodecInfo(*entry)

Nevertheless, it can be cleaned up after checkin, so please
go ahead with it.

Regarding the idna.py patch, I think you should create a new
patch item for it and assign it to Martin.

Thanks.

Neal, I don't have time to review the two CJK patches.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-15 09:01

Message:
Logged In: YES 
user_id=33168

MAL, do you have any more issues with this patch?  Should it
be assigned to Martin?

MAL, Walter, can you review these patches 1443155 1449471
which I think are related?  Should they go in?

The first alpha is coming up soon and I'd like to get these
patches in ASAP.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-03 18:39

Message:
Logged In: YES 
user_id=89016

This fourth version of the patch removes the changes to 
Lib/encodings/idna.py (only the addition of the 
IncrementalEncoder/IncrementalDecoder and the changed 
getregentry() remain). This patch to idna.py probably only 
makes sense once this patch is in.

> Is it possible to make IncrementalEncoder/Decoder
> instances iterable per-se (without the need to go
> through the helper functions iterencode/iterdecode) ?

For IncrementalEncoder/Decoder to be iterable it would have 
to have some iterable from which it gets the input. But 
this has the same limitation as the stream API: The user is 
forced to provide the input as a service that the 
encoder/decoder uses, which requires support for a certain 
API. The only change would be that now it's an iterator API 
instead of a stream API.

The incremental codecs invert the call logic: The user no 
longer has to provide a callback service to the codec, but 
calls the codec directly. This gives much more flexibility.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-03 00:03

Message:
Logged In: YES 
user_id=38388

Very nice ! 

This is a much better approach than the feed style path you
wanted to take previously.

Minor nits:

Please separate out the non-related changes to the IDNA
codec into a new patch and assign that to Martin for review.

Is it possible to make IncrementalEncoder/Decoder instances
iterable per-se (without the need to go through the helper
functions iterencode/iterdecode) ?

Thanks.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-01 15:47

Message:
Logged In: YES 
user_id=89016

This third version of the patch fixes the bug when the
iterator in iterencode() or iterdecode() is empty and
updates the docstring in encodings/__init__.py.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-28 13:08

Message:
Logged In: YES 
user_id=89016

This second version of the patch enhances
codecs.iterencode() and codecs.iterdecode(), so that
additional keyword arguments are passed through to the
Incremental(De|En)coder constructor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 18:00:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 09:00:50 -0700
Subject: [Patches] [ python-Patches-1448484 ] declspec for ssize_t
Message-ID: <E1FUnCc-0003cI-D2@sc8-sf-web1.sourceforge.net>

Patches item #1448484, was opened at 2006-03-12 22:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448484&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 2.5
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: declspec for ssize_t

Initial Comment:
If you apply this patch (against today's SVN trunk)
then the new ssize_t funcs will be exported when
building a DLL with cygwin gcc 3.4.4.  Then you'll hit
another problem, about which more in the next patch.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 18:00

Message:
Logged In: YES 
user_id=21627

I believe the problem has been fixed in the trunk; if not,
please submit a bug report.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 11:24

Message:
Logged In: YES 
user_id=21627

Can you please explain what the problem is? PyArg_Parse is
declared dllexport already in Include/modsupport.h, so
declaring it dllexport in getargs.c should not be necessary.

Also, please don't declare _PyArg_Parse_SizeT dllexport in
the implementation file; instead, add a prototype in the
header file and declare that as dllexport. IOW, there
shouldn't be any changes to getargs.c.


----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-03-13 15:21

Message:
Logged In: YES 
user_id=52562

I think the initial summary wasn't clear.  With this patch,
the new ssize_t feature that was recently merged into trunk
compiles on Cygwin.  Without this patch, it doesn't.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448484&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 18:06:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 09:06:13 -0700
Subject: [Patches] [ python-Patches-1470875 ] Building Python with MS Free
	Compiler
Message-ID: <E1FUnHp-000433-9h@sc8-sf-web1.sourceforge.net>

Patches item #1470875, was opened at 2006-04-15 17: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=1470875&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
Submitted By: Paul Moore (pmoore)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building Python with MS Free Compiler

Initial Comment:
The attached zipfile contains a patch to
PCBuild\readme.txt plus two ".build" files.

The readme patch explains how to build Python on
Windows with the free MS Toolkit compiler. The .build
files are required for this process - details in the
documentation - and should be placed in the PCBuild
directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470875&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 18:07:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 09:07:08 -0700
Subject: [Patches] [ python-Patches-1470875 ] Building Python with MS Free
	Compiler
Message-ID: <E1FUnIi-00046x-8k@sc8-sf-web1.sourceforge.net>

Patches item #1470875, was opened at 2006-04-15 17:06
Message generated for change (Settings changed) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470875&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
Submitted By: Paul Moore (pmoore)
>Assigned to: Martin v. L??wis (loewis)
Summary: Building Python with MS Free Compiler

Initial Comment:
The attached zipfile contains a patch to
PCBuild\readme.txt plus two ".build" files.

The readme patch explains how to build Python on
Windows with the free MS Toolkit compiler. The .build
files are required for this process - details in the
documentation - and should be placed in the PCBuild
directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470875&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 18:24:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 09:24:44 -0700
Subject: [Patches] [ python-Patches-1442867 ] Add support for the
	If-Modified-Since header
Message-ID: <E1FUnZk-0001VN-Mo@sc8-sf-web5.sourceforge.net>

Patches item #1442867, was opened at 2006-03-04 03:40
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442867&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: Open
Resolution: None
Priority: 5
Submitted By: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for the If-Modified-Since header

Initial Comment:
Added support for the If-Modified-Since header to
SimpleHTTPServer.  That way things like images don't
get downloaded again on every new page request.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 18:24

Message:
Logged In: YES 
user_id=21627

What is the reason for raising ValueError, instead of
returning True right away?

Please re-read section 14.25 of the RFC: a if-modified-since
date "from the future" must be considered invalid.

Also, there seems to be some interaction with the Range:
header. How is that dealt with?

Also, where is the length attribute to if-modified-since
specified?

Also, should there be changed to Doc/lib/libsimplehttp.tex?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442867&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 19:59:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 10:59:04 -0700
Subject: [Patches] [ python-Patches-1470846 ] urllib2 ProxyBasicAuthHandler
	broken
Message-ID: <E1FUp32-00045o-OH@sc8-sf-web1.sourceforge.net>

Patches item #1470846, was opened at 2006-04-15 15:22
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470846&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 ProxyBasicAuthHandler broken

Initial Comment:
urllib2.ProxyBasicAuthHandler has been broken since
revision 38092 back in December 2004 (unlike the
alternative, using a userinfo URL component in the
string passed to ProxyHandler, e.g.
"joe:password at example.com", which works fine ATM).

There are two problems: First, with a proxy, you're
always authenticating yourself for the whole proxy, not
just for a specific path.  Second, you're
authenticating yourself to the proxy, not to the HTTP
server.  The ProxyBasicAuthHandler subclass dutifully
passes in the right thing for the host argument, but
AbstractBasicAuthHandler ignores it, which means that
it never finds the password -- e.g. if you're trying to
connect to http://python.org/dev through myproxy.com,
it'll be looking for a username/password for
http://python.org/dev instead of the needed myproxy.com.

Since fixing this entails the host argument to
http_error_auth_reqed no longer being ignored,
HTTPBasicAuthHandler must now pass the full URL, which
means AbstractBasicAuthHandler must accept either an
authority or a URL.  ProxyBasicAuthHandler could also
supply a full URL like "http://proxy.example.com/", but
the 'host' argument prior to December 2004 was not
ignored, and accepted a hostname (!), so we should keep
that working rather than insisting on a full URL.  I
also documented this behaviour.

The patch fixes the bug, adds several new tests, and
updates and fixes mis-named method documentation for
http_error_auth_reqed, and a typo in the examples.

Note one of the tests in the attached patch relies on a
currently non-existent URL at python.org requiring
basic authorization (not *proxy* basic auth in this
test, just basic auth).  So I guess the code in the
test_urllib2net.py patch hunk has to be commented out
or something until somebody adds the necessary few
lines of Apache config.

Would also be nice to add a functional test for Proxy
auth itself.  I'm sure python.org doesn't want to be
the world's proxy, but something could be configured
that does the basic auth dance then responds with 403.
 What would be most suitable: something like
SimpleHTTPServer sitting behind Apache, some mod_python
magic...??


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-15 18:59

Message:
Logged In: YES 
user_id=261020

I should have mentioned in my initial comment that this
patch also fixes bug 900898 (an HTTPPasswordMgr bug that
arises when an authority with a port is passed to
.find_user_password()).  The patch includes tests for this
issue, but I've just added a couple more: patch
"proxy_path_2.patch" includes those new tests and supercedes
"proxy_path.patch".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470846&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 20:07:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 11:07:52 -0700
Subject: [Patches] [ python-Patches-1470875 ] Building Python with MS Free
	Compiler
Message-ID: <E1FUpBY-0004sR-JM@sc8-sf-web3.sourceforge.net>

Patches item #1470875, was opened at 2006-04-15 18:06
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470875&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L??wis (loewis)
Summary: Building Python with MS Free Compiler

Initial Comment:
The attached zipfile contains a patch to
PCBuild\readme.txt plus two ".build" files.

The readme patch explains how to build Python on
Windows with the free MS Toolkit compiler. The .build
files are required for this process - details in the
documentation - and should be placed in the PCBuild
directory.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 20:07

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed (with a typo fix) as r45438.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470875&group_id=5470

From noreply at sourceforge.net  Sat Apr 15 22:03:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 15 Apr 2006 13:03:50 -0700
Subject: [Patches] [ python-Patches-1470976 ] Fix for urllib/urllib2 ftp
	bugs 1357260 and 1281692
Message-ID: <E1FUqzm-0007Jv-7L@sc8-sf-web6.sourceforge.net>

Patches item #1470976, was opened at 2006-04-15 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=1470976&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for urllib/urllib2 ftp bugs 1357260 and 1281692

Initial Comment:
This fixes 1357260 and 1281692.

As suggested in the initial comment for 1357260, the
patch simply removes the code that does an NLST before
the attempt to actually fetch the file, since some
server operators turn off file listing (presumably in
an attempt to provide increased security of some kind).
 "Easier to ask forgiveness than get permission"
applies to the FTP protocol as much as to Python :-)

FWIW, I verified that this allows retrieval in some
cases where it wasn't previously, using proftpd 1.2.10
(gentoo ebuild r7) with this configuration directive
placed inside the <Anonymous ~ftp></Anonymous> directive:

    <Limit LIST NLST>
      DenyAll
    </Limit>

Without the patch, I get a 450 when doing a urlopen on
files accessible from that server (using either urllib
or urllib2).  With the patch, I can retrieve the files.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470976&group_id=5470

From noreply at sourceforge.net  Sun Apr 16 15:43:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Apr 2006 06:43:05 -0700
Subject: [Patches] [ python-Patches-1471291 ] Forbid iteration over strings
Message-ID: <E1FV7Wr-00055a-8Q@sc8-sf-web3.sourceforge.net>

Patches item #1471291, was opened at 2006-04-16 09:43
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=1471291&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: 1
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Forbid iteration over strings

Initial Comment:
This was proposed on the list.  It turned out to be
easy to implement the basic feature (iter() only calls
__iter__ and doesn't fall back on __getitem__) but a
disaster to use -- even after extensive fixes to the
sre compiler and smaller fixes to half a dozen other
modules, 120 tests were failing.  I'm saving the diffs
here for posterity.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471291&group_id=5470

From noreply at sourceforge.net  Sun Apr 16 22:57:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Apr 2006 13:57:24 -0700
Subject: [Patches] [ python-Patches-1063914 ] Tkinter clipboard_get method
	(new in Tk 8.4)
Message-ID: <E1FVEJA-0006Tw-9N@sc8-sf-web6.sourceforge.net>

Patches item #1063914, was opened at 2004-11-10 17:07
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063914&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 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Martin Franklin (mfranklin1)
Assigned to: Martin v. L??wis (loewis)
Summary: Tkinter clipboard_get method (new in Tk 8.4)

Initial Comment:
When Tkinter was patched to include the new Tk 8.4 stuff
the clipboard_get method was left out.  The attached
diff -c 
file should fix this...



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-16 22:57

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, applied as r45461. I agree with jepler
in all points.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2005-04-12 17:43

Message:
Logged In: YES 
user_id=2772

The existing selection_get method also raises TclError,
instead of returning some sentinel value.  clipboard_get
should do the same.

>>> t.selection_get(type="INTEGER")
TclError: PRIMARY selection doesn't exist or form "INTEGER"
not defined

The patch looks obviously correct.  Under light testing, it
worked properly (Python 2.3.5 / Linux),  Recommend "apply".

----------------------------------------------------------------------

Comment By: Martin Franklin (mfranklin1)
Date: 2004-11-11 14:55

Message:
Logged In: YES 
user_id=482545


Thanks Martin I wasn't sure...

I wanted to point out that this method raises a TclError if
it is called when the clipboard is empty... not sure if that
is pythonic or not... perhaps I could catch it and return an
empty string?  Perhaps I should bring this up on the Tkinter
mail list...




----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-11-10 23:21

Message:
Logged In: YES 
user_id=21627

It's too late for 2.4; retargetting for 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1063914&group_id=5470

From chacaraconfeccoes at dglnet.com.br  Mon Apr 17 07:27:55 2006
From: chacaraconfeccoes at dglnet.com.br (Chácara Confecções)
Date: Mon, 17 Apr 2006 05:27:55 GMT
Subject: [Patches] Moda Feminina .
Message-ID: <20060417052648.E586B4CFD@mx1.dglnet.com.br>

An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20060417/a1f5b79e/attachment.html 

From noreply at sourceforge.net  Mon Apr 17 08:01:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 16 Apr 2006 23:01:55 -0700
Subject: [Patches] [ python-Patches-1471578 ] start testing strings > 2GB
Message-ID: <E1FVMo7-00054q-OC@sc8-sf-web5.sourceforge.net>

Patches item #1471578, was opened at 2006-04-16 23:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: start testing strings > 2GB

Initial Comment:
Incomplete patch.  Would be great if someone picked
this up and ran with it.  Need to be conservative and
try not to use too much memory in these tests.

Should start with strings and unicode.  Those will be
the most important things to test first.  Then can move
to arrays, mmap and other sequences.  Eventually on to
lists, sets, and dicts.

Right now, I'm sticking this in
Lib/tests/bigmem/test_str.py. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 15:41:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 06:41:05 -0700
Subject: [Patches] [ python-Patches-982340 ] applesingle endianness issue
Message-ID: <E1FVTyT-00039E-Pq@sc8-sf-web1.sourceforge.net>

Patches item #982340, was opened at 2004-06-30 02:20
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982340&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 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: applesingle endianness issue

Initial Comment:
the struct formats in applesingle.py do not declare endianness and 
thus won't work on little endian architectures.  This patch adds the 
endian declarations to the struct formats.
(from http://www.opensource.apple.com/darwinsource/
WWDC2004/)

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 15:41

Message:
Logged In: YES 
user_id=580910

Fixed in revision 45487 on the trunk. Please confirm and close this patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982340&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 15:41:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 06:41:44 -0700
Subject: [Patches] [ python-Patches-1218421 ] byteorder issue in
	PyMac_GetOSType
Message-ID: <E1FVTz6-0003Aw-RY@sc8-sf-web1.sourceforge.net>

Patches item #1218421, was opened at 2005-06-10 20:59
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1218421&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 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: byteorder issue in PyMac_GetOSType

Initial Comment:
The attached patch fixes an issue with byte order in 
PyMac_GetOSType (and its reverse).

These functions convert from an OSType to a string (and back) by 
interpreting an OSType as a 4-byte string. This is not correct if 
you're not on a big-endian system, such as some of the future Apple 
systems.
 
The attached patch is for python 2.4.1.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 15:41

Message:
Logged In: YES 
user_id=580910

Fixed in revision 45487 on the trunk

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1218421&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 16:25:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 07:25:42 -0700
Subject: [Patches] [ python-Patches-1471761 ] test for broken poll at runtime
Message-ID: <E1FVUfe-0000fA-An@sc8-sf-web4-b.sourceforge.net>

Patches item #1471761, was opened at 2006-04-17 16: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=1471761&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: test for broken poll at runtime

Initial Comment:
This patch moves the test for a broken poll() implementation from 
configure-time to runtime.

The reason for creating this patch is that we'd like to have one python 
binary for OSX 10.3 and later. OSX 10.3 has a broken version of poll, 
while 10.4 doesn't. With this patch you'll have select.poll when it is 
available and working indepent of the version of the OS where python was 
build.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 16:31:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 07:31:57 -0700
Subject: [Patches] [ python-Patches-1097739 ] Direct framework linking for
	MACOSX_DEPLOYMENT_TARGET < 10.3
Message-ID: <E1FVUlh-00017x-Li@sc8-sf-web4-b.sourceforge.net>

Patches item #1097739, was opened at 2005-01-07 11:06
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097739&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 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Direct framework linking for MACOSX_DEPLOYMENT_TARGET < 10.3

Initial Comment:
It is not a good idea to use -framework (even with -F) if it is 
necessary to link to a less-than-current framework.  For Python, 
this is the case.

This patch to configure.in should (in theory) resolve this issue.  
Note that since only the .in is patched, autoconf must be run after 
application.

I have only tested the 10.3 scenario, but will comment as soon as 
the 10.2 build has finished and I've tested it.

Background reading:
http://bob.pythonmac.org/archives/2005/01/05/versioned-
frameworks-considered-harmful/
http://mail.python.org/pipermail/python-dev/2005-January/
thread.html#50649



----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:31

Message:
Logged In: YES 
user_id=580910

Bob,

Could you please close this patch, it has been applied.

Ronald

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2005-01-07 14:09

Message:
Logged In: YES 
user_id=45365

Looks good. Checked in as configure.in 1.480, configure 1.467.

Will backport to 2.4 and 2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097739&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 16:46:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 07:46:14 -0700
Subject: [Patches] [ python-Patches-1471761 ] test for broken poll at runtime
Message-ID: <E1FVUzW-0001F2-1R@sc8-sf-web6.sourceforge.net>

Patches item #1471761, was opened at 2006-04-17 16:25
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: test for broken poll at runtime

Initial Comment:
This patch moves the test for a broken poll() implementation from 
configure-time to runtime.

The reason for creating this patch is that we'd like to have one python 
binary for OSX 10.3 and later. OSX 10.3 has a broken version of poll, 
while 10.4 doesn't. With this patch you'll have select.poll when it is 
available and working indepent of the version of the OS where python was 
build.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:46

Message:
Logged In: YES 
user_id=580910

I've uploaded a new version of the patch, and removed the earlier one, because 
the first version also contained an unrelated patch.

Also note that this patch updates configure.in, hence autoconf should be run 
before checking it in.

And finally: the original author of this patch is Bob Ipollito (etrepum), I've 
harvested this from the python24-fat tree.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 19:13:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 10:13:52 -0700
Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb
Message-ID: <E1FVXIO-0000pG-OC@sc8-sf-web3.sourceforge.net>

Patches item #790710, was opened at 2003-08-18 19:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&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.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Gr?goire Dooms (dooms)
Assigned to: Martin v. L??wis (loewis)
Summary: breakpoint command lists in pdb

Initial Comment:
This patch enables the user to define a list of commands 
associated to a breakpoint. Those commands are executed 
whenever the given breakpoint makes the program stop 
execution. 
The &quot;commands [bpnumber]&quot; command works like in gdb. 
 
This patch is against the CVS HEAD, it has been tested with 
python 2.3. 
The documentation is updated too. 
 
 

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 19:13

Message:
Logged In: YES 
user_id=21627

Thanks for again for the patch; I committed it as r45492.
Sorry it took so long. I forgot that you had created a
documentation patch originally also; I just redid the
documentation from the doc string. If you think the
documentation should be changed, please submit a new patch.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-02-06 19:14

Message:
Logged In: YES 
user_id=6380

Still no time, so unassigning.

----------------------------------------------------------------------

Comment By: Gr?goire Dooms (dooms)
Date: 2005-02-06 14:06

Message:
Logged In: YES 
user_id=846867

Patch against python 2.4 : pdb.py revision 1.73 

----------------------------------------------------------------------

Comment By: Gr?goire Dooms (dooms)
Date: 2005-02-06 14:03

Message:
Logged In: YES 
user_id=846867

I redid this patch according to your comments. The command 
list definition interaction is made by calling cmdloop again. 
onecmd is overriden to check if the line is entered in "normal 
mode" or in "command list definition mode". This way is much 
cleaner than before. I also renamed all additional data 
attributes so they contain "commands" as a substring. 
 
I add the new patch against revision 1.66 (python 2.3) and 
revision 1.73 (python 2.4). This patch does not contain the 
documentation changes as I did not rewrite the doc (refer to 
the old diff file for the doc patch). 

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-08-18 19:40

Message:
Logged In: YES 
user_id=21627

Oops. Changing the prompt itself is fine - I just disliked
the control flow that follows.

IDLE things can be discussed on either list, I guess, or
directly sent to kbk. If you mean changes, you best submit
them as a patch here to SF.

----------------------------------------------------------------------

Comment By: Gr?goire Dooms (dooms)
Date: 2004-08-18 14:48

Message:
Logged In: YES 
user_id=846867

Ok, I see. 
This implementation is one year old. 
I'll recode this according to your comments. 
 
Why should'nt 'commands' change the prompt ? 
Should I assign to somebody else ? 
Are IDLE topics preferably discussed in idle-dev or 
python-dev mailing list ?   
 

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-08-18 14:19

Message:
Logged In: YES 
user_id=21627

I like the feature, but the implementation is not acceptable
in its current form: it changes the prompt, and the rebinds
all existing commands so that they add to self.commands.

Instead of all this trickery, do_commands should invoke
cmdloop directly, and add precmd and do_end implementations;
overriding onecmd also might be an option.

In addition, the patch should avoid setting member variables
of pdb in cases where a local variable is sufficient (e.g.
lastcmd_back).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-21 00:02

Message:
Logged In: YES 
user_id=6380

I'm all for this, but don't have the bandwidth to review it.
Who does?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 20:19:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 11:19:41 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FVYK5-0005rd-NH@sc8-sf-web3.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
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=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 20:20:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 11:20:36 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FVYKy-0005wL-Gb@sc8-sf-web3.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 20:24:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 11:24:24 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FVYOe-0006Ey-AV@sc8-sf-web3.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 20:40:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 11:40:21 -0700
Subject: [Patches] [ python-Patches-1097739 ] Direct framework linking for
	MACOSX_DEPLOYMENT_TARGET < 10.3
Message-ID: <E1FVYe5-0007QW-DY@sc8-sf-web3.sourceforge.net>

Patches item #1097739, was opened at 2005-01-07 11:06
Message generated for change (Settings changed) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097739&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 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Direct framework linking for MACOSX_DEPLOYMENT_TARGET < 10.3

Initial Comment:
It is not a good idea to use -framework (even with -F) if it is 
necessary to link to a less-than-current framework.  For Python, 
this is the case.

This patch to configure.in should (in theory) resolve this issue.  
Note that since only the .in is patched, autoconf must be run after 
application.

I have only tested the 10.3 scenario, but will comment as soon as 
the 10.2 build has finished and I've tested it.

Background reading:
http://bob.pythonmac.org/archives/2005/01/05/versioned-
frameworks-considered-harmful/
http://mail.python.org/pipermail/python-dev/2005-January/
thread.html#50649



----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:31

Message:
Logged In: YES 
user_id=580910

Bob,

Could you please close this patch, it has been applied.

Ronald

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2005-01-07 14:09

Message:
Logged In: YES 
user_id=45365

Looks good. Checked in as configure.in 1.480, configure 1.467.

Will backport to 2.4 and 2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097739&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 21:49:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 12:49:03 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FVZiZ-0007sy-At@sc8-sf-web5.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21: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=1471925&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 21:50:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 12:50:32 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FVZk0-00080s-AR@sc8-sf-web5.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21:49
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 21:50

Message:
Logged In: YES 
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Mon Apr 17 23:52:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 14:52:36 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FVbe8-0000Qg-5s@sc8-sf-web5.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 00:02:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 15:02:51 -0700
Subject: [Patches] [ python-Patches-1471761 ] test for broken poll at runtime
Message-ID: <E1FVbo3-0007QO-4s@sc8-sf-web1.sourceforge.net>

Patches item #1471761, was opened at 2006-04-17 16:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: test for broken poll at runtime

Initial Comment:
This patch moves the test for a broken poll() implementation from 
configure-time to runtime.

The reason for creating this patch is that we'd like to have one python 
binary for OSX 10.3 and later. OSX 10.3 has a broken version of poll, 
while 10.4 doesn't. With this patch you'll have select.poll when it is 
available and working indepent of the version of the OS where python was 
build.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:02

Message:
Logged In: YES 
user_id=21627

I'm -1 for this patch in its current form. Python shouldn't
perform "unnecessary" system calls, even if they are as 
cheap as creating a pipe.

It's fine that you want to use the same binary across OSX 
releases; please rewrite the patch to be Mac-specific: 
Always run the configure test for a broken poll, but ignore 
its outcome on OSX. The easiest way to achieve this on top 
of your current patch might be the following:

- #undef HAVE_BROKEN_POLL on OSX in selectmodule.c
- implement select_have_broken_poll to return 0 (i.e. just
the last statement) on anything but OSX.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:46

Message:
Logged In: YES 
user_id=580910

I've uploaded a new version of the patch, and removed the earlier one, because 
the first version also contained an unrelated patch.

Also note that this patch updates configure.in, hence autoconf should be run 
before checking it in.

And finally: the original author of this patch is Bob Ipollito (etrepum), I've 
harvested this from the python24-fat tree.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 00:18:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 15:18:06 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FVc2o-00009e-9P@sc8-sf-web1.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21:49
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:18

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. I wonder why you are clearing
the errors from PyObject_DelAttrString, though: There
shouldn't be any errors (right?), so if that fails,
something is seriously wrong.

As for the time changes: are you saying OSX doesn't have
gettimeofday? I can find a manual page on

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/gettimeofday.2.html

This has higher resolution than ftime, and also takes higher
precedence in timemodule.c: Why is it not used?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 21:50

Message:
Logged In: YES 
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 05:43:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 20:43:53 -0700
Subject: [Patches] [ python-Patches-1267629 ] pdb: implement "until",
	fix for 1248119
Message-ID: <E1FVh85-0000no-I3@sc8-sf-web4-b.sourceforge.net>

Patches item #1267629, was opened at 2005-08-23 19:24
Message generated for change (Settings changed) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1267629&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
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb: implement "until",fix for 1248119

Initial Comment:
The patch implements the "until" command in pdb

"until" command 
continues execution until the line with a number
greater than the current one is reached or until the
current frame returns"""

which allows to quickly step through the loops or list
comprehensions without using temporary
breakpoints...(temporary breakpoints are often less
convenient: more to type, and the user needs to think
about line numbers)

The name "until" is borrowed from gdb..

There is a small issue of abbreviations current pdb
abbreviates 
up as "u"
until as "unt"

While gdb abbreviates until as "u", and up has no
abbreviation...

Should abbreviations be synced?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1267629&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 07:42:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Apr 2006 22:42:17 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FViyf-00014s-J1@sc8-sf-web4-b.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 10:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Armin Rigo (arigo)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-17 22:42

Message:
Logged In: YES 
user_id=33168

My man page (man 7 unix) says:

sun_family  always contains AF_UNIX.  sun_path contains the
zero-terminated pathname of the socket in the file system. 
 If  sun_path  starts with  a zero byte it refers to the
abstract namespace maintained by the Unix protocol module. 
The socket's address in this namespace is  given by  the
rest of the bytes in sun_path.  Note that names in the
abstract namespace are not zero-terminated.

I read that (rest of the bytes in sun_path) to mean that if
the first byte is NUL, the address is all the remaining
bytes in sun_path (ie, sun_path is treated as binary).  Also
since the abstract namespace is not NUL-terminated.  I don't
know if the man page is correct.  Do you understand the
manpage the way I do?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-14 01:33

Message:
Logged In: YES 
user_id=4771

You're missing the point of my patch.  It is to preserve
the originally specified length of the name.  The names
'\x00abc', '\x00abc\x00' and '\x00abc\x00\x00' are all
different for the Linux IP stack, as far as I can tell.
In operations like bind() we specify the length of the
name by setting addrlen to the length of the header
plus the number of bytes actually used in the sun_path
array.  The kernel code remembers this length, and
passes it back in &addrlen to functions like
getsockaddr().  That's why I compute the number of
bytes that are really meaningful as the addrlen minus
the headers, instead of just UNIX_PATH_MAX.

About the second #ifdef, I really meant the > to be >
and not >=, because it is acceptable to pass a name
containing exactly UNIX_PATH_MAX bytes -- the abstract
namespace names don't have to be followed by a
terminating '\x00'.  By contrast, the regular names
must not be longer than UNIX_PATH_MAX-1 characters to
allow for the extra '\x00'.

In some sense, the Linux abstract namespace is rather
strange from the point of view of C, but not if you
think about it as you would think about Python strings.
Indeed, apart from the requirement that they start
with '\x00', these names have an intrinsic length
which is not related to any embedded '\x00'.  It is
stored together with the name in some kernel
structures, but outside the sun_path array of bytes.

But enough theory: the patch you propose don't pass
its own new test on my machine because of this :-)
Does it pass on yours?

I'm not too concerned about addrlen ending up shorter
than the size of the headers.  That would be a Linux
kernel bug.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 22:01

Message:
Logged In: YES 
user_id=33168

Wow!  Now I see why you wanted review.

Modules/socketmodule.c:

In the first #ifdef linux section (968+), why the calc for
addrlen?  Isn't the len just sizeof(a->sun_path) and that
can be passed to FromStringAndSize()?

In the second #ifdef linux section (1098+), should if (len >
sizeof ...) be >= like the other check?

It's probably easier to show what I mean in code.  Attached
is another patch.  I didn't test it.  There's a big comment
that we should address in either patch about a negative
length issue.


----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2006-04-13 07:31

Message:
Logged In: YES 
user_id=129426

Armin, I don't have access to a Linux machine anymore so I
can't really comment on this issue anymore, sorry.
Also this patch was not made for a specific use case I had,
it was a patch for an open bug filed by someone else (bug
764437).
Previous discussion can be found there.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-13 05:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-12 21:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 06:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 05:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 03:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 12:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 11:38:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 02:38:13 -0700
Subject: [Patches] [ python-Patches-1472184 ] pdb 'clear' command doesn't
	clear selected bp's
Message-ID: <E1FVmez-0000Ay-7R@sc8-sf-web1.sourceforge.net>

Patches item #1472184, was opened at 2006-04-18 09: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=1472184&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'clear' command doesn't clear selected bp's

Initial Comment:
Pdb 'clear x' command doesn't clear selected breakpoints
that are already set:

$ ./python -m pdb ../test.py
> /home/xyz/python/test.py(3)<module>()
-> def t(x):
(Pdb) break 5
Breakpoint 1 at /home/xyz/python/test.py:5
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /home/xyz/python/test.py:5
(Pdb) clear 1
No breakpoint numbered 1
(Pdb)                    
...
  for i in numberlist:
*  if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): 
    print 'No breakpoint numbered', i
...

Each i is a string and it's compared to 0 and len(...),
so condition * is always True. 
The fix is trivial:
*  if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)):


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 11:47:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 02:47:39 -0700
Subject: [Patches] [ python-Patches-1472184 ] [patch] pdb 'clear' command
	doesn't clear selected bp's
Message-ID: <E1FVmo7-0000u0-92@sc8-sf-web1.sourceforge.net>

Patches item #1472184, was opened at 2006-04-18 09:38
Message generated for change (Settings changed) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&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: Open
>Resolution: Accepted
Priority: 5
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
>Summary: [patch] pdb 'clear' command doesn't clear selected bp's

Initial Comment:
Pdb 'clear x' command doesn't clear selected breakpoints
that are already set:

$ ./python -m pdb ../test.py
> /home/xyz/python/test.py(3)<module>()
-> def t(x):
(Pdb) break 5
Breakpoint 1 at /home/xyz/python/test.py:5
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /home/xyz/python/test.py:5
(Pdb) clear 1
No breakpoint numbered 1
(Pdb)                    
...
  for i in numberlist:
*  if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): 
    print 'No breakpoint numbered', i
...

Each i is a string and it's compared to 0 and len(...),
so condition * is always True. 
The fix is trivial:
*  if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)):


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 11:53:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 02:53:31 -0700
Subject: [Patches] [ python-Patches-1472184 ] fix for #1472191
Message-ID: <E1FVmtn-0001M6-SD@sc8-sf-web1.sourceforge.net>

Patches item #1472184, was opened at 2006-04-18 09:38
Message generated for change (Settings changed) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&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: Open
Resolution: Accepted
>Priority: 7
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
>Summary: fix for #1472191

Initial Comment:
Pdb 'clear x' command doesn't clear selected breakpoints
that are already set:

$ ./python -m pdb ../test.py
> /home/xyz/python/test.py(3)<module>()
-> def t(x):
(Pdb) break 5
Breakpoint 1 at /home/xyz/python/test.py:5
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /home/xyz/python/test.py:5
(Pdb) clear 1
No breakpoint numbered 1
(Pdb)                    
...
  for i in numberlist:
*  if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): 
    print 'No breakpoint numbered', i
...

Each i is a string and it's compared to 0 and len(...),
so condition * is always True. 
The fix is trivial:
*  if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)):


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 13:52:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 04:52:20 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FVokm-0003KA-3B@sc8-sf-web4-b.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 18:18
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Armin Rigo (arigo)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2006-04-18 11:52

Message:
Logged In: YES 
user_id=4771

The man page is indeed confusing.  I was relying on
small experiments.  On my Linux box at least, the
address does not have to occupy the whole of the
sun_path array.  You can really do the following:
set sun_path to '\x00!\x00\x00\x00\x00\x00\x00...'
then call bind() with an addrlen that covers only the
first two characters '\x00!', and then call bind() on
another socket with the same sun_path but an addrlen
that covers the first three characters '\x00!\x00'.
The two addresses don't conflict and are regarded as
different.

Conversely, if I try to bind() two sockets with the
same addrlen and a sun_path that differs after the
number of bytes included in the addrlen, I get an
"Address already in use", thus showing that addrlen
is really meaningful.

Another hint is that if you let the system pick a
default local address for your socket, as e.g. is done
by s=socket(AF_UNIX); s.connect(...), then getsockname()
will return a name that looks like '\x00000003'.  More
precisely, the addrlen is much shorter than the maximum
that would correspond to the whole sun_path array.

A more practical example: it is bogus to ignore the
addrlen and always return the whole sun_path array,
because if we did that, then the following kind of code
would fail:

  >>> s1 = socket(AF_UNIX); s2 = socket(AF_UNIX)
  >>> s1.bind('\x00hello')
  >>> s2.connect(s1.getsockname())

because getsockname() would return a string that is
108 characters long, and the connect would fail.
(Just try it out!  It gives 'Connection refused'.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-18 05:42

Message:
Logged In: YES 
user_id=33168

My man page (man 7 unix) says:

sun_family  always contains AF_UNIX.  sun_path contains the
zero-terminated pathname of the socket in the file system. 
 If  sun_path  starts with  a zero byte it refers to the
abstract namespace maintained by the Unix protocol module. 
The socket's address in this namespace is  given by  the
rest of the bytes in sun_path.  Note that names in the
abstract namespace are not zero-terminated.

I read that (rest of the bytes in sun_path) to mean that if
the first byte is NUL, the address is all the remaining
bytes in sun_path (ie, sun_path is treated as binary).  Also
since the abstract namespace is not NUL-terminated.  I don't
know if the man page is correct.  Do you understand the
manpage the way I do?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-14 08:33

Message:
Logged In: YES 
user_id=4771

You're missing the point of my patch.  It is to preserve
the originally specified length of the name.  The names
'\x00abc', '\x00abc\x00' and '\x00abc\x00\x00' are all
different for the Linux IP stack, as far as I can tell.
In operations like bind() we specify the length of the
name by setting addrlen to the length of the header
plus the number of bytes actually used in the sun_path
array.  The kernel code remembers this length, and
passes it back in &addrlen to functions like
getsockaddr().  That's why I compute the number of
bytes that are really meaningful as the addrlen minus
the headers, instead of just UNIX_PATH_MAX.

About the second #ifdef, I really meant the > to be >
and not >=, because it is acceptable to pass a name
containing exactly UNIX_PATH_MAX bytes -- the abstract
namespace names don't have to be followed by a
terminating '\x00'.  By contrast, the regular names
must not be longer than UNIX_PATH_MAX-1 characters to
allow for the extra '\x00'.

In some sense, the Linux abstract namespace is rather
strange from the point of view of C, but not if you
think about it as you would think about Python strings.
Indeed, apart from the requirement that they start
with '\x00', these names have an intrinsic length
which is not related to any embedded '\x00'.  It is
stored together with the name in some kernel
structures, but outside the sun_path array of bytes.

But enough theory: the patch you propose don't pass
its own new test on my machine because of this :-)
Does it pass on yours?

I'm not too concerned about addrlen ending up shorter
than the size of the headers.  That would be a Linux
kernel bug.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-14 05:01

Message:
Logged In: YES 
user_id=33168

Wow!  Now I see why you wanted review.

Modules/socketmodule.c:

In the first #ifdef linux section (968+), why the calc for
addrlen?  Isn't the len just sizeof(a->sun_path) and that
can be passed to FromStringAndSize()?

In the second #ifdef linux section (1098+), should if (len >
sizeof ...) be >= like the other check?

It's probably easier to show what I mean in code.  Attached
is another patch.  I didn't test it.  There's a big comment
that we should address in either patch about a negative
length issue.


----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2006-04-13 14:31

Message:
Logged In: YES 
user_id=129426

Armin, I don't have access to a Linux machine anymore so I
can't really comment on this issue anymore, sorry.
Also this patch was not made for a specific use case I had,
it was a patch for an open bug filed by someone else (bug
764437).
Previous discussion can be found there.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-13 12:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 04:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 13:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 12:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 11:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 20:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 14:22:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 05:22:27 -0700
Subject: [Patches] [ python-Patches-1472257 ] fix for #1472251
Message-ID: <E1FVpDv-0004Of-3R@sc8-sf-web6.sourceforge.net>

Patches item #1472257, was opened at 2006-04-18 12: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=1472257&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: Open
Resolution: None
Priority: 5
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for #1472251

Initial Comment:
This simple patch ensure that the first argument to the
'run/runeval' functions is string.See Bug #1472251 for
more details.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 14:33:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 05:33:56 -0700
Subject: [Patches] [ python-Patches-1472263 ] fix for #1472251
Message-ID: <E1FVpP2-0002jp-2Y@sc8-sf-web3.sourceforge.net>

Patches item #1472263, was opened at 2006-04-18 12: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=1472263&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: Open
Resolution: None
Priority: 5
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for #1472251

Initial Comment:
This simple patch ensure that the first argument to the
'run/runeval' functions in bdb.py is a string.For more
details see Bug #1472251.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472263&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 18:48:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 09:48:16 -0700
Subject: [Patches] [ python-Patches-1472459 ] Updates to PEP 359 and 3002
Message-ID: <E1FVtNA-0001Ql-6s@sc8-sf-web2.sourceforge.net>

Patches item #1472459, was opened at 2006-04-18 10: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=1472459&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
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: Updates to PEP 359 and 3002

Initial Comment:
I don't have commit access to the peps directory, so
here are some updates to PEPs 359 and 3002.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 21:05:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 12:05:32 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FVvW0-0008CN-Et@sc8-sf-web6.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 21:27:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 12:27:34 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FVvrK-0006aA-QS@sc8-sf-web3.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21:49
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:27

Message:
Logged In: YES 
user_id=580910

Good points. I was clearing errors because it seemed better to ignore errors. 
But you're right, if this does fail somethings is seriously wrong. I've replaced 
error-checking by return statements (but have not replaced the patch).

The change to time is interesting, I added those changes because the binary 
wouldn't run without the patch, without realizing that configure/timemodule 
is picking up the wrong function for finding the current time.  That seems to 
be caused by a bug in the preprocessor code that selects the right section of 
code. OSX 10.4 has both gettimeofday and ftime, and with the current set of 
#if statements this means both the gettimeofday and ftime blocks get 
compiled in. The ftime-bit is dead code, but present nonetheless.

I tried to rearange the #if-statements to make sure just one block gets 
included, but then get compiler warnings because floattime checks for an 
error-return of gettimeofday.  IMHO the error-return check is rather lame, 
the only reason this could fail is when the first argument of gettimeofday is 
invalid (and SUS says this function will always return 0, although manpage on 
darwin and linux claim otherwise), And time(2) can also return -1 to indicate 
failure ;-)

If uploaded a new patch (version 2) that removes error clearing for the DelAttr 
calls in posixmodule and chickens out on the ftime issue by #undef-ing 
HAVE_FTIME for OSX systems that HAVE_GETTIMEOFDAY.

SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/
gettimeofday.html

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:18

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. I wonder why you are clearing
the errors from PyObject_DelAttrString, though: There
shouldn't be any errors (right?), so if that fails,
something is seriously wrong.

As for the time changes: are you saying OSX doesn't have
gettimeofday? I can find a manual page on

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/gettimeofday.2.html

This has higher resolution than ftime, and also takes higher
precedence in timemodule.c: Why is it not used?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 21:50

Message:
Logged In: YES 
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 21:29:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 12:29:51 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FVvtX-0006jU-0E@sc8-sf-web3.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21:49
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:29

Message:
Logged In: YES 
user_id=580910

Version 3 solves the ftime issue the other (IMO more correct) way: it ignores the 
returnvalue of gettimeofday and conditionalizes the floattime code in such way 
that either gettimeofday or ftime is used, but never both.

 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:27

Message:
Logged In: YES 
user_id=580910

Good points. I was clearing errors because it seemed better to ignore errors. 
But you're right, if this does fail somethings is seriously wrong. I've replaced 
error-checking by return statements (but have not replaced the patch).

The change to time is interesting, I added those changes because the binary 
wouldn't run without the patch, without realizing that configure/timemodule 
is picking up the wrong function for finding the current time.  That seems to 
be caused by a bug in the preprocessor code that selects the right section of 
code. OSX 10.4 has both gettimeofday and ftime, and with the current set of 
#if statements this means both the gettimeofday and ftime blocks get 
compiled in. The ftime-bit is dead code, but present nonetheless.

I tried to rearange the #if-statements to make sure just one block gets 
included, but then get compiler warnings because floattime checks for an 
error-return of gettimeofday.  IMHO the error-return check is rather lame, 
the only reason this could fail is when the first argument of gettimeofday is 
invalid (and SUS says this function will always return 0, although manpage on 
darwin and linux claim otherwise), And time(2) can also return -1 to indicate 
failure ;-)

If uploaded a new patch (version 2) that removes error clearing for the DelAttr 
calls in posixmodule and chickens out on the ftime issue by #undef-ing 
HAVE_FTIME for OSX systems that HAVE_GETTIMEOFDAY.

SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/
gettimeofday.html

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:18

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. I wonder why you are clearing
the errors from PyObject_DelAttrString, though: There
shouldn't be any errors (right?), so if that fails,
something is seriously wrong.

As for the time changes: are you saying OSX doesn't have
gettimeofday? I can find a manual page on

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/gettimeofday.2.html

This has higher resolution than ftime, and also takes higher
precedence in timemodule.c: Why is it not used?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 21:50

Message:
Logged In: YES 
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 21:44:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 12:44:00 -0700
Subject: [Patches] [ python-Patches-1472459 ] Updates to PEP 359 and 3002
Message-ID: <E1FVw7E-0003s1-0C@sc8-sf-web5.sourceforge.net>

Patches item #1472459, was opened at 2006-04-18 12:48
Message generated for change (Comment added) made by goodger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&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
Submitted By: Steven Bethard (bediviere)
>Assigned to: David Goodger (goodger)
Summary: Updates to PEP 359 and 3002

Initial Comment:
I don't have commit access to the peps directory, so
here are some updates to PEPs 359 and 3002.

----------------------------------------------------------------------

>Comment By: David Goodger (goodger)
Date: 2006-04-18 15:43

Message:
Logged In: YES 
user_id=7733

In future, please send PEP updates to the PEP editors
(peps at python.org).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 21:46:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 12:46:12 -0700
Subject: [Patches] [ python-Patches-1471761 ] test for broken poll at runtime
Message-ID: <E1FVw9M-0002oX-Ga@sc8-sf-web6.sourceforge.net>

Patches item #1471761, was opened at 2006-04-17 16:25
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: test for broken poll at runtime

Initial Comment:
This patch moves the test for a broken poll() implementation from 
configure-time to runtime.

The reason for creating this patch is that we'd like to have one python 
binary for OSX 10.3 and later. OSX 10.3 has a broken version of poll, 
while 10.4 doesn't. With this patch you'll have select.poll when it is 
available and working indepent of the version of the OS where python was 
build.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:46

Message:
Logged In: YES 
user_id=580910

I don't quite understand why runtime testing is considered bad here, although I 
guess the time used by a lot of runtime tests could add up. 

But anyway, broken-poll-at-runtime-2.patch implements your suggestion. 

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:02

Message:
Logged In: YES 
user_id=21627

I'm -1 for this patch in its current form. Python shouldn't
perform "unnecessary" system calls, even if they are as 
cheap as creating a pipe.

It's fine that you want to use the same binary across OSX 
releases; please rewrite the patch to be Mac-specific: 
Always run the configure test for a broken poll, but ignore 
its outcome on OSX. The easiest way to achieve this on top 
of your current patch might be the following:

- #undef HAVE_BROKEN_POLL on OSX in selectmodule.c
- implement select_have_broken_poll to return 0 (i.e. just
the last statement) on anything but OSX.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:46

Message:
Logged In: YES 
user_id=580910

I've uploaded a new version of the patch, and removed the earlier one, because 
the first version also contained an unrelated patch.

Also note that this patch updates configure.in, hence autoconf should be run 
before checking it in.

And finally: the original author of this patch is Bob Ipollito (etrepum), I've 
harvested this from the python24-fat tree.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 22:00:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 13:00:06 -0700
Subject: [Patches] [ python-Patches-1472459 ] Updates to PEP 359 and 3002
Message-ID: <E1FVwMo-0007KA-97@sc8-sf-web2.sourceforge.net>

Patches item #1472459, was opened at 2006-04-18 10:48
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&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
Submitted By: Steven Bethard (bediviere)
Assigned to: David Goodger (goodger)
Summary: Updates to PEP 359 and 3002

Initial Comment:
I don't have commit access to the peps directory, so
here are some updates to PEPs 359 and 3002.

----------------------------------------------------------------------

>Comment By: Steven Bethard (bediviere)
Date: 2006-04-18 14:00

Message:
Logged In: YES 
user_id=945502

Will do.

I guess PEP 1 probably needs updated - it says:

"""
For more mature, or finished PEPs you may want to submit
corrections to the SourceForge bug manager [11] or better
yet, the SourceForge patch manager [6] so that your changes
don't get lost.
"""

It also mentions some stuff about CVS which is presumably no
longer accurate.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-18 13:43

Message:
Logged In: YES 
user_id=7733

In future, please send PEP updates to the PEP editors
(peps at python.org).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 22:22:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 13:22:14 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FVwiE-0002DK-8w@sc8-sf-web3.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 22:22

Message:
Logged In: YES 
user_id=580910

I don't know how I managed to do that, but my initial patch misses an 
essential bit in pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

On non-universal builds or builds for other platforms this is equivalent to the 
current version, on the universal build this ensures that pyconfig.h only sets 
WORDS_BIGENDIAN during the creation of PPC binaries.

python-universal-2.patch avoids the empty if-statement in configure.in and 
includes the pyconfig.h.in change I mentioned above. It also adds a test to 
test_capi that checks if sys.byteorder is consistent with WORDS_BIGENDIAN 
(the former isn't derived from the latter).

I haven't changed -current-version because I haven't had time to fully check 
if that would be safe. 

I did verify that --enable-framework and --enable-universalsdk are fully 
indepedent. 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 22:31:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 13:31:49 -0700
Subject: [Patches] [ python-Patches-1472459 ] Updates to PEP 359 and 3002
Message-ID: <E1FVwrV-0001DS-1Q@sc8-sf-web2.sourceforge.net>

Patches item #1472459, was opened at 2006-04-18 12:48
Message generated for change (Comment added) made by goodger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&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
Submitted By: Steven Bethard (bediviere)
Assigned to: David Goodger (goodger)
Summary: Updates to PEP 359 and 3002

Initial Comment:
I don't have commit access to the peps directory, so
here are some updates to PEPs 359 and 3002.

----------------------------------------------------------------------

>Comment By: David Goodger (goodger)
Date: 2006-04-18 16:31

Message:
Logged In: YES 
user_id=7733

I didn't realize that PEP 1 recommended the SF trackers
(although the PEPs in question are neither mature nor
finished ;-).  I'd say it's OK to use SF, but be sure to
assign the patch to a PEP editor (I don't always catch every
new patche & bug report).  I'll update PEP 1.

I believe this is the first time anyone has gone this route.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2006-04-18 16:00

Message:
Logged In: YES 
user_id=945502

Will do.

I guess PEP 1 probably needs updated - it says:

"""
For more mature, or finished PEPs you may want to submit
corrections to the SourceForge bug manager [11] or better
yet, the SourceForge patch manager [6] so that your changes
don't get lost.
"""

It also mentions some stuff about CVS which is presumably no
longer accurate.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-18 15:43

Message:
Logged In: YES 
user_id=7733

In future, please send PEP updates to the PEP editors
(peps at python.org).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 23:17:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 14:17:34 -0700
Subject: [Patches] [ python-Patches-1472257 ] fix for #1472251
Message-ID: <E1FVxZm-0004fv-D5@sc8-sf-web2.sourceforge.net>

Patches item #1472257, was opened at 2006-04-18 12:22
Message generated for change (Settings changed) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&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: Open
Resolution: None
>Priority: 6
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for #1472251

Initial Comment:
This simple patch ensure that the first argument to the
'run/runeval' functions is string.See Bug #1472251 for
more details.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 23:49:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 14:49:58 -0700
Subject: [Patches] [ python-Patches-1472184 ] pdb: fix for #1472191('clear'
	command bug)
Message-ID: <E1FVy58-0006zd-DJ@sc8-sf-web2.sourceforge.net>

Patches item #1472184, was opened at 2006-04-18 09:38
Message generated for change (Settings changed) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&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: Open
Resolution: Accepted
Priority: 7
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
>Summary: pdb: fix for #1472191('clear' command bug)

Initial Comment:
Pdb 'clear x' command doesn't clear selected breakpoints
that are already set:

$ ./python -m pdb ../test.py
> /home/xyz/python/test.py(3)<module>()
-> def t(x):
(Pdb) break 5
Breakpoint 1 at /home/xyz/python/test.py:5
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /home/xyz/python/test.py:5
(Pdb) clear 1
No breakpoint numbered 1
(Pdb)                    
...
  for i in numberlist:
*  if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): 
    print 'No breakpoint numbered', i
...

Each i is a string and it's compared to 0 and len(...),
so condition * is always True. 
The fix is trivial:
*  if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)):


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 23:51:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 14:51:04 -0700
Subject: [Patches] [ python-Patches-1472184 ] pdb: fix for #1472191('clear'
	command bug)
Message-ID: <E1FVy6C-0004iR-42@sc8-sf-web4-b.sourceforge.net>

Patches item #1472184, was opened at 2006-04-18 09:38
Message generated for change (Settings changed) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&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: Open
Resolution: Accepted
>Priority: 6
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb: fix for #1472191('clear' command bug)

Initial Comment:
Pdb 'clear x' command doesn't clear selected breakpoints
that are already set:

$ ./python -m pdb ../test.py
> /home/xyz/python/test.py(3)<module>()
-> def t(x):
(Pdb) break 5
Breakpoint 1 at /home/xyz/python/test.py:5
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /home/xyz/python/test.py:5
(Pdb) clear 1
No breakpoint numbered 1
(Pdb)                    
...
  for i in numberlist:
*  if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): 
    print 'No breakpoint numbered', i
...

Each i is a string and it's compared to 0 and len(...),
so condition * is always True. 
The fix is trivial:
*  if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)):


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472184&group_id=5470

From noreply at sourceforge.net  Tue Apr 18 23:52:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 14:52:36 -0700
Subject: [Patches] [ python-Patches-1472257 ] pdb: fix for
	#1472251('run/runeval' commands bug)
Message-ID: <E1FVy7g-0007D5-5i@sc8-sf-web2.sourceforge.net>

Patches item #1472257, was opened at 2006-04-18 12:22
Message generated for change (Settings changed) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&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: Open
Resolution: None
Priority: 6
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
>Summary: pdb: fix for #1472251('run/runeval' commands bug)

Initial Comment:
This simple patch ensure that the first argument to the
'run/runeval' functions is string.See Bug #1472251 for
more details.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 00:40:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 15:40:59 -0700
Subject: [Patches] [ python-Patches-1472639 ] make range be xrange
Message-ID: <E1FVysV-0007oB-QE@sc8-sf-web1.sourceforge.net>

Patches item #1472639, was opened at 2006-04-19 00: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=1472639&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: make range be xrange

Initial Comment:
As discussed (in private email), make range an alias
for xrange and see howmuch breaks ;)

Aside from Python/bltinmodule.c, 31 files had to be
changed: 3 modules (but one of them was a doctest in
doctest), 2 test output files (for profile and
cProfile), and 26 tests. The predominant breakage in
tests was due to tests using range() to express
expected-test-output, and comparing it with the output
list. Another fair sized portion (particularly of
doctests, and including the doctest in doctest itself
that had to be updated) broke because of reliance on
the repr of range(). Only a few tests broke because of
xrange() being immutable (mostly tests that were
actually testing list-behaviour, like item- and
slice-assignment, on a list created by range()), but
that were all two real breakages in actual modules. The
only place that broke because xrange can't handle longs
was the test for range() that tested whether it'd take
longs. Overall, ~185 lines had to be changed.

The patch still breaks a test: the test to see if
range() does proper checks on its arguments (using the
'badint' class in test_builtin.) I didn't fix it to
remind myself that xrange() should be made to operate
on longs :) (It currently fails because xrange() will
turn all its arguments into C long integers before it
does any checks.)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472639&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 01:27:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 16:27:29 -0700
Subject: [Patches] [ python-Patches-1472459 ] Updates to PEP 359 and 3002
Message-ID: <E1FVzbV-0003Mf-Oa@sc8-sf-web4-b.sourceforge.net>

Patches item #1472459, was opened at 2006-04-18 12:48
Message generated for change (Settings changed) made by goodger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&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
Submitted By: Steven Bethard (bediviere)
Assigned to: David Goodger (goodger)
Summary: Updates to PEP 359 and 3002

Initial Comment:
I don't have commit access to the peps directory, so
here are some updates to PEPs 359 and 3002.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-18 16:31

Message:
Logged In: YES 
user_id=7733

I didn't realize that PEP 1 recommended the SF trackers
(although the PEPs in question are neither mature nor
finished ;-).  I'd say it's OK to use SF, but be sure to
assign the patch to a PEP editor (I don't always catch every
new patche & bug report).  I'll update PEP 1.

I believe this is the first time anyone has gone this route.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2006-04-18 16:00

Message:
Logged In: YES 
user_id=945502

Will do.

I guess PEP 1 probably needs updated - it says:

"""
For more mature, or finished PEPs you may want to submit
corrections to the SourceForge bug manager [11] or better
yet, the SourceForge patch manager [6] so that your changes
don't get lost.
"""

It also mentions some stuff about CVS which is presumably no
longer accurate.

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-18 15:43

Message:
Logged In: YES 
user_id=7733

In future, please send PEP updates to the PEP editors
(peps at python.org).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472459&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 08:29:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 23:29:20 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FW6Bk-00038w-6f@sc8-sf-web2.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 10:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Armin Rigo (arigo)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-18 23:29

Message:
Logged In: YES 
user_id=33168

I guess I really need to test this on my box.  I don't know
if the man page is correct or if I'm reading it correct. 
BTW what linux are you running (kernel version/distro)?  I'm
2.6.8-gentoo-r4.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-18 04:52

Message:
Logged In: YES 
user_id=4771

The man page is indeed confusing.  I was relying on
small experiments.  On my Linux box at least, the
address does not have to occupy the whole of the
sun_path array.  You can really do the following:
set sun_path to '\x00!\x00\x00\x00\x00\x00\x00...'
then call bind() with an addrlen that covers only the
first two characters '\x00!', and then call bind() on
another socket with the same sun_path but an addrlen
that covers the first three characters '\x00!\x00'.
The two addresses don't conflict and are regarded as
different.

Conversely, if I try to bind() two sockets with the
same addrlen and a sun_path that differs after the
number of bytes included in the addrlen, I get an
"Address already in use", thus showing that addrlen
is really meaningful.

Another hint is that if you let the system pick a
default local address for your socket, as e.g. is done
by s=socket(AF_UNIX); s.connect(...), then getsockname()
will return a name that looks like '\x00000003'.  More
precisely, the addrlen is much shorter than the maximum
that would correspond to the whole sun_path array.

A more practical example: it is bogus to ignore the
addrlen and always return the whole sun_path array,
because if we did that, then the following kind of code
would fail:

  >>> s1 = socket(AF_UNIX); s2 = socket(AF_UNIX)
  >>> s1.bind('\x00hello')
  >>> s2.connect(s1.getsockname())

because getsockname() would return a string that is
108 characters long, and the connect would fail.
(Just try it out!  It gives 'Connection refused'.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-17 22:42

Message:
Logged In: YES 
user_id=33168

My man page (man 7 unix) says:

sun_family  always contains AF_UNIX.  sun_path contains the
zero-terminated pathname of the socket in the file system. 
 If  sun_path  starts with  a zero byte it refers to the
abstract namespace maintained by the Unix protocol module. 
The socket's address in this namespace is  given by  the
rest of the bytes in sun_path.  Note that names in the
abstract namespace are not zero-terminated.

I read that (rest of the bytes in sun_path) to mean that if
the first byte is NUL, the address is all the remaining
bytes in sun_path (ie, sun_path is treated as binary).  Also
since the abstract namespace is not NUL-terminated.  I don't
know if the man page is correct.  Do you understand the
manpage the way I do?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-14 01:33

Message:
Logged In: YES 
user_id=4771

You're missing the point of my patch.  It is to preserve
the originally specified length of the name.  The names
'\x00abc', '\x00abc\x00' and '\x00abc\x00\x00' are all
different for the Linux IP stack, as far as I can tell.
In operations like bind() we specify the length of the
name by setting addrlen to the length of the header
plus the number of bytes actually used in the sun_path
array.  The kernel code remembers this length, and
passes it back in &addrlen to functions like
getsockaddr().  That's why I compute the number of
bytes that are really meaningful as the addrlen minus
the headers, instead of just UNIX_PATH_MAX.

About the second #ifdef, I really meant the > to be >
and not >=, because it is acceptable to pass a name
containing exactly UNIX_PATH_MAX bytes -- the abstract
namespace names don't have to be followed by a
terminating '\x00'.  By contrast, the regular names
must not be longer than UNIX_PATH_MAX-1 characters to
allow for the extra '\x00'.

In some sense, the Linux abstract namespace is rather
strange from the point of view of C, but not if you
think about it as you would think about Python strings.
Indeed, apart from the requirement that they start
with '\x00', these names have an intrinsic length
which is not related to any embedded '\x00'.  It is
stored together with the name in some kernel
structures, but outside the sun_path array of bytes.

But enough theory: the patch you propose don't pass
its own new test on my machine because of this :-)
Does it pass on yours?

I'm not too concerned about addrlen ending up shorter
than the size of the headers.  That would be a Linux
kernel bug.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 22:01

Message:
Logged In: YES 
user_id=33168

Wow!  Now I see why you wanted review.

Modules/socketmodule.c:

In the first #ifdef linux section (968+), why the calc for
addrlen?  Isn't the len just sizeof(a->sun_path) and that
can be passed to FromStringAndSize()?

In the second #ifdef linux section (1098+), should if (len >
sizeof ...) be >= like the other check?

It's probably easier to show what I mean in code.  Attached
is another patch.  I didn't test it.  There's a big comment
that we should address in either patch about a negative
length issue.


----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2006-04-13 07:31

Message:
Logged In: YES 
user_id=129426

Armin, I don't have access to a Linux machine anymore so I
can't really comment on this issue anymore, sorry.
Also this patch was not made for a specific use case I had,
it was a patch for an open bug filed by someone else (bug
764437).
Previous discussion can be found there.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-13 05:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-12 21:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 06:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 05:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 03:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 12:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 08:33:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Apr 2006 23:33:04 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FW6FM-0000fp-Kk@sc8-sf-web4-b.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 10:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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: Accepted
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Armin Rigo (arigo)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-18 23:33

Message:
Logged In: YES 
user_id=33168

Damn, I wasn't finished.  I uploaded a new patch.  The only
difference is that I added 2 test cases.  I ran this under
valgrind and there were no errors.  I was concerned about
the boundaries, particularly given how poor the man page is.

Are anonymous namespaces supported on other platforms?

I'm fine with this going in, but it needs an update to
Misc/NEWS and Doc/lib/libsocket.tex.  Hmmm, there's nothing
remotely close in the doc currently about AF_UNIX.  I'll
leave it to your best judgment Armin.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-18 23:29

Message:
Logged In: YES 
user_id=33168

I guess I really need to test this on my box.  I don't know
if the man page is correct or if I'm reading it correct. 
BTW what linux are you running (kernel version/distro)?  I'm
2.6.8-gentoo-r4.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-18 04:52

Message:
Logged In: YES 
user_id=4771

The man page is indeed confusing.  I was relying on
small experiments.  On my Linux box at least, the
address does not have to occupy the whole of the
sun_path array.  You can really do the following:
set sun_path to '\x00!\x00\x00\x00\x00\x00\x00...'
then call bind() with an addrlen that covers only the
first two characters '\x00!', and then call bind() on
another socket with the same sun_path but an addrlen
that covers the first three characters '\x00!\x00'.
The two addresses don't conflict and are regarded as
different.

Conversely, if I try to bind() two sockets with the
same addrlen and a sun_path that differs after the
number of bytes included in the addrlen, I get an
"Address already in use", thus showing that addrlen
is really meaningful.

Another hint is that if you let the system pick a
default local address for your socket, as e.g. is done
by s=socket(AF_UNIX); s.connect(...), then getsockname()
will return a name that looks like '\x00000003'.  More
precisely, the addrlen is much shorter than the maximum
that would correspond to the whole sun_path array.

A more practical example: it is bogus to ignore the
addrlen and always return the whole sun_path array,
because if we did that, then the following kind of code
would fail:

  >>> s1 = socket(AF_UNIX); s2 = socket(AF_UNIX)
  >>> s1.bind('\x00hello')
  >>> s2.connect(s1.getsockname())

because getsockname() would return a string that is
108 characters long, and the connect would fail.
(Just try it out!  It gives 'Connection refused'.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-17 22:42

Message:
Logged In: YES 
user_id=33168

My man page (man 7 unix) says:

sun_family  always contains AF_UNIX.  sun_path contains the
zero-terminated pathname of the socket in the file system. 
 If  sun_path  starts with  a zero byte it refers to the
abstract namespace maintained by the Unix protocol module. 
The socket's address in this namespace is  given by  the
rest of the bytes in sun_path.  Note that names in the
abstract namespace are not zero-terminated.

I read that (rest of the bytes in sun_path) to mean that if
the first byte is NUL, the address is all the remaining
bytes in sun_path (ie, sun_path is treated as binary).  Also
since the abstract namespace is not NUL-terminated.  I don't
know if the man page is correct.  Do you understand the
manpage the way I do?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-14 01:33

Message:
Logged In: YES 
user_id=4771

You're missing the point of my patch.  It is to preserve
the originally specified length of the name.  The names
'\x00abc', '\x00abc\x00' and '\x00abc\x00\x00' are all
different for the Linux IP stack, as far as I can tell.
In operations like bind() we specify the length of the
name by setting addrlen to the length of the header
plus the number of bytes actually used in the sun_path
array.  The kernel code remembers this length, and
passes it back in &addrlen to functions like
getsockaddr().  That's why I compute the number of
bytes that are really meaningful as the addrlen minus
the headers, instead of just UNIX_PATH_MAX.

About the second #ifdef, I really meant the > to be >
and not >=, because it is acceptable to pass a name
containing exactly UNIX_PATH_MAX bytes -- the abstract
namespace names don't have to be followed by a
terminating '\x00'.  By contrast, the regular names
must not be longer than UNIX_PATH_MAX-1 characters to
allow for the extra '\x00'.

In some sense, the Linux abstract namespace is rather
strange from the point of view of C, but not if you
think about it as you would think about Python strings.
Indeed, apart from the requirement that they start
with '\x00', these names have an intrinsic length
which is not related to any embedded '\x00'.  It is
stored together with the name in some kernel
structures, but outside the sun_path array of bytes.

But enough theory: the patch you propose don't pass
its own new test on my machine because of this :-)
Does it pass on yours?

I'm not too concerned about addrlen ending up shorter
than the size of the headers.  That would be a Linux
kernel bug.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 22:01

Message:
Logged In: YES 
user_id=33168

Wow!  Now I see why you wanted review.

Modules/socketmodule.c:

In the first #ifdef linux section (968+), why the calc for
addrlen?  Isn't the len just sizeof(a->sun_path) and that
can be passed to FromStringAndSize()?

In the second #ifdef linux section (1098+), should if (len >
sizeof ...) be >= like the other check?

It's probably easier to show what I mean in code.  Attached
is another patch.  I didn't test it.  There's a big comment
that we should address in either patch about a negative
length issue.


----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2006-04-13 07:31

Message:
Logged In: YES 
user_id=129426

Armin, I don't have access to a Linux machine anymore so I
can't really comment on this issue anymore, sorry.
Also this patch was not made for a specific use case I had,
it was a patch for an open bug filed by someone else (bug
764437).
Previous discussion can be found there.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-13 05:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-12 21:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 06:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 05:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 03:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 12:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 11:34:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Apr 2006 02:34:33 -0700
Subject: [Patches] [ python-Patches-1472854 ] rlcompleter to be usable
	without readline
Message-ID: <E1FW94z-0001hb-Oj@sc8-sf-web3.sourceforge.net>

Patches item #1472854, was opened at 2006-04-19 11:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472854&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: rlcompleter to be usable without readline

Initial Comment:
ignores ImportError on readline

the completer's nice core functionality depends not on
readline and is useful standalone. E.g. I like to use
it in projects on Windows.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472854&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 13:51:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Apr 2006 04:51:29 -0700
Subject: [Patches] [ python-Patches-1062014 ] fix for 764437 AF_UNIX socket
	special linux socket names
Message-ID: <E1FWBDV-0002CC-Ua@sc8-sf-web2.sourceforge.net>

Patches item #1062014, was opened at 2004-11-07 18:18
Message generated for change (Settings changed) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&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.5
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Armin Rigo (arigo)
Summary: fix for 764437 AF_UNIX socket special linux socket names

Initial Comment:
The patch addresses two things:
1. the socket name (obtained using getsockname() or
getpeername() ) will now be correct in case of the
special linux socket names (starting with 0 byte)
2. the socket module now has a new constant:
UNIX_PATH_MAX , that can be used to build
correctly-sized path names.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2006-04-19 11:51

Message:
Logged In: YES 
user_id=4771

Checked in as r45560 with a Misc/NEWS entry.
No update to the docs (they basically refer to the
platform's socket documentation for this kind of
details).

I don't know if other platforms support something
similar; the man page documents this extension as
Linux-specific.  I wouldn't worry about it unless
somebody shows up and points to another platform...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 06:33

Message:
Logged In: YES 
user_id=33168

Damn, I wasn't finished.  I uploaded a new patch.  The only
difference is that I added 2 test cases.  I ran this under
valgrind and there were no errors.  I was concerned about
the boundaries, particularly given how poor the man page is.

Are anonymous namespaces supported on other platforms?

I'm fine with this going in, but it needs an update to
Misc/NEWS and Doc/lib/libsocket.tex.  Hmmm, there's nothing
remotely close in the doc currently about AF_UNIX.  I'll
leave it to your best judgment Armin.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 06:29

Message:
Logged In: YES 
user_id=33168

I guess I really need to test this on my box.  I don't know
if the man page is correct or if I'm reading it correct. 
BTW what linux are you running (kernel version/distro)?  I'm
2.6.8-gentoo-r4.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-18 11:52

Message:
Logged In: YES 
user_id=4771

The man page is indeed confusing.  I was relying on
small experiments.  On my Linux box at least, the
address does not have to occupy the whole of the
sun_path array.  You can really do the following:
set sun_path to '\x00!\x00\x00\x00\x00\x00\x00...'
then call bind() with an addrlen that covers only the
first two characters '\x00!', and then call bind() on
another socket with the same sun_path but an addrlen
that covers the first three characters '\x00!\x00'.
The two addresses don't conflict and are regarded as
different.

Conversely, if I try to bind() two sockets with the
same addrlen and a sun_path that differs after the
number of bytes included in the addrlen, I get an
"Address already in use", thus showing that addrlen
is really meaningful.

Another hint is that if you let the system pick a
default local address for your socket, as e.g. is done
by s=socket(AF_UNIX); s.connect(...), then getsockname()
will return a name that looks like '\x00000003'.  More
precisely, the addrlen is much shorter than the maximum
that would correspond to the whole sun_path array.

A more practical example: it is bogus to ignore the
addrlen and always return the whole sun_path array,
because if we did that, then the following kind of code
would fail:

  >>> s1 = socket(AF_UNIX); s2 = socket(AF_UNIX)
  >>> s1.bind('\x00hello')
  >>> s2.connect(s1.getsockname())

because getsockname() would return a string that is
108 characters long, and the connect would fail.
(Just try it out!  It gives 'Connection refused'.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-18 05:42

Message:
Logged In: YES 
user_id=33168

My man page (man 7 unix) says:

sun_family  always contains AF_UNIX.  sun_path contains the
zero-terminated pathname of the socket in the file system. 
 If  sun_path  starts with  a zero byte it refers to the
abstract namespace maintained by the Unix protocol module. 
The socket's address in this namespace is  given by  the
rest of the bytes in sun_path.  Note that names in the
abstract namespace are not zero-terminated.

I read that (rest of the bytes in sun_path) to mean that if
the first byte is NUL, the address is all the remaining
bytes in sun_path (ie, sun_path is treated as binary).  Also
since the abstract namespace is not NUL-terminated.  I don't
know if the man page is correct.  Do you understand the
manpage the way I do?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-14 08:33

Message:
Logged In: YES 
user_id=4771

You're missing the point of my patch.  It is to preserve
the originally specified length of the name.  The names
'\x00abc', '\x00abc\x00' and '\x00abc\x00\x00' are all
different for the Linux IP stack, as far as I can tell.
In operations like bind() we specify the length of the
name by setting addrlen to the length of the header
plus the number of bytes actually used in the sun_path
array.  The kernel code remembers this length, and
passes it back in &addrlen to functions like
getsockaddr().  That's why I compute the number of
bytes that are really meaningful as the addrlen minus
the headers, instead of just UNIX_PATH_MAX.

About the second #ifdef, I really meant the > to be >
and not >=, because it is acceptable to pass a name
containing exactly UNIX_PATH_MAX bytes -- the abstract
namespace names don't have to be followed by a
terminating '\x00'.  By contrast, the regular names
must not be longer than UNIX_PATH_MAX-1 characters to
allow for the extra '\x00'.

In some sense, the Linux abstract namespace is rather
strange from the point of view of C, but not if you
think about it as you would think about Python strings.
Indeed, apart from the requirement that they start
with '\x00', these names have an intrinsic length
which is not related to any embedded '\x00'.  It is
stored together with the name in some kernel
structures, but outside the sun_path array of bytes.

But enough theory: the patch you propose don't pass
its own new test on my machine because of this :-)
Does it pass on yours?

I'm not too concerned about addrlen ending up shorter
than the size of the headers.  That would be a Linux
kernel bug.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-14 05:01

Message:
Logged In: YES 
user_id=33168

Wow!  Now I see why you wanted review.

Modules/socketmodule.c:

In the first #ifdef linux section (968+), why the calc for
addrlen?  Isn't the len just sizeof(a->sun_path) and that
can be passed to FromStringAndSize()?

In the second #ifdef linux section (1098+), should if (len >
sizeof ...) be >= like the other check?

It's probably easier to show what I mean in code.  Attached
is another patch.  I didn't test it.  There's a big comment
that we should address in either patch about a negative
length issue.


----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2006-04-13 14:31

Message:
Logged In: YES 
user_id=129426

Armin, I don't have access to a Linux machine anymore so I
can't really comment on this issue anymore, sorry.
Also this patch was not made for a specific use case I had,
it was a patch for an open bug filed by someone else (bug
764437).
Previous discussion can be found there.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-13 12:10

Message:
Logged In: YES 
user_id=4771

Hi Neal.  Although the patch is small I'd appreciate a
quick review, yes.  Also, Irmen, it would be nice to know
if my solution -- trying to preserve the length of the
addresses -- suits your original use case as well.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-13 04:09

Message:
Logged In: YES 
user_id=33168

Armin, do you want someone to review this?  Is it
small/straightforward enough that it could be checked in? 
Just trying to figure out if there's anything I should do.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 13:19

Message:
Logged In: YES 
user_id=4771

Added "#ifdef linux" in my patch, following the idea from
the original patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-04-12 12:57

Message:
Logged In: YES 
user_id=4771

I have made an independent patch for this, based on another
interpretation of "man 7 unix": all the names in the Linux
abstract namespace don't have to be UNIX_PATH_MAX characters
long; instead, their length is remembered by the system and
available as 'addrlen', which is correctly passed around in
socketmodule.c.

The attached patch allows these special names of any length
to be set and read, and the length is preserved.  It does
not expose UNIX_PATH_MAX because it's not an essential
piece of information.  I've written a small test too.

I don't think the docs need updating for this patch, beyond
a mention in the NEWS file.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-08 11:05

Message:
Logged In: YES 
user_id=129426

Not only does it need a new regression test, but if it is
accepted as-is, the socket module docs need to be updated
too (mention the new constant for use with the special
naming case)

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 20:11

Message:
Logged In: YES 
user_id=469548

As you noted on IRC: this needs a new regression test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062014&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 17:57:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Apr 2006 08:57:38 -0700
Subject: [Patches] [ python-Patches-1471578 ] start testing strings > 2GB
Message-ID: <E1FWF3i-0000Ky-Mm@sc8-sf-web4-b.sourceforge.net>

Patches item #1471578, was opened at 2006-04-17 08:01
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: start testing strings > 2GB

Initial Comment:
Incomplete patch.  Would be great if someone picked
this up and ran with it.  Need to be conservative and
try not to use too much memory in these tests.

Should start with strings and unicode.  Those will be
the most important things to test first.  Then can move
to arrays, mmap and other sequences.  Eventually on to
lists, sets, and dicts.

Right now, I'm sticking this in
Lib/tests/bigmem/test_str.py. 

----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 17:57

Message:
Logged In: YES 
user_id=34209

FWIW, I have a couple of 16Gb AMD64 machines at work, that
I'm preparing to be database servers. As long as they aren't
in production, I'm using them in off-hours to run with these
tests, although I don't know how far I'll get. (On the other
hand, it already found a couple of bugs ;)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 19:00:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Apr 2006 10:00:26 -0700
Subject: [Patches] [ python-Patches-1471578 ] start testing strings > 2GB
Message-ID: <E1FWG2U-0000EC-G2@sc8-sf-web2.sourceforge.net>

Patches item #1471578, was opened at 2006-04-16 23:01
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: start testing strings > 2GB

Initial Comment:
Incomplete patch.  Would be great if someone picked
this up and ran with it.  Need to be conservative and
try not to use too much memory in these tests.

Should start with strings and unicode.  Those will be
the most important things to test first.  Then can move
to arrays, mmap and other sequences.  Eventually on to
lists, sets, and dicts.

Right now, I'm sticking this in
Lib/tests/bigmem/test_str.py. 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 10:00

Message:
Logged In: YES 
user_id=33168

Cool.  I hadn't gotten a chance to run this yet.  In fact, I
never even verified it was syntactically correct. :-) 
Hopefully, this gives others the idea and they can help beef
up the tests.

Thanks for testing it out!

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 08:57

Message:
Logged In: YES 
user_id=34209

FWIW, I have a couple of 16Gb AMD64 machines at work, that
I'm preparing to be database servers. As long as they aren't
in production, I'm using them in off-hours to run with these
tests, although I don't know how far I'll get. (On the other
hand, it already found a couple of bugs ;)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 19:43:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Apr 2006 10:43:06 -0700
Subject: [Patches] [ python-Patches-1473132 ] Improve docs for tp_clear and
	tp_traverse
Message-ID: <E1FWGhm-0000QR-0l@sc8-sf-web6.sourceforge.net>

Patches item #1473132, was opened at 2006-04-19 13:43
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=1473132&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve docs for tp_clear and tp_traverse

Initial Comment:
The attached patch greatly enhances the documentation
for the tp_clear and tp_traverse functions. The patch
is against Doc/api/newtypes.tex, r45562.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473132&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 22:00:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Apr 2006 13:00:36 -0700
Subject: [Patches] [ python-Patches-1471578 ] start testing strings > 2GB
Message-ID: <E1FWIqq-0002Lr-51@sc8-sf-web6.sourceforge.net>

Patches item #1471578, was opened at 2006-04-17 08:01
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: start testing strings > 2GB

Initial Comment:
Incomplete patch.  Would be great if someone picked
this up and ran with it.  Need to be conservative and
try not to use too much memory in these tests.

Should start with strings and unicode.  Those will be
the most important things to test first.  Then can move
to arrays, mmap and other sequences.  Eventually on to
lists, sets, and dicts.

Right now, I'm sticking this in
Lib/tests/bigmem/test_str.py. 

----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 22:00

Message:
Logged In: YES 
user_id=34209

It was syntactically correct, but many of the tests were
broken ;) Here's an updated version. I arranged it so
there's a 1K test version for easy debugging of tests, as
well as the 2GB and 4GB versions. There's still tests to be
added, but I'm bored with it now. (Python trunk on my
debian-amd64 box ran the 1K and 2GB versions without any new
issues, the 4GB one is still chugging away.)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 19:00

Message:
Logged In: YES 
user_id=33168

Cool.  I hadn't gotten a chance to run this yet.  In fact, I
never even verified it was syntactically correct. :-) 
Hopefully, this gives others the idea and they can help beef
up the tests.

Thanks for testing it out!

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 17:57

Message:
Logged In: YES 
user_id=34209

FWIW, I have a couple of 16Gb AMD64 machines at work, that
I'm preparing to be database servers. As long as they aren't
in production, I'm using them in off-hours to run with these
tests, although I don't know how far I'll get. (On the other
hand, it already found a couple of bugs ;)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&group_id=5470

From noreply at sourceforge.net  Wed Apr 19 23:39:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Apr 2006 14:39:28 -0700
Subject: [Patches] [ python-Patches-1473257 ] Add a gi_code attr to
	generators
Message-ID: <E1FWKOW-0001IF-MX@sc8-sf-web6.sourceforge.net>

Patches item #1473257, was opened at 2006-04-19 17:39
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=1473257&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
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add a gi_code attr to generators

Initial Comment:
In the test suite for one of my packages, I've used
something like gen.gi_frame.f_code.co_name to help make
human-readable assertions about when certain generators
are run deep inside the application. This was possible
because Python 2.4 guaranteed that gi_frame was always
a frame instance, even after the generator exhausted
itself. In Python 2.5, however, gi_frame is None when
the generator has run till exhaustion, meaning that I
can't always get to f_code.co_name.

I'd like to add a gi_code attribute to generators that
would allow users to access the code object behind the
generator, even when gi_frame is None. This attribute
would be read-only and would follow this rule:

>>> def f():
...     yield 5
...
>>> g = f()
>>> g.gi_code is f.func_code
True
>>>

The attached patch (against r45570) implements the
proposed attribute (in Include/genobject.h and
Objects/genobject.c) and adds test cases to
Lib/test/test_generators.py for this attribute.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&group_id=5470

From noreply at sourceforge.net  Thu Apr 20 13:17:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 04:17:04 -0700
Subject: [Patches] [ python-Patches-1429539 ] pdb: fix for 1326406 (import
	__main__ pdb failure)
Message-ID: <E1FWX9k-00039f-SN@sc8-sf-web5.sourceforge.net>

Patches item #1429539, was opened at 2006-02-11 03:34
Message generated for change (Comment added) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&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
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb: fix for  1326406 (import  __main__ pdb failure)

Initial Comment:
The patch allows pdb to debug program which 
import from __main__


----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-20 11:17

Message:
Logged In: YES 
user_id=1491175

I think that exposing pdb's namespaces for debugged code is
dangerous.When debugged code have this kind of access he can
dynamic change pdb's behaviour without your control:

y.py:
die = """\
def destroy(x,y):
        print 'Iam crashing your HOME and deleting your FILES'

Pdb.__dict__['do_break'] = destroy # pdb's break = destroy
"""
x.py:
# innocently looking code;)
import y
exec(y.puff)
print "X"

with your patch:
$ python2.5 -m pdb x.py
> /home/xyz/python/x.py(1)<module>()
-> import y
(Pdb) Pdb.__dict__['do_break']
<function do_break at 0xb7cafdf4>
(Pdb) break
(Pdb) n
> /home/xyz/python/x.py(2)<module>()
-> exec(y.puff)
(Pdb) n
> /home/xyz/python/x.py(3)<module>()
-> print "X"
(Pdb) Pdb.__dict__['do_break']
<function destroy at 0xb7cb81b4>
(Pdb) break
Iam crashing your HOME and deleting your FILES

I think that this patch can't be accepted due to above
reason.According to my advanced reaserch;) ( find Lib/ -name
'*.py' -exec grep 'from __main__ import' {} -ls \; ) 'from
__main__' is rare case so maybe it will be reasonable to
simply handle ImportError and print something like
'** 'from __main__ import' not supported' message.What do  
you think?       
  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&group_id=5470

From noreply at sourceforge.net  Thu Apr 20 20:24:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 11:24:42 -0700
Subject: [Patches] [ python-Patches-1470504 ] partially fix test_class in
	p3yk
Message-ID: <E1FWdpa-0006QS-GS@sc8-sf-web1.sourceforge.net>

Patches item #1470504, was opened at 2006-04-14 15:27
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470504&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: partially fix test_class in p3yk

Initial Comment:
Partially fix test_class in p3yk. This allows the test
to be actually run, although it could also be solved by
allowing 'exec' to receive any dict-like object
(there's a patch for that elsewhere, slated for 2.5, I
believe, but dictproxy objects would have to grow
setitem support for it to work.) Me, I prefer setattr()
like this over mucking with __dict__, although I have
to admit it did find a potential bug :) (The issue is
that class.__dict__ is a dictproxy object, if class is
a newstyle class.)

There are, however, more problems with test_class that
this doesn't resolve:

 - Classic classes that have a __cmp__ or __eq__
method, but no __hash__ method, are unhashable. The
same is not true for new-style classes. I'm not sure
whether that's a bug in new-style classes, or
desireable behaviour.

 - The recursive-__call__ test (where Ainst.__call__ ==
Ainst, so the hunt for the actual code to run is
recursive) crashes Python on my machine. The test
doesn't crash for classic classes. It seems to be a
stack overflow, or some other memory corruption scheme,
but I'll have to find me a machine with less address
space and memory to more comfortly debug this (talk
about a luxury problem!)

 - __coerce__ isn't being called. I don't recall
whether that's a newstyle-class issue, or a py3k
decision, or a bug. If it isn't a bug, output just has
to be regenerated.

 - Output has to be regenerated to pick up __truediv__
and __rtruediv__ instead of __div__ and __rdiv__.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-04-20 14:24

Message:
Logged In: YES 
user_id=764593

It was correct not to call coerce.

According to the documentation in abstract.c just above 
binary_op1 and ternary_op, coerce is not called unless at 
least one of the objects is old-style.

Should coerce therefore also be removed from builtins?


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 05:19

Message:
Logged In: YES 
user_id=34209

Checked in this fix, still leaves the other issues open.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470504&group_id=5470

From noreply at sourceforge.net  Thu Apr 20 22:44:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 13:44:49 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FWg1B-0004u1-Av@sc8-sf-web6.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21:49
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&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: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-20 22:44

Message:
Logged In: YES 
user_id=21627

The patch is fine(*). Please do add a comment to the time
implementation to elaborate on the story of return values,
and why falling back should not be done (it ought not be
necessary, on systems where it is necessary, it might not
help, and it will hurt the OSX port).

One more bit on return values: gettimeofday can indeed fail
on Linux, and also when there is a TZ problem. OTOH, ftime
is implemented on top of gettimeofday (sic), and will then
fail for the same reason. I haven't looked at the time
implementation.

If you want to be really cautious, you could return 0.0 in
case the functions fail. The only caller of floattime will
then raise an IOError.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:29

Message:
Logged In: YES 
user_id=580910

Version 3 solves the ftime issue the other (IMO more correct) way: it ignores the 
returnvalue of gettimeofday and conditionalizes the floattime code in such way 
that either gettimeofday or ftime is used, but never both.

 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:27

Message:
Logged In: YES 
user_id=580910

Good points. I was clearing errors because it seemed better to ignore errors. 
But you're right, if this does fail somethings is seriously wrong. I've replaced 
error-checking by return statements (but have not replaced the patch).

The change to time is interesting, I added those changes because the binary 
wouldn't run without the patch, without realizing that configure/timemodule 
is picking up the wrong function for finding the current time.  That seems to 
be caused by a bug in the preprocessor code that selects the right section of 
code. OSX 10.4 has both gettimeofday and ftime, and with the current set of 
#if statements this means both the gettimeofday and ftime blocks get 
compiled in. The ftime-bit is dead code, but present nonetheless.

I tried to rearange the #if-statements to make sure just one block gets 
included, but then get compiler warnings because floattime checks for an 
error-return of gettimeofday.  IMHO the error-return check is rather lame, 
the only reason this could fail is when the first argument of gettimeofday is 
invalid (and SUS says this function will always return 0, although manpage on 
darwin and linux claim otherwise), And time(2) can also return -1 to indicate 
failure ;-)

If uploaded a new patch (version 2) that removes error clearing for the DelAttr 
calls in posixmodule and chickens out on the ftime issue by #undef-ing 
HAVE_FTIME for OSX systems that HAVE_GETTIMEOFDAY.

SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/
gettimeofday.html

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:18

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. I wonder why you are clearing
the errors from PyObject_DelAttrString, though: There
shouldn't be any errors (right?), so if that fails,
something is seriously wrong.

As for the time changes: are you saying OSX doesn't have
gettimeofday? I can find a manual page on

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/gettimeofday.2.html

This has higher resolution than ftime, and also takes higher
precedence in timemodule.c: Why is it not used?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 21:50

Message:
Logged In: YES 
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Thu Apr 20 22:46:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 13:46:40 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FWg2y-00040Y-6s@sc8-sf-web3.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21:49
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&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: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-20 22:44

Message:
Logged In: YES 
user_id=21627

The patch is fine(*). Please do add a comment to the time
implementation to elaborate on the story of return values,
and why falling back should not be done (it ought not be
necessary, on systems where it is necessary, it might not
help, and it will hurt the OSX port).

One more bit on return values: gettimeofday can indeed fail
on Linux, and also when there is a TZ problem. OTOH, ftime
is implemented on top of gettimeofday (sic), and will then
fail for the same reason. I haven't looked at the time
implementation.

If you want to be really cautious, you could return 0.0 in
case the functions fail. The only caller of floattime will
then raise an IOError.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:29

Message:
Logged In: YES 
user_id=580910

Version 3 solves the ftime issue the other (IMO more correct) way: it ignores the 
returnvalue of gettimeofday and conditionalizes the floattime code in such way 
that either gettimeofday or ftime is used, but never both.

 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:27

Message:
Logged In: YES 
user_id=580910

Good points. I was clearing errors because it seemed better to ignore errors. 
But you're right, if this does fail somethings is seriously wrong. I've replaced 
error-checking by return statements (but have not replaced the patch).

The change to time is interesting, I added those changes because the binary 
wouldn't run without the patch, without realizing that configure/timemodule 
is picking up the wrong function for finding the current time.  That seems to 
be caused by a bug in the preprocessor code that selects the right section of 
code. OSX 10.4 has both gettimeofday and ftime, and with the current set of 
#if statements this means both the gettimeofday and ftime blocks get 
compiled in. The ftime-bit is dead code, but present nonetheless.

I tried to rearange the #if-statements to make sure just one block gets 
included, but then get compiler warnings because floattime checks for an 
error-return of gettimeofday.  IMHO the error-return check is rather lame, 
the only reason this could fail is when the first argument of gettimeofday is 
invalid (and SUS says this function will always return 0, although manpage on 
darwin and linux claim otherwise), And time(2) can also return -1 to indicate 
failure ;-)

If uploaded a new patch (version 2) that removes error clearing for the DelAttr 
calls in posixmodule and chickens out on the ftime issue by #undef-ing 
HAVE_FTIME for OSX systems that HAVE_GETTIMEOFDAY.

SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/
gettimeofday.html

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:18

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. I wonder why you are clearing
the errors from PyObject_DelAttrString, though: There
shouldn't be any errors (right?), so if that fails,
something is seriously wrong.

As for the time changes: are you saying OSX doesn't have
gettimeofday? I can find a manual page on

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/gettimeofday.2.html

This has higher resolution than ftime, and also takes higher
precedence in timemodule.c: Why is it not used?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 21:50

Message:
Logged In: YES 
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Thu Apr 20 22:50:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 13:50:10 -0700
Subject: [Patches] [ python-Patches-1471761 ] test for broken poll at runtime
Message-ID: <E1FWg6M-0006o6-Si@sc8-sf-web4-b.sourceforge.net>

Patches item #1471761, was opened at 2006-04-17 16:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&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.5
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: test for broken poll at runtime

Initial Comment:
This patch moves the test for a broken poll() implementation from 
configure-time to runtime.

The reason for creating this patch is that we'd like to have one python 
binary for OSX 10.3 and later. OSX 10.3 has a broken version of poll, 
while 10.4 doesn't. With this patch you'll have select.poll when it is 
available and working indepent of the version of the OS where python was 
build.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-20 22:50

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply. When done, please leave the
subversion revision number here, and close the patch.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:46

Message:
Logged In: YES 
user_id=580910

I don't quite understand why runtime testing is considered bad here, although I 
guess the time used by a lot of runtime tests could add up. 

But anyway, broken-poll-at-runtime-2.patch implements your suggestion. 

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:02

Message:
Logged In: YES 
user_id=21627

I'm -1 for this patch in its current form. Python shouldn't
perform "unnecessary" system calls, even if they are as 
cheap as creating a pipe.

It's fine that you want to use the same binary across OSX 
releases; please rewrite the patch to be Mac-specific: 
Always run the configure test for a broken poll, but ignore 
its outcome on OSX. The easiest way to achieve this on top 
of your current patch might be the following:

- #undef HAVE_BROKEN_POLL on OSX in selectmodule.c
- implement select_have_broken_poll to return 0 (i.e. just
the last statement) on anything but OSX.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:46

Message:
Logged In: YES 
user_id=580910

I've uploaded a new version of the patch, and removed the earlier one, because 
the first version also contained an unrelated patch.

Also note that this patch updates configure.in, hence autoconf should be run 
before checking it in.

And finally: the original author of this patch is Bob Ipollito (etrepum), I've 
harvested this from the python24-fat tree.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&group_id=5470

From noreply at sourceforge.net  Thu Apr 20 22:54:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 13:54:45 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FWgAn-0004gY-Pe@sc8-sf-web3.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21:49
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&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: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-20 22:54

Message:
Logged In: YES 
user_id=580910

Thanks for the review. I will apply this patch this weekend, including the 
additional documentation in the time module.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-20 22:44

Message:
Logged In: YES 
user_id=21627

The patch is fine(*). Please do add a comment to the time
implementation to elaborate on the story of return values,
and why falling back should not be done (it ought not be
necessary, on systems where it is necessary, it might not
help, and it will hurt the OSX port).

One more bit on return values: gettimeofday can indeed fail
on Linux, and also when there is a TZ problem. OTOH, ftime
is implemented on top of gettimeofday (sic), and will then
fail for the same reason. I haven't looked at the time
implementation.

If you want to be really cautious, you could return 0.0 in
case the functions fail. The only caller of floattime will
then raise an IOError.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:29

Message:
Logged In: YES 
user_id=580910

Version 3 solves the ftime issue the other (IMO more correct) way: it ignores the 
returnvalue of gettimeofday and conditionalizes the floattime code in such way 
that either gettimeofday or ftime is used, but never both.

 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:27

Message:
Logged In: YES 
user_id=580910

Good points. I was clearing errors because it seemed better to ignore errors. 
But you're right, if this does fail somethings is seriously wrong. I've replaced 
error-checking by return statements (but have not replaced the patch).

The change to time is interesting, I added those changes because the binary 
wouldn't run without the patch, without realizing that configure/timemodule 
is picking up the wrong function for finding the current time.  That seems to 
be caused by a bug in the preprocessor code that selects the right section of 
code. OSX 10.4 has both gettimeofday and ftime, and with the current set of 
#if statements this means both the gettimeofday and ftime blocks get 
compiled in. The ftime-bit is dead code, but present nonetheless.

I tried to rearange the #if-statements to make sure just one block gets 
included, but then get compiler warnings because floattime checks for an 
error-return of gettimeofday.  IMHO the error-return check is rather lame, 
the only reason this could fail is when the first argument of gettimeofday is 
invalid (and SUS says this function will always return 0, although manpage on 
darwin and linux claim otherwise), And time(2) can also return -1 to indicate 
failure ;-)

If uploaded a new patch (version 2) that removes error clearing for the DelAttr 
calls in posixmodule and chickens out on the ftime issue by #undef-ing 
HAVE_FTIME for OSX systems that HAVE_GETTIMEOFDAY.

SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/
gettimeofday.html

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:18

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. I wonder why you are clearing
the errors from PyObject_DelAttrString, though: There
shouldn't be any errors (right?), so if that fails,
something is seriously wrong.

As for the time changes: are you saying OSX doesn't have
gettimeofday? I can find a manual page on

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/gettimeofday.2.html

This has higher resolution than ftime, and also takes higher
precedence in timemodule.c: Why is it not used?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 21:50

Message:
Logged In: YES 
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Fri Apr 21 01:28:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 16:28:10 -0700
Subject: [Patches] [ python-Patches-1470459 ] fix test_exceptions in p3yk
Message-ID: <E1FWiZG-0007di-Ep@sc8-sf-web2.sourceforge.net>

Patches item #1470459, was opened at 2006-04-14 19:15
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470459&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: Fixed
Priority: 5
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fix test_exceptions in p3yk

Initial Comment:
Fixes test_exceptions in p3yk, by making the test
exception inherit from Exception. Also fixes
PyErr_SetObject() to only set proper exceptions
(meaning subclasses of BaseException.) It raises
(somewhat arbitrarily) SystemError when the C API tries
to raise an invalid exception. Added a test for that
behaviour to test_exceptions, too.

----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-21 01:28

Message:
Logged In: YES 
user_id=34209

Checked this in.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470459&group_id=5470

From noreply at sourceforge.net  Fri Apr 21 03:34:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 18:34:19 -0700
Subject: [Patches] [ python-Patches-1100294 ] Log gc times when DEBUG_STATS
	set
Message-ID: <E1FWkXL-0004Qy-HL@sc8-sf-web6.sourceforge.net>

Patches item #1100294, was opened at 2005-01-11 11:11
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100294&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: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Log gc times when DEBUG_STATS set

Initial Comment:
The attached patch adds collection time to the information
the garbage collector prints when DEBUG_STATS is
enabled.  I was more-or-less challenged at work to show
that garbage collection wouldn't cripple our long-running,
high-performance servers at crucial times.  This seemed
the best way to demonstrate that it didn't present a
problem.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-04-20 20:34

Message:
Logged In: YES 
user_id=44345

checked in as rev 45590.


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-04-01 18:45

Message:
Logged In: YES 
user_id=12800

Sorry it's taken so long to review this.  +1.  I say go
ahead and apply it to Py 2.5.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-03-05 22:26

Message:
Logged In: YES 
user_id=12800

Looks pretty good.  I wonder if you should call
PyErr_Clear() when the import or call fails?  Other than
that, +1


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-02-23 20:22

Message:
Logged In: YES 
user_id=44345

Must not have had the box checked.  Thank goodness I almost never
delete files in ~/tmp/...

Skip


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-23 11:01

Message:
Logged In: YES 
user_id=12800

There's no patch here; are you sure you checked the
checkbox?  I'm actually putzing around in gcmodule.c atm to
address some related issues and I'd be willing to review
this patch if you attach it again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100294&group_id=5470

From noreply at sourceforge.net  Fri Apr 21 04:39:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 20 Apr 2006 19:39:42 -0700
Subject: [Patches] [ python-Patches-1429539 ] pdb: fix for 1326406 (import
	__main__ pdb failure)
Message-ID: <E1FWlYc-0001Xp-Dm@sc8-sf-web6.sourceforge.net>

Patches item #1429539, was opened at 2006-02-10 19:34
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&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
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb: fix for  1326406 (import  __main__ pdb failure)

Initial Comment:
The patch allows pdb to debug program which 
import from __main__


----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2006-04-20 19:39

Message:
Logged In: YES 
user_id=971153

I do see your point (In fact it was me who submitted the
patch #896011 which separated pdb namespace from the
program's -- and thus broke imports from __main__ ;-))..

I do want to bring a couple of points:

1. I don't think it matters whether a program can
intentionally interfere with pdb...Even when pdb's namespace
is separated, it's easy for the program to  interfere with
debugger.. (Or delete your home directory for that matter)

2. Importing from __main_ may not be common in the std lib,
but that's simply because stdlib doesn't contain that many
executable hence there are very few places where there is
__main__ to import from. 

google search for "from __main__ import" results in about 1M
hits.


3. Just for the record, profile module does not separate its
 namespace from programs's either...

So, basically, it boils down to this: what's worse breaking
imports from __main__ or risking accidental interference
between pdb and the program (e.g if your program redefines a
help symbol)...

As a middle ground it might be a good idea to expand the
patch to reduce pdb's dependency on module global symbols
and thus reducing the risk of interference.

What do you think?




----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-20 04:17

Message:
Logged In: YES 
user_id=1491175

I think that exposing pdb's namespaces for debugged code is
dangerous.When debugged code have this kind of access he can
dynamic change pdb's behaviour without your control:

y.py:
die = """\
def destroy(x,y):
        print 'Iam crashing your HOME and deleting your FILES'

Pdb.__dict__['do_break'] = destroy # pdb's break = destroy
"""
x.py:
# innocently looking code;)
import y
exec(y.puff)
print "X"

with your patch:
$ python2.5 -m pdb x.py
> /home/xyz/python/x.py(1)<module>()
-> import y
(Pdb) Pdb.__dict__['do_break']
<function do_break at 0xb7cafdf4>
(Pdb) break
(Pdb) n
> /home/xyz/python/x.py(2)<module>()
-> exec(y.puff)
(Pdb) n
> /home/xyz/python/x.py(3)<module>()
-> print "X"
(Pdb) Pdb.__dict__['do_break']
<function destroy at 0xb7cb81b4>
(Pdb) break
Iam crashing your HOME and deleting your FILES

I think that this patch can't be accepted due to above
reason.According to my advanced reaserch;) ( find Lib/ -name
'*.py' -exec grep 'from __main__ import' {} -ls \; ) 'from
__main__' is rare case so maybe it will be reasonable to
simply handle ImportError and print something like
'** 'from __main__ import' not supported' message.What do  
you think?       
  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&group_id=5470

From noreply at sourceforge.net  Fri Apr 21 17:25:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Apr 2006 08:25:12 -0700
Subject: [Patches] [ python-Patches-1429539 ] pdb: fix for 1326406 (import
	__main__ pdb failure)
Message-ID: <E1FWxVQ-0004Zt-BZ@sc8-sf-web1.sourceforge.net>

Patches item #1429539, was opened at 2006-02-10 19:34
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&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
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb: fix for  1326406 (import  __main__ pdb failure)

Initial Comment:
The patch allows pdb to debug program which 
import from __main__


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-04-21 08:25

Message:
Logged In: NO 

1. Could you give some code examples for that?
2,3. Did you notice that google search for "from __main__
import" give hits similar to: 
  t = Timer("test()", "from __main__ import test")
in most situations?
I think it's hard to value uses of "from..." based on google
search or similar method.Maybe we shoud ask on python-list
what are the others opinions?

>As a middle ground it might be a good idea to expand the
>patch to reduce pdb's dependency on module global symbols
I'am interesting how would you do that?
 

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-04-20 19:39

Message:
Logged In: YES 
user_id=971153

I do see your point (In fact it was me who submitted the
patch #896011 which separated pdb namespace from the
program's -- and thus broke imports from __main__ ;-))..

I do want to bring a couple of points:

1. I don't think it matters whether a program can
intentionally interfere with pdb...Even when pdb's namespace
is separated, it's easy for the program to  interfere with
debugger.. (Or delete your home directory for that matter)

2. Importing from __main_ may not be common in the std lib,
but that's simply because stdlib doesn't contain that many
executable hence there are very few places where there is
__main__ to import from. 

google search for "from __main__ import" results in about 1M
hits.


3. Just for the record, profile module does not separate its
 namespace from programs's either...

So, basically, it boils down to this: what's worse breaking
imports from __main__ or risking accidental interference
between pdb and the program (e.g if your program redefines a
help symbol)...

As a middle ground it might be a good idea to expand the
patch to reduce pdb's dependency on module global symbols
and thus reducing the risk of interference.

What do you think?




----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-20 04:17

Message:
Logged In: YES 
user_id=1491175

I think that exposing pdb's namespaces for debugged code is
dangerous.When debugged code have this kind of access he can
dynamic change pdb's behaviour without your control:

y.py:
die = """\
def destroy(x,y):
        print 'Iam crashing your HOME and deleting your FILES'

Pdb.__dict__['do_break'] = destroy # pdb's break = destroy
"""
x.py:
# innocently looking code;)
import y
exec(y.puff)
print "X"

with your patch:
$ python2.5 -m pdb x.py
> /home/xyz/python/x.py(1)<module>()
-> import y
(Pdb) Pdb.__dict__['do_break']
<function do_break at 0xb7cafdf4>
(Pdb) break
(Pdb) n
> /home/xyz/python/x.py(2)<module>()
-> exec(y.puff)
(Pdb) n
> /home/xyz/python/x.py(3)<module>()
-> print "X"
(Pdb) Pdb.__dict__['do_break']
<function destroy at 0xb7cb81b4>
(Pdb) break
Iam crashing your HOME and deleting your FILES

I think that this patch can't be accepted due to above
reason.According to my advanced reaserch;) ( find Lib/ -name
'*.py' -exec grep 'from __main__ import' {} -ls \; ) 'from
__main__' is rare case so maybe it will be reasonable to
simply handle ImportError and print something like
'** 'from __main__ import' not supported' message.What do  
you think?       
  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&group_id=5470

From noreply at sourceforge.net  Fri Apr 21 17:28:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Apr 2006 08:28:16 -0700
Subject: [Patches] [ python-Patches-1429539 ] pdb: fix for 1326406 (import
	__main__ pdb failure)
Message-ID: <E1FWxYO-0004vO-Qi@sc8-sf-web2.sourceforge.net>

Patches item #1429539, was opened at 2006-02-11 03:34
Message generated for change (Comment added) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&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
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb: fix for  1326406 (import  __main__ pdb failure)

Initial Comment:
The patch allows pdb to debug program which 
import from __main__


----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-21 15:28

Message:
Logged In: YES 
user_id=1491175

Sorry I forget to login in;)The comment below is from me.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-04-21 15:25

Message:
Logged In: NO 

1. Could you give some code examples for that?
2,3. Did you notice that google search for "from __main__
import" give hits similar to: 
  t = Timer("test()", "from __main__ import test")
in most situations?
I think it's hard to value uses of "from..." based on google
search or similar method.Maybe we shoud ask on python-list
what are the others opinions?

>As a middle ground it might be a good idea to expand the
>patch to reduce pdb's dependency on module global symbols
I'am interesting how would you do that?
 

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-04-21 02:39

Message:
Logged In: YES 
user_id=971153

I do see your point (In fact it was me who submitted the
patch #896011 which separated pdb namespace from the
program's -- and thus broke imports from __main__ ;-))..

I do want to bring a couple of points:

1. I don't think it matters whether a program can
intentionally interfere with pdb...Even when pdb's namespace
is separated, it's easy for the program to  interfere with
debugger.. (Or delete your home directory for that matter)

2. Importing from __main_ may not be common in the std lib,
but that's simply because stdlib doesn't contain that many
executable hence there are very few places where there is
__main__ to import from. 

google search for "from __main__ import" results in about 1M
hits.


3. Just for the record, profile module does not separate its
 namespace from programs's either...

So, basically, it boils down to this: what's worse breaking
imports from __main__ or risking accidental interference
between pdb and the program (e.g if your program redefines a
help symbol)...

As a middle ground it might be a good idea to expand the
patch to reduce pdb's dependency on module global symbols
and thus reducing the risk of interference.

What do you think?




----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-20 11:17

Message:
Logged In: YES 
user_id=1491175

I think that exposing pdb's namespaces for debugged code is
dangerous.When debugged code have this kind of access he can
dynamic change pdb's behaviour without your control:

y.py:
die = """\
def destroy(x,y):
        print 'Iam crashing your HOME and deleting your FILES'

Pdb.__dict__['do_break'] = destroy # pdb's break = destroy
"""
x.py:
# innocently looking code;)
import y
exec(y.puff)
print "X"

with your patch:
$ python2.5 -m pdb x.py
> /home/xyz/python/x.py(1)<module>()
-> import y
(Pdb) Pdb.__dict__['do_break']
<function do_break at 0xb7cafdf4>
(Pdb) break
(Pdb) n
> /home/xyz/python/x.py(2)<module>()
-> exec(y.puff)
(Pdb) n
> /home/xyz/python/x.py(3)<module>()
-> print "X"
(Pdb) Pdb.__dict__['do_break']
<function destroy at 0xb7cb81b4>
(Pdb) break
Iam crashing your HOME and deleting your FILES

I think that this patch can't be accepted due to above
reason.According to my advanced reaserch;) ( find Lib/ -name
'*.py' -exec grep 'from __main__ import' {} -ls \; ) 'from
__main__' is rare case so maybe it will be reasonable to
simply handle ImportError and print something like
'** 'from __main__ import' not supported' message.What do  
you think?       
  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&group_id=5470

From noreply at sourceforge.net  Sat Apr 22 00:10:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Apr 2006 15:10:57 -0700
Subject: [Patches] [ python-Patches-1474454 ] Allow
	PyArg_ParseTupleAndKeywords to unpack tuples
Message-ID: <E1FX3q5-00019z-SA@sc8-sf-web2.sourceforge.net>

Patches item #1474454, was opened at 2006-04-21 17: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=1474454&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
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow PyArg_ParseTupleAndKeywords to unpack tuples

Initial Comment:
PyArg_ParseTuple will unpack tuples using a format 
string like "i(ii)i", but this is currently disallowed 
when using keywords.  This allows 
PyArg_ParseTupleAndKeywords to behave in the same way.
Diff was done against 2.4.3 release, but code works 
equally well with 2.3.5.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474454&group_id=5470

From noreply at sourceforge.net  Sat Apr 22 07:46:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 21 Apr 2006 22:46:48 -0700
Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime
	tunable
Message-ID: <E1FXAxE-0001Yf-1D@sc8-sf-web4-b.sourceforge.net>

Patches item #1454481, was opened at 2006-03-20 07:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&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
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make thread stack size runtime tunable

Initial Comment:
Platform default thread stack sizes vary considerably.
Some are very generous (Win32: usually 1MB; Linux: 1MB,
sometimes 8MB).  Others are not (FreeBSD: 64k).

Some platforms have restricted virtual address space
OS/2: 512M less overhead) which makes hard coding a
generous default thread stack size problematic.  Some
platforms thread commit stack address space, even
though the memory backing it may not be committed
(Windows, OS/2 at least).

Some applications have a thirst for stack space in
threads (Zope). Some programmers want to be able to use
lots of threads, even in the face of sound advice about
the lack of wisdom in this approach.

The current approach to stack space management in
threads in Python uses a hard coded strategy, relying
on the platform having a useful default or relying on
the system administrator or distribution builder
over-riding the default at compile time.

This patch is intended to allow developers some control
over managing this resource from within Python code by
way of a function in the thread module.  As written, it
is not intended to provide unlimited flexibility; that
would probably require exposing the underlying
mechanism as an option on the creation of each thread.

An alternative approach to providing the functionality
would be to use an environment variable to provide the
information to the thread module.  This has its pros
and cons, in terms of flexibility and ease of use, and
could be complementary to the approach implemented.

The patch has been tested on OS/2 and FreeBSD 4.8.  I
have no means of testing the code on Win32 or Linux,
though Linux is a pthread environment as is FreeBSD. 
Code base is SVN head from a few hours ago. A doc 
update is included.

While I would like to see this functionality in Python
2.5, it is not a critical issue.

Critique of the approach and implementation welcome. 
Something not addressed is the issue of tests,
primarily because I haven't been able to think of a
viable testing strategy - I'm all ears to suggestions
for this.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-04-22 01:46

Message:
Logged In: YES 
user_id=31435

The patch applies cleanly on WinXP, "and works" (I checked
this by setting various stack sizes, spawning a thread doing
nothing but a raw_input(), and looking at the VM size under
Task Manager while the thread was paused waiting for input
-- the VM size went up each time roughly by the stack-size
increase; finally set stack_size to 0 again, and all the
"extra" VM went away).

Note that Python C style for defining functions puts the
function name in the first column.  For example,

"""
static int
_pythread_nt_set_stacksize(size_t size)
"""

instead of

"""
static int _pythread_nt_set_stacksize(size_t size)
"""

The patch isn't consistent about this, and perhaps it's
errenously ;-) aping bad style in surrounding function
definitions.

This should really be exposed via threading.py.  `thread` is
increasingly "just an implementation detail" of `threading`,
and it actually felt weird to me to write a test program
that had to import `thread`.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-14 08:51

Message:
Logged In: YES 
user_id=250749

I have updated the patch along the lines Martin suggested.

I have omitted OS/2 from the list of supported platforms in
the doc patch as I haven't added OS/2 to anywhere else in
the docs.  My thinging has been that OS/2 is a 2nd tier
platform, and I have kept an extensive port README file in
the build directory (PC/os2emx) documenting port specific
behaviour.

The idea with the environment variable version was that it
would be less "intrusive" a change from the user POV.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 11:09

Message:
Logged In: YES 
user_id=21627

re 1) Currently, the usage of the stacksize attribute is
depending on the definition of a THREAD_STACK_SIZE macro. I
don't know where that comes from, but I guess whoever
defines it knows what he is doing, so that the stacksize
attribute is defined on such a system.

re 2) I can accept that Python enforces a minimum above
PTHREAD_STACK_MIN; it shouldn't be possible to set the stack
size below PTHREAD_STACK_MIN, since that *will* fail when a
thread is created.

-1 for an environment variable version. What problem would
that solve? If this patch gets implemented, applications can
define their own environment variables if they think it
helps, and users/admins can put something in
sitecustomize.py if they think there should be an
environment variable controlling the stack size for all
Python applications on the system.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-10 10:45

Message:
Logged In: YES 
user_id=250749

1) wrt _POSIX_THREAD_ATTR_STACKSIZE, I'll look at that
(though I note its absence from the existing code...)

2) PTHREAD_STACK_MIN on FreeBSD is 1k, which seemed grossly
inadequate for Python (my impression is that 20-32k is a
fairly safe minimum for Python).  In principle I don't have
a problem 
with relying on PTHREAD_STACK_MIN, except for trying to play
it safe.  Any further thoughts on this?

I'm also putting together an environment variable only
version of the patch, with a view to getting that in first,
and reworking this patch to work on top of that.

Thanks for the comments.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 09:41

Message:
Logged In: YES 
user_id=21627

Usage of pthread_attr_setstacksize should be conditional on
the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to
POSIX. Errors from pthread_attr_setstacksize should be
reported (POSIX lists EINVAL as a possible error).

I think PTHREAD_STACK_MIN should be considered. 

The documentation should list availibility of the feature,
currently Win32, OS/2, and POSIX threads (with the TSS
option, to be precise). If some platforms have specific
additional requirements on the possible values (eg. must be
a multiple of the page size), these should be documented, as
well.

Apart from that, the patch looks fine.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-03-22 03:28

Message:
Logged In: YES 
user_id=250749

Thanks for the comments.

As implemented, the function is both a getter and
(optionally) a setter which makes attempting to use a
"get"/"set" prefix 
awkward.

I chose this approach to make it a little simpler to support
temporary changes.  I did consider using a module
attribute/variable, but it is slightly more unwieldy for
this case:

old_size = thread.stack_size(new_size)
...
thread.stack_size(old_size)

vs

old_size = thread.stack_size
thread.stack_size = new_size
...
thread.stack_size = old_size

or (using get/set accessors)

old_size = thread.get_stacksize()
thread.set_stacksize(new_size)
...
thread.set_stacksize(old_size)

I think an argument can be made for passing on the
"get"/"set" naming consistency based on the guidelines in
PEP 8.  While I have a preference for what I've implemented,
I'm more interested in getting the functionality in than
debating its decor.  If there's a strong view about these 
issues, I'm prepared to revise the patch accordingly.

I don't believe that the functionality belongs anywhere else
than the thread module, except possibly shadowing it in the
threading module, as it is highly specific to thread
support.  The sys module seems more appropriate for general 
knobs, and only for specific knobs when there is no other
choice IMO.  Doing it outside the thread module also
complicates the implementation, which I was trying to keep
as simple as I could.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-20 08:58

Message:
Logged In: YES 
user_id=55188

I'm all for this!  The FreeBSD port have maintained a local
patch to bump THREAD_STACK_SIZE.  The patch will lighten
FreeBSD users' burden around thread stack size.

BTW, the naming, "thread.stack_size" seems to miss a verb
while all the other functions on the thread module have it.
 How about set_stack_size() or set_stacksize()?  Or, how
about in sys module?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470

From noreply at sourceforge.net  Sat Apr 22 15:13:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Apr 2006 06:13:52 -0700
Subject: [Patches] [ python-Patches-1474454 ] Allow
	PyArg_ParseTupleAndKeywords to unpack tuples
Message-ID: <E1FXHvs-0005rw-NB@sc8-sf-web4-b.sourceforge.net>

Patches item #1474454, was opened at 2006-04-22 00:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474454&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: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow PyArg_ParseTupleAndKeywords to unpack tuples

Initial Comment:
PyArg_ParseTuple will unpack tuples using a format 
string like "i(ii)i", but this is currently disallowed 
when using keywords.  This allows 
PyArg_ParseTupleAndKeywords to behave in the same way.
Diff was done against 2.4.3 release, but code works 
equally well with 2.3.5.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-22 15:13

Message:
Logged In: YES 
user_id=21627

The patch is wrong: It uses strchr to find a "matching"
paren; this does not take into account nested tuples.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474454&group_id=5470

From noreply at sourceforge.net  Sat Apr 22 15:14:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Apr 2006 06:14:41 -0700
Subject: [Patches] [ python-Patches-1474454 ] Allow
	PyArg_ParseTupleAndKeywords to unpack tuples
Message-ID: <E1FXHwf-0007Mw-Ek@sc8-sf-web6.sourceforge.net>

Patches item #1474454, was opened at 2006-04-22 00:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474454&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
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow PyArg_ParseTupleAndKeywords to unpack tuples

Initial Comment:
PyArg_ParseTuple will unpack tuples using a format 
string like "i(ii)i", but this is currently disallowed 
when using keywords.  This allows 
PyArg_ParseTupleAndKeywords to behave in the same way.
Diff was done against 2.4.3 release, but code works 
equally well with 2.3.5.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-22 15:14

Message:
Logged In: YES 
user_id=21627

(Didn't mean to reject it yet)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-22 15:13

Message:
Logged In: YES 
user_id=21627

The patch is wrong: It uses strchr to find a "matching"
paren; this does not take into account nested tuples.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474454&group_id=5470

From noreply at sourceforge.net  Sat Apr 22 15:17:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Apr 2006 06:17:27 -0700
Subject: [Patches] [ python-Patches-1473625 ] cPickle produces
	locale-dependent dumps
Message-ID: <E1FXHzL-0007lF-Ky@sc8-sf-web3.sourceforge.net>

Patches item #1473625, was opened at 2006-04-20 17:25
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473625&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.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle produces locale-dependent dumps

Initial Comment:
Dumping a float with cPickle produces a result which is
locale-dependent.  This causes problems when trying to
load the dump under a different locale (the regular
pickle module is not affected by this bug).  IMHO, the
dump should be locale-independent to ensure
portability. See the attached file for a sample session
log showing the behaviour of both pickle and cPickle
under C and ca_ES.UTF-8 locales (Catalan uses a comma
to separate the integer and decimal part).


----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-04-21 11:42

Message:
Logged In: YES 
user_id=1064183

The problem seems to be in save_float() in the cPickle.c
module.  It uses PyOS_snprintf() to dump floats, but it is
locale-dependent.  Fortunately, the PyOS_ascii_formatd()
function can be used.  The attached patch seems to fix the
problem, and pickling tests run OK.  It would be nice to see
this patch applied to 2.4 also.

(BTW, I meant PEP 331 in the previous comment, not 311, sorry.)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-20 23:54

Message:
Logged In: YES 
user_id=21627

Right, cPickle should use C locale floating point numbers,
using the PEP 331 API. Would you like to investigate a patch?

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-04-20 17:28

Message:
Logged In: YES 
user_id=1064183

As a side note, does this have anything to do with PEP 311?
 http://www.python.org/dev/peps/pep-0331/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473625&group_id=5470

From noreply at sourceforge.net  Sat Apr 22 21:31:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Apr 2006 12:31:53 -0700
Subject: [Patches] [ python-Patches-1474454 ] Allow
	PyArg_ParseTupleAndKeywords to unpack tuples
Message-ID: <E1FXNph-0007Az-Tf@sc8-sf-web5.sourceforge.net>

Patches item #1474454, was opened at 2006-04-21 17:10
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474454&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
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow PyArg_ParseTupleAndKeywords to unpack tuples

Initial Comment:
PyArg_ParseTuple will unpack tuples using a format 
string like "i(ii)i", but this is currently disallowed 
when using keywords.  This allows 
PyArg_ParseTupleAndKeywords to behave in the same way.
Diff was done against 2.4.3 release, but code works 
equally well with 2.3.5.


----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2006-04-22 14:31

Message:
Logged In: YES 
user_id=771074

Attaching patch that handles nested tuples.

However, another option would be to remove all the pre-
validation and just let the conversion functions return any 
format errors.  The max nbr of args could be determined 
from the keyword list instead of the format string, and 
avoid some duplicated logic.
The logic for checking optional args would also need to be
moved, but this could allow a fix for the bad error msg 
that's sometimes thrown.



----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-22 08:14

Message:
Logged In: YES 
user_id=21627

(Didn't mean to reject it yet)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-22 08:13

Message:
Logged In: YES 
user_id=21627

The patch is wrong: It uses strchr to find a "matching"
paren; this does not take into account nested tuples.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474454&group_id=5470

From noreply at sourceforge.net  Sun Apr 23 05:30:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Apr 2006 20:30:48 -0700
Subject: [Patches] [ python-Patches-1473132 ] Improve docs for tp_clear and
	tp_traverse
Message-ID: <E1FXVJA-0005kK-Bd@sc8-sf-web5.sourceforge.net>

Patches item #1473132, was opened at 2006-04-19 13:43
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473132&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve docs for tp_clear and tp_traverse

Initial Comment:
The attached patch greatly enhances the documentation
for the tp_clear and tp_traverse functions. The patch
is against Doc/api/newtypes.tex, r45562.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-04-22 23:30

Message:
Logged In: YES 
user_id=31435

I agree the additional info is helpful (thanks!).

Alas, there's more to it, and it's hard to know when to stop
:-(.

For example, an author of a type may _want_ to visit, e.g.,
contained strings in tp_traverse, because they want
gc.get_referents() to return the contained strings
(typically as a debugging aid).

The issues wrt to tp_clear are subtler.  The real
requirement is that the aggregate of all tp_clears called
break all possible cycles.  For one thing, that means
there's no real reason for a tp_clear to touch a member
that's known to be a Python string or integer (since such an
object can't be in a cycle, clearing it can't help to break
a cycle).  It's only tp_dealloc that _must_ drop references
to all containees.

Subtler is that a gc'ed container type may choose not to
implement tp_clear at all.  If you look, you'll see that
Python's tuple type in fact leaves its tp_clear slot empty.
 This isn't a problem because it's impossible to have a
cycle composed _solely_ of tuples (that may not be obvious,
but it's true -- it derives from that tuples are immutable).
 Any cycle a tuple may be in will be broken if the non-tuple
objects in the cycle clear their containees, so there's no
actually need for tuples to have a tp_clear.

The possibility should be mentioned, although it's fine to
recommend playing it safe.  Indeed, I don't think it buys
anything worth having for tuples not to have an obvious
tp_clear implementation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473132&group_id=5470

From noreply at sourceforge.net  Sun Apr 23 07:35:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Apr 2006 22:35:29 -0700
Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime
	tunable
Message-ID: <E1FXXFp-0001hS-Jm@sc8-sf-web1.sourceforge.net>

Patches item #1454481, was opened at 2006-03-20 23:37
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&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
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make thread stack size runtime tunable

Initial Comment:
Platform default thread stack sizes vary considerably.
Some are very generous (Win32: usually 1MB; Linux: 1MB,
sometimes 8MB).  Others are not (FreeBSD: 64k).

Some platforms have restricted virtual address space
OS/2: 512M less overhead) which makes hard coding a
generous default thread stack size problematic.  Some
platforms thread commit stack address space, even
though the memory backing it may not be committed
(Windows, OS/2 at least).

Some applications have a thirst for stack space in
threads (Zope). Some programmers want to be able to use
lots of threads, even in the face of sound advice about
the lack of wisdom in this approach.

The current approach to stack space management in
threads in Python uses a hard coded strategy, relying
on the platform having a useful default or relying on
the system administrator or distribution builder
over-riding the default at compile time.

This patch is intended to allow developers some control
over managing this resource from within Python code by
way of a function in the thread module.  As written, it
is not intended to provide unlimited flexibility; that
would probably require exposing the underlying
mechanism as an option on the creation of each thread.

An alternative approach to providing the functionality
would be to use an environment variable to provide the
information to the thread module.  This has its pros
and cons, in terms of flexibility and ease of use, and
could be complementary to the approach implemented.

The patch has been tested on OS/2 and FreeBSD 4.8.  I
have no means of testing the code on Win32 or Linux,
though Linux is a pthread environment as is FreeBSD. 
Code base is SVN head from a few hours ago. A doc 
update is included.

While I would like to see this functionality in Python
2.5, it is not a critical issue.

Critique of the approach and implementation welcome. 
Something not addressed is the issue of tests,
primarily because I haven't been able to think of a
viable testing strategy - I'm all ears to suggestions
for this.

----------------------------------------------------------------------

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-23 15:35

Message:
Logged In: YES 
user_id=250749

Thanks Tim.

My default action is to try and match the prevailing style,
but  cut'n'paste propagated the flaw.  thread_pthread.h was
clean AFAICS, so I'll do a style normalisation (as a
separate checkin) on thread_nt.py and thread_os2.h when
commit time comes.

As an "implementation detail", I hadn't considered that
exposing it via threading was appropriate.

I can see 2 approaches:
- a simple shadow of the function as a module level function;
or
- a classmethod of the Thread class.

Any hints on which would be the more preferable or natural
approach?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-22 15:46

Message:
Logged In: YES 
user_id=31435

The patch applies cleanly on WinXP, "and works" (I checked
this by setting various stack sizes, spawning a thread doing
nothing but a raw_input(), and looking at the VM size under
Task Manager while the thread was paused waiting for input
-- the VM size went up each time roughly by the stack-size
increase; finally set stack_size to 0 again, and all the
"extra" VM went away).

Note that Python C style for defining functions puts the
function name in the first column.  For example,

"""
static int
_pythread_nt_set_stacksize(size_t size)
"""

instead of

"""
static int _pythread_nt_set_stacksize(size_t size)
"""

The patch isn't consistent about this, and perhaps it's
errenously ;-) aping bad style in surrounding function
definitions.

This should really be exposed via threading.py.  `thread` is
increasingly "just an implementation detail" of `threading`,
and it actually felt weird to me to write a test program
that had to import `thread`.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-14 22:51

Message:
Logged In: YES 
user_id=250749

I have updated the patch along the lines Martin suggested.

I have omitted OS/2 from the list of supported platforms in
the doc patch as I haven't added OS/2 to anywhere else in
the docs.  My thinging has been that OS/2 is a 2nd tier
platform, and I have kept an extensive port README file in
the build directory (PC/os2emx) documenting port specific
behaviour.

The idea with the environment variable version was that it
would be less "intrusive" a change from the user POV.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-11 01:09

Message:
Logged In: YES 
user_id=21627

re 1) Currently, the usage of the stacksize attribute is
depending on the definition of a THREAD_STACK_SIZE macro. I
don't know where that comes from, but I guess whoever
defines it knows what he is doing, so that the stacksize
attribute is defined on such a system.

re 2) I can accept that Python enforces a minimum above
PTHREAD_STACK_MIN; it shouldn't be possible to set the stack
size below PTHREAD_STACK_MIN, since that *will* fail when a
thread is created.

-1 for an environment variable version. What problem would
that solve? If this patch gets implemented, applications can
define their own environment variables if they think it
helps, and users/admins can put something in
sitecustomize.py if they think there should be an
environment variable controlling the stack size for all
Python applications on the system.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-11 00:45

Message:
Logged In: YES 
user_id=250749

1) wrt _POSIX_THREAD_ATTR_STACKSIZE, I'll look at that
(though I note its absence from the existing code...)

2) PTHREAD_STACK_MIN on FreeBSD is 1k, which seemed grossly
inadequate for Python (my impression is that 20-32k is a
fairly safe minimum for Python).  In principle I don't have
a problem 
with relying on PTHREAD_STACK_MIN, except for trying to play
it safe.  Any further thoughts on this?

I'm also putting together an environment variable only
version of the patch, with a view to getting that in first,
and reworking this patch to work on top of that.

Thanks for the comments.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 23:41

Message:
Logged In: YES 
user_id=21627

Usage of pthread_attr_setstacksize should be conditional on
the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to
POSIX. Errors from pthread_attr_setstacksize should be
reported (POSIX lists EINVAL as a possible error).

I think PTHREAD_STACK_MIN should be considered. 

The documentation should list availibility of the feature,
currently Win32, OS/2, and POSIX threads (with the TSS
option, to be precise). If some platforms have specific
additional requirements on the possible values (eg. must be
a multiple of the page size), these should be documented, as
well.

Apart from that, the patch looks fine.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-03-22 19:28

Message:
Logged In: YES 
user_id=250749

Thanks for the comments.

As implemented, the function is both a getter and
(optionally) a setter which makes attempting to use a
"get"/"set" prefix 
awkward.

I chose this approach to make it a little simpler to support
temporary changes.  I did consider using a module
attribute/variable, but it is slightly more unwieldy for
this case:

old_size = thread.stack_size(new_size)
...
thread.stack_size(old_size)

vs

old_size = thread.stack_size
thread.stack_size = new_size
...
thread.stack_size = old_size

or (using get/set accessors)

old_size = thread.get_stacksize()
thread.set_stacksize(new_size)
...
thread.set_stacksize(old_size)

I think an argument can be made for passing on the
"get"/"set" naming consistency based on the guidelines in
PEP 8.  While I have a preference for what I've implemented,
I'm more interested in getting the functionality in than
debating its decor.  If there's a strong view about these 
issues, I'm prepared to revise the patch accordingly.

I don't believe that the functionality belongs anywhere else
than the thread module, except possibly shadowing it in the
threading module, as it is highly specific to thread
support.  The sys module seems more appropriate for general 
knobs, and only for specific knobs when there is no other
choice IMO.  Doing it outside the thread module also
complicates the implementation, which I was trying to keep
as simple as I could.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-21 00:58

Message:
Logged In: YES 
user_id=55188

I'm all for this!  The FreeBSD port have maintained a local
patch to bump THREAD_STACK_SIZE.  The patch will lighten
FreeBSD users' burden around thread stack size.

BTW, the naming, "thread.stack_size" seems to miss a verb
while all the other functions on the thread module have it.
 How about set_stack_size() or set_stacksize()?  Or, how
about in sys module?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470

From noreply at sourceforge.net  Sun Apr 23 08:18:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 22 Apr 2006 23:18:13 -0700
Subject: [Patches] [ python-Patches-1474907 ] detect %zd format for
	PY_FORMAT_SIZE_T
Message-ID: <E1FXXvB-0005NE-46@sc8-sf-web1.sourceforge.net>

Patches item #1474907, was opened at 2006-04-22 23: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=1474907&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Martin v. L??wis (loewis)
Summary: detect %zd format for PY_FORMAT_SIZE_T

Initial Comment:
The patch modifies configure.in to add PY_FORMAT_SIZE_T
to configure.in (meaning you need to run autoheader on
configure.in) so that if %zd is supported for size_t it
sets PY_FORMAT_SIZE_T to "z", otherwise it goes
undefined and the preprocessor trickery in
Include/pyport.h kicks in.

This fix removes compiler warnings on OS X 10.4.6 with
gcc 4.0.1 thanks to PY_FORMAT_SIZE_T being set to "".

Initially assigned to Martin v. Loewis since he said
this would be good to do and the Py_ssize_t stuff is
his invention.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&group_id=5470

From noreply at sourceforge.net  Sun Apr 23 13:59:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Apr 2006 04:59:52 -0700
Subject: [Patches] [ python-Patches-1471925 ] Weak linking support for OSX
Message-ID: <E1FXdFo-00044v-VR@sc8-sf-web2.sourceforge.net>

Patches item #1471925, was opened at 2006-04-17 21:49
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&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: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Weak linking support for OSX

Initial Comment:
The "itch" that is scratched by this patch is the wish to be able to use a 
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the 
same time the binary should offer full access to OSX 10.4 API's when 
running on that system.

This patch weakly links a number of functions in the posix, time and 
socket modules.

I'm not quite happy with code duplication in the time and socket modules, 
but don't quite know how to fix that.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-23 13:59

Message:
Logged In: YES 
user_id=580910

I've checked in weaklinking-2.patch with a better comment. This is the version 
that #undefs HAVE_FTIME on OSX. I've checked in this version instead of the 
newer one because a comment in floattime claims that gettimeofday does 
actually fail on some platforms.

Checked in as revision 45660

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-20 22:54

Message:
Logged In: YES 
user_id=580910

Thanks for the review. I will apply this patch this weekend, including the 
additional documentation in the time module.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-20 22:44

Message:
Logged In: YES 
user_id=21627

The patch is fine(*). Please do add a comment to the time
implementation to elaborate on the story of return values,
and why falling back should not be done (it ought not be
necessary, on systems where it is necessary, it might not
help, and it will hurt the OSX port).

One more bit on return values: gettimeofday can indeed fail
on Linux, and also when there is a TZ problem. OTOH, ftime
is implemented on top of gettimeofday (sic), and will then
fail for the same reason. I haven't looked at the time
implementation.

If you want to be really cautious, you could return 0.0 in
case the functions fail. The only caller of floattime will
then raise an IOError.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:29

Message:
Logged In: YES 
user_id=580910

Version 3 solves the ftime issue the other (IMO more correct) way: it ignores the 
returnvalue of gettimeofday and conditionalizes the floattime code in such way 
that either gettimeofday or ftime is used, but never both.

 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:27

Message:
Logged In: YES 
user_id=580910

Good points. I was clearing errors because it seemed better to ignore errors. 
But you're right, if this does fail somethings is seriously wrong. I've replaced 
error-checking by return statements (but have not replaced the patch).

The change to time is interesting, I added those changes because the binary 
wouldn't run without the patch, without realizing that configure/timemodule 
is picking up the wrong function for finding the current time.  That seems to 
be caused by a bug in the preprocessor code that selects the right section of 
code. OSX 10.4 has both gettimeofday and ftime, and with the current set of 
#if statements this means both the gettimeofday and ftime blocks get 
compiled in. The ftime-bit is dead code, but present nonetheless.

I tried to rearange the #if-statements to make sure just one block gets 
included, but then get compiler warnings because floattime checks for an 
error-return of gettimeofday.  IMHO the error-return check is rather lame, 
the only reason this could fail is when the first argument of gettimeofday is 
invalid (and SUS says this function will always return 0, although manpage on 
darwin and linux claim otherwise), And time(2) can also return -1 to indicate 
failure ;-)

If uploaded a new patch (version 2) that removes error clearing for the DelAttr 
calls in posixmodule and chickens out on the ftime issue by #undef-ing 
HAVE_FTIME for OSX systems that HAVE_GETTIMEOFDAY.

SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/
gettimeofday.html

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:18

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. I wonder why you are clearing
the errors from PyObject_DelAttrString, though: There
shouldn't be any errors (right?), so if that fails,
something is seriously wrong.

As for the time changes: are you saying OSX doesn't have
gettimeofday? I can find a manual page on

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/gettimeofday.2.html

This has higher resolution than ftime, and also takes higher
precedence in timemodule.c: Why is it not used?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 21:50

Message:
Logged In: YES 
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471925&group_id=5470

From noreply at sourceforge.net  Sun Apr 23 14:36:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Apr 2006 05:36:45 -0700
Subject: [Patches] [ python-Patches-1471761 ] test for broken poll at runtime
Message-ID: <E1FXdpV-0007kj-5O@sc8-sf-web5.sourceforge.net>

Patches item #1471761, was opened at 2006-04-17 16:25
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&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.5
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: test for broken poll at runtime

Initial Comment:
This patch moves the test for a broken poll() implementation from 
configure-time to runtime.

The reason for creating this patch is that we'd like to have one python 
binary for OSX 10.3 and later. OSX 10.3 has a broken version of poll, 
while 10.4 doesn't. With this patch you'll have select.poll when it is 
available and working indepent of the version of the OS where python was 
build.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-23 14:36

Message:
Logged In: YES 
user_id=580910

Commited as revision 45661

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-20 22:50

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply. When done, please leave the
subversion revision number here, and close the patch.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:46

Message:
Logged In: YES 
user_id=580910

I don't quite understand why runtime testing is considered bad here, although I 
guess the time used by a lot of runtime tests could add up. 

But anyway, broken-poll-at-runtime-2.patch implements your suggestion. 

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-18 00:02

Message:
Logged In: YES 
user_id=21627

I'm -1 for this patch in its current form. Python shouldn't
perform "unnecessary" system calls, even if they are as 
cheap as creating a pipe.

It's fine that you want to use the same binary across OSX 
releases; please rewrite the patch to be Mac-specific: 
Always run the configure test for a broken poll, but ignore 
its outcome on OSX. The easiest way to achieve this on top 
of your current patch might be the following:

- #undef HAVE_BROKEN_POLL on OSX in selectmodule.c
- implement select_have_broken_poll to return 0 (i.e. just
the last statement) on anything but OSX.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:46

Message:
Logged In: YES 
user_id=580910

I've uploaded a new version of the patch, and removed the earlier one, because 
the first version also contained an unrelated patch.

Also note that this patch updates configure.in, hence autoconf should be run 
before checking it in.

And finally: the original author of this patch is Bob Ipollito (etrepum), I've 
harvested this from the python24-fat tree.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471761&group_id=5470

From noreply at sourceforge.net  Sun Apr 23 20:10:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Apr 2006 11:10:53 -0700
Subject: [Patches] [ python-Patches-1429539 ] pdb: fix for 1326406 (import
	__main__ pdb failure)
Message-ID: <E1FXj2r-00057z-Li@sc8-sf-web6.sourceforge.net>

Patches item #1429539, was opened at 2006-02-10 19:34
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&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
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb: fix for  1326406 (import  __main__ pdb failure)

Initial Comment:
The patch allows pdb to debug program which 
import from __main__


----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2006-04-23 11:10

Message:
Logged In: YES 
user_id=971153

> 1. Could you give some code examples for that?

Do you mean examples of intentional interference with
debugger? Well, you could just traverse the stack and check
whether the program runs under debugger and then do anything
you want... But why do you think intentional interference
would ever be an issue? After all python is not a language
to write debugger-resistant applications ;-) 

Anyway, here are some examples of unintentional interference:

1. If you need a custom version of std module, you can
modify sys.path and then import the module.. Which works by
itself. But if pdb is loaded first and imports the module,
then it does not work...

2. Similar problem with any application which changes
sys.stdout/sys.stdin (there is actually a SF bug for that)

3.  Also I don't see how pdb in its current form can control
any program which needs a full-screen control of the terminal...

4. Any program which tries to do any magic with stack and
assumes that top level stack frame is the main application
will not work under pdb (where top level stack frame is pdb)

---------------------------------------------------
And there is a whole separate bunch of intereference issues
when pdb restarts the program.

---------------------------------------------------

When a program does run in pdb's namespace (as would be the
case if this patch is applied), pdb could save copies of all
module global symbols which it needs and thus become immune
to the accidental overwriting of those symbols in the main
program...

There could be a better way...



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-21 08:28

Message:
Logged In: YES 
user_id=1491175

Sorry I forget to login in;)The comment below is from me.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-04-21 08:25

Message:
Logged In: NO 

1. Could you give some code examples for that?
2,3. Did you notice that google search for "from __main__
import" give hits similar to: 
  t = Timer("test()", "from __main__ import test")
in most situations?
I think it's hard to value uses of "from..." based on google
search or similar method.Maybe we shoud ask on python-list
what are the others opinions?

>As a middle ground it might be a good idea to expand the
>patch to reduce pdb's dependency on module global symbols
I'am interesting how would you do that?
 

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-04-20 19:39

Message:
Logged In: YES 
user_id=971153

I do see your point (In fact it was me who submitted the
patch #896011 which separated pdb namespace from the
program's -- and thus broke imports from __main__ ;-))..

I do want to bring a couple of points:

1. I don't think it matters whether a program can
intentionally interfere with pdb...Even when pdb's namespace
is separated, it's easy for the program to  interfere with
debugger.. (Or delete your home directory for that matter)

2. Importing from __main_ may not be common in the std lib,
but that's simply because stdlib doesn't contain that many
executable hence there are very few places where there is
__main__ to import from. 

google search for "from __main__ import" results in about 1M
hits.


3. Just for the record, profile module does not separate its
 namespace from programs's either...

So, basically, it boils down to this: what's worse breaking
imports from __main__ or risking accidental interference
between pdb and the program (e.g if your program redefines a
help symbol)...

As a middle ground it might be a good idea to expand the
patch to reduce pdb's dependency on module global symbols
and thus reducing the risk of interference.

What do you think?




----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-20 04:17

Message:
Logged In: YES 
user_id=1491175

I think that exposing pdb's namespaces for debugged code is
dangerous.When debugged code have this kind of access he can
dynamic change pdb's behaviour without your control:

y.py:
die = """\
def destroy(x,y):
        print 'Iam crashing your HOME and deleting your FILES'

Pdb.__dict__['do_break'] = destroy # pdb's break = destroy
"""
x.py:
# innocently looking code;)
import y
exec(y.puff)
print "X"

with your patch:
$ python2.5 -m pdb x.py
> /home/xyz/python/x.py(1)<module>()
-> import y
(Pdb) Pdb.__dict__['do_break']
<function do_break at 0xb7cafdf4>
(Pdb) break
(Pdb) n
> /home/xyz/python/x.py(2)<module>()
-> exec(y.puff)
(Pdb) n
> /home/xyz/python/x.py(3)<module>()
-> print "X"
(Pdb) Pdb.__dict__['do_break']
<function destroy at 0xb7cb81b4>
(Pdb) break
Iam crashing your HOME and deleting your FILES

I think that this patch can't be accepted due to above
reason.According to my advanced reaserch;) ( find Lib/ -name
'*.py' -exec grep 'from __main__ import' {} -ls \; ) 'from
__main__' is rare case so maybe it will be reasonable to
simply handle ImportError and print something like
'** 'from __main__ import' not supported' message.What do  
you think?       
  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&group_id=5470

From noreply at sourceforge.net  Sun Apr 23 22:25:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Apr 2006 13:25:33 -0700
Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime
	tunable
Message-ID: <E1FXl9B-0006bl-G5@sc8-sf-web4-b.sourceforge.net>

Patches item #1454481, was opened at 2006-03-20 07:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&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
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make thread stack size runtime tunable

Initial Comment:
Platform default thread stack sizes vary considerably.
Some are very generous (Win32: usually 1MB; Linux: 1MB,
sometimes 8MB).  Others are not (FreeBSD: 64k).

Some platforms have restricted virtual address space
OS/2: 512M less overhead) which makes hard coding a
generous default thread stack size problematic.  Some
platforms thread commit stack address space, even
though the memory backing it may not be committed
(Windows, OS/2 at least).

Some applications have a thirst for stack space in
threads (Zope). Some programmers want to be able to use
lots of threads, even in the face of sound advice about
the lack of wisdom in this approach.

The current approach to stack space management in
threads in Python uses a hard coded strategy, relying
on the platform having a useful default or relying on
the system administrator or distribution builder
over-riding the default at compile time.

This patch is intended to allow developers some control
over managing this resource from within Python code by
way of a function in the thread module.  As written, it
is not intended to provide unlimited flexibility; that
would probably require exposing the underlying
mechanism as an option on the creation of each thread.

An alternative approach to providing the functionality
would be to use an environment variable to provide the
information to the thread module.  This has its pros
and cons, in terms of flexibility and ease of use, and
could be complementary to the approach implemented.

The patch has been tested on OS/2 and FreeBSD 4.8.  I
have no means of testing the code on Win32 or Linux,
though Linux is a pthread environment as is FreeBSD. 
Code base is SVN head from a few hours ago. A doc 
update is included.

While I would like to see this functionality in Python
2.5, it is not a critical issue.

Critique of the approach and implementation welcome. 
Something not addressed is the issue of tests,
primarily because I haven't been able to think of a
viable testing strategy - I'm all ears to suggestions
for this.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-04-23 16:25

Message:
Logged In: YES 
user_id=31435

Right, this one: "a simple shadow of the function as a
module level function".  If it affects all threads (which it
does), then a module function is a natural place for it.  If
I a saw a method on the Thread class, the most natural (to
me ;-)) assumption is that a_thread.stack_size(N) would set
the stack size for the specific thread `a_thread`, but not
affect other threads.  Part of what makes that "the most
natural" assumption is that Thread has no class or static
methods today.  As a module-level function, no such
confusion is sanely possible.

Sticking "stack_size" in threading.__all__, and adding

from thread import stack_size

to threading.py is all I'm looking for here.  Well, plus
docs and a test case ;-)

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-23 01:35

Message:
Logged In: YES 
user_id=250749

Thanks Tim.

My default action is to try and match the prevailing style,
but  cut'n'paste propagated the flaw.  thread_pthread.h was
clean AFAICS, so I'll do a style normalisation (as a
separate checkin) on thread_nt.py and thread_os2.h when
commit time comes.

As an "implementation detail", I hadn't considered that
exposing it via threading was appropriate.

I can see 2 approaches:
- a simple shadow of the function as a module level function;
or
- a classmethod of the Thread class.

Any hints on which would be the more preferable or natural
approach?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-22 01:46

Message:
Logged In: YES 
user_id=31435

The patch applies cleanly on WinXP, "and works" (I checked
this by setting various stack sizes, spawning a thread doing
nothing but a raw_input(), and looking at the VM size under
Task Manager while the thread was paused waiting for input
-- the VM size went up each time roughly by the stack-size
increase; finally set stack_size to 0 again, and all the
"extra" VM went away).

Note that Python C style for defining functions puts the
function name in the first column.  For example,

"""
static int
_pythread_nt_set_stacksize(size_t size)
"""

instead of

"""
static int _pythread_nt_set_stacksize(size_t size)
"""

The patch isn't consistent about this, and perhaps it's
errenously ;-) aping bad style in surrounding function
definitions.

This should really be exposed via threading.py.  `thread` is
increasingly "just an implementation detail" of `threading`,
and it actually felt weird to me to write a test program
that had to import `thread`.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-14 08:51

Message:
Logged In: YES 
user_id=250749

I have updated the patch along the lines Martin suggested.

I have omitted OS/2 from the list of supported platforms in
the doc patch as I haven't added OS/2 to anywhere else in
the docs.  My thinging has been that OS/2 is a 2nd tier
platform, and I have kept an extensive port README file in
the build directory (PC/os2emx) documenting port specific
behaviour.

The idea with the environment variable version was that it
would be less "intrusive" a change from the user POV.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 11:09

Message:
Logged In: YES 
user_id=21627

re 1) Currently, the usage of the stacksize attribute is
depending on the definition of a THREAD_STACK_SIZE macro. I
don't know where that comes from, but I guess whoever
defines it knows what he is doing, so that the stacksize
attribute is defined on such a system.

re 2) I can accept that Python enforces a minimum above
PTHREAD_STACK_MIN; it shouldn't be possible to set the stack
size below PTHREAD_STACK_MIN, since that *will* fail when a
thread is created.

-1 for an environment variable version. What problem would
that solve? If this patch gets implemented, applications can
define their own environment variables if they think it
helps, and users/admins can put something in
sitecustomize.py if they think there should be an
environment variable controlling the stack size for all
Python applications on the system.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-10 10:45

Message:
Logged In: YES 
user_id=250749

1) wrt _POSIX_THREAD_ATTR_STACKSIZE, I'll look at that
(though I note its absence from the existing code...)

2) PTHREAD_STACK_MIN on FreeBSD is 1k, which seemed grossly
inadequate for Python (my impression is that 20-32k is a
fairly safe minimum for Python).  In principle I don't have
a problem 
with relying on PTHREAD_STACK_MIN, except for trying to play
it safe.  Any further thoughts on this?

I'm also putting together an environment variable only
version of the patch, with a view to getting that in first,
and reworking this patch to work on top of that.

Thanks for the comments.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 09:41

Message:
Logged In: YES 
user_id=21627

Usage of pthread_attr_setstacksize should be conditional on
the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to
POSIX. Errors from pthread_attr_setstacksize should be
reported (POSIX lists EINVAL as a possible error).

I think PTHREAD_STACK_MIN should be considered. 

The documentation should list availibility of the feature,
currently Win32, OS/2, and POSIX threads (with the TSS
option, to be precise). If some platforms have specific
additional requirements on the possible values (eg. must be
a multiple of the page size), these should be documented, as
well.

Apart from that, the patch looks fine.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-03-22 03:28

Message:
Logged In: YES 
user_id=250749

Thanks for the comments.

As implemented, the function is both a getter and
(optionally) a setter which makes attempting to use a
"get"/"set" prefix 
awkward.

I chose this approach to make it a little simpler to support
temporary changes.  I did consider using a module
attribute/variable, but it is slightly more unwieldy for
this case:

old_size = thread.stack_size(new_size)
...
thread.stack_size(old_size)

vs

old_size = thread.stack_size
thread.stack_size = new_size
...
thread.stack_size = old_size

or (using get/set accessors)

old_size = thread.get_stacksize()
thread.set_stacksize(new_size)
...
thread.set_stacksize(old_size)

I think an argument can be made for passing on the
"get"/"set" naming consistency based on the guidelines in
PEP 8.  While I have a preference for what I've implemented,
I'm more interested in getting the functionality in than
debating its decor.  If there's a strong view about these 
issues, I'm prepared to revise the patch accordingly.

I don't believe that the functionality belongs anywhere else
than the thread module, except possibly shadowing it in the
threading module, as it is highly specific to thread
support.  The sys module seems more appropriate for general 
knobs, and only for specific knobs when there is no other
choice IMO.  Doing it outside the thread module also
complicates the implementation, which I was trying to keep
as simple as I could.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-20 08:58

Message:
Logged In: YES 
user_id=55188

I'm all for this!  The FreeBSD port have maintained a local
patch to bump THREAD_STACK_SIZE.  The patch will lighten
FreeBSD users' burden around thread stack size.

BTW, the naming, "thread.stack_size" seems to miss a verb
while all the other functions on the thread module have it.
 How about set_stack_size() or set_stacksize()?  Or, how
about in sys module?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470

From noreply at sourceforge.net  Mon Apr 24 04:13:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 23 Apr 2006 19:13:22 -0700
Subject: [Patches] [ python-Patches-1475231 ] New doctest option: +SKIP
Message-ID: <E1FXqZm-00076B-Mz@sc8-sf-web4-b.sourceforge.net>

Patches item #1475231, was opened at 2006-04-23 22:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475231&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: Open
Resolution: None
Priority: 5
Submitted By: Edward Loper (edloper)
Assigned to: Tim Peters (tim_one)
Summary: New doctest option: +SKIP

Initial Comment:
Adds a new option & directive to doctest, SKIP, which 
can be used to selectively skip examples.

This can be useful in contexts where doctest examples 
serve as both documentation and test cases, and an 
example should be included for documentation 
purposes, but should not be checked.  E.g., the 
example's output might be random; or the example 
might depend on resources which would be unavailable 
to the test driver.  The SKIP flag can also be used 
for temporarily "commenting out" examples.

Patch includes updates to tests & documentation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475231&group_id=5470

From noreply at sourceforge.net  Mon Apr 24 15:09:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Apr 2006 06:09:39 -0700
Subject: [Patches] [ python-Patches-1475523 ] patch fixing #1448060
	(gettext.py bug)
Message-ID: <E1FY0ot-0004nz-2w@sc8-sf-web2.sourceforge.net>

Patches item #1475523, was opened at 2006-04-24 13: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=1475523&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
Submitted By: Thenault Sylvain (syt)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch fixing #1448060 (gettext.py bug)

Initial Comment:
Here is a patch for the bug described in
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

It follows the latest Martin followup as I understand
it. I'm not sure if multi-lines field handling should
be totally discarded while reading metadata headers (as
implemented), or if it should only be discarded for the
content-type and plural-forms header. If one think this
patch isn't correct, please comment so I can fix it.

Notice that if the second solution was intended, lines
such as 

"#-#-#-#-#  fr.po  #-#-#-#-#\n"

inserted by msgcat/msgmerge will have to be treated
differently (i.e. multi-lines support but skip lines
begining with a #).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&group_id=5470

From noreply at sourceforge.net  Mon Apr 24 15:11:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Apr 2006 06:11:00 -0700
Subject: [Patches] [ python-Patches-1475523 ] patch fixing #1448060
	(gettext.py bug)
Message-ID: <E1FY0qC-0005OY-QW@sc8-sf-web2.sourceforge.net>

Patches item #1475523, was opened at 2006-04-24 13:09
Message generated for change (Settings changed) made by syt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&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: 7
Submitted By: Thenault Sylvain (syt)
>Assigned to: Martin v. L??wis (loewis)
Summary: patch fixing #1448060 (gettext.py bug)

Initial Comment:
Here is a patch for the bug described in
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

It follows the latest Martin followup as I understand
it. I'm not sure if multi-lines field handling should
be totally discarded while reading metadata headers (as
implemented), or if it should only be discarded for the
content-type and plural-forms header. If one think this
patch isn't correct, please comment so I can fix it.

Notice that if the second solution was intended, lines
such as 

"#-#-#-#-#  fr.po  #-#-#-#-#\n"

inserted by msgcat/msgmerge will have to be treated
differently (i.e. multi-lines support but skip lines
begining with a #).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&group_id=5470

From noreply at sourceforge.net  Tue Apr 25 01:12:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Apr 2006 16:12:05 -0700
Subject: [Patches] [ python-Patches-1475845 ] IndentationError for
	unexpected indent
Message-ID: <E1FYADt-0002Py-2I@sc8-sf-web5.sourceforge.net>

Patches item #1475845, was opened at 2006-04-24 13: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=1475845&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Miller (rcmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: IndentationError for unexpected indent

Initial Comment:
This patch raises an IndentationError rather than a
generic "invalid syntax" error for unexpected
indentation.  Code to do this was already in
pythonrun.c:err_input() but was not being reached due
to a failure to pass the INDENT token in the perrdetail
structure.  The patch also adds tests for the 3 kinds
of indentation errors (unexpected indent, no indent
where required, invalid outdent level) to test_syntax.py .


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475845&group_id=5470

From noreply at sourceforge.net  Tue Apr 25 05:32:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Apr 2006 20:32:54 -0700
Subject: [Patches] [ python-Patches-1475231 ] New doctest option: +SKIP
Message-ID: <E1FYEII-0001Oj-8M@sc8-sf-web2.sourceforge.net>

Patches item #1475231, was opened at 2006-04-23 22:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475231&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: Accepted
Priority: 5
Submitted By: Edward Loper (edloper)
>Assigned to: Nobody/Anonymous (nobody)
Summary: New doctest option: +SKIP

Initial Comment:
Adds a new option & directive to doctest, SKIP, which 
can be used to selectively skip examples.

This can be useful in contexts where doctest examples 
serve as both documentation and test cases, and an 
example should be included for documentation 
purposes, but should not be checked.  E.g., the 
example's output might be random; or the example 
might depend on resources which would be unavailable 
to the test driver.  The SKIP flag can also be used 
for temporarily "commenting out" examples.

Patch includes updates to tests & documentation.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-04-24 23:32

Message:
Logged In: YES 
user_id=31435

Many thanks for the thorough patch, Edward!  This was
checked in to the trunk, as revision 45701.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475231&group_id=5470

From noreply at sourceforge.net  Tue Apr 25 08:20:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Apr 2006 23:20:18 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FYGuI-0002K1-8B@sc8-sf-web6.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 08:20

Message:
Logged In: YES 
user_id=580910

Martin,

Do you have time to look at this patch again? I'd like to get this patch in before 
2.5a2.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 22:22

Message:
Logged In: YES 
user_id=580910

I don't know how I managed to do that, but my initial patch misses an 
essential bit in pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

On non-universal builds or builds for other platforms this is equivalent to the 
current version, on the universal build this ensures that pyconfig.h only sets 
WORDS_BIGENDIAN during the creation of PPC binaries.

python-universal-2.patch avoids the empty if-statement in configure.in and 
includes the pyconfig.h.in change I mentioned above. It also adds a test to 
test_capi that checks if sys.byteorder is consistent with WORDS_BIGENDIAN 
(the former isn't derived from the latter).

I haven't changed -current-version because I haven't had time to fully check 
if that would be safe. 

I did verify that --enable-framework and --enable-universalsdk are fully 
indepedent. 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Tue Apr 25 08:21:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Apr 2006 23:21:57 -0700
Subject: [Patches] [ python-Patches-1324770 ] Adding redblack tree to
	collections module
Message-ID: <E1FYGvt-0003AB-G6@sc8-sf-web6.sourceforge.net>

Patches item #1324770, was opened at 2005-10-12 13:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Adding redblack tree to collections module

Initial Comment:
This patch drafts a new type "rbtree" implementing
Redblack Tree for collections module. It's just a
preliminary material for the future discussion and
includes a least working code.

Usage:

[basic list-like tree operations]

>>> from collections import rbtree
>>> r = rbtree()
>>> map(r.insert, [9, 3, 4, 100, 'dalki', 'subak', -51])
[None, None, None, None, None, None, None]
>>> r.values()
[-51, 3, 4, 9, 100, 'dalki', 'subak']
>>> r.remove(100)
>>> r.values()
[-51, 3, 4, 9, 'dalki', 'subak']
>>> r.insert('snisni')
>>> r.values()
[-51, 3, 4, 9, 'dalki', 'snisni', 'subak']
>>> 9 in r
True
>>> 8 in r
False

[labeled nodes operations]

>>> r = rbtree()
>>> r['dalki'] = 5; r['subak'] = 1; r['spam'] = 7
>>> r.values()
[1, 5, 7]
>>> r.keys()
['subak', 'dalki', 'spam']
>>> r['egg'] = 1
>>> r.items()
[('egg', 1), ('dalki', 5), ('spam', 7)]
>>> del r['spam']
>>> r.items()
[('egg', 1), ('dalki', 5)]

[mixed altogether]

>>> r.insert(7)
>>> r.insert(0)
>>> r.items()
[(None, 0), ('egg', 1), ('dalki', 5), (None, 7)]
>>> r['dalki'] = 7
>>> r.items()
[(None, 0), ('egg', 1), ('dalki', 7)]

[heapq-like stuff]

>>> r = rbtree()
>>> map(r.insert, range(20))
[None, None, None, None, None, None, None, None, None,
None, None, None, None, None, None, None, None, None,
None, None]
>>> r.nfirst(3)
[0, 1, 2]
>>> r.nfirst(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> r.nlast(5)
[19, 18, 17, 16, 15]
>>> r.popleft(5)
[0, 1, 2, 3, 4]
>>> r.values()
[5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
>>> r.popright(15)
[19, 18, 17, 16]
>>> r.values()
[5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
>>> r['ham'] = 14
>>> r.poprightitems(14, True)
[(None, 15), ('ham', 14)]

[cmp, key and reverse are also supported]

>>> r = rbtree(key=lambda x: x%10)
>>> map(r.insert, range(30))
[None, None, None, None, None, None, None, None, None,
None, None, None, None, None, None, None, None, None,
None, None, None, None, None, None, None, None, None,
None, None, None]
>>> r.values()
[20, 21, 22, 23, 24, 25, 26, 27, 28, 29]
>>> r['yay'] = 78
>>> r.values()
[20, 21, 22, 23, 24, 25, 26, 27, 78, 29]
>>> r.items()
[(None, 20), (None, 21), (None, 22), (None, 23), (None,
24), (None, 25), (None, 26), (None, 27), ('yay', 78),
(None, 29)]
>>> r.clear()
>>> r.values()
[]
>>> r = rbtree(reverse=True)
>>> map(r.insert, range(10))
[None, None, None, None, None, None, None, None, None,
None]
>>> r.values()
[9, 8, 7, 6, 5, 4, 3, 2, 1, 0]


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-25 08:21

Message:
Logged In: YES 
user_id=21627

This implementation gives me many questions:
- what is the rationale for keeping a separate keys
dictionary? If applications wanted that, couldn't they
maintain a key dictionary themselves? It just seems strange
to rely on hashing inside a rbtree implementation.
- Currently, you need two RichCompare invocations for
insertion/contains. Couldn't that be reduced to just one
comparison if __cmp__ is used?
- for key functions, wouldn't it usually be better to cache
the key?
- shouldn't tp_clear also be implemented?
- this entire code needs many more comments. For example,
why does the forward iterator first follow the right-most
links? I would have expected that it needs to start with the
leftmost node first (and somehow, it does - but why?)

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-19 04:08

Message:
Logged In: YES 
user_id=55188

Updated the patch for the current svn.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-10-16 09:42

Message:
Logged In: YES 
user_id=55188

Added iterator and reverse iterator implementations and
__copy__ method.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2005-10-14 17:55

Message:
Logged In: YES 
user_id=55188

Added a unittest and fixed a bug on initcollection() calling
PyType_Ready(&rbtree_type).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&group_id=5470

From noreply at sourceforge.net  Tue Apr 25 08:38:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 24 Apr 2006 23:38:18 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FYHBi-0006UC-LP@sc8-sf-web2.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-25 08:38

Message:
Logged In: YES 
user_id=21627

Somehow, my last message got lost (I think SF was down, and
I never got back to retype it), sorry.

I disagree that the pyconfig.h.in change has no effect on
other platforms: it will affect any system that either
defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__, e.g. gcc on
Itanium. Not a big problem, since it should be conceptually
correct on all systems where it is defined.

However, the real problem is that you are editing
pyconfig.h.in. This is a generated file, and your change is
lost the next time somebody runs autoheader. Please use
AH_VERBATIM to define the block to be generated for
WORDS_BIGENDIAN.

I can understand that you cannot use sys.byteorder. That
doesn't mean osxconfig.h is required, though: If pyconfig.h
already solves the problem, we should use that, instead of
duplicating it. For example, you could write a
expat_config.h which has

#include <pyconfig.h>
#ifdef WORDS_BIGENDIAN
#define BYTEORDER 4321
#else
#define BYTEORDER 1234
#endif
#define XML_NS 1
#define XML_DTD 1
#define XML_CONTEXT_BYTES 1024

and then just define HAVE_EXPAT_CONFIG_H in setup.py


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 08:20

Message:
Logged In: YES 
user_id=580910

Martin,

Do you have time to look at this patch again? I'd like to get this patch in before 
2.5a2.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 22:22

Message:
Logged In: YES 
user_id=580910

I don't know how I managed to do that, but my initial patch misses an 
essential bit in pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

On non-universal builds or builds for other platforms this is equivalent to the 
current version, on the universal build this ensures that pyconfig.h only sets 
WORDS_BIGENDIAN during the creation of PPC binaries.

python-universal-2.patch avoids the empty if-statement in configure.in and 
includes the pyconfig.h.in change I mentioned above. It also adds a test to 
test_capi that checks if sys.byteorder is consistent with WORDS_BIGENDIAN 
(the former isn't derived from the latter).

I haven't changed -current-version because I haven't had time to fully check 
if that would be safe. 

I did verify that --enable-framework and --enable-universalsdk are fully 
indepedent. 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Tue Apr 25 13:26:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Apr 2006 04:26:19 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FYLgR-0008Ql-IB@sc8-sf-web4-b.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 13:26

Message:
Logged In: YES 
user_id=580910

It may well be that SF just dropped your message. I'm pretty sure I had already 
uploaded a new version of the patch.

Version 3 incorporates your suggestions: AH_VERBATIM to do the edit in 
pyconfig.h.in and introduce a expat_config.h that contains expat configuration. 
That file is used on all platforms.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-25 08:38

Message:
Logged In: YES 
user_id=21627

Somehow, my last message got lost (I think SF was down, and
I never got back to retype it), sorry.

I disagree that the pyconfig.h.in change has no effect on
other platforms: it will affect any system that either
defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__, e.g. gcc on
Itanium. Not a big problem, since it should be conceptually
correct on all systems where it is defined.

However, the real problem is that you are editing
pyconfig.h.in. This is a generated file, and your change is
lost the next time somebody runs autoheader. Please use
AH_VERBATIM to define the block to be generated for
WORDS_BIGENDIAN.

I can understand that you cannot use sys.byteorder. That
doesn't mean osxconfig.h is required, though: If pyconfig.h
already solves the problem, we should use that, instead of
duplicating it. For example, you could write a
expat_config.h which has

#include <pyconfig.h>
#ifdef WORDS_BIGENDIAN
#define BYTEORDER 4321
#else
#define BYTEORDER 1234
#endif
#define XML_NS 1
#define XML_DTD 1
#define XML_CONTEXT_BYTES 1024

and then just define HAVE_EXPAT_CONFIG_H in setup.py


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 08:20

Message:
Logged In: YES 
user_id=580910

Martin,

Do you have time to look at this patch again? I'd like to get this patch in before 
2.5a2.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 22:22

Message:
Logged In: YES 
user_id=580910

I don't know how I managed to do that, but my initial patch misses an 
essential bit in pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

On non-universal builds or builds for other platforms this is equivalent to the 
current version, on the universal build this ensures that pyconfig.h only sets 
WORDS_BIGENDIAN during the creation of PPC binaries.

python-universal-2.patch avoids the empty if-statement in configure.in and 
includes the pyconfig.h.in change I mentioned above. It also adds a test to 
test_capi that checks if sys.byteorder is consistent with WORDS_BIGENDIAN 
(the former isn't derived from the latter).

I haven't changed -current-version because I haven't had time to fully check 
if that would be safe. 

I did verify that --enable-framework and --enable-universalsdk are fully 
indepedent. 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Tue Apr 25 19:22:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Apr 2006 10:22:34 -0700
Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs
Message-ID: <E1FYRFC-0006mf-0f@sc8-sf-web4-b.sourceforge.net>

Patches item #1455898, was opened at 2006-03-22 08:31
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&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 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Walter D?rwald (doerwalter)
Summary: patch for mbcs codecs

Initial Comment:
Hello.

I have noticed mbcs codecs sometimes generates broken
string. I'm using Windows(Japanese) so mbcs is mapped
to cp932 (close to shift_jis)

When I run the attached script "a.zip", the entry
"Error 00007"'s message becomes broken like attached
file "b.txt".

I think this happens because the string passed to
PyUnicode_DecodeMBCS() sometimes terminates with
leading byte, and MultiByteToWideChar() counts it for
size of result string.buffer size.

I hope attached patch "mbcs.patch" may fix the problem.
It would be nice if this bug will be fixed in 2.4.3...
Thank you.






----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-04-25 19:22

Message:
Logged In: YES 
user_id=89016

I think the default value for final in mbcs_decode() should
be true, so that the stateless decoder detects incomplete
byte sequences too.

----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-04-07 11:10

Message:
Logged In: YES 
user_id=1200846

I have sent contributor form via postal mail. Probably you
can get it after 10 days.

----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-28 10:16

Message:
Logged In: YES 
user_id=1200846

You are right. I've updated the patch. (mbcs5.patch)

>>> import codecs
[20198 refs]
>>> d = codecs.getincrementaldecoder("mbcs")()
[20198 refs]
>>> d.decode('\x82\xa0\x82')
u'\u3042'
[20198 refs]
>>> d.decode('')
u''
[20198 refs]
>>> d.decode('', final=True)
u'\x00'
[20198 refs]


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-27 18:06

Message:
Logged In: YES 
user_id=89016

_buffer_decode() in the IncrementalDecoder ignores the final
argument. IncrementalDecoder._buffer_decode() should pass on
its final argument to _codecsmodules.c::mbcs_decode(), which
should be extended to accept the final argument. Also
PyUnicode_DecodeMBCSStateful() must handle consumed == NULL
correctly (with your patch it drops trailing lead bytes even
if consumed == NULL)

----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-27 09:41

Message:
Logged In: YES 
user_id=1200846

I replaced tests. Probably this is better instead of
comparing the two string generated by same decoder.

----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-27 07:44

Message:
Logged In: YES 
user_id=1200846

My real name is Hirokazu Yamamoto. But sorry, I don't have
FAX. (It's needed to send contributor form, isn't it?)

I'll attach the patch updated for trunk. And I'll attach the
tests.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-26 23:05

Message:
Logged In: YES 
user_id=21627

I have reservations against this patch because of the
quasi-anonymous nature of the submission. ocean-city, can
you please state your real name? Would you also be willing
to fill out a contributor form, as shown on

http://www.python.org/psf/contrib-form.html

----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-24 15:02

Message:
Logged In: YES 
user_id=1200846

OK, I'll try.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-23 22:44

Message:
Logged In: YES 
user_id=89016

This isn't a bugfix in the strictest sense, so IMHO this
patch shouldn't go into 2.4. 

If the patch goes into 2.5, it would need the appropriate
changes to encodings/mbcs.py (i.e. the IncrementalDecoder
would have to be changed (inheriting from
BufferedIncrementalDecoder).

I realize that this patch might be hard to test, as results
are dependent on locale. Nevertheless at least some tests
would be good (even if they are only run or do something
useful on a certain locale and are skipped otherwise).

ocean-city, can you update the patch for the trunk and add
tests?


----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-23 03:51

Message:
Logged In: YES 
user_id=1200846

Hello. This is my final patch. (mbcs4.patch)

 - mbcs3a.patch: _mbsbtype depends on locale not system ANSI
code page. so probably it's not good to use it with
MultiByteToWideChar.

 - mbcs3b.patch: CharNext may cause buffer overflow. and
this patch always calls CharPrev but it's not needed if
string is not terminated with "potensial" lead byte.

I hope this is stable enough to commit on repositry. Thank you.


----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-22 15:36

Message:
Logged In: YES 
user_id=1200846

Sorry, I was stupid.

MSDN
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_0o2t.asp)
saids,

> IsDBCSLeadByte can only indicate a potential lead byte value. 

IsDBCSLeadByte was returning 1 for some trail byte (ex: "???"[1])

The patch "mbcs3a.patch" worked for me, but _mbsbtype is
probably compiler specific. Is that OK?

The patch "mbcs3b.patch" also worked for me and it only uses
Win32API, but I don't have enough faith on this
implementation...



----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-22 11:31

Message:
Logged In: YES 
user_id=1200846

Sorry, I found problem when tried more long text file...
Please wait. I'll investigate more intensibly.

----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-22 11:13

Message:
Logged In: YES 
user_id=1200846

Thank you for reply. How about this? (I'm a newbie, I hope
this is right tex format but... can you confirm this? I
created this patch by copy & paste from
PyUnicode_DecodeUTF16Stateful and some modification)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-22 10:12

Message:
Logged In: YES 
user_id=38388

One more nit: the doc patch is missing. Please add a patch
for the API docs.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-22 10:11

Message:
Logged In: YES 
user_id=38388

As I understand your comment, the mbcs codec will have a
problem if the input string terminates with a lead byte.

Could you add a comment regarding this to the patch ?!

I can't test the patch, since I don't have a Japanese
Windows to check on, but from looking at the patch, it seems OK.


----------------------------------------------------------------------

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-03-22 08:42

Message:
Logged In: YES 
user_id=1200846

I forgot to mention this. "mbcs.patch" is for
release24-maint branch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470

From noreply at sourceforge.net  Wed Apr 26 00:29:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Apr 2006 15:29:35 -0700
Subject: [Patches] [ python-Patches-1471578 ] start testing strings > 2GB
Message-ID: <E1FYW2J-0007WQ-UR@sc8-sf-web5.sourceforge.net>

Patches item #1471578, was opened at 2006-04-17 08:01
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: start testing strings > 2GB

Initial Comment:
Incomplete patch.  Would be great if someone picked
this up and ran with it.  Need to be conservative and
try not to use too much memory in these tests.

Should start with strings and unicode.  Those will be
the most important things to test first.  Then can move
to arrays, mmap and other sequences.  Eventually on to
lists, sets, and dicts.

Right now, I'm sticking this in
Lib/tests/bigmem/test_str.py. 

----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-26 00:29

Message:
Logged In: YES 
user_id=34209

Well, I got unbored long enough to finish most (byte)string
tests, and do some tuple testing too. But, boy, do those
need a lot of memory. The 16Gb box I was testing on took 4
days to finish the tuple tests -- and I had to quickly add a
spare disk as swap, as the 20Gb I had allocated was just not
enough :)

Here's a completely reworked testfile. It adds a few things:

 - Support for 'bigmem tests' in test_support, and a
command-line option to regrtest. If bigmem tests aren't
explicitly enabled in regrtest, the tests are still run,
just with very small sizes (in order to test the tests
themselves.) Enabling the test is done by passing an upper
memory limit, and the framework tries to get tests to stay
inside that limit.

 - Instead of 'size' as a class attribute, each test is
decorated with a minimum size and expected memory use (in
bytes per size). The decorator calculates the allowable size
from the memory use and the limit, and skips the test if
it's going to take too much memory even with the minimum
size. In verbose mode, it warns that it skipped a file.

As I said, the tuple tests take quite a lot of memory, and
you probably don't want to the tests to start swapping (swap
is quite, quite slow.) However, not many of these tests can
be run with less than 8Gb of memory, and that'll just cover
the string tests and a few of the simpler tuple tests.

On the plus side, while the string tests found several bugs
in the Py_ssize_tification, the tuple tests found none. Or
perhaps that's a downside? I'm not sure. Anyway,
everything's here to build tests for more datatypes: dicts,
lists, sets and unicode strings come to mind (where testing
unicode strings is the most likely to discover bugs, and
should only take 2 to 4 times as much memory as the string
tests), but there's also array, buffer and probably more in
modules that can do with similar tests.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 22:00

Message:
Logged In: YES 
user_id=34209

It was syntactically correct, but many of the tests were
broken ;) Here's an updated version. I arranged it so
there's a 1K test version for easy debugging of tests, as
well as the 2GB and 4GB versions. There's still tests to be
added, but I'm bored with it now. (Python trunk on my
debian-amd64 box ran the 1K and 2GB versions without any new
issues, the 4GB one is still chugging away.)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 19:00

Message:
Logged In: YES 
user_id=33168

Cool.  I hadn't gotten a chance to run this yet.  In fact, I
never even verified it was syntactically correct. :-) 
Hopefully, this gives others the idea and they can help beef
up the tests.

Thanks for testing it out!

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 17:57

Message:
Logged In: YES 
user_id=34209

FWIW, I have a couple of 16Gb AMD64 machines at work, that
I'm preparing to be database servers. As long as they aren't
in production, I'm using them in off-hours to run with these
tests, although I don't know how far I'll get. (On the other
hand, it already found a couple of bugs ;)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&group_id=5470

From noreply at sourceforge.net  Wed Apr 26 03:21:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Apr 2006 18:21:26 -0700
Subject: [Patches] [ python-Patches-1476578 ] Add help reference on Mac
Message-ID: <E1FYYic-0007Cr-VA@sc8-sf-web6.sourceforge.net>

Patches item #1476578, was opened at 2006-04-25 21:21
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=1476578&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Sherwood (bsherwood)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add help reference on Mac

Initial Comment:
On the Mac, you can't add a help reference in Configure
IDLE by browsing because configHelpSourceEdit.py tries
to assign into a specific entry in a tuple. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1476578&group_id=5470

From noreply at sourceforge.net  Wed Apr 26 06:03:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 25 Apr 2006 21:03:44 -0700
Subject: [Patches] [ python-Patches-1471578 ] start testing strings > 2GB
Message-ID: <E1FYbFg-0005jh-NB@sc8-sf-web2.sourceforge.net>

Patches item #1471578, was opened at 2006-04-16 23:01
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&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
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: start testing strings > 2GB

Initial Comment:
Incomplete patch.  Would be great if someone picked
this up and ran with it.  Need to be conservative and
try not to use too much memory in these tests.

Should start with strings and unicode.  Those will be
the most important things to test first.  Then can move
to arrays, mmap and other sequences.  Eventually on to
lists, sets, and dicts.

Right now, I'm sticking this in
Lib/tests/bigmem/test_str.py. 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-25 21:03

Message:
Logged In: YES 
user_id=33168

Thomas, let's move this to either the sandbox or actual test
suite.  Everything you wrote makes sense.  A lot of it
probably should be added to comments and/or some sort of README.

My hope is that if this is somewhere in the core (or
sandbox), we might be able to attract some people with some
real big mem machines.

Thanks for doing all this work. 

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-25 15:29

Message:
Logged In: YES 
user_id=34209

Well, I got unbored long enough to finish most (byte)string
tests, and do some tuple testing too. But, boy, do those
need a lot of memory. The 16Gb box I was testing on took 4
days to finish the tuple tests -- and I had to quickly add a
spare disk as swap, as the 20Gb I had allocated was just not
enough :)

Here's a completely reworked testfile. It adds a few things:

 - Support for 'bigmem tests' in test_support, and a
command-line option to regrtest. If bigmem tests aren't
explicitly enabled in regrtest, the tests are still run,
just with very small sizes (in order to test the tests
themselves.) Enabling the test is done by passing an upper
memory limit, and the framework tries to get tests to stay
inside that limit.

 - Instead of 'size' as a class attribute, each test is
decorated with a minimum size and expected memory use (in
bytes per size). The decorator calculates the allowable size
from the memory use and the limit, and skips the test if
it's going to take too much memory even with the minimum
size. In verbose mode, it warns that it skipped a file.

As I said, the tuple tests take quite a lot of memory, and
you probably don't want to the tests to start swapping (swap
is quite, quite slow.) However, not many of these tests can
be run with less than 8Gb of memory, and that'll just cover
the string tests and a few of the simpler tuple tests.

On the plus side, while the string tests found several bugs
in the Py_ssize_tification, the tuple tests found none. Or
perhaps that's a downside? I'm not sure. Anyway,
everything's here to build tests for more datatypes: dicts,
lists, sets and unicode strings come to mind (where testing
unicode strings is the most likely to discover bugs, and
should only take 2 to 4 times as much memory as the string
tests), but there's also array, buffer and probably more in
modules that can do with similar tests.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 13:00

Message:
Logged In: YES 
user_id=34209

It was syntactically correct, but many of the tests were
broken ;) Here's an updated version. I arranged it so
there's a 1K test version for easy debugging of tests, as
well as the 2GB and 4GB versions. There's still tests to be
added, but I'm bored with it now. (Python trunk on my
debian-amd64 box ran the 1K and 2GB versions without any new
issues, the 4GB one is still chugging away.)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 10:00

Message:
Logged In: YES 
user_id=33168

Cool.  I hadn't gotten a chance to run this yet.  In fact, I
never even verified it was syntactically correct. :-) 
Hopefully, this gives others the idea and they can help beef
up the tests.

Thanks for testing it out!

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 08:57

Message:
Logged In: YES 
user_id=34209

FWIW, I have a couple of 16Gb AMD64 machines at work, that
I'm preparing to be database servers. As long as they aren't
in production, I'm using them in off-hours to run with these
tests, although I don't know how far I'll get. (On the other
hand, it already found a couple of bugs ;)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&group_id=5470

From noreply at sourceforge.net  Wed Apr 26 17:54:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 08:54:29 -0700
Subject: [Patches] [ python-Patches-1471578 ] start testing strings > 2GB
Message-ID: <E1FYmLV-0001mg-U5@sc8-sf-web5.sourceforge.net>

Patches item #1471578, was opened at 2006-04-17 08:01
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: start testing strings > 2GB

Initial Comment:
Incomplete patch.  Would be great if someone picked
this up and ran with it.  Need to be conservative and
try not to use too much memory in these tests.

Should start with strings and unicode.  Those will be
the most important things to test first.  Then can move
to arrays, mmap and other sequences.  Eventually on to
lists, sets, and dicts.

Right now, I'm sticking this in
Lib/tests/bigmem/test_str.py. 

----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-26 17:54

Message:
Logged In: YES 
user_id=34209

Checked in my latest version (which has list tests on top of
the string/tuple tests) so it'd make it into alpha 2.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-26 06:03

Message:
Logged In: YES 
user_id=33168

Thomas, let's move this to either the sandbox or actual test
suite.  Everything you wrote makes sense.  A lot of it
probably should be added to comments and/or some sort of README.

My hope is that if this is somewhere in the core (or
sandbox), we might be able to attract some people with some
real big mem machines.

Thanks for doing all this work. 

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-26 00:29

Message:
Logged In: YES 
user_id=34209

Well, I got unbored long enough to finish most (byte)string
tests, and do some tuple testing too. But, boy, do those
need a lot of memory. The 16Gb box I was testing on took 4
days to finish the tuple tests -- and I had to quickly add a
spare disk as swap, as the 20Gb I had allocated was just not
enough :)

Here's a completely reworked testfile. It adds a few things:

 - Support for 'bigmem tests' in test_support, and a
command-line option to regrtest. If bigmem tests aren't
explicitly enabled in regrtest, the tests are still run,
just with very small sizes (in order to test the tests
themselves.) Enabling the test is done by passing an upper
memory limit, and the framework tries to get tests to stay
inside that limit.

 - Instead of 'size' as a class attribute, each test is
decorated with a minimum size and expected memory use (in
bytes per size). The decorator calculates the allowable size
from the memory use and the limit, and skips the test if
it's going to take too much memory even with the minimum
size. In verbose mode, it warns that it skipped a file.

As I said, the tuple tests take quite a lot of memory, and
you probably don't want to the tests to start swapping (swap
is quite, quite slow.) However, not many of these tests can
be run with less than 8Gb of memory, and that'll just cover
the string tests and a few of the simpler tuple tests.

On the plus side, while the string tests found several bugs
in the Py_ssize_tification, the tuple tests found none. Or
perhaps that's a downside? I'm not sure. Anyway,
everything's here to build tests for more datatypes: dicts,
lists, sets and unicode strings come to mind (where testing
unicode strings is the most likely to discover bugs, and
should only take 2 to 4 times as much memory as the string
tests), but there's also array, buffer and probably more in
modules that can do with similar tests.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 22:00

Message:
Logged In: YES 
user_id=34209

It was syntactically correct, but many of the tests were
broken ;) Here's an updated version. I arranged it so
there's a 1K test version for easy debugging of tests, as
well as the 2GB and 4GB versions. There's still tests to be
added, but I'm bored with it now. (Python trunk on my
debian-amd64 box ran the 1K and 2GB versions without any new
issues, the 4GB one is still chugging away.)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 19:00

Message:
Logged In: YES 
user_id=33168

Cool.  I hadn't gotten a chance to run this yet.  In fact, I
never even verified it was syntactically correct. :-) 
Hopefully, this gives others the idea and they can help beef
up the tests.

Thanks for testing it out!

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-04-19 17:57

Message:
Logged In: YES 
user_id=34209

FWIW, I have a couple of 16Gb AMD64 machines at work, that
I'm preparing to be database servers. As long as they aren't
in production, I'm using them in off-hours to run with these
tests, although I don't know how far I'll get. (On the other
hand, it already found a couple of bugs ;)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471578&group_id=5470

From noreply at sourceforge.net  Wed Apr 26 18:15:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 09:15:13 -0700
Subject: [Patches] [ python-Patches-1474907 ] detect %zd format for
	PY_FORMAT_SIZE_T
Message-ID: <E1FYmfZ-0003h5-RA@sc8-sf-web3.sourceforge.net>

Patches item #1474907, was opened at 2006-04-23 08:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Martin v. L??wis (loewis)
Summary: detect %zd format for PY_FORMAT_SIZE_T

Initial Comment:
The patch modifies configure.in to add PY_FORMAT_SIZE_T
to configure.in (meaning you need to run autoheader on
configure.in) so that if %zd is supported for size_t it
sets PY_FORMAT_SIZE_T to "z", otherwise it goes
undefined and the preprocessor trickery in
Include/pyport.h kicks in.

This fix removes compiler warnings on OS X 10.4.6 with
gcc 4.0.1 thanks to PY_FORMAT_SIZE_T being set to "".

Initially assigned to Martin v. Loewis since he said
this would be good to do and the Py_ssize_t stuff is
his invention.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-26 18:15

Message:
Logged In: YES 
user_id=21627

The patch seems to rely on printf returning <0 for the
unrecognized format. That seems unreliable: atleast on
Linux, printf just outputs the format as-is for unrecognized
formats. Instead, I think it should use sprintf, and then
check whether the result is the string "0" (in addition to
checking whether the printf call itself failed).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&group_id=5470

From noreply at sourceforge.net  Thu Apr 27 00:36:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 15:36:48 -0700
Subject: [Patches] [ python-Patches-1477281 ] __init__.py'less package
	import warnings
Message-ID: <E1FYscq-0001xB-Cx@sc8-sf-web1.sourceforge.net>

Patches item #1477281, was opened at 2006-04-27 00: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=1477281&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __init__.py'less package import warnings

Initial Comment:
New! Industrial strength pitchfork-repellant. Just
sprinkle onto 2.5 and watch the pitchforks melt away,
to be replaced by hearthfelt grouphugs.

This patch (which probably needs some reformatting)
adds warnings when Python would have imported a module,
if only there had been an __init__.py. The text is
currently helpful, but it can easily be changed into a
FutureWarning with a warning that it'll change in 2.6
(or 'might change in the future'.)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477281&group_id=5470

From noreply at sourceforge.net  Thu Apr 27 00:47:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 15:47:08 -0700
Subject: [Patches] [ python-Patches-1477281 ] __init__.py'less package
	import warnings
Message-ID: <E1FYsmq-00078T-L6@sc8-sf-web1.sourceforge.net>

Patches item #1477281, was opened at 2006-04-26 18:36
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477281&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __init__.py'less package import warnings

Initial Comment:
New! Industrial strength pitchfork-repellant. Just
sprinkle onto 2.5 and watch the pitchforks melt away,
to be replaced by hearthfelt grouphugs.

This patch (which probably needs some reformatting)
adds warnings when Python would have imported a module,
if only there had been an __init__.py. The text is
currently helpful, but it can easily be changed into a
FutureWarning with a warning that it'll change in 2.6
(or 'might change in the future'.)


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-26 18:47

Message:
Logged In: YES 
user_id=6380

The patch doesn't check for errors coming out of
PyErr_Warn() -- remember, a warning can always be turned
into an exception.

I'll see if we can patch Google's Python like this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477281&group_id=5470

From noreply at sourceforge.net  Thu Apr 27 00:54:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 15:54:01 -0700
Subject: [Patches] [ python-Patches-1477281 ] __init__.py'less package
	import warnings
Message-ID: <E1FYstV-0003C3-9N@sc8-sf-web6.sourceforge.net>

Patches item #1477281, was opened at 2006-04-27 00:36
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477281&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
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __init__.py'less package import warnings

Initial Comment:
New! Industrial strength pitchfork-repellant. Just
sprinkle onto 2.5 and watch the pitchforks melt away,
to be replaced by hearthfelt grouphugs.

This patch (which probably needs some reformatting)
adds warnings when Python would have imported a module,
if only there had been an __init__.py. The text is
currently helpful, but it can easily be changed into a
FutureWarning with a warning that it'll change in 2.6
(or 'might change in the future'.)


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-27 00:54

Message:
Logged In: YES 
user_id=34209

Let's just check it into Python 2.5 instead (it's still an
hour and 7 minutes until trunk freeze, I think? :>)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-27 00:47

Message:
Logged In: YES 
user_id=6380

The patch doesn't check for errors coming out of
PyErr_Warn() -- remember, a warning can always be turned
into an exception.

I'll see if we can patch Google's Python like this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477281&group_id=5470

From noreply at sourceforge.net  Thu Apr 27 04:19:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 19:19:03 -0700
Subject: [Patches] [ python-Patches-1477350 ] Allow os.listdir to accept
	file names longer than MAX_PATH
Message-ID: <E1FYw5v-0005LH-8B@sc8-sf-web5.sourceforge.net>

Patches item #1477350, was opened at 2006-04-26 21:19
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=1477350&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
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow os.listdir to accept file names longer than MAX_PATH

Initial Comment:
On windows, os.listdir currently truncates paths 
longer than MAX_PATH due to using a fixed-size 
buffer.  Patch allocates a buffer of needed size.
It also replaces the forward slash appended to the 
path with a backslash since forward slashes don't
work when using a raw path.  There was also a 
potential crash if FindClose failed.

Diff'ed against 2.4.3.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477350&group_id=5470

From noreply at sourceforge.net  Thu Apr 27 05:38:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 20:38:14 -0700
Subject: [Patches] [ python-Patches-1477350 ] Allow os.listdir to accept
	file names longer than MAX_PATH
Message-ID: <E1FYxKY-0001YN-VN@sc8-sf-web3.sourceforge.net>

Patches item #1477350, was opened at 2006-04-26 21:19
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477350&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
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow os.listdir to accept file names longer than MAX_PATH

Initial Comment:
On windows, os.listdir currently truncates paths 
longer than MAX_PATH due to using a fixed-size 
buffer.  Patch allocates a buffer of needed size.
It also replaces the forward slash appended to the 
path with a backslash since forward slashes don't
work when using a raw path.  There was also a 
potential crash if FindClose failed.

Diff'ed against 2.4.3.



----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2006-04-26 22:38

Message:
Logged In: YES 
user_id=771074

Attaching a test script

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477350&group_id=5470

From noreply at sourceforge.net  Thu Apr 27 06:59:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 21:59:24 -0700
Subject: [Patches] [ python-Patches-1474907 ] detect %zd format for
	PY_FORMAT_SIZE_T
Message-ID: <E1FYyb6-0005m2-SN@sc8-sf-web5.sourceforge.net>

Patches item #1474907, was opened at 2006-04-22 23:18
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Martin v. L??wis (loewis)
Summary: detect %zd format for PY_FORMAT_SIZE_T

Initial Comment:
The patch modifies configure.in to add PY_FORMAT_SIZE_T
to configure.in (meaning you need to run autoheader on
configure.in) so that if %zd is supported for size_t it
sets PY_FORMAT_SIZE_T to "z", otherwise it goes
undefined and the preprocessor trickery in
Include/pyport.h kicks in.

This fix removes compiler warnings on OS X 10.4.6 with
gcc 4.0.1 thanks to PY_FORMAT_SIZE_T being set to "".

Initially assigned to Martin v. Loewis since he said
this would be good to do and the Py_ssize_t stuff is
his invention.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-04-26 21:59

Message:
Logged In: YES 
user_id=357491

OK, uploaded a new version that uses strchr to check for
'%', 'z', and 'd'.  If it looks reasonable I will apply it
and hope I don't break the buildbot.  =)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-26 09:15

Message:
Logged In: YES 
user_id=21627

The patch seems to rely on printf returning <0 for the
unrecognized format. That seems unreliable: atleast on
Linux, printf just outputs the format as-is for unrecognized
formats. Instead, I think it should use sprintf, and then
check whether the result is the string "0" (in addition to
checking whether the printf call itself failed).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&group_id=5470

From noreply at sourceforge.net  Thu Apr 27 07:16:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 22:16:49 -0700
Subject: [Patches] [ python-Patches-1474907 ] detect %zd format for
	PY_FORMAT_SIZE_T
Message-ID: <E1FYyrx-0002tJ-CT@sc8-sf-web4-b.sourceforge.net>

Patches item #1474907, was opened at 2006-04-22 23:18
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Martin v. L??wis (loewis)
Summary: detect %zd format for PY_FORMAT_SIZE_T

Initial Comment:
The patch modifies configure.in to add PY_FORMAT_SIZE_T
to configure.in (meaning you need to run autoheader on
configure.in) so that if %zd is supported for size_t it
sets PY_FORMAT_SIZE_T to "z", otherwise it goes
undefined and the preprocessor trickery in
Include/pyport.h kicks in.

This fix removes compiler warnings on OS X 10.4.6 with
gcc 4.0.1 thanks to PY_FORMAT_SIZE_T being set to "".

Initially assigned to Martin v. Loewis since he said
this would be good to do and the Py_ssize_t stuff is
his invention.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-04-26 22:16

Message:
Logged In: YES 
user_id=357491

Realized there is a better way: just strncmp() for the
expected result.  Uploaded a new version.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-26 21:59

Message:
Logged In: YES 
user_id=357491

OK, uploaded a new version that uses strchr to check for
'%', 'z', and 'd'.  If it looks reasonable I will apply it
and hope I don't break the buildbot.  =)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-26 09:15

Message:
Logged In: YES 
user_id=21627

The patch seems to rely on printf returning <0 for the
unrecognized format. That seems unreliable: atleast on
Linux, printf just outputs the format as-is for unrecognized
formats. Instead, I think it should use sprintf, and then
check whether the result is the string "0" (in addition to
checking whether the printf call itself failed).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&group_id=5470

From noreply at sourceforge.net  Thu Apr 27 07:29:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 26 Apr 2006 22:29:03 -0700
Subject: [Patches] [ python-Patches-1474907 ] detect %zd format for
	PY_FORMAT_SIZE_T
Message-ID: <E1FYz3n-0004Cc-Pq@sc8-sf-web5.sourceforge.net>

Patches item #1474907, was opened at 2006-04-23 08:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Martin v. L??wis (loewis)
Summary: detect %zd format for PY_FORMAT_SIZE_T

Initial Comment:
The patch modifies configure.in to add PY_FORMAT_SIZE_T
to configure.in (meaning you need to run autoheader on
configure.in) so that if %zd is supported for size_t it
sets PY_FORMAT_SIZE_T to "z", otherwise it goes
undefined and the preprocessor trickery in
Include/pyport.h kicks in.

This fix removes compiler warnings on OS X 10.4.6 with
gcc 4.0.1 thanks to PY_FORMAT_SIZE_T being set to "".

Initially assigned to Martin v. Loewis since he said
this would be good to do and the Py_ssize_t stuff is
his invention.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-27 07:29

Message:
Logged In: YES 
user_id=21627

Looks fine to me, although it has "unusual" style of C:

- sizeof(char) is guaranteed to be 1 by the C standard. The
C standard defines "char" and "byte" as synonyms, even if
that means that "byte" has more than 8 bits. sizeof gives
the number of bytes, so for char, it is always 1.

- for a fixed-size array, people would normally make this an
automatic (stack) variable, instead of bothering with
explicit memory allocation, i.e.

  char str_buffer[4]

Just out of fear of buffer overruns, many people would also
add some horrendous overallocation, such as str_buffer[1024] :-)


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-27 07:16

Message:
Logged In: YES 
user_id=357491

Realized there is a better way: just strncmp() for the
expected result.  Uploaded a new version.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-27 06:59

Message:
Logged In: YES 
user_id=357491

OK, uploaded a new version that uses strchr to check for
'%', 'z', and 'd'.  If it looks reasonable I will apply it
and hope I don't break the buildbot.  =)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-26 18:15

Message:
Logged In: YES 
user_id=21627

The patch seems to rely on printf returning <0 for the
unrecognized format. That seems unreliable: atleast on
Linux, printf just outputs the format as-is for unrecognized
formats. Instead, I think it should use sprintf, and then
check whether the result is the string "0" (in addition to
checking whether the printf call itself failed).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&group_id=5470

From noreply at sourceforge.net  Fri Apr 28 06:51:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 27 Apr 2006 21:51:24 -0700
Subject: [Patches] [ python-Patches-1474907 ] detect %zd format for
	PY_FORMAT_SIZE_T
Message-ID: <E1FZKwu-0001Qk-5J@sc8-sf-web6.sourceforge.net>

Patches item #1474907, was opened at 2006-04-22 23:18
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Martin v. L??wis (loewis)
Summary: detect %zd format for PY_FORMAT_SIZE_T

Initial Comment:
The patch modifies configure.in to add PY_FORMAT_SIZE_T
to configure.in (meaning you need to run autoheader on
configure.in) so that if %zd is supported for size_t it
sets PY_FORMAT_SIZE_T to "z", otherwise it goes
undefined and the preprocessor trickery in
Include/pyport.h kicks in.

This fix removes compiler warnings on OS X 10.4.6 with
gcc 4.0.1 thanks to PY_FORMAT_SIZE_T being set to "".

Initially assigned to Martin v. Loewis since he said
this would be good to do and the Py_ssize_t stuff is
his invention.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-04-27 21:51

Message:
Logged In: YES 
user_id=357491

Yeah, I tried to use a string constant as a stack value, but
that didn't work.  =)  My brain just was not thinking in C
when I first came up with the patch.

I have a new version that uses a char array as the buffer. 
I am on vacation so I don't have the time to apply it and
break buildbot, so I will hold off on applying if no one
finds problems with this version.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-26 22:29

Message:
Logged In: YES 
user_id=21627

Looks fine to me, although it has "unusual" style of C:

- sizeof(char) is guaranteed to be 1 by the C standard. The
C standard defines "char" and "byte" as synonyms, even if
that means that "byte" has more than 8 bits. sizeof gives
the number of bytes, so for char, it is always 1.

- for a fixed-size array, people would normally make this an
automatic (stack) variable, instead of bothering with
explicit memory allocation, i.e.

  char str_buffer[4]

Just out of fear of buffer overruns, many people would also
add some horrendous overallocation, such as str_buffer[1024] :-)


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-26 22:16

Message:
Logged In: YES 
user_id=357491

Realized there is a better way: just strncmp() for the
expected result.  Uploaded a new version.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-26 21:59

Message:
Logged In: YES 
user_id=357491

OK, uploaded a new version that uses strchr to check for
'%', 'z', and 'd'.  If it looks reasonable I will apply it
and hope I don't break the buildbot.  =)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-26 09:15

Message:
Logged In: YES 
user_id=21627

The patch seems to rely on printf returning <0 for the
unrecognized format. That seems unreliable: atleast on
Linux, printf just outputs the format as-is for unrecognized
formats. Instead, I think it should use sprintf, and then
check whether the result is the string "0" (in addition to
checking whether the printf call itself failed).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1474907&group_id=5470

From noreply at sourceforge.net  Fri Apr 28 11:54:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 02:54:50 -0700
Subject: [Patches] [ python-Patches-1478292 ] Fix doctest nit.
Message-ID: <E1FZPgY-0007HZ-DR@sc8-sf-web6.sourceforge.net>

Patches item #1478292, was opened at 2006-04-28 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=1478292&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: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Tim Peters (tim_one)
Summary: Fix doctest nit.

Initial Comment:
I was puzzled by this behaviour:

C:\>py25
Python 2.5a2 (r25a2:45740, Apr 27 2006, 06:31:19) [MSC
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> from doctest import register_optionflag
>>> print register_optionflag("SPAM")
1024
>>> print register_optionflag("SPAM")
2048
>>> print register_optionflag("SPAM")
2048
>>>

I suggest that register_optionflags does not
re-register already registered flags.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478292&group_id=5470

From noreply at sourceforge.net  Fri Apr 28 14:33:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 05:33:22 -0700
Subject: [Patches] [ python-Patches-1478364 ] Picky floats
Message-ID: <E1FZS9y-0006Ac-1O@sc8-sf-web5.sourceforge.net>

Patches item #1478364, was opened at 2006-04-28 07: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=1478364&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Picky floats

Initial Comment:
I came across a bug at work yesterday where I had
written:

    if not delta:
        return 0.0

where delta was a floating point number.  After a
series of calculations piling up round-off error it
took on a value on the order of 1e-8.  Not zero, but it
should have been.  The fix was easy enough:

    if abs(delta) < EPSILON:
        return 0.0

for a suitable value of EPSILON.

That got me to thinking...  I'm sure I have plenty of
other similar mistakes in my code.  (Never was much of
a numerical analysis guy...)  What if there was a
picky-float configure option that generated warnings if
you compared a float with either another float or an
int using "=="?  Does that make sense to try for
testing purposes?  The initial implementation seemed
straightforward enough, though I'm sure if this idea
merits any serious consideration it will need some more
work (at the least this behavior should probably be
user-enabled).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&group_id=5470

From noreply at sourceforge.net  Fri Apr 28 14:38:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 05:38:30 -0700
Subject: [Patches] [ python-Patches-1478364 ] Picky floats
Message-ID: <E1FZSEw-00052p-6D@sc8-sf-web4-b.sourceforge.net>

Patches item #1478364, was opened at 2006-04-28 07:33
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Picky floats

Initial Comment:
I came across a bug at work yesterday where I had
written:

    if not delta:
        return 0.0

where delta was a floating point number.  After a
series of calculations piling up round-off error it
took on a value on the order of 1e-8.  Not zero, but it
should have been.  The fix was easy enough:

    if abs(delta) < EPSILON:
        return 0.0

for a suitable value of EPSILON.

That got me to thinking...  I'm sure I have plenty of
other similar mistakes in my code.  (Never was much of
a numerical analysis guy...)  What if there was a
picky-float configure option that generated warnings if
you compared a float with either another float or an
int using "=="?  Does that make sense to try for
testing purposes?  The initial implementation seemed
straightforward enough, though I'm sure if this idea
merits any serious consideration it will need some more
work (at the least this behavior should probably be
user-enabled).


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-04-28 07:38

Message:
Logged In: YES 
user_id=44345

FYI, regarding my original note and the attached patch,
I realized that comparison with ints is mostly (always?)
okay, so I took that out of the patch.  Forgot to amend
the wording above though.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&group_id=5470

From noreply at sourceforge.net  Fri Apr 28 15:25:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 06:25:39 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FZSyZ-0002NX-6Y@sc8-sf-web5.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Martin v. L??wis (loewis)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-28 15:25

Message:
Logged In: YES 
user_id=580910

It's me again. Could you have a look at the patch again? 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 13:26

Message:
Logged In: YES 
user_id=580910

It may well be that SF just dropped your message. I'm pretty sure I had already 
uploaded a new version of the patch.

Version 3 incorporates your suggestions: AH_VERBATIM to do the edit in 
pyconfig.h.in and introduce a expat_config.h that contains expat configuration. 
That file is used on all platforms.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-25 08:38

Message:
Logged In: YES 
user_id=21627

Somehow, my last message got lost (I think SF was down, and
I never got back to retype it), sorry.

I disagree that the pyconfig.h.in change has no effect on
other platforms: it will affect any system that either
defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__, e.g. gcc on
Itanium. Not a big problem, since it should be conceptually
correct on all systems where it is defined.

However, the real problem is that you are editing
pyconfig.h.in. This is a generated file, and your change is
lost the next time somebody runs autoheader. Please use
AH_VERBATIM to define the block to be generated for
WORDS_BIGENDIAN.

I can understand that you cannot use sys.byteorder. That
doesn't mean osxconfig.h is required, though: If pyconfig.h
already solves the problem, we should use that, instead of
duplicating it. For example, you could write a
expat_config.h which has

#include <pyconfig.h>
#ifdef WORDS_BIGENDIAN
#define BYTEORDER 4321
#else
#define BYTEORDER 1234
#endif
#define XML_NS 1
#define XML_DTD 1
#define XML_CONTEXT_BYTES 1024

and then just define HAVE_EXPAT_CONFIG_H in setup.py


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 08:20

Message:
Logged In: YES 
user_id=580910

Martin,

Do you have time to look at this patch again? I'd like to get this patch in before 
2.5a2.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 22:22

Message:
Logged In: YES 
user_id=580910

I don't know how I managed to do that, but my initial patch misses an 
essential bit in pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

On non-universal builds or builds for other platforms this is equivalent to the 
current version, on the universal build this ensures that pyconfig.h only sets 
WORDS_BIGENDIAN during the creation of PPC binaries.

python-universal-2.patch avoids the empty if-statement in configure.in and 
includes the pyconfig.h.in change I mentioned above. It also adds a test to 
test_capi that checks if sys.byteorder is consistent with WORDS_BIGENDIAN 
(the former isn't derived from the latter).

I haven't changed -current-version because I haven't had time to fully check 
if that would be safe. 

I did verify that --enable-framework and --enable-universalsdk are fully 
indepedent. 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Fri Apr 28 17:14:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 08:14:53 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FZUgH-0008N4-Hw@sc8-sf-web6.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-28 17:14

Message:
Logged In: YES 
user_id=21627

The patch is fine; please apply. Don't forget to update
Misc/NEWS.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-28 15:25

Message:
Logged In: YES 
user_id=580910

It's me again. Could you have a look at the patch again? 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 13:26

Message:
Logged In: YES 
user_id=580910

It may well be that SF just dropped your message. I'm pretty sure I had already 
uploaded a new version of the patch.

Version 3 incorporates your suggestions: AH_VERBATIM to do the edit in 
pyconfig.h.in and introduce a expat_config.h that contains expat configuration. 
That file is used on all platforms.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-25 08:38

Message:
Logged In: YES 
user_id=21627

Somehow, my last message got lost (I think SF was down, and
I never got back to retype it), sorry.

I disagree that the pyconfig.h.in change has no effect on
other platforms: it will affect any system that either
defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__, e.g. gcc on
Itanium. Not a big problem, since it should be conceptually
correct on all systems where it is defined.

However, the real problem is that you are editing
pyconfig.h.in. This is a generated file, and your change is
lost the next time somebody runs autoheader. Please use
AH_VERBATIM to define the block to be generated for
WORDS_BIGENDIAN.

I can understand that you cannot use sys.byteorder. That
doesn't mean osxconfig.h is required, though: If pyconfig.h
already solves the problem, we should use that, instead of
duplicating it. For example, you could write a
expat_config.h which has

#include <pyconfig.h>
#ifdef WORDS_BIGENDIAN
#define BYTEORDER 4321
#else
#define BYTEORDER 1234
#endif
#define XML_NS 1
#define XML_DTD 1
#define XML_CONTEXT_BYTES 1024

and then just define HAVE_EXPAT_CONFIG_H in setup.py


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 08:20

Message:
Logged In: YES 
user_id=580910

Martin,

Do you have time to look at this patch again? I'd like to get this patch in before 
2.5a2.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 22:22

Message:
Logged In: YES 
user_id=580910

I don't know how I managed to do that, but my initial patch misses an 
essential bit in pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

On non-universal builds or builds for other platforms this is equivalent to the 
current version, on the universal build this ensures that pyconfig.h only sets 
WORDS_BIGENDIAN during the creation of PPC binaries.

python-universal-2.patch avoids the empty if-statement in configure.in and 
includes the pyconfig.h.in change I mentioned above. It also adds a test to 
test_capi that checks if sys.byteorder is consistent with WORDS_BIGENDIAN 
(the former isn't derived from the latter).

I haven't changed -current-version because I haven't had time to fully check 
if that would be safe. 

I did verify that --enable-framework and --enable-universalsdk are fully 
indepedent. 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Fri Apr 28 17:46:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 08:46:51 -0700
Subject: [Patches] [ python-Patches-1478364 ] Picky floats
Message-ID: <E1FZVBD-0002oL-Vj@sc8-sf-web4-b.sourceforge.net>

Patches item #1478364, was opened at 2006-04-28 14:33
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Picky floats

Initial Comment:
I came across a bug at work yesterday where I had
written:

    if not delta:
        return 0.0

where delta was a floating point number.  After a
series of calculations piling up round-off error it
took on a value on the order of 1e-8.  Not zero, but it
should have been.  The fix was easy enough:

    if abs(delta) < EPSILON:
        return 0.0

for a suitable value of EPSILON.

That got me to thinking...  I'm sure I have plenty of
other similar mistakes in my code.  (Never was much of
a numerical analysis guy...)  What if there was a
picky-float configure option that generated warnings if
you compared a float with either another float or an
int using "=="?  Does that make sense to try for
testing purposes?  The initial implementation seemed
straightforward enough, though I'm sure if this idea
merits any serious consideration it will need some more
work (at the least this behavior should probably be
user-enabled).


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-28 17:46

Message:
Logged In: YES 
user_id=21627

I don't think it should be configure-time option. If
implemented, it should be a run-time option, e.g. through a
interpreter command line option, or even a flag in the sys
module.

OTOH, I doubt that it is very useful in practice. How many
warnings do you get out of the test suite when this is on?

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-28 14:38

Message:
Logged In: YES 
user_id=44345

FYI, regarding my original note and the attached patch,
I realized that comparison with ints is mostly (always?)
okay, so I took that out of the patch.  Forgot to amend
the wording above though.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 01:43:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 16:43:08 -0700
Subject: [Patches] [ python-Patches-1478364 ] Picky floats
Message-ID: <E1FZcc8-0005BF-Dh@sc8-sf-web6.sourceforge.net>

Patches item #1478364, was opened at 2006-04-28 07:33
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Picky floats

Initial Comment:
I came across a bug at work yesterday where I had
written:

    if not delta:
        return 0.0

where delta was a floating point number.  After a
series of calculations piling up round-off error it
took on a value on the order of 1e-8.  Not zero, but it
should have been.  The fix was easy enough:

    if abs(delta) < EPSILON:
        return 0.0

for a suitable value of EPSILON.

That got me to thinking...  I'm sure I have plenty of
other similar mistakes in my code.  (Never was much of
a numerical analysis guy...)  What if there was a
picky-float configure option that generated warnings if
you compared a float with either another float or an
int using "=="?  Does that make sense to try for
testing purposes?  The initial implementation seemed
straightforward enough, though I'm sure if this idea
merits any serious consideration it will need some more
work (at the least this behavior should probably be
user-enabled).


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-04-28 18:43

Message:
Logged In: YES 
user_id=44345

Yeah, I don't think configure-time selection is the ultimate choice either.
Ideally, I think it's something you might want to enable on a per-module
basis, but other than __future__ settings I'm not aware of anything.

I just ran "make test" which runs everything twice.  Looking at the output
it seems to be complaining about 93 locations.  All but 16 of them are in
the test suite itself.  I've not checked any of them carefully yet.  A quick
scan suggests most are comparisons with small integer-valued floats,
so most are probably innocuous.

I'm not surprised there's not a lot of problem in the standard library
though, since it doesn't really do much in the way of numerical
algorithms.  It might be more instructive to look at some more
floating point-intensive code  (scipy?, MayaVi?).

I'm less interested in finding specific bugs at this point though.  I'm
more concerned with deciding whether a suitably constrained
implementation can be provided.

(BTW, off-list I got a somewhat related report of lots of float comparison
warnings in the Python C code by Intel's C compiler.  I've asked him to
run it again and file a bug report.)

Skip


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-28 10:46

Message:
Logged In: YES 
user_id=21627

I don't think it should be configure-time option. If
implemented, it should be a run-time option, e.g. through a
interpreter command line option, or even a flag in the sys
module.

OTOH, I doubt that it is very useful in practice. How many
warnings do you get out of the test suite when this is on?

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-28 07:38

Message:
Logged In: YES 
user_id=44345

FYI, regarding my original note and the attached patch,
I realized that comparison with ints is mostly (always?)
okay, so I took that out of the patch.  Forgot to amend
the wording above though.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 06:35:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 21:35:24 -0700
Subject: [Patches] [ python-Patches-1478788 ] Rename functional to functools
Message-ID: <E1FZhAy-0006oJ-JF@sc8-sf-web2.sourceforge.net>

Patches item #1478788, was opened at 2006-04-29 00:35
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=1478788&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rename functional to functools

Initial Comment:
This patch handles the requested renaming of the
functional module to functools.

Due to problems encountered when generating the patch
(svn's diff doesn't handle moved+edited files well and
PC/VC6/pythoncore.dsp was marked as binary), I've had
to upload the new versions of several files with
instructions on how to use them:

1. Apply rename_functional.patch
2. Apply pep-0309.txt.diff to
projects/peps/trunk/pep-0309.txt
3. Delete the following:
   - Doc/lib/libfunctional.tex
   - Lib/test/test_functional.py
   - Modules/functionalmodule.c
4. Add the following:
   - libfunctools.tex -> Doc/lib/libfunctools.tex
   - test_functools.py -> Lib/test/test_functools.py
   - functoolsmodule.c -> Modules/functoolsmodule.c
5. Merge pythoncore.dsp with PC/VC6/pythoncore.dsp


rename_functional.patch changes the following files:
- PCbuild/pythoncore.vcproj
- setup.py
- Misc/NEWS
- PC/config.c
- Doc/whatsnew/whatsnew25.tex
- Doc/lib/lib.tex

All changes to projects/python were based on r45757.
The changes to PEP 309 were based on r45798.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478788&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 07:12:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 28 Apr 2006 22:12:10 -0700
Subject: [Patches] [ python-Patches-1478364 ] Picky floats
Message-ID: <E1FZhkY-0003aS-38@sc8-sf-web5.sourceforge.net>

Patches item #1478364, was opened at 2006-04-28 08:33
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Picky floats

Initial Comment:
I came across a bug at work yesterday where I had
written:

    if not delta:
        return 0.0

where delta was a floating point number.  After a
series of calculations piling up round-off error it
took on a value on the order of 1e-8.  Not zero, but it
should have been.  The fix was easy enough:

    if abs(delta) < EPSILON:
        return 0.0

for a suitable value of EPSILON.

That got me to thinking...  I'm sure I have plenty of
other similar mistakes in my code.  (Never was much of
a numerical analysis guy...)  What if there was a
picky-float configure option that generated warnings if
you compared a float with either another float or an
int using "=="?  Does that make sense to try for
testing purposes?  The initial implementation seemed
straightforward enough, though I'm sure if this idea
merits any serious consideration it will need some more
work (at the least this behavior should probably be
user-enabled).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-04-29 01:12

Message:
Logged In: YES 
user_id=31435

The problem with looking "at some more floating
point-intensive code (scipy?, MayaVi?)" is that people
writing scientific code generally don't use float comparison
incorrectly -- wading through false positives isn't all that
much fun ;-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-28 19:43

Message:
Logged In: YES 
user_id=44345

Yeah, I don't think configure-time selection is the ultimate choice either.
Ideally, I think it's something you might want to enable on a per-module
basis, but other than __future__ settings I'm not aware of anything.

I just ran "make test" which runs everything twice.  Looking at the output
it seems to be complaining about 93 locations.  All but 16 of them are in
the test suite itself.  I've not checked any of them carefully yet.  A quick
scan suggests most are comparisons with small integer-valued floats,
so most are probably innocuous.

I'm not surprised there's not a lot of problem in the standard library
though, since it doesn't really do much in the way of numerical
algorithms.  It might be more instructive to look at some more
floating point-intensive code  (scipy?, MayaVi?).

I'm less interested in finding specific bugs at this point though.  I'm
more concerned with deciding whether a suitably constrained
implementation can be provided.

(BTW, off-list I got a somewhat related report of lots of float comparison
warnings in the Python C code by Intel's C compiler.  I've asked him to
run it again and file a bug report.)

Skip


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-28 11:46

Message:
Logged In: YES 
user_id=21627

I don't think it should be configure-time option. If
implemented, it should be a run-time option, e.g. through a
interpreter command line option, or even a flag in the sys
module.

OTOH, I doubt that it is very useful in practice. How many
warnings do you get out of the test suite when this is on?

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-04-28 08:38

Message:
Logged In: YES 
user_id=44345

FYI, regarding my original note and the attached patch,
I realized that comparison with ints is mostly (always?)
okay, so I took that out of the patch.  Forgot to amend
the wording above though.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478364&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 09:09:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 00:09:53 -0700
Subject: [Patches] [ python-Patches-1478788 ] Rename functional to functools
Message-ID: <E1FZjaT-0007AC-Bz@sc8-sf-web1.sourceforge.net>

Patches item #1478788, was opened at 2006-04-29 14:35
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478788&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
>Assigned to: Nick Coghlan (ncoghlan)
Summary: Rename functional to functools

Initial Comment:
This patch handles the requested renaming of the
functional module to functools.

Due to problems encountered when generating the patch
(svn's diff doesn't handle moved+edited files well and
PC/VC6/pythoncore.dsp was marked as binary), I've had
to upload the new versions of several files with
instructions on how to use them:

1. Apply rename_functional.patch
2. Apply pep-0309.txt.diff to
projects/peps/trunk/pep-0309.txt
3. Delete the following:
   - Doc/lib/libfunctional.tex
   - Lib/test/test_functional.py
   - Modules/functionalmodule.c
4. Add the following:
   - libfunctools.tex -> Doc/lib/libfunctools.tex
   - test_functools.py -> Lib/test/test_functools.py
   - functoolsmodule.c -> Modules/functoolsmodule.c
5. Merge pythoncore.dsp with PC/VC6/pythoncore.dsp


rename_functional.patch changes the following files:
- PCbuild/pythoncore.vcproj
- setup.py
- Misc/NEWS
- PC/config.c
- Doc/whatsnew/whatsnew25.tex
- Doc/lib/lib.tex

All changes to projects/python were based on r45757.
The changes to PEP 309 were based on r45798.

----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-29 17:09

Message:
Logged In: YES 
user_id=1038590

Inspecting the changes manually (rather than applying them
locally):

The change to NEWS should be an extra entry to say that
functional was renamed to functools for alpha 3 rather than
changing the earlier entry to say functools.

I suggest providing the what's new changes as a separate
patch - AMK may prefer to make his own changes to that area
of the docs.

I believe an update to the dependencies file for the Library
Reference is currently missing.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478788&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 13:32:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 04:32:32 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FZnge-0008N1-BO@sc8-sf-web6.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-29 13:32

Message:
Logged In: YES 
user_id=580910

Applied in revision 45800


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-28 17:14

Message:
Logged In: YES 
user_id=21627

The patch is fine; please apply. Don't forget to update
Misc/NEWS.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-28 15:25

Message:
Logged In: YES 
user_id=580910

It's me again. Could you have a look at the patch again? 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 13:26

Message:
Logged In: YES 
user_id=580910

It may well be that SF just dropped your message. I'm pretty sure I had already 
uploaded a new version of the patch.

Version 3 incorporates your suggestions: AH_VERBATIM to do the edit in 
pyconfig.h.in and introduce a expat_config.h that contains expat configuration. 
That file is used on all platforms.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-25 08:38

Message:
Logged In: YES 
user_id=21627

Somehow, my last message got lost (I think SF was down, and
I never got back to retype it), sorry.

I disagree that the pyconfig.h.in change has no effect on
other platforms: it will affect any system that either
defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__, e.g. gcc on
Itanium. Not a big problem, since it should be conceptually
correct on all systems where it is defined.

However, the real problem is that you are editing
pyconfig.h.in. This is a generated file, and your change is
lost the next time somebody runs autoheader. Please use
AH_VERBATIM to define the block to be generated for
WORDS_BIGENDIAN.

I can understand that you cannot use sys.byteorder. That
doesn't mean osxconfig.h is required, though: If pyconfig.h
already solves the problem, we should use that, instead of
duplicating it. For example, you could write a
expat_config.h which has

#include <pyconfig.h>
#ifdef WORDS_BIGENDIAN
#define BYTEORDER 4321
#else
#define BYTEORDER 1234
#endif
#define XML_NS 1
#define XML_DTD 1
#define XML_CONTEXT_BYTES 1024

and then just define HAVE_EXPAT_CONFIG_H in setup.py


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 08:20

Message:
Logged In: YES 
user_id=580910

Martin,

Do you have time to look at this patch again? I'd like to get this patch in before 
2.5a2.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 22:22

Message:
Logged In: YES 
user_id=580910

I don't know how I managed to do that, but my initial patch misses an 
essential bit in pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

On non-universal builds or builds for other platforms this is equivalent to the 
current version, on the universal build this ensures that pyconfig.h only sets 
WORDS_BIGENDIAN during the creation of PPC binaries.

python-universal-2.patch avoids the empty if-statement in configure.in and 
includes the pyconfig.h.in change I mentioned above. It also adds a test to 
test_capi that checks if sys.byteorder is consistent with WORDS_BIGENDIAN 
(the former isn't derived from the latter).

I haven't changed -current-version because I haven't had time to fully check 
if that would be safe. 

I did verify that --enable-framework and --enable-universalsdk are fully 
indepedent. 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 14:37:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 05:37:58 -0700
Subject: [Patches] [ python-Patches-1471883 ] --enable-universalsdk on Mac
	OS X
Message-ID: <E1FZohy-00046h-77@sc8-sf-web4-b.sourceforge.net>

Patches item #1471883, was opened at 2006-04-17 20:19
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: --enable-universalsdk on Mac OS X

Initial Comment:
This patch adds an --enable-universalsdk flag to configure. When this is 
used on a MacOS X system with Xcode 2.1 or later this can be used to 
create universal (aka "fat") binaries for python and its extensions.

This patches updates configure.in, which means autoconf should be used 
before checking in the patch.

I've tested the patch on Linux as well, it seems to have no bad effects 
there.

This patch is a cleaned up version of the code behind the --enable-
universal-sdk flag in the python24-fat tree at http://svn.pythonmac.org/
python24/python24-fat.



----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-29 14:37

Message:
Logged In: YES 
user_id=21627

I just added expat_config.h and edited Misc/NEWS in 45808.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-29 13:32

Message:
Logged In: YES 
user_id=580910

Applied in revision 45800


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-28 17:14

Message:
Logged In: YES 
user_id=21627

The patch is fine; please apply. Don't forget to update
Misc/NEWS.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-28 15:25

Message:
Logged In: YES 
user_id=580910

It's me again. Could you have a look at the patch again? 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 13:26

Message:
Logged In: YES 
user_id=580910

It may well be that SF just dropped your message. I'm pretty sure I had already 
uploaded a new version of the patch.

Version 3 incorporates your suggestions: AH_VERBATIM to do the edit in 
pyconfig.h.in and introduce a expat_config.h that contains expat configuration. 
That file is used on all platforms.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-25 08:38

Message:
Logged In: YES 
user_id=21627

Somehow, my last message got lost (I think SF was down, and
I never got back to retype it), sorry.

I disagree that the pyconfig.h.in change has no effect on
other platforms: it will affect any system that either
defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__, e.g. gcc on
Itanium. Not a big problem, since it should be conceptually
correct on all systems where it is defined.

However, the real problem is that you are editing
pyconfig.h.in. This is a generated file, and your change is
lost the next time somebody runs autoheader. Please use
AH_VERBATIM to define the block to be generated for
WORDS_BIGENDIAN.

I can understand that you cannot use sys.byteorder. That
doesn't mean osxconfig.h is required, though: If pyconfig.h
already solves the problem, we should use that, instead of
duplicating it. For example, you could write a
expat_config.h which has

#include <pyconfig.h>
#ifdef WORDS_BIGENDIAN
#define BYTEORDER 4321
#else
#define BYTEORDER 1234
#endif
#define XML_NS 1
#define XML_DTD 1
#define XML_CONTEXT_BYTES 1024

and then just define HAVE_EXPAT_CONFIG_H in setup.py


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-25 08:20

Message:
Logged In: YES 
user_id=580910

Martin,

Do you have time to look at this patch again? I'd like to get this patch in before 
2.5a2.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 22:22

Message:
Logged In: YES 
user_id=580910

I don't know how I managed to do that, but my initial patch misses an 
essential bit in pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

On non-universal builds or builds for other platforms this is equivalent to the 
current version, on the universal build this ensures that pyconfig.h only sets 
WORDS_BIGENDIAN during the creation of PPC binaries.

python-universal-2.patch avoids the empty if-statement in configure.in and 
includes the pyconfig.h.in change I mentioned above. It also adds a test to 
test_capi that checks if sys.byteorder is consistent with WORDS_BIGENDIAN 
(the former isn't derived from the latter).

I haven't changed -current-version because I haven't had time to fully check 
if that would be safe. 

I did verify that --enable-framework and --enable-universalsdk are fully 
indepedent. 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-18 21:05

Message:
Logged In: YES 
user_id=580910

osxconfig.h is there because this patch compiles all sources with 'cc -arch 
i386 -arch ppc' as the compiler. This means we can't use sys.byteorder to 
determine the right value for BYTORDER because that will be wrong for one of 
the architectures. 

The value of BYTORDER is used during the compilation of the expat sources, 
which don't include Python.h and that's probably because it is 3th-party 
software.

There is no dependency between --enable-framework and --with-universal-
sdk. I've tested this patch both with and without --enable-framework.  
Writing this I notice that I haven't checked if --enable-framework without --
with-universal-sdk still works. I'll check that and remove the empty 
statement.

-current-version doesn't include the micro release because the current build 
also doesn't do that.  It seems to be safe to change this, but I'd have to test to 
be sure.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-17 23:52

Message:
Logged In: YES 
user_id=21627

I don't understand the rationale for
Modules/expat/osxconfig.h. I thought there was some magic to
make Python.h's WORDS_BIGENDIAN always correct. If so,
BYTEORDER wouldn't be needed at all anymore.

In Makefile.pre.in, the -install-name option seems to imply
-enable-framework. If this is indeed a hard dependency,
configuring with universal-sdk, yet without framework should
make configure abort. If it's not a hard dependency, the
linker command line should be corrected for the case of
--disable-framework.

Minor issues:
- avoid empty statements; reverse the if test
"${enable_universalsdk}"; test
- shouldn't the -current-version include the micro release?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 20:24

Message:
Logged In: YES 
user_id=580910

My patch refers to osxconfig.h, but that file isn't in the patch :-(. I've uploaded it 
seperately, it should be saved as Modules/expat/osconfig.h.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471883&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 15:33:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 06:33:58 -0700
Subject: [Patches] [ python-Patches-1355023 ] support whence argument for
	GzipFile.seek (bug #1316069)
Message-ID: <E1FZpaA-00055n-CA@sc8-sf-web5.sourceforge.net>

Patches item #1355023, was opened at 2005-11-12 10:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&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
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fredrik Lundh (effbot)
Summary: support whence argument for GzipFile.seek (bug #1316069)

Initial Comment:
This adds support for whence=0 and whence=1 to the GzipFile
seek method.  See

    www.python.org/sf/1316069 

for background.

Open questions:

Q: can/should whence=2 be supported?
Q: if not, should whence=2 give an IOError or a ValueError
Q: can patches be attached to bug reports?

</F>

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 13:33

Message:
Logged In: YES 
user_id=849994

Can this be checked in before 2.5a3?

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2005-11-13 11:36

Message:
Logged In: YES 
user_id=38376

I'll add a test case and check it in.

>From what I can tell, no documentation is affected by this
change
(maybe the gzip documentation should include a full
description of
what exactly "simulates most of the methods of a file
object" really
means, but that's a separate issue).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-11-13 10:57

Message:
Logged In: YES 
user_id=21627

I think whence=2 can be supported, but shouldn't be. For
reading, only negative offsets would be meaningful, and they
can be supported the same way as they currently are (i.e.
read all over). For writing, whence=2 would have no effect.

seek apparently always gives a value error (e.g. also
file.seek, for whence=10), so it should do so also here.

Patches can be attached to bug reports if you are a patch admin.

The patch lacks documentation and test case changes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 18:04:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 09:04:36 -0700
Subject: [Patches] [ python-Patches-1478788 ] Rename functional to functools
Message-ID: <E1FZrvw-0004sU-J7@sc8-sf-web1.sourceforge.net>

Patches item #1478788, was opened at 2006-04-29 00:35
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478788&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Rename functional to functools

Initial Comment:
This patch handles the requested renaming of the
functional module to functools.

Due to problems encountered when generating the patch
(svn's diff doesn't handle moved+edited files well and
PC/VC6/pythoncore.dsp was marked as binary), I've had
to upload the new versions of several files with
instructions on how to use them:

1. Apply rename_functional.patch
2. Apply pep-0309.txt.diff to
projects/peps/trunk/pep-0309.txt
3. Delete the following:
   - Doc/lib/libfunctional.tex
   - Lib/test/test_functional.py
   - Modules/functionalmodule.c
4. Add the following:
   - libfunctools.tex -> Doc/lib/libfunctools.tex
   - test_functools.py -> Lib/test/test_functools.py
   - functoolsmodule.c -> Modules/functoolsmodule.c
5. Merge pythoncore.dsp with PC/VC6/pythoncore.dsp


rename_functional.patch changes the following files:
- PCbuild/pythoncore.vcproj
- setup.py
- Misc/NEWS
- PC/config.c
- Doc/whatsnew/whatsnew25.tex
- Doc/lib/lib.tex

All changes to projects/python were based on r45757.
The changes to PEP 309 were based on r45798.

----------------------------------------------------------------------

>Comment By: Collin Winter (collinwinter)
Date: 2006-04-29 12:04

Message:
Logged In: YES 
user_id=1344176

The patch to whatsnew25.tex has been separated out into its
own diff.

The patch to NEWS has been changed as recommended.

I'm not sure what you mean by "the dependencies file for the
Library Reference". grepping my checkout reveals no further
mentions of the old functional name.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-29 03:09

Message:
Logged In: YES 
user_id=1038590

Inspecting the changes manually (rather than applying them
locally):

The change to NEWS should be an extra entry to say that
functional was renamed to functools for alpha 3 rather than
changing the earlier entry to say functools.

I suggest providing the what's new changes as a separate
patch - AMK may prefer to make his own changes to that area
of the docs.

I believe an update to the dependencies file for the Library
Reference is currently missing.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478788&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 18:43:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 09:43:23 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1FZsXT-0000bw-Q7@sc8-sf-web4-b.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 17:43
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=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 23:11:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 14:11:43 -0700
Subject: [Patches] [ python-Patches-1473257 ] Add a gi_code attr to
	generators
Message-ID: <E1FZwj9-0004ok-Cl@sc8-sf-web5.sourceforge.net>

Patches item #1473257, was opened at 2006-04-19 17:39
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&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
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add a gi_code attr to generators

Initial Comment:
In the test suite for one of my packages, I've used
something like gen.gi_frame.f_code.co_name to help make
human-readable assertions about when certain generators
are run deep inside the application. This was possible
because Python 2.4 guaranteed that gi_frame was always
a frame instance, even after the generator exhausted
itself. In Python 2.5, however, gi_frame is None when
the generator has run till exhaustion, meaning that I
can't always get to f_code.co_name.

I'd like to add a gi_code attribute to generators that
would allow users to access the code object behind the
generator, even when gi_frame is None. This attribute
would be read-only and would follow this rule:

>>> def f():
...     yield 5
...
>>> g = f()
>>> g.gi_code is f.func_code
True
>>>

The attached patch (against r45570) implements the
proposed attribute (in Include/genobject.h and
Objects/genobject.c) and adds test cases to
Lib/test/test_generators.py for this attribute.

----------------------------------------------------------------------

>Comment By: Collin Winter (collinwinter)
Date: 2006-04-29 17:11

Message:
Logged In: YES 
user_id=1344176

I've updated the patch; it's now against SVN r45808.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&group_id=5470

From noreply at sourceforge.net  Sat Apr 29 23:12:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 14:12:00 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1FZwjQ-0000CI-DS@sc8-sf-web4-b.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 09:43
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 14:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 02:27:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 17:27:51 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1FZzmx-00030n-Gc@sc8-sf-web3.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 17:43
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 01:27

Message:
Logged In: YES 
user_id=261020

I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file.  That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.

Your other point stunned me a bit.  I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public.  Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place.  Looking at some other stdlib code, I see
that underscores would have been more conventional after all.

Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:

http://www.python.org/dev/summary/2004-07-16_2004-07-31/#use-the-docs-to-know-what-the-public-api-is-people

e.g. from Tim Peters:

"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""

However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).

So, I guess I should:

1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.

2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run).  However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed.  So suggestions are welcome here on the
best course of action.

3. As you suggest, submit a patch to add an __all__ to
cookielib.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 22:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 02:37:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 17:37:26 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1FZzwE-00068h-N4@sc8-sf-web1.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 09:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-29 17:37

Message:
Logged In: YES 
user_id=33168

John, at this point (2.x) we should at least do no worse. 
Don't export unnecessary vars in any new code.  We should
also start documenting the situation and work towards
improving it.  For 3k, we should do better and solidify the
rules and do massive cleanup (module by module).  This will
probably involve some arm twisting of Guido. :-)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-29 17:27

Message:
Logged In: YES 
user_id=261020

I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file.  That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.

Your other point stunned me a bit.  I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public.  Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place.  Looking at some other stdlib code, I see
that underscores would have been more conventional after all.

Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:

http://www.python.org/dev/summary/2004-07-16_2004-07-31/#use-the-docs-to-know-what-the-public-api-is-people

e.g. from Tim Peters:

"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""

However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).

So, I guess I should:

1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.

2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run).  However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed.  So suggestions are welcome here on the
best course of action.

3. As you suggest, submit a patch to add an __all__ to
cookielib.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 14:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 03:22:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 18:22:25 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1Fa0dl-0004Yy-Q4@sc8-sf-web1.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 17:43
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:22

Message:
Logged In: YES 
user_id=261020

So, you (Neil) agree with my three numbered action points
below?  You repeat my suggestion that we document this as if
it were a new suggestion; did you read my comment?

Sigh, sorry for being a little grumpy about this, but it's
hard to "do no worse" for a project if that project doesn't
seem itself to be very sure what it considers "worse":

While I must say I *agree* with you that such practices are
not good, if I as somebody apparently unusually inclined to
heavy use of underscores (even in most of my module names,
in library code) actually thought, however foolishly, that I
was *following stdlib conventions* by using *fewer*
underscores (for reasons I'll try to refrain from debating
further here), it does indeed seem pretty clear we're in
need of explicit documentation on this!  So your advice to
"do no worse" is a little annoying at this point... :-)

OK, so, what should get documented, specifically?  And where
should documentation for module authors go?

a). Stdlib module authors should always use underscores for
non-public module globals.

b). Don't know about this one: should non-legacy stdlib
modules (viz, those that follow rule a)) define __all__? 
(perhaps a point against doing this is that it may encourage
import * ?).

c). Stdlib packages should use __init__ to export public names.

d). Any discrepancy between __all__ and the API
documentation is a bug.

e). Stdlib users should assume all non- (I guess this should
be go somewhere near the library reference introduction)

Finally, how about my point 2?  Should I add underscores to
cookielib module globals I consider non-public (== all
undocumented module globals), or not?

Thanks for the feedback, both of you!


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-30 01:37

Message:
Logged In: YES 
user_id=33168

John, at this point (2.x) we should at least do no worse. 
Don't export unnecessary vars in any new code.  We should
also start documenting the situation and work towards
improving it.  For 3k, we should do better and solidify the
rules and do massive cleanup (module by module).  This will
probably involve some arm twisting of Guido. :-)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 01:27

Message:
Logged In: YES 
user_id=261020

I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file.  That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.

Your other point stunned me a bit.  I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public.  Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place.  Looking at some other stdlib code, I see
that underscores would have been more conventional after all.

Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:

http://www.python.org/dev/summary/2004-07-16_2004-07-31/#use-the-docs-to-know-what-the-public-api-is-people

e.g. from Tim Peters:

"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""

However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).

So, I guess I should:

1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.

2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run).  However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed.  So suggestions are welcome here on the
best course of action.

3. As you suggest, submit a patch to add an __all__ to
cookielib.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 22:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 03:26:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 18:26:29 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1Fa0hh-0006jc-H5@sc8-sf-web1.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 17:43
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:26

Message:
Logged In: YES 
user_id=261020

Bleh.

e). Stdlib users should assume all undocumented module
globals are not part of the public API (I guess this should
be go somewhere near the library reference introduction)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:22

Message:
Logged In: YES 
user_id=261020

So, you (Neil) agree with my three numbered action points
below?  You repeat my suggestion that we document this as if
it were a new suggestion; did you read my comment?

Sigh, sorry for being a little grumpy about this, but it's
hard to "do no worse" for a project if that project doesn't
seem itself to be very sure what it considers "worse":

While I must say I *agree* with you that such practices are
not good, if I as somebody apparently unusually inclined to
heavy use of underscores (even in most of my module names,
in library code) actually thought, however foolishly, that I
was *following stdlib conventions* by using *fewer*
underscores (for reasons I'll try to refrain from debating
further here), it does indeed seem pretty clear we're in
need of explicit documentation on this!  So your advice to
"do no worse" is a little annoying at this point... :-)

OK, so, what should get documented, specifically?  And where
should documentation for module authors go?

a). Stdlib module authors should always use underscores for
non-public module globals.

b). Don't know about this one: should non-legacy stdlib
modules (viz, those that follow rule a)) define __all__? 
(perhaps a point against doing this is that it may encourage
import * ?).

c). Stdlib packages should use __init__ to export public names.

d). Any discrepancy between __all__ and the API
documentation is a bug.

e). Stdlib users should assume all non- (I guess this should
be go somewhere near the library reference introduction)

Finally, how about my point 2?  Should I add underscores to
cookielib module globals I consider non-public (== all
undocumented module globals), or not?

Thanks for the feedback, both of you!


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-30 01:37

Message:
Logged In: YES 
user_id=33168

John, at this point (2.x) we should at least do no worse. 
Don't export unnecessary vars in any new code.  We should
also start documenting the situation and work towards
improving it.  For 3k, we should do better and solidify the
rules and do massive cleanup (module by module).  This will
probably involve some arm twisting of Guido. :-)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 01:27

Message:
Logged In: YES 
user_id=261020

I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file.  That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.

Your other point stunned me a bit.  I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public.  Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place.  Looking at some other stdlib code, I see
that underscores would have been more conventional after all.

Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:

http://www.python.org/dev/summary/2004-07-16_2004-07-31/#use-the-docs-to-know-what-the-public-api-is-people

e.g. from Tim Peters:

"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""

However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).

So, I guess I should:

1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.

2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run).  However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed.  So suggestions are welcome here on the
best course of action.

3. As you suggest, submit a patch to add an __all__ to
cookielib.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 22:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 03:31:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 18:31:04 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1Fa0m8-0000iE-Cc@sc8-sf-web1.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 17:43
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:31

Message:
Logged In: YES 
user_id=261020

Hmm, perhaps by "do no worse" you simply meant not to rename
the function in this tracker item to a name not beginning
with an initial underscore (since that would introduce a new
non-public module global that does not begin with an
underscore).

In which case, sorry for the rant. :-)

My questions after the rant still stand. ;-)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:26

Message:
Logged In: YES 
user_id=261020

Bleh.

e). Stdlib users should assume all undocumented module
globals are not part of the public API (I guess this should
be go somewhere near the library reference introduction)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:22

Message:
Logged In: YES 
user_id=261020

So, you (Neil) agree with my three numbered action points
below?  You repeat my suggestion that we document this as if
it were a new suggestion; did you read my comment?

Sigh, sorry for being a little grumpy about this, but it's
hard to "do no worse" for a project if that project doesn't
seem itself to be very sure what it considers "worse":

While I must say I *agree* with you that such practices are
not good, if I as somebody apparently unusually inclined to
heavy use of underscores (even in most of my module names,
in library code) actually thought, however foolishly, that I
was *following stdlib conventions* by using *fewer*
underscores (for reasons I'll try to refrain from debating
further here), it does indeed seem pretty clear we're in
need of explicit documentation on this!  So your advice to
"do no worse" is a little annoying at this point... :-)

OK, so, what should get documented, specifically?  And where
should documentation for module authors go?

a). Stdlib module authors should always use underscores for
non-public module globals.

b). Don't know about this one: should non-legacy stdlib
modules (viz, those that follow rule a)) define __all__? 
(perhaps a point against doing this is that it may encourage
import * ?).

c). Stdlib packages should use __init__ to export public names.

d). Any discrepancy between __all__ and the API
documentation is a bug.

e). Stdlib users should assume all non- (I guess this should
be go somewhere near the library reference introduction)

Finally, how about my point 2?  Should I add underscores to
cookielib module globals I consider non-public (== all
undocumented module globals), or not?

Thanks for the feedback, both of you!


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-30 01:37

Message:
Logged In: YES 
user_id=33168

John, at this point (2.x) we should at least do no worse. 
Don't export unnecessary vars in any new code.  We should
also start documenting the situation and work towards
improving it.  For 3k, we should do better and solidify the
rules and do massive cleanup (module by module).  This will
probably involve some arm twisting of Guido. :-)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 01:27

Message:
Logged In: YES 
user_id=261020

I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file.  That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.

Your other point stunned me a bit.  I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public.  Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place.  Looking at some other stdlib code, I see
that underscores would have been more conventional after all.

Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:

http://www.python.org/dev/summary/2004-07-16_2004-07-31/#use-the-docs-to-know-what-the-public-api-is-people

e.g. from Tim Peters:

"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""

However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).

So, I guess I should:

1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.

2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run).  However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed.  So suggestions are welcome here on the
best course of action.

3. As you suggest, submit a patch to add an __all__ to
cookielib.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 22:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 04:23:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 19:23:43 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1Fa1b5-0006Py-QK@sc8-sf-web4-b.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 09:43
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 19:23

Message:
Logged In: YES 
user_id=357491

You should use an underscore if you don't have an __all__
defined.  This is mostly for protection for ``from cookielib
import *`` code.  But if you define an __all__ I think you
are fine.

You do not need to document that undocumented globals should
not be relied upon.  Yes, people should know better (I
personally got nailed by the Debian folk for an undocumented
function in site.py that I changed the parameters of).  But
the suggestions Neal and I are making are to protect people
who do their doc checking from the command-line and thus
just do ``import cookielib; dir(cookielib)``.  I know Python
is for use by adults, but sometimes going a small step to
protect the adolescents is also okay.  =)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-29 18:31

Message:
Logged In: YES 
user_id=261020

Hmm, perhaps by "do no worse" you simply meant not to rename
the function in this tracker item to a name not beginning
with an initial underscore (since that would introduce a new
non-public module global that does not begin with an
underscore).

In which case, sorry for the rant. :-)

My questions after the rant still stand. ;-)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-29 18:26

Message:
Logged In: YES 
user_id=261020

Bleh.

e). Stdlib users should assume all undocumented module
globals are not part of the public API (I guess this should
be go somewhere near the library reference introduction)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-29 18:22

Message:
Logged In: YES 
user_id=261020

So, you (Neil) agree with my three numbered action points
below?  You repeat my suggestion that we document this as if
it were a new suggestion; did you read my comment?

Sigh, sorry for being a little grumpy about this, but it's
hard to "do no worse" for a project if that project doesn't
seem itself to be very sure what it considers "worse":

While I must say I *agree* with you that such practices are
not good, if I as somebody apparently unusually inclined to
heavy use of underscores (even in most of my module names,
in library code) actually thought, however foolishly, that I
was *following stdlib conventions* by using *fewer*
underscores (for reasons I'll try to refrain from debating
further here), it does indeed seem pretty clear we're in
need of explicit documentation on this!  So your advice to
"do no worse" is a little annoying at this point... :-)

OK, so, what should get documented, specifically?  And where
should documentation for module authors go?

a). Stdlib module authors should always use underscores for
non-public module globals.

b). Don't know about this one: should non-legacy stdlib
modules (viz, those that follow rule a)) define __all__? 
(perhaps a point against doing this is that it may encourage
import * ?).

c). Stdlib packages should use __init__ to export public names.

d). Any discrepancy between __all__ and the API
documentation is a bug.

e). Stdlib users should assume all non- (I guess this should
be go somewhere near the library reference introduction)

Finally, how about my point 2?  Should I add underscores to
cookielib module globals I consider non-public (== all
undocumented module globals), or not?

Thanks for the feedback, both of you!


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-29 17:37

Message:
Logged In: YES 
user_id=33168

John, at this point (2.x) we should at least do no worse. 
Don't export unnecessary vars in any new code.  We should
also start documenting the situation and work towards
improving it.  For 3k, we should do better and solidify the
rules and do massive cleanup (module by module).  This will
probably involve some arm twisting of Guido. :-)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-29 17:27

Message:
Logged In: YES 
user_id=261020

I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file.  That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.

Your other point stunned me a bit.  I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public.  Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place.  Looking at some other stdlib code, I see
that underscores would have been more conventional after all.

Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:

http://www.python.org/dev/summary/2004-07-16_2004-07-31/#use-the-docs-to-know-what-the-public-api-is-people

e.g. from Tim Peters:

"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""

However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).

So, I guess I should:

1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.

2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run).  However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed.  So suggestions are welcome here on the
best course of action.

3. As you suggest, submit a patch to add an __all__ to
cookielib.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 14:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 06:12:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 29 Apr 2006 21:12:20 -0700
Subject: [Patches] [ python-Patches-1479181 ] Split open() and file()
Message-ID: <E1Fa3IC-0001zL-Hd@sc8-sf-web1.sourceforge.net>

Patches item #1479181, was opened at 2006-04-29 21:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479181&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
Submitted By: Aahz (aahz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Split open() and file()

Initial Comment:
Make open() a factory function instead of an alias to file().  Includes
doc patches and a bugfix to Lib/test/test_subprocess.py (which was
relying on open() being an alias to file()).  There were no other
changes to the test suite -- this appears to be a completely transparent
fix.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479181&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 09:06:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 00:06:26 -0700
Subject: [Patches] [ python-Patches-1470846 ] urllib2 ProxyBasicAuthHandler
	broken
Message-ID: <E1Fa60g-00035u-3F@sc8-sf-web1.sourceforge.net>

Patches item #1470846, was opened at 2006-04-15 14:22
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470846&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 ProxyBasicAuthHandler broken

Initial Comment:
urllib2.ProxyBasicAuthHandler has been broken since
revision 38092 back in December 2004 (unlike the
alternative, using a userinfo URL component in the
string passed to ProxyHandler, e.g.
"joe:password at example.com", which works fine ATM).

There are two problems: First, with a proxy, you're
always authenticating yourself for the whole proxy, not
just for a specific path.  Second, you're
authenticating yourself to the proxy, not to the HTTP
server.  The ProxyBasicAuthHandler subclass dutifully
passes in the right thing for the host argument, but
AbstractBasicAuthHandler ignores it, which means that
it never finds the password -- e.g. if you're trying to
connect to http://python.org/dev through myproxy.com,
it'll be looking for a username/password for
http://python.org/dev instead of the needed myproxy.com.

Since fixing this entails the host argument to
http_error_auth_reqed no longer being ignored,
HTTPBasicAuthHandler must now pass the full URL, which
means AbstractBasicAuthHandler must accept either an
authority or a URL.  ProxyBasicAuthHandler could also
supply a full URL like "http://proxy.example.com/", but
the 'host' argument prior to December 2004 was not
ignored, and accepted a hostname (!), so we should keep
that working rather than insisting on a full URL.  I
also documented this behaviour.

The patch fixes the bug, adds several new tests, and
updates and fixes mis-named method documentation for
http_error_auth_reqed, and a typo in the examples.

Note one of the tests in the attached patch relies on a
currently non-existent URL at python.org requiring
basic authorization (not *proxy* basic auth in this
test, just basic auth).  So I guess the code in the
test_urllib2net.py patch hunk has to be commented out
or something until somebody adds the necessary few
lines of Apache config.

Would also be nice to add a functional test for Proxy
auth itself.  I'm sure python.org doesn't want to be
the world's proxy, but something could be configured
that does the basic auth dance then responds with 403.
 What would be most suitable: something like
SimpleHTTPServer sitting behind Apache, some mod_python
magic...??


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 07:06

Message:
Logged In: YES 
user_id=849994

Applied patch as rev. 45815.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 17:59

Message:
Logged In: YES 
user_id=261020

I should have mentioned in my initial comment that this
patch also fixes bug 900898 (an HTTPPasswordMgr bug that
arises when an authority with a port is passed to
.find_user_password()).  The patch includes tests for this
issue, but I've just added a couple more: patch
"proxy_path_2.patch" includes those new tests and supercedes
"proxy_path.patch".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470846&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 09:48:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 00:48:03 -0700
Subject: [Patches] [ python-Patches-1479219 ] ColorDelegator - Several bug
	fixes
Message-ID: <E1Fa6ex-0005iB-TW@sc8-sf-web4-b.sourceforge.net>

Patches item #1479219, was opened at 2006-04-30 10: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=1479219&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: 5
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: ColorDelegator - Several bug fixes

Initial Comment:
This patch fixes the following bugs in the Bug Tracker:

[ 1325071 ] "as" keyword sometimes highlighted in strings


This patch fixes the following undocumented bugs:

* "as" keyword colored as a keyword even in comments on
the 'import' line
* Comments such as "#False identity", which start with
a keyword immediatly after the '#' character, aren't
colored as comments.
* In unicode string literals (e.g. u"bob"), the
preceding 'u' character isn't colored as part of the
string. But the preceding 'r' of raw string literals is.

I have only added/fixed minor details, no logic changes.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479219&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 10:29:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 01:29:02 -0700
Subject: [Patches] [ python-Patches-860326 ] PyErrr_Display and
	traceback.format_exception_only behaviour
Message-ID: <E1Fa7Ic-00078V-TO@sc8-sf-web2.sourceforge.net>

Patches item #860326, was opened at 2003-12-15 13:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&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
Submitted By: J??rgen Hermann (jhermann)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyErrr_Display and traceback.format_exception_only behaviour

Initial Comment:
PyErrr_Display and traceback.format_exception_only
behave differently; namely, the first one prints the
module of an exception, the latter not.

The attached tb_problem.py illustrates the problem, it
prints:

Error: text

Traceback (most recent call last):
  File &quot;tb_problem.py&quot;, line 3, in ?
    raise uu.Error(&quot;text&quot;)
uu.Error: text

(note the diff betwen &quot;Error:...&quot; and &quot;ui.Error:...&quot;)

The attached patch fixes this. Python 2.2.2 has the
same problem.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 08:29

Message:
Logged In: YES 
user_id=849994

Seems like this is an item for Python 3000.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-13 02:29

Message:
Logged In: YES 
user_id=31435

Opened this again.  Anthony reverted the patch on both trunk
and 2.4 branch.  Whether it will be applied on the trunk
again is being discussed on python-dev.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-13 01:17

Message:
Logged In: YES 
user_id=31435

As noted on python-dev, the 2.4-branch backport should be
reverted, because it changes visible behavior (including
causing at least three of the standard tests to fail).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-12 21:16

Message:
Logged In: YES 
user_id=849994

Late is better than never ;)

Thanks for the patch, I applied it as rev. 45321, 45322(2.4).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 10:29:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 01:29:35 -0700
Subject: [Patches] [ python-Patches-1479219 ] ColorDelegator - Several bug
	fixes
Message-ID: <E1Fa7J9-0001pD-AS@sc8-sf-web4-b.sourceforge.net>

Patches item #1479219, was opened at 2006-04-30 07:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479219&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: 5
Submitted By: Tal Einat (taleinat)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: ColorDelegator - Several bug fixes

Initial Comment:
This patch fixes the following bugs in the Bug Tracker:

[ 1325071 ] "as" keyword sometimes highlighted in strings


This patch fixes the following undocumented bugs:

* "as" keyword colored as a keyword even in comments on
the 'import' line
* Comments such as "#False identity", which start with
a keyword immediatly after the '#' character, aren't
colored as comments.
* In unicode string literals (e.g. u"bob"), the
preceding 'u' character isn't colored as part of the
string. But the preceding 'r' of raw string literals is.

I have only added/fixed minor details, no logic changes.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479219&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 10:31:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 01:31:57 -0700
Subject: [Patches] [ python-Patches-1471291 ] Forbid iteration over strings
Message-ID: <E1Fa7LR-00031r-Vt@sc8-sf-web4-b.sourceforge.net>

Patches item #1471291, was opened at 2006-04-16 13:43
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471291&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: 1
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Forbid iteration over strings

Initial Comment:
This was proposed on the list.  It turned out to be
easy to implement the basic feature (iter() only calls
__iter__ and doesn't fall back on __getitem__) but a
disaster to use -- even after extensive fixes to the
sre compiler and smaller fixes to half a dozen other
modules, 120 tests were failing.  I'm saving the diffs
here for posterity.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 08:31

Message:
Logged In: YES 
user_id=849994

Marking as Rejected as this was included in PEP 3099.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1471291&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 10:33:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 01:33:05 -0700
Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from
	pythoncore dll
Message-ID: <E1Fa7MX-0005FS-0U@sc8-sf-web1.sourceforge.net>

Patches item #1449471, was opened at 2006-03-14 10:18
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&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: Accepted
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Hye-Shik Chang (perky)
Summary: Splitting CJK codecs from pythoncore dll

Initial Comment:
As many of western language natives have requested it,
this patch splits CJK codecs from pythoncore dll. 
python25.dll shrinks from 2024KB to 1364KB by this. 
Even some of CJK users would take some advantages for
domestic py2exe-ed releases.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 08:33

Message:
Logged In: YES 
user_id=849994

What's the status of this? It's marked as Accepted, but not
checked in.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 20:53

Message:
Logged In: YES 
user_id=21627

I personally think the codec from the Marsians is more
important to be part of the core than _hotshot module.

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 11:24

Message:
Logged In: YES 
user_id=972995

good decision. 
otherwise, once we learn the codecs of Marsians, they would
have probably gone into the core as well :-) 

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-19 13:22

Message:
Logged In: YES 
user_id=55188

Aah.  Then, how about to use a way how the PuTTY project does?
They maintain a relatively simple perl script to generate
various types of build files including MSVC6 dsw, MSVC7.1
sln, Dev-Cpp project, MinGW Makefile, MS nmake Makefile and
Borland C++ project file at a time.  If we make a simliar
thing, keeping PC/VC6 up-to-date would become a bit easy.

I'll try it in my spare time before the first alpha of 2.5.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 11:56

Message:
Logged In: YES 
user_id=21627

The main issue is maintainability. Everytime a module is
added, a project file needs to be created, which is more
tedious than adding a few lines to setup.py (although one
also has to remember editing Modules/Setup.dist); in
addition, Tools/msi/msi.py needs to be edited.

Everytime a "global" change is made to the compilation
options of Python (e.g. adding AMD64 configurations), it
needs to be applied to all project files individually.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-19 10:20

Message:
Logged In: YES 
user_id=55188

Yes.  I agree about the arbitrariness where to modules go.
I thought that some dll size was concerned looking
"unicodedata" module case; which is only 396KB.  It would be
clearer if we use same scheme for Windows distribution as
specified in Modules/Setup.dist. (what drawbacks are
expected then?)

Thank you for the review!

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 10:00

Message:
Logged In: YES 
user_id=21627

I must say that I find this splitting arbitrary. Why are
these modules moved out of pythonxy.dll, when, say,
multibytecodec, mmap, parser, xxsubtype, sha512 stay. I
really wish there was some policy guiding this.

That said, as the author of the code, it is certainly your
decision to make that split that way. So please go ahead and
apply that patch.

Please also add the new modules to Tool/msi/msi.py.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 10:34:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 01:34:26 -0700
Subject: [Patches] [ python-Patches-1462338 ] upgrade pyexpat to expat 2.0.0
Message-ID: <E1Fa7Nq-00082g-9p@sc8-sf-web5.sourceforge.net>

Patches item #1462338, was opened at 2006-03-31 18:47
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462338&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
Submitted By: Trent Mick (tmick)
Assigned to: Nobody/Anonymous (nobody)
Summary: upgrade pyexpat to expat 2.0.0

Initial Comment:
Update Modules/expat to expat 2.0.0. The only effective
change in the introduction of the XML_Size typedef for
the XML_GetCurrent{Column|Line}Number() functions which
effectively changed the type from 'int' to 'long'.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 08:34

Message:
Logged In: YES 
user_id=849994

Can this go into 2.5?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462338&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 11:22:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 02:22:45 -0700
Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from
	pythoncore dll
Message-ID: <E1Fa88b-0004Lc-C3@sc8-sf-web1.sourceforge.net>

Patches item #1449471, was opened at 2006-03-14 11:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&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: Accepted
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Hye-Shik Chang (perky)
Summary: Splitting CJK codecs from pythoncore dll

Initial Comment:
As many of western language natives have requested it,
this patch splits CJK codecs from pythoncore dll. 
python25.dll shrinks from 2024KB to 1364KB by this. 
Even some of CJK users would take some advantages for
domestic py2exe-ed releases.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-04-30 11:22

Message:
Logged In: YES 
user_id=21627

See my message from 2006-03-19 11:00. It's accepted, and
perky could check it in if he wanted to.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 10:33

Message:
Logged In: YES 
user_id=849994

What's the status of this? It's marked as Accepted, but not
checked in.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-20 21:53

Message:
Logged In: YES 
user_id=21627

I personally think the codec from the Marsians is more
important to be part of the core than _hotshot module.

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 12:24

Message:
Logged In: YES 
user_id=972995

good decision. 
otherwise, once we learn the codecs of Marsians, they would
have probably gone into the core as well :-) 

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-19 14:22

Message:
Logged In: YES 
user_id=55188

Aah.  Then, how about to use a way how the PuTTY project does?
They maintain a relatively simple perl script to generate
various types of build files including MSVC6 dsw, MSVC7.1
sln, Dev-Cpp project, MinGW Makefile, MS nmake Makefile and
Borland C++ project file at a time.  If we make a simliar
thing, keeping PC/VC6 up-to-date would become a bit easy.

I'll try it in my spare time before the first alpha of 2.5.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 12:56

Message:
Logged In: YES 
user_id=21627

The main issue is maintainability. Everytime a module is
added, a project file needs to be created, which is more
tedious than adding a few lines to setup.py (although one
also has to remember editing Modules/Setup.dist); in
addition, Tools/msi/msi.py needs to be edited.

Everytime a "global" change is made to the compilation
options of Python (e.g. adding AMD64 configurations), it
needs to be applied to all project files individually.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2006-03-19 11:20

Message:
Logged In: YES 
user_id=55188

Yes.  I agree about the arbitrariness where to modules go.
I thought that some dll size was concerned looking
"unicodedata" module case; which is only 396KB.  It would be
clearer if we use same scheme for Windows distribution as
specified in Modules/Setup.dist. (what drawbacks are
expected then?)

Thank you for the review!

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-19 11:00

Message:
Logged In: YES 
user_id=21627

I must say that I find this splitting arbitrary. Why are
these modules moved out of pythonxy.dll, when, say,
multibytecodec, mmap, parser, xxsubtype, sha512 stay. I
really wish there was some policy guiding this.

That said, as the author of the code, it is certainly your
decision to make that split that way. So please go ahead and
apply that patch.

Please also add the new modules to Tool/msi/msi.py.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 11:26:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 02:26:18 -0700
Subject: [Patches] [ python-Patches-1470976 ] Fix for urllib/urllib2 ftp
	bugs 1357260 and 1281692
Message-ID: <E1Fa8C2-0007wD-S1@sc8-sf-web3.sourceforge.net>

Patches item #1470976, was opened at 2006-04-15 20:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470976&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for urllib/urllib2 ftp bugs 1357260 and 1281692

Initial Comment:
This fixes 1357260 and 1281692.

As suggested in the initial comment for 1357260, the
patch simply removes the code that does an NLST before
the attempt to actually fetch the file, since some
server operators turn off file listing (presumably in
an attempt to provide increased security of some kind).
 "Easier to ask forgiveness than get permission"
applies to the FTP protocol as much as to Python :-)

FWIW, I verified that this allows retrieval in some
cases where it wasn't previously, using proftpd 1.2.10
(gentoo ebuild r7) with this configuration directive
placed inside the <Anonymous ~ftp></Anonymous> directive:

    <Limit LIST NLST>
      DenyAll
    </Limit>

Without the patch, I get a 450 when doing a urlopen on
files accessible from that server (using either urllib
or urllib2).  With the patch, I can retrieve the files.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 09:26

Message:
Logged In: YES 
user_id=849994

Committed in rev. 45819.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1470976&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 12:24:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 03:24:03 -0700
Subject: [Patches] [ python-Patches-1479255 ] Fix building with SWIG's -c++
	option set in setup.py
Message-ID: <E1Fa95v-0004hf-CE@sc8-sf-web2.sourceforge.net>

Patches item #1479255, was opened at 2006-04-30 13: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=1479255&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: dOb (d0b)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix building with SWIG's -c++ option set in setup.py

Initial Comment:
When the '--swig-opts -c++' command line option is
used, the target extension is changed from .c to .cpp
but when the '-c++' option is passed to an Extension
with the swig_opts keyword argument, the target
extension is not changed. This causes the compiler to
treat the C++ source as C and fail.

With the patch distutils uses the Extension's swig_opts
argument in addition to the command line options to
determine if the target extension should be .c or .cpp.

Here are examples of what arguments get used with the
executables in different situations:

Without -c++
swig.exe -python -Iinclude -o
interface/interface_wrap.c interface/interface.i
cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iinclude
-IC:\Python24\include -IC:\Python24\PC
/Tcinterface/interface_wrap.c
/Fobuild\temp.win32-2.4\Release\interface/interface_wrap.obj

With -c++ (as command line option)
swig.exe -python -Iinclude -c++ -o
interface/interface_wrap.cpp interface/interface.i
cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iinclude
-IC:\Python24\include -IC:\Python24\PC
/Tpinterface/interface_wrap.cpp
/Fobuild\temp.win32-2.4\Release\interface/interface_wrap.obj

With -c++ (in swig_opts in setup.py)
swig.exe -python -Iinclude -c++ -o
interface/interface_wrap.c interface/interface.i
cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iinclude
-IC:\Python24\include -IC:\Python24\PC
/Tcinterface/interface_wrap.c
/Fobuild\temp.win32-2.4\Release\interface/interface_wrap.obj

With -c++ (in swig_opts in setup.py with patch applied)
swig.exe -python -Iinclude -c++ -o
interface/interface_wrap.cpp interface/interface.i
cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iinclude
-IC:\Python24\include -IC:\Python24\PC
/Tpinterface/interface_wrap.cpp
/Fobuild\temp.win32-2.4\Release\interface/interface_wrap.obj

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479255&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 13:14:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 04:14:49 -0700
Subject: [Patches] [ python-Patches-1473625 ] cPickle produces
	locale-dependent dumps
Message-ID: <E1Fa9t3-000875-Me@sc8-sf-web2.sourceforge.net>

Patches item #1473625, was opened at 2006-04-20 15:25
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473625&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.5
>Status: Closed
>Resolution: Accepted
Priority: 7
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle produces locale-dependent dumps

Initial Comment:
Dumping a float with cPickle produces a result which is
locale-dependent.  This causes problems when trying to
load the dump under a different locale (the regular
pickle module is not affected by this bug).  IMHO, the
dump should be locale-independent to ensure
portability. See the attached file for a sample session
log showing the behaviour of both pickle and cPickle
under C and ca_ES.UTF-8 locales (Catalan uses a comma
to separate the integer and decimal part).


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 11:14

Message:
Logged In: YES 
user_id=849994

I applied a similar patch in rev. 45821. Thank you!

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-04-21 09:42

Message:
Logged In: YES 
user_id=1064183

The problem seems to be in save_float() in the cPickle.c
module.  It uses PyOS_snprintf() to dump floats, but it is
locale-dependent.  Fortunately, the PyOS_ascii_formatd()
function can be used.  The attached patch seems to fix the
problem, and pickling tests run OK.  It would be nice to see
this patch applied to 2.4 also.

(BTW, I meant PEP 331 in the previous comment, not 311, sorry.)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-20 21:54

Message:
Logged In: YES 
user_id=21627

Right, cPickle should use C locale floating point numbers,
using the PEP 331 API. Would you like to investigate a patch?

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-04-20 15:28

Message:
Logged In: YES 
user_id=1064183

As a side note, does this have anything to do with PEP 311?
 http://www.python.org/dev/peps/pep-0331/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473625&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 13:16:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 04:16:26 -0700
Subject: [Patches] [ python-Patches-1473257 ] Add a gi_code attr to
	generators
Message-ID: <E1Fa9uc-0000Ut-Q1@sc8-sf-web2.sourceforge.net>

Patches item #1473257, was opened at 2006-04-19 21:39
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&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
Submitted By: Collin Winter (collinwinter)
>Assigned to: Phillip J. Eby (pje)
Summary: Add a gi_code attr to generators

Initial Comment:
In the test suite for one of my packages, I've used
something like gen.gi_frame.f_code.co_name to help make
human-readable assertions about when certain generators
are run deep inside the application. This was possible
because Python 2.4 guaranteed that gi_frame was always
a frame instance, even after the generator exhausted
itself. In Python 2.5, however, gi_frame is None when
the generator has run till exhaustion, meaning that I
can't always get to f_code.co_name.

I'd like to add a gi_code attribute to generators that
would allow users to access the code object behind the
generator, even when gi_frame is None. This attribute
would be read-only and would follow this rule:

>>> def f():
...     yield 5
...
>>> g = f()
>>> g.gi_code is f.func_code
True
>>>

The attached patch (against r45570) implements the
proposed attribute (in Include/genobject.h and
Objects/genobject.c) and adds test cases to
Lib/test/test_generators.py for this attribute.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-04-29 21:11

Message:
Logged In: YES 
user_id=1344176

I've updated the patch; it's now against SVN r45808.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 13:17:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 04:17:02 -0700
Subject: [Patches] [ python-Patches-1473257 ] Add a gi_code attr to
	generators
Message-ID: <E1Fa9vC-0000n3-DE@sc8-sf-web2.sourceforge.net>

Patches item #1473257, was opened at 2006-04-19 21:39
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&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
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: Add a gi_code attr to generators

Initial Comment:
In the test suite for one of my packages, I've used
something like gen.gi_frame.f_code.co_name to help make
human-readable assertions about when certain generators
are run deep inside the application. This was possible
because Python 2.4 guaranteed that gi_frame was always
a frame instance, even after the generator exhausted
itself. In Python 2.5, however, gi_frame is None when
the generator has run till exhaustion, meaning that I
can't always get to f_code.co_name.

I'd like to add a gi_code attribute to generators that
would allow users to access the code object behind the
generator, even when gi_frame is None. This attribute
would be read-only and would follow this rule:

>>> def f():
...     yield 5
...
>>> g = f()
>>> g.gi_code is f.func_code
True
>>>

The attached patch (against r45570) implements the
proposed attribute (in Include/genobject.h and
Objects/genobject.c) and adds test cases to
Lib/test/test_generators.py for this attribute.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 11:17

Message:
Logged In: YES 
user_id=849994

Phillip, do you have an opinion on this one?

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-04-29 21:11

Message:
Logged In: YES 
user_id=1344176

I've updated the patch; it's now against SVN r45808.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 13:19:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 04:19:11 -0700
Subject: [Patches] [ python-Patches-1475845 ] IndentationError for
	unexpected indent
Message-ID: <E1Fa9xH-0001tO-Lq@sc8-sf-web2.sourceforge.net>

Patches item #1475845, was opened at 2006-04-24 23:12
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475845&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Miller (rcmiller)
>Assigned to: Martin v. L??wis (loewis)
Summary: IndentationError for unexpected indent

Initial Comment:
This patch raises an IndentationError rather than a
generic "invalid syntax" error for unexpected
indentation.  Code to do this was already in
pythonrun.c:err_input() but was not being reached due
to a failure to pass the INDENT token in the perrdetail
structure.  The patch also adds tests for the 3 kinds
of indentation errors (unexpected indent, no indent
where required, invalid outdent level) to test_syntax.py .


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475845&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 13:20:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 04:20:12 -0700
Subject: [Patches] [ python-Patches-1475845 ] IndentationError for
	unexpected indent
Message-ID: <E1Fa9yG-0002Pc-2g@sc8-sf-web2.sourceforge.net>

Patches item #1475845, was opened at 2006-04-24 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=1475845&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Miller (rcmiller)
Assigned to: Martin v. L??wis (loewis)
Summary: IndentationError for unexpected indent

Initial Comment:
This patch raises an IndentationError rather than a
generic "invalid syntax" error for unexpected
indentation.  Code to do this was already in
pythonrun.c:err_input() but was not being reached due
to a failure to pass the INDENT token in the perrdetail
structure.  The patch also adds tests for the 3 kinds
of indentation errors (unexpected indent, no indent
where required, invalid outdent level) to test_syntax.py .


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 11:20

Message:
Logged In: YES 
user_id=849994

Martin, do we want to change this? I myself have always
wondered what IndentationError was for if it was not raised
in these cases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475845&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 15:15:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 06:15:11 -0700
Subject: [Patches] [ python-Patches-1479302 ] Make urllib2 digest auth and
	basic auth play together
Message-ID: <E1FaBlX-0003wx-FW@sc8-sf-web1.sourceforge.net>

Patches item #1479302, was opened at 2006-04-30 14:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make urllib2 digest auth and basic auth play together

Initial Comment:
urllib2.HTTPDigestAuthHandler breaks urllib2's handler
scheme by raising an exception instead of returning
None to indicate another handler might handle the
response.  This stops everything in its tracks (the
exception is not caught by urllib2) and prevents
urllib2.HTTPBasicAuthHandler from handling basic auth
scheme 40* responses.

The patch simply removes the raise statement, so that
the .http_error_auth_reqed(), and therefore
.http_error_40*(), returns None.

There is also a unit test.

(will upload patch in a sec when I have the tracker ID
to insert in the test)

2.4 backport candidate.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 15:25:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 06:25:10 -0700
Subject: [Patches] [ python-Patches-1479302 ] Make urllib2 digest auth and
	basic auth play together
Message-ID: <E1FaBvC-000393-KG@sc8-sf-web4-b.sourceforge.net>

Patches item #1479302, was opened at 2006-04-30 14:15
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make urllib2 digest auth and basic auth play together

Initial Comment:
urllib2.HTTPDigestAuthHandler breaks urllib2's handler
scheme by raising an exception instead of returning
None to indicate another handler might handle the
response.  This stops everything in its tracks (the
exception is not caught by urllib2) and prevents
urllib2.HTTPBasicAuthHandler from handling basic auth
scheme 40* responses.

The patch simply removes the raise statement, so that
the .http_error_auth_reqed(), and therefore
.http_error_40*(), returns None.

There is also a unit test.

(will upload patch in a sec when I have the tracker ID
to insert in the test)

2.4 backport candidate.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 14:25

Message:
Logged In: YES 
user_id=261020

Just a note that an XXX comment at the top of the code
comments that:

"""
If an authentication error handler that tries to perform
authentication for some reason but fails, how should the
error be signalled?  The client needs to know the HTTP error
code.  But if the handler knows that the problem was, e.g.,
that it didn't know that hash algo that requested in the
challenge, it would be good to pass that information along
to the client, too.
"""

I think this problem should be handled using module logging,
similarly to how module cookielib logs its reasoning for
accepting and returning cookies.

Do people agree?  If so, I'll file another patch to add that.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 15:42:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 06:42:19 -0700
Subject: [Patches] [ python-Patches-1479302 ] Make urllib2 digest auth and
	basic auth play together
Message-ID: <E1FaCBn-0008DA-Lh@sc8-sf-web5.sourceforge.net>

Patches item #1479302, was opened at 2006-04-30 14:15
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make urllib2 digest auth and basic auth play together

Initial Comment:
urllib2.HTTPDigestAuthHandler breaks urllib2's handler
scheme by raising an exception instead of returning
None to indicate another handler might handle the
response.  This stops everything in its tracks (the
exception is not caught by urllib2) and prevents
urllib2.HTTPBasicAuthHandler from handling basic auth
scheme 40* responses.

The patch simply removes the raise statement, so that
the .http_error_auth_reqed(), and therefore
.http_error_40*(), returns None.

There is also a unit test.

(will upload patch in a sec when I have the tracker ID
to insert in the test)

2.4 backport candidate.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 14:42

Message:
Logged In: YES 
user_id=261020

Hmm, on second thoughts: use of module logging only solves
the debugging problem.  People may want to programatically
handle failure of authentication (and, say, report to the
user "authentication failed, you entered the wrong username
or password", or "authentication failed: hash algorithm YYY
not implemented").

That doesn't make applying this patch a bad idea, because
the HTTPDigestAuthHandler ValueError is not useful for that
purpose.  People wanting to handle this at run time can
(already) and should catch the HTTPError that will
eventually be raised when no handler handles the 40*
reponse.  (although the bug addressed by this patch breaks
that in one very specific case, of course: where both digest
+ basic handlers are present, and a basic auth challenge is
received)

In summary, this patch should be applied, but we should also
, as an additional feature, think up some way of allowing
auth failure information to be reported by these handlers
(probably by stuffing the info into the HTTPError).


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 14:25

Message:
Logged In: YES 
user_id=261020

Just a note that an XXX comment at the top of the code
comments that:

"""
If an authentication error handler that tries to perform
authentication for some reason but fails, how should the
error be signalled?  The client needs to know the HTTP error
code.  But if the handler knows that the problem was, e.g.,
that it didn't know that hash algo that requested in the
challenge, it would be good to pass that information along
to the client, too.
"""

I think this problem should be handled using module logging,
similarly to how module cookielib logs its reasoning for
accepting and returning cookies.

Do people agree?  If so, I'll file another patch to add that.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 16:35:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 07:35:02 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1FaD0o-0002FZ-M0@sc8-sf-web1.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 17:43
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 15:35

Message:
Logged In: YES 
user_id=261020

<shrug> I still think there should be documented guidelines
on this for both stdlib users and contributors (though they
should not live in the cookielib docs, of course!).

I've added a new patch to this tracker item,
cookielib_baseexception_2.patch, that adds an __all__ and
uses the name _warn_unhandled_exception (in addition to the
original patch contents).  I verified that the set of
documented module globals is identical to those listed in
the new __all__.  Let me know if I should also rename all
other non-public module globals defined in cookielib to have
initial underscores.

Just for the record, here is the list of all module globals
NOT listed in the new __all__ (as determined by doing
dir(cookielib) prior to applying the patch, and removing the
items I didn't add to __all__, so includes some noise from
things like 'import sys'):

['Absent', 'DAYS', 'DEFAULT_HTTP_PORT', 'EPOCH_YEAR',
'ESCAPED_CHAR_RE', 'HEADER_ESCAPE_RE',
'HEADER_JOIN_ESCAPE_RE', 'HEADER_QUOTED_VALUE_RE',
'HEADER_TOKEN_RE', 'HEADER_VALUE_RE', 'HTTP_PATH_SAFE',
'IPV4_RE', 'ISO_DATE_RE', 'LOOSE_HTTP_DATE_RE',
'MISSING_FILENAME_TEXT', 'MONTHS', 'MONTHS_LOWER',
'STRICT_DATE_RE', 'TIMEZONE_RE', 'UTC_ZONES', 'WEEKDAY_RE',
'__builtins__', '__doc__', '__file__', '__name__',
'_str2time', '_threading', '_timegm', 'copy', 'cut_port_re',
'debug', 'deepvalues', 'domain_match', 'eff_request_host',
'escape_path', 'http2time', 'httplib', 'is_HDN',
'is_third_party', 'iso2time', 'join_header_words',
'liberal_is_HDN', 'logging', 'lwp_cookie_str', 'month',
'offset_from_tz_string', 'parse_ns_headers', 're', 'reach',
'request_host', 'request_path', 'request_port',
'split_header_words', 'sys', 'time', 'time2isoz',
'time2netscape', 'timegm', 'unmatched',
'uppercase_escaped_char', 'urllib', 'urlparse',
'user_domain_match', 'vals_sorted_by_key',
'warn_unhandled_exception']


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-30 03:23

Message:
Logged In: YES 
user_id=357491

You should use an underscore if you don't have an __all__
defined.  This is mostly for protection for ``from cookielib
import *`` code.  But if you define an __all__ I think you
are fine.

You do not need to document that undocumented globals should
not be relied upon.  Yes, people should know better (I
personally got nailed by the Debian folk for an undocumented
function in site.py that I changed the parameters of).  But
the suggestions Neal and I are making are to protect people
who do their doc checking from the command-line and thus
just do ``import cookielib; dir(cookielib)``.  I know Python
is for use by adults, but sometimes going a small step to
protect the adolescents is also okay.  =)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:31

Message:
Logged In: YES 
user_id=261020

Hmm, perhaps by "do no worse" you simply meant not to rename
the function in this tracker item to a name not beginning
with an initial underscore (since that would introduce a new
non-public module global that does not begin with an
underscore).

In which case, sorry for the rant. :-)

My questions after the rant still stand. ;-)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:26

Message:
Logged In: YES 
user_id=261020

Bleh.

e). Stdlib users should assume all undocumented module
globals are not part of the public API (I guess this should
be go somewhere near the library reference introduction)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:22

Message:
Logged In: YES 
user_id=261020

So, you (Neil) agree with my three numbered action points
below?  You repeat my suggestion that we document this as if
it were a new suggestion; did you read my comment?

Sigh, sorry for being a little grumpy about this, but it's
hard to "do no worse" for a project if that project doesn't
seem itself to be very sure what it considers "worse":

While I must say I *agree* with you that such practices are
not good, if I as somebody apparently unusually inclined to
heavy use of underscores (even in most of my module names,
in library code) actually thought, however foolishly, that I
was *following stdlib conventions* by using *fewer*
underscores (for reasons I'll try to refrain from debating
further here), it does indeed seem pretty clear we're in
need of explicit documentation on this!  So your advice to
"do no worse" is a little annoying at this point... :-)

OK, so, what should get documented, specifically?  And where
should documentation for module authors go?

a). Stdlib module authors should always use underscores for
non-public module globals.

b). Don't know about this one: should non-legacy stdlib
modules (viz, those that follow rule a)) define __all__? 
(perhaps a point against doing this is that it may encourage
import * ?).

c). Stdlib packages should use __init__ to export public names.

d). Any discrepancy between __all__ and the API
documentation is a bug.

e). Stdlib users should assume all non- (I guess this should
be go somewhere near the library reference introduction)

Finally, how about my point 2?  Should I add underscores to
cookielib module globals I consider non-public (== all
undocumented module globals), or not?

Thanks for the feedback, both of you!


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-30 01:37

Message:
Logged In: YES 
user_id=33168

John, at this point (2.x) we should at least do no worse. 
Don't export unnecessary vars in any new code.  We should
also start documenting the situation and work towards
improving it.  For 3k, we should do better and solidify the
rules and do massive cleanup (module by module).  This will
probably involve some arm twisting of Guido. :-)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 01:27

Message:
Logged In: YES 
user_id=261020

I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file.  That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.

Your other point stunned me a bit.  I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public.  Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place.  Looking at some other stdlib code, I see
that underscores would have been more conventional after all.

Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:

http://www.python.org/dev/summary/2004-07-16_2004-07-31/#use-the-docs-to-know-what-the-public-api-is-people

e.g. from Tim Peters:

"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""

However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).

So, I guess I should:

1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.

2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run).  However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed.  So suggestions are welcome here on the
best course of action.

3. As you suggest, submit a patch to add an __all__ to
cookielib.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 22:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 16:36:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 07:36:51 -0700
Subject: [Patches] [ python-Patches-1479302 ] Make urllib2 digest auth and
	basic auth play together
Message-ID: <E1FaD2Z-0002PH-KD@sc8-sf-web1.sourceforge.net>

Patches item #1479302, was opened at 2006-04-30 14:15
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make urllib2 digest auth and basic auth play together

Initial Comment:
urllib2.HTTPDigestAuthHandler breaks urllib2's handler
scheme by raising an exception instead of returning
None to indicate another handler might handle the
response.  This stops everything in its tracks (the
exception is not caught by urllib2) and prevents
urllib2.HTTPBasicAuthHandler from handling basic auth
scheme 40* responses.

The patch simply removes the raise statement, so that
the .http_error_auth_reqed(), and therefore
.http_error_40*(), returns None.

There is also a unit test.

(will upload patch in a sec when I have the tracker ID
to insert in the test)

2.4 backport candidate.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 15:36

Message:
Logged In: YES 
user_id=261020

(...and the new patch makes a tiny fix to a
slightly-inaccurate statement in the module docstring)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 14:42

Message:
Logged In: YES 
user_id=261020

Hmm, on second thoughts: use of module logging only solves
the debugging problem.  People may want to programatically
handle failure of authentication (and, say, report to the
user "authentication failed, you entered the wrong username
or password", or "authentication failed: hash algorithm YYY
not implemented").

That doesn't make applying this patch a bad idea, because
the HTTPDigestAuthHandler ValueError is not useful for that
purpose.  People wanting to handle this at run time can
(already) and should catch the HTTPError that will
eventually be raised when no handler handles the 40*
reponse.  (although the bug addressed by this patch breaks
that in one very specific case, of course: where both digest
+ basic handlers are present, and a basic auth challenge is
received)

In summary, this patch should be applied, but we should also
, as an additional feature, think up some way of allowing
auth failure information to be reported by these handlers
(probably by stuffing the info into the HTTPError).


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 14:25

Message:
Logged In: YES 
user_id=261020

Just a note that an XXX comment at the top of the code
comments that:

"""
If an authentication error handler that tries to perform
authentication for some reason but fails, how should the
error be signalled?  The client needs to know the HTTP error
code.  But if the handler knows that the problem was, e.g.,
that it didn't know that hash algo that requested in the
challenge, it would be good to pass that information along
to the client, too.
"""

I think this problem should be handled using module logging,
similarly to how module cookielib logs its reasoning for
accepting and returning cookies.

Do people agree?  If so, I'll file another patch to add that.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 16:37:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 07:37:48 -0700
Subject: [Patches] [ python-Patches-1479302 ] Make urllib2 digest auth and
	basic auth play together
Message-ID: <E1FaD3U-0002Um-5v@sc8-sf-web1.sourceforge.net>

Patches item #1479302, was opened at 2006-04-30 14:15
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&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
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make urllib2 digest auth and basic auth play together

Initial Comment:
urllib2.HTTPDigestAuthHandler breaks urllib2's handler
scheme by raising an exception instead of returning
None to indicate another handler might handle the
response.  This stops everything in its tracks (the
exception is not caught by urllib2) and prevents
urllib2.HTTPBasicAuthHandler from handling basic auth
scheme 40* responses.

The patch simply removes the raise statement, so that
the .http_error_auth_reqed(), and therefore
.http_error_40*(), returns None.

There is also a unit test.

(will upload patch in a sec when I have the tracker ID
to insert in the test)

2.4 backport candidate.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 15:37

Message:
Logged In: YES 
user_id=261020

Argh, posted to the wrong tracker item for that last
comment, too many bugs on the go at once, sorry.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 15:36

Message:
Logged In: YES 
user_id=261020

(...and the new patch makes a tiny fix to a
slightly-inaccurate statement in the module docstring)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 14:42

Message:
Logged In: YES 
user_id=261020

Hmm, on second thoughts: use of module logging only solves
the debugging problem.  People may want to programatically
handle failure of authentication (and, say, report to the
user "authentication failed, you entered the wrong username
or password", or "authentication failed: hash algorithm YYY
not implemented").

That doesn't make applying this patch a bad idea, because
the HTTPDigestAuthHandler ValueError is not useful for that
purpose.  People wanting to handle this at run time can
(already) and should catch the HTTPError that will
eventually be raised when no handler handles the 40*
reponse.  (although the bug addressed by this patch breaks
that in one very specific case, of course: where both digest
+ basic handlers are present, and a basic auth challenge is
received)

In summary, this patch should be applied, but we should also
, as an additional feature, think up some way of allowing
auth failure information to be reported by these handlers
(probably by stuffing the info into the HTTPError).


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 14:25

Message:
Logged In: YES 
user_id=261020

Just a note that an XXX comment at the top of the code
comments that:

"""
If an authentication error handler that tries to perform
authentication for some reason but fails, how should the
error be signalled?  The client needs to know the HTTP error
code.  But if the handler knows that the problem was, e.g.,
that it didn't know that hash algo that requested in the
challenge, it would be good to pass that information along
to the client, too.
"""

I think this problem should be handled using module logging,
similarly to how module cookielib logs its reasoning for
accepting and returning cookies.

Do people agree?  If so, I'll file another patch to add that.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 16:38:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 07:38:23 -0700
Subject: [Patches] [ python-Patches-1478993 ] Take advantage of
	BaseException/Exception split in cookielib
Message-ID: <E1FaD43-0002Zq-Q5@sc8-sf-web1.sourceforge.net>

Patches item #1478993, was opened at 2006-04-29 17:43
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&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: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Take advantage of BaseException/Exception split in cookielib

Initial Comment:
The patch takes advantage of the exception hierarchy
reorganisation to remove some ugly code in cookielib. 
It clarifies a couple of exception messages, too.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 15:38

Message:
Logged In: YES 
user_id=261020

(...and the new patch makes a tiny fix to a
slightly-inaccurate statement in the module docstring)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 15:35

Message:
Logged In: YES 
user_id=261020

<shrug> I still think there should be documented guidelines
on this for both stdlib users and contributors (though they
should not live in the cookielib docs, of course!).

I've added a new patch to this tracker item,
cookielib_baseexception_2.patch, that adds an __all__ and
uses the name _warn_unhandled_exception (in addition to the
original patch contents).  I verified that the set of
documented module globals is identical to those listed in
the new __all__.  Let me know if I should also rename all
other non-public module globals defined in cookielib to have
initial underscores.

Just for the record, here is the list of all module globals
NOT listed in the new __all__ (as determined by doing
dir(cookielib) prior to applying the patch, and removing the
items I didn't add to __all__, so includes some noise from
things like 'import sys'):

['Absent', 'DAYS', 'DEFAULT_HTTP_PORT', 'EPOCH_YEAR',
'ESCAPED_CHAR_RE', 'HEADER_ESCAPE_RE',
'HEADER_JOIN_ESCAPE_RE', 'HEADER_QUOTED_VALUE_RE',
'HEADER_TOKEN_RE', 'HEADER_VALUE_RE', 'HTTP_PATH_SAFE',
'IPV4_RE', 'ISO_DATE_RE', 'LOOSE_HTTP_DATE_RE',
'MISSING_FILENAME_TEXT', 'MONTHS', 'MONTHS_LOWER',
'STRICT_DATE_RE', 'TIMEZONE_RE', 'UTC_ZONES', 'WEEKDAY_RE',
'__builtins__', '__doc__', '__file__', '__name__',
'_str2time', '_threading', '_timegm', 'copy', 'cut_port_re',
'debug', 'deepvalues', 'domain_match', 'eff_request_host',
'escape_path', 'http2time', 'httplib', 'is_HDN',
'is_third_party', 'iso2time', 'join_header_words',
'liberal_is_HDN', 'logging', 'lwp_cookie_str', 'month',
'offset_from_tz_string', 'parse_ns_headers', 're', 'reach',
'request_host', 'request_path', 'request_port',
'split_header_words', 'sys', 'time', 'time2isoz',
'time2netscape', 'timegm', 'unmatched',
'uppercase_escaped_char', 'urllib', 'urlparse',
'user_domain_match', 'vals_sorted_by_key',
'warn_unhandled_exception']


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-30 03:23

Message:
Logged In: YES 
user_id=357491

You should use an underscore if you don't have an __all__
defined.  This is mostly for protection for ``from cookielib
import *`` code.  But if you define an __all__ I think you
are fine.

You do not need to document that undocumented globals should
not be relied upon.  Yes, people should know better (I
personally got nailed by the Debian folk for an undocumented
function in site.py that I changed the parameters of).  But
the suggestions Neal and I are making are to protect people
who do their doc checking from the command-line and thus
just do ``import cookielib; dir(cookielib)``.  I know Python
is for use by adults, but sometimes going a small step to
protect the adolescents is also okay.  =)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:31

Message:
Logged In: YES 
user_id=261020

Hmm, perhaps by "do no worse" you simply meant not to rename
the function in this tracker item to a name not beginning
with an initial underscore (since that would introduce a new
non-public module global that does not begin with an
underscore).

In which case, sorry for the rant. :-)

My questions after the rant still stand. ;-)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:26

Message:
Logged In: YES 
user_id=261020

Bleh.

e). Stdlib users should assume all undocumented module
globals are not part of the public API (I guess this should
be go somewhere near the library reference introduction)


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 02:22

Message:
Logged In: YES 
user_id=261020

So, you (Neil) agree with my three numbered action points
below?  You repeat my suggestion that we document this as if
it were a new suggestion; did you read my comment?

Sigh, sorry for being a little grumpy about this, but it's
hard to "do no worse" for a project if that project doesn't
seem itself to be very sure what it considers "worse":

While I must say I *agree* with you that such practices are
not good, if I as somebody apparently unusually inclined to
heavy use of underscores (even in most of my module names,
in library code) actually thought, however foolishly, that I
was *following stdlib conventions* by using *fewer*
underscores (for reasons I'll try to refrain from debating
further here), it does indeed seem pretty clear we're in
need of explicit documentation on this!  So your advice to
"do no worse" is a little annoying at this point... :-)

OK, so, what should get documented, specifically?  And where
should documentation for module authors go?

a). Stdlib module authors should always use underscores for
non-public module globals.

b). Don't know about this one: should non-legacy stdlib
modules (viz, those that follow rule a)) define __all__? 
(perhaps a point against doing this is that it may encourage
import * ?).

c). Stdlib packages should use __init__ to export public names.

d). Any discrepancy between __all__ and the API
documentation is a bug.

e). Stdlib users should assume all non- (I guess this should
be go somewhere near the library reference introduction)

Finally, how about my point 2?  Should I add underscores to
cookielib module globals I consider non-public (== all
undocumented module globals), or not?

Thanks for the feedback, both of you!


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-30 01:37

Message:
Logged In: YES 
user_id=33168

John, at this point (2.x) we should at least do no worse. 
Don't export unnecessary vars in any new code.  We should
also start documenting the situation and work towards
improving it.  For 3k, we should do better and solidify the
rules and do massive cleanup (module by module).  This will
probably involve some arm twisting of Guido. :-)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-30 01:27

Message:
Logged In: YES 
user_id=261020

I changed the exception detail strings to use %r to get
quotes around the filename and quoted "bad" line read from
the file.  That makes it clearer what is part of the
explanatory English text and what is part of the filename
(or part of the quoted bad line, as the case may be). 
Filenames can and do contain spaces, commas, etc.

Your other point stunned me a bit.  I don't think it had
ever even really *occurred* to me that stdlib users might
consider stdlib module globals that are not documented as
public.  Ironically, I think that's because the code from
which cookielib derives is much stricter about this, all
modules starting with '_' and package __init__ exporting a
short list of names -- I guess I thought I was following
stdlib conventions by *not* adding initial underscores all
over the place.  Looking at some other stdlib code, I see
that underscores would have been more conventional after all.

Searching for reassurance, I discovered this from one of
your old python-dev summaries that confirms that
undocumented stdlib module globals are not considered part
of the module public interface:

http://www.python.org/dev/summary/2004-07-16_2004-07-31/#use-the-docs-to-know-what-the-public-api-is-people

e.g. from Tim Peters:

"""
As you noted later, it wasn't part of keyword's documented
interface, and you *always* act at your own risk when you go
beyond the docs.
"""

However, I don't see that this is explicitly documented,
which seems unfortunate to me (even though Tim's statement
is true regardless of any convention Python might have).

So, I guess I should:

1. Write something explicit about this (along the lines of
"Use undocumented module globals at your own risk") for the
stdlib library docs -- perhaps starting from Tim's post --
and submit that as a doc patch.

2. Leave all module global names in cookielib unchanged (so
people using those functions don't suffer gratuitous
breakage, even though any such people are asking for trouble
in the long run).  However, in the thread above, Michael
Hudson disagrees with that, and suggests all such module
globals be renamed.  So suggestions are welcome here on the
best course of action.

3. As you suggest, submit a patch to add an __all__ to
cookielib.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-04-29 22:12

Message:
Logged In: YES 
user_id=357491

Overall the patch looks fine (on vacation so not up for
applying and handling any possible failures so not going to
assign to myself).  But a question and a suggestion.

Why were the error strings changed to use the repr instead
of the string representation?  What does it buy you?

And if you are going to be changing the function name, you
might want to consider using a leading underscore to prevent
people from using it or getting exported.  Otherwise I would
define __all__ for the module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1478993&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 20:15:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 11:15:26 -0700
Subject: [Patches] [ python-Patches-1472854 ] rlcompleter to be usable
	without readline
Message-ID: <E1FaGS6-0004KR-Dr@sc8-sf-web1.sourceforge.net>

Patches item #1472854, was opened at 2006-04-19 09:34
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472854&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.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: rlcompleter to be usable without readline

Initial Comment:
ignores ImportError on readline

the completer's nice core functionality depends not on
readline and is useful standalone. E.g. I like to use
it in projects on Windows.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 18:15

Message:
Logged In: YES 
user_id=849994

Thanks for the patch, applied and updated docs in rev. 45825.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472854&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 20:16:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 11:16:12 -0700
Subject: [Patches] [ python-Patches-1472263 ] fix for #1472251
Message-ID: <E1FaGSq-0004PU-01@sc8-sf-web1.sourceforge.net>

Patches item #1472263, was opened at 2006-04-18 12:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472263&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: Duplicate
Priority: 5
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for #1472251

Initial Comment:
This simple patch ensure that the first argument to the
'run/runeval' functions in bdb.py is a string.For more
details see Bug #1472251.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 18:16

Message:
Logged In: YES 
user_id=849994

Duplicate of #1472257.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472263&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 20:33:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 11:33:54 -0700
Subject: [Patches] [ python-Patches-1479438 ] with statement context
	managers - with should be keyword
Message-ID: <E1FaGjy-0003vB-OP@sc8-sf-web2.sourceforge.net>

Patches item #1479438, was opened at 2006-04-30 18: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=1479438&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
Submitted By: Matt Fleming (splitscreen)
Assigned to: Nobody/Anonymous (nobody)
Summary: with statement context managers - with should be keyword

Initial Comment:
In the language reference documentation whenever the
with statement is referenced in the same sentence as
its context manager 'with' should be a keyword.

For example, 

"With statement context objects also need to implement
this method;"

Attached is a patch that fixes some of the references I
found.

Thanks,
Matt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479438&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 21:31:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 12:31:23 -0700
Subject: [Patches] [ python-Patches-1479438 ] with statement context
	managers - with should be keyword
Message-ID: <E1FaHdb-0004P4-4L@sc8-sf-web4-b.sourceforge.net>

Patches item #1479438, was opened at 2006-04-30 11:33
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479438&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
Submitted By: Matt Fleming (splitscreen)
>Assigned to: Nick Coghlan (ncoghlan)
Summary: with statement context managers - with should be keyword

Initial Comment:
In the language reference documentation whenever the
with statement is referenced in the same sentence as
its context manager 'with' should be a keyword.

For example, 

"With statement context objects also need to implement
this method;"

Attached is a patch that fixes some of the references I
found.

Thanks,
Matt

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-30 12:31

Message:
Logged In: YES 
user_id=33168

Nick, can you take care of this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479438&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 21:34:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 12:34:31 -0700
Subject: [Patches] [ python-Patches-1479438 ] with statement context
	managers - with should be keyword
Message-ID: <E1FaHgd-0005tv-QI@sc8-sf-web2.sourceforge.net>

Patches item #1479438, was opened at 2006-04-30 18:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479438&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
Submitted By: Matt Fleming (splitscreen)
>Assigned to: Nobody/Anonymous (nobody)
Summary: with statement context managers - with should be keyword

Initial Comment:
In the language reference documentation whenever the
with statement is referenced in the same sentence as
its context manager 'with' should be a keyword.

For example, 

"With statement context objects also need to implement
this method;"

Attached is a patch that fixes some of the references I
found.

Thanks,
Matt

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 19:34

Message:
Logged In: YES 
user_id=849994

Thanks! Applied as rev. 45826.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-30 19:31

Message:
Logged In: YES 
user_id=33168

Nick, can you take care of this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479438&group_id=5470

From noreply at sourceforge.net  Sun Apr 30 23:27:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 14:27:45 -0700
Subject: [Patches] [ python-Patches-1464708 ] fixed handling of nested
	comments in mail addresses
Message-ID: <E1FaJSD-00005k-DY@sc8-sf-web4-b.sourceforge.net>

Patches item #1464708, was opened at 2006-04-05 02:35
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464708&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.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: William McVey (wamcvey)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: fixed handling of nested  comments in mail addresses

Initial Comment:
RFC 2822 allows for comments to include other comments
in a mail address. email.Utils.getaddresses() handled
addresses with a comment, but incorrectly advanced the
parsing index twice after a comment finished. This
would cause the outer closing paren in an address like:
    Foo ((FOO Rocks)) <foo at bar.com>
to be missed, and treating the rest of the line as part
of the outer comment.

This patch fixes the bug and adds a testcase to look
for the bug.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-04-30 17:27

Message:
Logged In: YES 
user_id=12800

Applied to Python 2.4 for email 3.0 in r45829.  This needs
to be back ported to Python 2.3 for email 2.5 and forward
ported to Python 2.5 for email 4.0.

----------------------------------------------------------------------

Comment By: William McVey (wamcvey)
Date: 2006-04-05 15:51

Message:
Logged In: YES 
user_id=25956

I see now that there appears to be duplicate patches against
the email package attached. I'll go ahead and remove the
duplicate, leaving one patch for email package and one patch
for rfc822.py. 

Oh, and it probably goes without saying, but the first patch
is relative to the 'email' package directory and the second
is relative to the Lib directory in which rfc822.py is located.

----------------------------------------------------------------------

Comment By: William McVey (wamcvey)
Date: 2006-04-05 15:46

Message:
Logged In: YES 
user_id=25956

I just realized that I only submitted the patch for the
email package and that the same bug exists in the rfc822.py
package. Even though deprecated, I imagine bug fixes are
still appropriate, so I'm attaching a second attachment
which patch rfc822.py and adds a testcase for this condition
to test/test_rfc822.py. I also noticed that the testcase
driver in test_rfc822.py emitted a print statement error but
didn't raise a condition when the parsed name or address
differed from the expected name. I've adjusted the driver to
use assertions so that the error condition are more
noticeable (e.g. error status codes).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-05 02:46

Message:
Logged In: YES 
user_id=33168

Barry, has the new email addressed this?

----------------------------------------------------------------------

Comment By: William McVey (wamcvey)
Date: 2006-04-05 02:38

Message:
Logged In: YES 
user_id=25956

hmm, didn't seem to attach my patch the first time. Let's
try adding it again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1464708&group_id=5470