From noreply at sourceforge.net  Fri Apr  1 05:59:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 05:59:44 2005
Subject: [Patches] [ python-Patches-1174589 ] hierarchical regular expression
Message-ID: <E1DHDJu-0005CH-2r@sc8-sf-web4.sourceforge.net>

Patches item #1174589, was opened at 2005-04-01 03: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=1174589&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Ottrey (ottrey)
Assigned to: Nobody/Anonymous (nobody)
Summary: hierarchical regular expression

Initial Comment:
( from the re2 sourceforge project
http://pyre2.sourceforge.net )

The re2 library provides a hierarchical regular
expression extension to the re library.

re2 extracts a hierarchy of named groups from a string,
rather than the flat, incomplete dictionary that the
standard re module returns. 

>>> import re
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat1=re.compile(regex)
>>> m=pat1.match(buf)
>>> m.groupdict()
{'verse': '10 lords a-leaping', 'number': '10',
'activity': 'lords a-leaping'}

>>> import re2
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat2=re2.compile(regex)
>>> x=pat2.extract(buf)
>>> x
{'verse': [{'number': '12', 'activity': 'drummers
drumming'}, {'number': '11', 'activity': 'pipers
piping'}, {'number': '10', 'activity': 'lords a-leaping'}]}

(See http://pyre2.sourceforge.net/ for more details.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174589&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 07:24:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 07:24:47 2005
Subject: [Patches] [ python-Patches-1174614 ] site enhancements
Message-ID: <E1DHEeC-0003ob-Qy@sc8-sf-web1.sourceforge.net>

Patches item #1174614, was opened at 2005-04-01 00: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=1174614&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: site enhancements

Initial Comment:
The current site.py has three major deficiencies:

(1) All site dirs must exist on the filesystem:  Since PEP 302 (New 
Import Hooks) was adopted, this is not necessarily true.  
sys.meta_path and sys.path_hooks can have valid uses for non-
existent paths.  Even the standard zipimport hook supports in-zip-
file paths (i.e. foo.zip/bar).

(2) The directories added to sys.path by .pth files are not scanned 
for further .pth files.  If they were, you could make life much easier 
on developers and users of multi-user systems.  For example, it 
would be possible for an administrator to drop in a .pth file into the 
system-wide site-packages to allow users to have their own local 
site-packages folder.  Currently, you could try this, but it wouldn't 
work because many packages such as PIL, Numeric, and PyObjC 
take advantage of .pth files during their installation.

(3) To support the above use case, .pth files should be allowed to 
use os.path.expanduser(), so you can toss a tilde in front and do the 
right thing.  Currently, the only way to support (2) is to use an ugly 
"import" pth hook.

Attached is a patch to CVS HEAD that:
(1) Removes the os.path.exists() / os.path.isdir() restrictions
(2) Changes the .pth reader to use addsitedir() (top down) rather than 
sys.path.append()
(3) makepath() uses os.path.expanduser() after the os.path.join().

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 21:30:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 21:30:26 2005
Subject: [Patches] [ python-Patches-1175004 ] Export more libreadline API
	functions
Message-ID: <E1DHRqZ-0006sm-QC@sc8-sf-web3.sourceforge.net>

Patches item #1175004, was opened at 2005-04-01 11: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=1175004&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Edge (bruce_edge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Export more libreadline API functions

Initial Comment:
The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175004&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 21:57:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 21:57:27 2005
Subject: [Patches] [ python-Patches-1174589 ] hierarchical regular expression
Message-ID: <E1DHSGf-0001E3-Ld@sc8-sf-web1.sourceforge.net>

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

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Ottrey (ottrey)
Assigned to: Nobody/Anonymous (nobody)
Summary: hierarchical regular expression

Initial Comment:
( from the re2 sourceforge project
http://pyre2.sourceforge.net )

The re2 library provides a hierarchical regular
expression extension to the re library.

re2 extracts a hierarchy of named groups from a string,
rather than the flat, incomplete dictionary that the
standard re module returns. 

>>> import re
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat1=re.compile(regex)
>>> m=pat1.match(buf)
>>> m.groupdict()
{'verse': '10 lords a-leaping', 'number': '10',
'activity': 'lords a-leaping'}

>>> import re2
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat2=re2.compile(regex)
>>> x=pat2.extract(buf)
>>> x
{'verse': [{'number': '12', 'activity': 'drummers
drumming'}, {'number': '11', 'activity': 'pipers
piping'}, {'number': '10', 'activity': 'lords a-leaping'}]}

(See http://pyre2.sourceforge.net/ for more details.)

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

>Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 21:57

Message:
Logged In: YES 
user_id=21627

Is this a patch? If so, where is the code, and are you its
author?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174589&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 22:53:54 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 22:53:56 2005
Subject: [Patches] [ python-Patches-1175048 ] Export more libreadline API
	functions
Message-ID: <E1DHT9O-0003xg-HG@sc8-sf-web4.sourceforge.net>

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

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Edge (bruce_edge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Export more libreadline API functions

Initial Comment:
The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175048&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 22:57:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 22:57:58 2005
Subject: [Patches] [ python-Patches-1175004 ] Export more libreadline API
	functions
Message-ID: <E1DHTDH-0001v6-PI@sc8-sf-web3.sourceforge.net>

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

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Edge (bruce_edge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Export more libreadline API functions

Initial Comment:
The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

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

>Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 22:57

Message:
Logged In: YES 
user_id=21627

Have these function always been available in readline (i.e.
all readline versions)? If not, please provide configure.in
changes.

Also, please provide Doc/lib/libreadline.tex changes.

If you cannot provide these things, please indicate so.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175004&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 22:58:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 22:58:58 2005
Subject: [Patches] [ python-Patches-1175048 ] Export more libreadline API
	functions
Message-ID: <E1DHTEG-0007Bx-2F@sc8-sf-web2.sourceforge.net>

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

Category: Modules
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Bruce Edge (bruce_edge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Export more libreadline API functions

Initial Comment:
The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

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

>Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 22:58

Message:
Logged In: YES 
user_id=21627

I guess this is a duplicate of 1175004. Closing it as such;
please correct me if I'm wrong.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175048&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 23:16:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 23:17:01 2005
Subject: [Patches] [ python-Patches-1175004 ] Export more libreadline API
	functions
Message-ID: <E1DHTVi-0004SA-IY@sc8-sf-web1.sourceforge.net>

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

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Edge (bruce_edge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Export more libreadline API functions

Initial Comment:
The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

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

>Comment By: Bruce Edge (bruce_edge)
Date: 2005-04-01 13:16

Message:
Logged In: YES 
user_id=1251183

AFAIK, yes, they have always been available, at least in
Linux. I've been carrying this patch around since python 2.1.
I have not looked into this on other platforms.
I can't commit to providing doc changes. With my schedule,
it was all I could do to package it up and send it in. 
I'm sorry, I know this is incomplete work, but I figure
someone may be able to use it.

-Bruce

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 12:57

Message:
Logged In: YES 
user_id=21627

Have these function always been available in readline (i.e.
all readline versions)? If not, please provide configure.in
changes.

Also, please provide Doc/lib/libreadline.tex changes.

If you cannot provide these things, please indicate so.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175004&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 23:17:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 23:17:23 2005
Subject: [Patches] [ python-Patches-1175070 ] Patch for whitespace
	enforcement
Message-ID: <E1DHTW5-0004Sp-10@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Patch for whitespace enforcement

Initial Comment:
A first proof-of-concept version of the whitespace
enforcement feature I announced in my blog:
http://www.artima.com/weblogs/viewpost.jsp?thread=101968 .

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175070&group_id=5470
From noreply at sourceforge.net  Fri Apr  1 23:31:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  1 23:31:06 2005
Subject: [Patches] [ python-Patches-1175004 ] Export more libreadline API
	functions
Message-ID: <E1DHTjM-00053K-EI@sc8-sf-web1.sourceforge.net>

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

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Edge (bruce_edge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Export more libreadline API functions

Initial Comment:
The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

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

>Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 23:31

Message:
Logged In: YES 
user_id=21627

As incomplete work, we might have to reject it, unless
somebody volunteers to complete it. Let's give it one month
from now.

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

Comment By: Bruce Edge (bruce_edge)
Date: 2005-04-01 23:16

Message:
Logged In: YES 
user_id=1251183

AFAIK, yes, they have always been available, at least in
Linux. I've been carrying this patch around since python 2.1.
I have not looked into this on other platforms.
I can't commit to providing doc changes. With my schedule,
it was all I could do to package it up and send it in. 
I'm sorry, I know this is incomplete work, but I figure
someone may be able to use it.

-Bruce

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 22:57

Message:
Logged In: YES 
user_id=21627

Have these function always been available in readline (i.e.
all readline versions)? If not, please provide configure.in
changes.

Also, please provide Doc/lib/libreadline.tex changes.

If you cannot provide these things, please indicate so.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175004&group_id=5470
From noreply at sourceforge.net  Sat Apr  2 01:10:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 01:10:21 2005
Subject: [Patches] [ python-Patches-1174589 ] hierarchical regular expression
Message-ID: <E1DHVHO-0006zl-EA@sc8-sf-web3.sourceforge.net>

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

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Ottrey (ottrey)
Assigned to: Nobody/Anonymous (nobody)
Summary: hierarchical regular expression

Initial Comment:
( from the re2 sourceforge project
http://pyre2.sourceforge.net )

The re2 library provides a hierarchical regular
expression extension to the re library.

re2 extracts a hierarchy of named groups from a string,
rather than the flat, incomplete dictionary that the
standard re module returns. 

>>> import re
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat1=re.compile(regex)
>>> m=pat1.match(buf)
>>> m.groupdict()
{'verse': '10 lords a-leaping', 'number': '10',
'activity': 'lords a-leaping'}

>>> import re2
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat2=re2.compile(regex)
>>> x=pat2.extract(buf)
>>> x
{'verse': [{'number': '12', 'activity': 'drummers
drumming'}, {'number': '11', 'activity': 'pipers
piping'}, {'number': '10', 'activity': 'lords a-leaping'}]}

(See http://pyre2.sourceforge.net/ for more details.)

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

>Comment By: Chris Ottrey (ottrey)
Date: 2005-04-01 23:10

Message:
Logged In: YES 
user_id=609576

Sorry, it's more an extension than a patch.
(Although maybe it could be applied as a patch to the re
library.)
(BTW Where is the correct place to submit extensions?)

The code is in this subversion repository:
  http://pintje.servebeer.com/svn/pyre2/trunk/

Or available for download here:
  http://sourceforge.net/project/showfiles.php?group_id=134583

And has a development wiki here:
  http://py.redsoft.be/pyre2/wiki/

And yes, I'm the author.

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

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

Message:
Logged In: YES 
user_id=21627

Is this a patch? If so, where is the code, and are you its
author?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174589&group_id=5470
From noreply at sourceforge.net  Sat Apr  2 01:49:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 01:49:15 2005
Subject: [Patches] [ python-Patches-1174589 ] hierarchical regular expression
Message-ID: <E1DHVt1-0008G8-Uv@sc8-sf-web3.sourceforge.net>

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

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Ottrey (ottrey)
Assigned to: Nobody/Anonymous (nobody)
Summary: hierarchical regular expression

Initial Comment:
( from the re2 sourceforge project
http://pyre2.sourceforge.net )

The re2 library provides a hierarchical regular
expression extension to the re library.

re2 extracts a hierarchy of named groups from a string,
rather than the flat, incomplete dictionary that the
standard re module returns. 

>>> import re
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat1=re.compile(regex)
>>> m=pat1.match(buf)
>>> m.groupdict()
{'verse': '10 lords a-leaping', 'number': '10',
'activity': 'lords a-leaping'}

>>> import re2
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat2=re2.compile(regex)
>>> x=pat2.extract(buf)
>>> x
{'verse': [{'number': '12', 'activity': 'drummers
drumming'}, {'number': '11', 'activity': 'pipers
piping'}, {'number': '10', 'activity': 'lords a-leaping'}]}

(See http://pyre2.sourceforge.net/ for more details.)

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

>Comment By: Martin v. L?wis (loewis)
Date: 2005-04-02 01:49

Message:
Logged In: YES 
user_id=21627

We accept extensions only by means of patches. So you would
create a patch (as a unified or context diff) for the
current CVS;for completely new files, providing a tar ball
is also reasonable. I expect that you don't suggest literal
inclusion of the svn trunk directory into the dist/src
directory of the Python distribution.

However, in the specific case, I think whether or not the
new functionality should  be added to Python at all probably
needs discussion. I recommend to ask on python-dev; be
prepared to write a PEP. As a starting point, I'm personally
concerned to have a module named "re2" in the standard
library. This will cause confusion to the users; it might be
better to merge the functionality into the re module.

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

Comment By: Chris Ottrey (ottrey)
Date: 2005-04-02 01:10

Message:
Logged In: YES 
user_id=609576

Sorry, it's more an extension than a patch.
(Although maybe it could be applied as a patch to the re
library.)
(BTW Where is the correct place to submit extensions?)

The code is in this subversion repository:
  http://pintje.servebeer.com/svn/pyre2/trunk/

Or available for download here:
  http://sourceforge.net/project/showfiles.php?group_id=134583

And has a development wiki here:
  http://py.redsoft.be/pyre2/wiki/

And yes, I'm the author.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 21:57

Message:
Logged In: YES 
user_id=21627

Is this a patch? If so, where is the code, and are you its
author?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174589&group_id=5470
From noreply at sourceforge.net  Sat Apr  2 08:39:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 08:39:45 2005
Subject: [Patches] [ python-Patches-1173134 ] improvement of the script
	adaptation for the win32 platform
Message-ID: <E1DHcIH-0007Tz-6o@sc8-sf-web2.sourceforge.net>

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

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vivian De Smedt (vds2212)
Assigned to: Nobody/Anonymous (nobody)
Summary: improvement of the script adaptation for the win32 platform

Initial Comment:
Distutils have a script functionality that copy the 
corresponding file
into a common script folder (that could be on the 
path) and sligthly
modify the first line of the script to reflect the path 
of the python
executable.

It is very nice because it make new commands 
directly available but 
for the window platform I think it could be 
improved.

First the extention of the script could be .bat such 
that they will be
accessible as commands as soon as the script 
folder is in the path.

Second the first line adaptation could be slightly 
different and take
advantage of the -x option of the python executable

#!python foo bar

could become:

@C:\Python24\python.exe -x "%~f0" foo bar  & exit /
b

instead of:

#!C:\Python24\python.exe -x "%~f0"  foo bar & exit /
b

In attachement I add my modified version of the 
build_scripts.py file (Revision 1.25, the head of the 
30th of March)



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

>Comment By: Vivian De Smedt (vds2212)
Date: 2005-04-02 08:39

Message:
Logged In: YES 
user_id=511447

 Here is a small summary of the remark made arround 
the she-bang modification of the windows platform.

1. Trent let us know that the she-bang modification 
works only for the win nt sons and that in general it is 
better to use the .bat extension instead of the .cmd one

2. I realize that we shouldn't change the extension of a 
script if it exist since the extention could be usefull to 
determine which version of python to run
 - pythonw for the .pyw extention
 - python for the .py extention

According to these remarks and in the purpose to be 
as conservative as possible I make this another 
proposition:

The change in the she bang will happend only if
 - the win32 platform is detected (os.name == "nt")
 - the platform is win NT son (os.environ["OS"] == 
"Windows_NT")
 - the original script had no extension (os.path.
splitext(outfile)[1] == "")

Furthermore I add the %* in the new nt she-bang to let 
the underlying script know about command line 
argument.

such that the unix she-bang:

    #!python foo bar

will become:

    @C:\Python24\Python.exe -x "%%~f0" foo bar %* & 
exit /b

I think that in these conditions the change could only 
improve the existing situation at least it improve for 
some them (Zope, Chetaah, PyCrust, IPython)

Tell me what you think about the proposed change.

Vivian.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173134&group_id=5470
From noreply at sourceforge.net  Sat Apr  2 09:16:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 09:16:26 2005
Subject: [Patches] [ python-Patches-1174589 ] hierarchical regular expression
Message-ID: <E1DHcrn-0004oy-UA@sc8-sf-web4.sourceforge.net>

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

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Ottrey (ottrey)
Assigned to: Nobody/Anonymous (nobody)
Summary: hierarchical regular expression

Initial Comment:
( from the re2 sourceforge project
http://pyre2.sourceforge.net )

The re2 library provides a hierarchical regular
expression extension to the re library.

re2 extracts a hierarchy of named groups from a string,
rather than the flat, incomplete dictionary that the
standard re module returns. 

>>> import re
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat1=re.compile(regex)
>>> m=pat1.match(buf)
>>> m.groupdict()
{'verse': '10 lords a-leaping', 'number': '10',
'activity': 'lords a-leaping'}

>>> import re2
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat2=re2.compile(regex)
>>> x=pat2.extract(buf)
>>> x
{'verse': [{'number': '12', 'activity': 'drummers
drumming'}, {'number': '11', 'activity': 'pipers
piping'}, {'number': '10', 'activity': 'lords a-leaping'}]}

(See http://pyre2.sourceforge.net/ for more details.)

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

>Comment By: Chris Ottrey (ottrey)
Date: 2005-04-02 07:16

Message:
Logged In: YES 
user_id=609576

Ok.
I'll ask on python-dev then.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 23:49

Message:
Logged In: YES 
user_id=21627

We accept extensions only by means of patches. So you would
create a patch (as a unified or context diff) for the
current CVS;for completely new files, providing a tar ball
is also reasonable. I expect that you don't suggest literal
inclusion of the svn trunk directory into the dist/src
directory of the Python distribution.

However, in the specific case, I think whether or not the
new functionality should  be added to Python at all probably
needs discussion. I recommend to ask on python-dev; be
prepared to write a PEP. As a starting point, I'm personally
concerned to have a module named "re2" in the standard
library. This will cause confusion to the users; it might be
better to merge the functionality into the re module.

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

Comment By: Chris Ottrey (ottrey)
Date: 2005-04-01 23:10

Message:
Logged In: YES 
user_id=609576

Sorry, it's more an extension than a patch.
(Although maybe it could be applied as a patch to the re
library.)
(BTW Where is the correct place to submit extensions?)

The code is in this subversion repository:
  http://pintje.servebeer.com/svn/pyre2/trunk/

Or available for download here:
  http://sourceforge.net/project/showfiles.php?group_id=134583

And has a development wiki here:
  http://py.redsoft.be/pyre2/wiki/

And yes, I'm the author.

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

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

Message:
Logged In: YES 
user_id=21627

Is this a patch? If so, where is the code, and are you its
author?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174589&group_id=5470
From noreply at sourceforge.net  Sat Apr  2 17:18:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 17:19:01 2005
Subject: [Patches] [ python-Patches-1175070 ] Patch for whitespace
	enforcement
Message-ID: <E1DHkOp-0002HJ-4w@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Patch for whitespace enforcement

Initial Comment:
A first proof-of-concept version of the whitespace
enforcement feature I announced in my blog:
http://www.artima.com/weblogs/viewpost.jsp?thread=101968 .

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2005-04-02 10:18

Message:
Logged In: YES 
user_id=6380

April Fool!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175070&group_id=5470
From noreply at sourceforge.net  Sat Apr  2 18:44:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 18:44:39 2005
Subject: [Patches] [ python-Patches-624325 ] attributes for urlsplit,
	urlparse result
Message-ID: <E1DHljg-0004Zy-Vo@sc8-sf-web4.sourceforge.net>

Patches item #624325, was opened at 2002-10-16 23:59
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&group_id=5470

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: Reinhold Birkenfeld (birkenfeld)
Date: 2005-04-02 18: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 21: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 18: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 22: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 19: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  2 19:10:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 19:10:47 2005
Subject: [Patches] [ python-Patches-695275 ] environment parameter for popen2
Message-ID: <E1DHm8y-0006Rb-7i@sc8-sf-web1.sourceforge.net>

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

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
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: Reinhold Birkenfeld (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  Sat Apr  2 19:13:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 19:13:52 2005
Subject: [Patches] [ python-Patches-1144549 ] cgitb: make more usable for
	'binary-only' sw (new patch)
Message-ID: <E1DHmBy-0002z2-If@sc8-sf-web3.sourceforge.net>

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

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Reinhold Birkenfeld (birkenfeld)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgitb: make more usable for 'binary-only' sw (new patch)

Initial Comment:
see patch #751943:

"""
I am abusing cgitb to show a traceback window for a GUI
application in Qt. In such a case, the source code to
the program is not always available. The stack trace is
anyway useful to be submitted to the developers of the
code. I attach a patch that should add some info to the
HTML traceback made by cgitb in case the source file is
not available.
"""

This new patch, however, does not generate a link to
"file://?" if the filename is not known.

At the same time, it stops shadowing file() by renaming
local vars.

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

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-04-02 19:13

Message:
Logged In: YES 
user_id=1188172

Deleted first, useless patch.

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

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-02-20 08:17

Message:
Logged In: YES 
user_id=1188172

You're right, the 'or ?' must vanish; see attached second patch.

But I did diff against CVS HEAD, didn't I?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-02-20 03:14

Message:
Logged In: NO 

!             filename = os.path.abspath(filename) or '?'

Why is the 'or ?' still there?

Also, patches are preferred to be against CVS HEAD, rather
than against a previous patched version.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144549&group_id=5470
From noreply at sourceforge.net  Sat Apr  2 20:51:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 20:51:54 2005
Subject: [Patches] [ python-Patches-1167709 ] ast for decorators
Message-ID: <E1DHnip-0006GV-Ow@sc8-sf-web3.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Brett Cannon (bcannon)
Summary: ast for decorators

Initial Comment:
This patch adds the generation of AST nodes for
decorators.  There is no compiler support for
decorators yet.  Note I also added support for ignoring
NULL's passed to the *_free functions generated by
asdl_c.py so that error handling is somewhat simplified.

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-04-02 18:51

Message:
Logged In: YES 
user_id=35752

Thanks for the patch.  The only change I made was to change
// comments
to /* ... */ comments.

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

Comment By: John Ehresman (jpe)
Date: 2005-03-22 17:24

Message:
Logged In: YES 
user_id=22785

New patch that handles @dottedname correctly and implements
bytecode generation.  The test_decorators test passes.

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

Comment By: John Ehresman (jpe)
Date: 2005-03-21 21:11

Message:
Logged In: YES 
user_id=22785

This doesn't quite work.  I just realized when working on
the compiler portion that @foo is different than @foo().

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1167709&group_id=5470
From noreply at sourceforge.net  Sat Apr  2 21:00:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  2 21:00:59 2005
Subject: [Patches] [ python-Patches-1170272 ] [ast branch] unicode literal
	fixes
Message-ID: <E1DHnrd-0001mn-Jl@sc8-sf-web1.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Brett Cannon (bcannon)
Summary: [ast branch] unicode literal fixes

Initial Comment:
Attached patch fixes test_eval by dealing with unicode
input correctly.  I'm also compiling tokenizer.c
directly rather than tokenizer_pgen.c --
tokenizer_pgen.c simply defines PGEN and then includes
tokenizer.c, which disables some of the unicode
support.  I don't think tokenizer_pgen.c is needed.


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

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-04-02 19:00

Message:
Logged In: YES 
user_id=35752

Commited.  Thanks for the patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1170272&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 16:11:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 16:11:24 2005
Subject: [Patches] [ python-Patches-1173475 ] __slots__ for subclasses of
	variable length types
Message-ID: <E1DI5ov-0006fD-AB@sc8-sf-web2.sourceforge.net>

Patches item #1173475, was opened at 2005-03-30 17:09
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173475&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Armin Rigo (arigo)
Summary: __slots__ for subclasses of variable length types

Initial Comment:
This is a first, rough cut at allowing subclasses of variable length 
types to have __slots__ of all flavours, not just __dict__.

The motivation is trying to understand and document what's going on 
in typeobject.c, and the less special cases knocking around the 
better.

This patch also allows instances of such classes to be weakly 
referenced.

What is missing: tests, lots of tests, documentation.  Also, the code 
is a bit hackish at various points; a degree of clean up can certainly 
be acheived.

Also, I think my code probably fails to cope with code like:

class A(str):
 pass # implicitly adds __dict__, __weakref__
class B(A):
 __slots__ = ["a", "b"]

b = B()
b.c = 1

Hmm, yes.  Oh well, no time to fix today (I don't think it's that big a 
deal).

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-03 14:11

Message:
Logged In: YES 
user_id=4771

I'm confused: the rule for negative slot offsets appear to be different to the one for tp_dictoffset, which only increases the amount of obscurity around here.

tp_dictoffset counts relative to the end of the object, whereas in your patch negative slot offsets are a different trick to mean "relative to the start but skipping the varsized part".  The difference shows up when subclassing increases tp_basicsize.  This should be resolved one way or the other -- and I think that a clear picture of the various parts of the object and how they are measured would be a good start.

That's also related to your proposed change to extra_ivars(), which would become slightly more permissive; I strongly suspect that it would allow more strange segfaulting cases to sneak in undetected...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173475&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 16:24:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 16:24:44 2005
Subject: [Patches] [ python-Patches-1172711 ] long long support for array
	module
Message-ID: <E1DI61p-00034q-OP@sc8-sf-web4.sourceforge.net>

Patches item #1172711, was opened at 2005-03-29 18:58
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1172711&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Oren Tirosh (orenti)
Assigned to: Nobody/Anonymous (nobody)
Summary: long long support for array module

Initial Comment:
This patch adds signed and unsigned long long support
to the array module. These types are already supported
by the struct module and use the same format characters
(q/Q).

Also corrects a minor bug in PyLong_AsUnsignedLongLong
which reports a BadInternalCall for arguments of
inappropriate type rather than a mere TypeError as
reported by the other conversion functions.


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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-03 14:24

Message:
Logged In: YES 
user_id=4771

No two conversion function in longobject.c seem to have the same rules for what to do about non-long objects :-(  I'm afraid some clean-up would be useful, but also difficult for fear of breaking existing user C code :-(

In fact, your patch doesn't apply with today's CVS because someone already tried to add some magic in PyObject_AsLongLong().  It also fails on test_array.py and applies uncleanly on arraymodule.c.

Also, it needs to update the array module documentation.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1172711&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 16:32:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 16:32:20 2005
Subject: [Patches] [ python-Patches-1173475 ] __slots__ for subclasses of
	variable length types
Message-ID: <E1DI69A-0000o7-Sz@sc8-sf-web3.sourceforge.net>

Patches item #1173475, was opened at 2005-03-30 18:09
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173475&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Armin Rigo (arigo)
Summary: __slots__ for subclasses of variable length types

Initial Comment:
This is a first, rough cut at allowing subclasses of variable length 
types to have __slots__ of all flavours, not just __dict__.

The motivation is trying to understand and document what's going on 
in typeobject.c, and the less special cases knocking around the 
better.

This patch also allows instances of such classes to be weakly 
referenced.

What is missing: tests, lots of tests, documentation.  Also, the code 
is a bit hackish at various points; a degree of clean up can certainly 
be acheived.

Also, I think my code probably fails to cope with code like:

class A(str):
 pass # implicitly adds __dict__, __weakref__
class B(A):
 __slots__ = ["a", "b"]

b = B()
b.c = 1

Hmm, yes.  Oh well, no time to fix today (I don't think it's that big a 
deal).

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-03 15:32

Message:
Logged In: YES 
user_id=6656

> I'm confused: the rule for negative slot offsets appear to be
> different to the one for tp_dictoffset

Yes.  I think this is actually necessary.

Consider:

class S(str):
    __slots__ = ['a']

you'd except S.__dict__['a'].__offset__ (well, if the attribute existed) to be 
-4.

Then

class T(S):
    __slots__ = ['b']

then using the 'from the end of the object' rule for  T().a would actually find 
T.b.  (IOW, T.__dict__['b'].__offset__ == T.__dict__['a'].__offset__ == -4).  
The alternative would be to somehow override all the slots in S when T is 
defined -- and this doesn't seem wise.

__dict__ indeed works differently, because 
instance.__class__.__dictoffset__ is updated on subclassing.  You could 
make __dict__ work like the slots mentioned above, but then you'd have to 
find the '__dict__' descriptor every time you wanted to access an 
instance's dictionary, and that would be slow (and might even not really 
work, but I don't want to risk brain-explosion by thinking about it too hard)

> which only increases the amount of obscurity around here.

Yeah, sorry about that.

I think something I've realised over the past few days is that __dict__ 
really is special.  I'm not sure __weakref__ is (though I guess it's special in 
that you want to be able to access it from C without any risk of executing 
Python level code, i.e. replacing Py_GETWEAKREFLIST(ob) with 
PyOjbect_GetAttrString(ob, "__weakref__") would be unfortunate).

> This should be resolved one way or the other 

See above -- don't think you can.

> -- and I think that
> a clear picture of the various parts of the object and how they
> are measured would be a good start.

No kidding here!

> That's also related to your proposed change to extra_ivars(),
> which would become slightly more permissive; I strongly suspect
> that it would allow more strange segfaulting cases to sneak in
> undetected...

Almost certainly!

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-03 15:11

Message:
Logged In: YES 
user_id=4771

I'm confused: the rule for negative slot offsets appear to be different to the one for tp_dictoffset, which only increases the amount of obscurity around here.

tp_dictoffset counts relative to the end of the object, whereas in your patch negative slot offsets are a different trick to mean "relative to the start but skipping the varsized part".  The difference shows up when subclassing increases tp_basicsize.  This should be resolved one way or the other -- and I think that a clear picture of the various parts of the object and how they are measured would be a good start.

That's also related to your proposed change to extra_ivars(), which would become slightly more permissive; I strongly suspect that it would allow more strange segfaulting cases to sneak in undetected...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173475&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 16:43:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 16:43:19 2005
Subject: [Patches] [ python-Patches-1170323 ] Method for cell objects to
	access contents
Message-ID: <E1DI6Jo-0006A9-TW@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul cannon (paulcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Method for cell objects to access contents

Initial Comment:
Having poked around a little bit, I found it's not
simple to get at the contents of a cell object from
Python. It's not the sort of thing that one needs to be
doing very frequently, but I've run into a few
situations recently where it would be really useful
from a debugging standpoint.

You can get at a cell object containing a given value
by making a quick closure and looking at the
func_closure attribute:

  (lambda x: lambda: x)(some_value).func_closure[0]

but there's not anything we can easily do with that
object to find out what it's pointing at. The str()
representation only tells us the id of the contained value.

This trivial patch creates a "value()" method for cell
objects that returns a new reference to the contained
object, for introspection purposes.

I should mention it's not the only way to accomplish
this; you can also get at the contents of a cell by
creating a new function from a code object and
manufacturing its func_closures tuple from the cell you
already have:

def get_cell_value(cell):
    return type(lambda: 0)(
        (lambda x: lambda: x)(0).func_code, {}, None,
None, (cell,)
    )()

..but that's non-obvious and not particularly convenient.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-03 14:43

Message:
Logged In: YES 
user_id=4771

I guess this can be safely sneaked in 2.5, as cells are quite undocumented internal objects anyway.  I believe it would be more natural to access the value as an attribute "c.value", though.  (Possibly even a read-write attribute?)

Probably not in 2.4, though; there is a no-new-feature policy.

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

Comment By: paul cannon (paulcannon)
Date: 2005-03-25 03:42

Message:
Logged In: YES 
user_id=222090

I should mention the patch applies against both 2.4 and the
latest 2.5 from CVS.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1170323&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 17:27:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 17:27:29 2005
Subject: [Patches] [ python-Patches-1173475 ] __slots__ for subclasses of
	variable length types
Message-ID: <E1DI70Y-0007jR-8q@sc8-sf-web1.sourceforge.net>

Patches item #1173475, was opened at 2005-03-30 17:09
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173475&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Armin Rigo (arigo)
Summary: __slots__ for subclasses of variable length types

Initial Comment:
This is a first, rough cut at allowing subclasses of variable length 
types to have __slots__ of all flavours, not just __dict__.

The motivation is trying to understand and document what's going on 
in typeobject.c, and the less special cases knocking around the 
better.

This patch also allows instances of such classes to be weakly 
referenced.

What is missing: tests, lots of tests, documentation.  Also, the code 
is a bit hackish at various points; a degree of clean up can certainly 
be acheived.

Also, I think my code probably fails to cope with code like:

class A(str):
 pass # implicitly adds __dict__, __weakref__
class B(A):
 __slots__ = ["a", "b"]

b = B()
b.c = 1

Hmm, yes.  Oh well, no time to fix today (I don't think it's that big a 
deal).

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-03 15:27

Message:
Logged In: YES 
user_id=4771

I think it's still possible to give slot.offset the same meaning as tp_dictoffset, even given the additional constrain that it can't change upon subclassing.  In your example classes S and T, we can put 'b' before 'a' in memory, so that a.offset==-4 (for both S and T) and b.offset==-8.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-03 14:32

Message:
Logged In: YES 
user_id=6656

> I'm confused: the rule for negative slot offsets appear to be
> different to the one for tp_dictoffset

Yes.  I think this is actually necessary.

Consider:

class S(str):
    __slots__ = ['a']

you'd except S.__dict__['a'].__offset__ (well, if the attribute existed) to be 
-4.

Then

class T(S):
    __slots__ = ['b']

then using the 'from the end of the object' rule for  T().a would actually find 
T.b.  (IOW, T.__dict__['b'].__offset__ == T.__dict__['a'].__offset__ == -4).  
The alternative would be to somehow override all the slots in S when T is 
defined -- and this doesn't seem wise.

__dict__ indeed works differently, because 
instance.__class__.__dictoffset__ is updated on subclassing.  You could 
make __dict__ work like the slots mentioned above, but then you'd have to 
find the '__dict__' descriptor every time you wanted to access an 
instance's dictionary, and that would be slow (and might even not really 
work, but I don't want to risk brain-explosion by thinking about it too hard)

> which only increases the amount of obscurity around here.

Yeah, sorry about that.

I think something I've realised over the past few days is that __dict__ 
really is special.  I'm not sure __weakref__ is (though I guess it's special in 
that you want to be able to access it from C without any risk of executing 
Python level code, i.e. replacing Py_GETWEAKREFLIST(ob) with 
PyOjbect_GetAttrString(ob, "__weakref__") would be unfortunate).

> This should be resolved one way or the other 

See above -- don't think you can.

> -- and I think that
> a clear picture of the various parts of the object and how they
> are measured would be a good start.

No kidding here!

> That's also related to your proposed change to extra_ivars(),
> which would become slightly more permissive; I strongly suspect
> that it would allow more strange segfaulting cases to sneak in
> undetected...

Almost certainly!

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-03 14:11

Message:
Logged In: YES 
user_id=4771

I'm confused: the rule for negative slot offsets appear to be different to the one for tp_dictoffset, which only increases the amount of obscurity around here.

tp_dictoffset counts relative to the end of the object, whereas in your patch negative slot offsets are a different trick to mean "relative to the start but skipping the varsized part".  The difference shows up when subclassing increases tp_basicsize.  This should be resolved one way or the other -- and I think that a clear picture of the various parts of the object and how they are measured would be a good start.

That's also related to your proposed change to extra_ivars(), which would become slightly more permissive; I strongly suspect that it would allow more strange segfaulting cases to sneak in undetected...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173475&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 17:29:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 17:29:45 2005
Subject: [Patches] [ python-Patches-1175850 ] Allow weak referencing of
	classic classes
Message-ID: <E1DI72k-0007nG-8J@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow weak referencing of classic classes

Initial Comment:
In Python 2.4, you can weakref instances of classic
classes but not the classes themselves.  Attached is a
patch which adds weakref support to classic classes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 18:19:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 18:19:25 2005
Subject: [Patches] [ python-Patches-1173475 ] __slots__ for subclasses of
	variable length types
Message-ID: <E1DI7on-0004OT-H1@sc8-sf-web3.sourceforge.net>

Patches item #1173475, was opened at 2005-03-30 18:09
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173475&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Armin Rigo (arigo)
Summary: __slots__ for subclasses of variable length types

Initial Comment:
This is a first, rough cut at allowing subclasses of variable length 
types to have __slots__ of all flavours, not just __dict__.

The motivation is trying to understand and document what's going on 
in typeobject.c, and the less special cases knocking around the 
better.

This patch also allows instances of such classes to be weakly 
referenced.

What is missing: tests, lots of tests, documentation.  Also, the code 
is a bit hackish at various points; a degree of clean up can certainly 
be acheived.

Also, I think my code probably fails to cope with code like:

class A(str):
 pass # implicitly adds __dict__, __weakref__
class B(A):
 __slots__ = ["a", "b"]

b = B()
b.c = 1

Hmm, yes.  Oh well, no time to fix today (I don't think it's that big a 
deal).

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-03 17:19

Message:
Logged In: YES 
user_id=6656

Heh, yes that works, and completely hadn't occurred to me.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-03 16:27

Message:
Logged In: YES 
user_id=4771

I think it's still possible to give slot.offset the same meaning as tp_dictoffset, even given the additional constrain that it can't change upon subclassing.  In your example classes S and T, we can put 'b' before 'a' in memory, so that a.offset==-4 (for both S and T) and b.offset==-8.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-03 15:32

Message:
Logged In: YES 
user_id=6656

> I'm confused: the rule for negative slot offsets appear to be
> different to the one for tp_dictoffset

Yes.  I think this is actually necessary.

Consider:

class S(str):
    __slots__ = ['a']

you'd except S.__dict__['a'].__offset__ (well, if the attribute existed) to be 
-4.

Then

class T(S):
    __slots__ = ['b']

then using the 'from the end of the object' rule for  T().a would actually find 
T.b.  (IOW, T.__dict__['b'].__offset__ == T.__dict__['a'].__offset__ == -4).  
The alternative would be to somehow override all the slots in S when T is 
defined -- and this doesn't seem wise.

__dict__ indeed works differently, because 
instance.__class__.__dictoffset__ is updated on subclassing.  You could 
make __dict__ work like the slots mentioned above, but then you'd have to 
find the '__dict__' descriptor every time you wanted to access an 
instance's dictionary, and that would be slow (and might even not really 
work, but I don't want to risk brain-explosion by thinking about it too hard)

> which only increases the amount of obscurity around here.

Yeah, sorry about that.

I think something I've realised over the past few days is that __dict__ 
really is special.  I'm not sure __weakref__ is (though I guess it's special in 
that you want to be able to access it from C without any risk of executing 
Python level code, i.e. replacing Py_GETWEAKREFLIST(ob) with 
PyOjbect_GetAttrString(ob, "__weakref__") would be unfortunate).

> This should be resolved one way or the other 

See above -- don't think you can.

> -- and I think that
> a clear picture of the various parts of the object and how they
> are measured would be a good start.

No kidding here!

> That's also related to your proposed change to extra_ivars(),
> which would become slightly more permissive; I strongly suspect
> that it would allow more strange segfaulting cases to sneak in
> undetected...

Almost certainly!

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-03 15:11

Message:
Logged In: YES 
user_id=4771

I'm confused: the rule for negative slot offsets appear to be different to the one for tp_dictoffset, which only increases the amount of obscurity around here.

tp_dictoffset counts relative to the end of the object, whereas in your patch negative slot offsets are a different trick to mean "relative to the start but skipping the varsized part".  The difference shows up when subclassing increases tp_basicsize.  This should be resolved one way or the other -- and I think that a clear picture of the various parts of the object and how they are measured would be a good start.

That's also related to your proposed change to extra_ivars(), which would become slightly more permissive; I strongly suspect that it would allow more strange segfaulting cases to sneak in undetected...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173475&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 21:09:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 21:09:51 2005
Subject: [Patches] [ python-Patches-1175933 ] threading.Condition.wait()
	return value indicates timeout
Message-ID: <E1DIATj-0006PV-G2@sc8-sf-web1.sourceforge.net>

Patches item #1175933, was opened at 2005-04-03 19: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=1175933&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Condition.wait() return value indicates timeout

Initial Comment:
A condition variable returns in two cases: it was
notified by another thread, or it timed out (if a
timeout was specified).  See an example in the popular
Boost C++ library:

http://boost.org/doc/html/condition.html

This patch adds this capability to the Python
threading.Condition.wait() method, which used to return
nothing.  I added the relevant couple of lines to the
documentaion as well (see patch).

(An example is using a condition variable as a sentinel
for exiting a loop or a polling thread.  Using the
return value one can decide whether to exit the loop or
not.)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175933&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 22:46:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 22:46:36 2005
Subject: [Patches] [ python-Patches-1175984 ] Make subprocess.Popen support
	file-like objects (win)
Message-ID: <E1DIBzL-0005yj-1P@sc8-sf-web4.sourceforge.net>

Patches item #1175984, was opened at 2005-04-03 16: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=1175984&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicolas Fleury (nidoizo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make subprocess.Popen support file-like objects (win)

Initial Comment:
This patch make subprocess.Popen support file-like
objects without fileno for stdout and stderr on Windows
(intend to do Unix once patch accepted).  It makes
subprocess.Popen able to redirect stdout and stderr to
objects like StringIO or other objects with file
objects interface.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175984&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 23:47:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 23:47:11 2005
Subject: [Patches] [ python-Patches-1176019 ] Implemented new 'class
	foo():pass' syntax
Message-ID: <E1DICw1-0002IV-Fy@sc8-sf-web1.sourceforge.net>

Patches item #1176019, was opened at 2005-04-03 16: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=1176019&group_id=5470

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implemented new 'class foo():pass' syntax

Initial Comment:
This patch implements the new 'class foo():pass' syntax 
for the ast branch.  It also includes minor modifications 
required to run build graminit.c on windows machines.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176019&group_id=5470
From noreply at sourceforge.net  Sun Apr  3 23:47:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr  3 23:47:43 2005
Subject: [Patches] [ python-Patches-1176019 ] Implemented new 'class
	foo():pass' syntax
Message-ID: <E1DICwX-0005gW-1r@sc8-sf-web3.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Brett Cannon (bcannon)
Summary: Implemented new 'class foo():pass' syntax

Initial Comment:
This patch implements the new 'class foo():pass' syntax 
for the ast branch.  It also includes minor modifications 
required to run build graminit.c on windows machines.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176019&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 00:03:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 00:03:43 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DIDBz-0006Ao-UG@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Jeremy Hylton (jhylton)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

Comment By: logistix (logistix)
Date: 2005-04-03 17:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-07 00:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 17:25:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 17:25:51 2005
Subject: [Patches] [ python-Patches-1175004 ] Export more libreadline API
	functions
Message-ID: <E1DITSV-0005mW-Uo@sc8-sf-web3.sourceforge.net>

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

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Edge (bruce_edge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Export more libreadline API functions

Initial Comment:
The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

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

>Comment By: Bruce Edge (bruce_edge)
Date: 2005-04-04 08:25

Message:
Logged In: YES 
user_id=1251183

I got the OK to work on the docs. Here's the patch
resubmitted with the libreadline.tex changes.

-Bruce

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 13:31

Message:
Logged In: YES 
user_id=21627

As incomplete work, we might have to reject it, unless
somebody volunteers to complete it. Let's give it one month
from now.

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

Comment By: Bruce Edge (bruce_edge)
Date: 2005-04-01 13:16

Message:
Logged In: YES 
user_id=1251183

AFAIK, yes, they have always been available, at least in
Linux. I've been carrying this patch around since python 2.1.
I have not looked into this on other platforms.
I can't commit to providing doc changes. With my schedule,
it was all I could do to package it up and send it in. 
I'm sorry, I know this is incomplete work, but I figure
someone may be able to use it.

-Bruce

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 12:57

Message:
Logged In: YES 
user_id=21627

Have these function always been available in readline (i.e.
all readline versions)? If not, please provide configure.in
changes.

Also, please provide Doc/lib/libreadline.tex changes.

If you cannot provide these things, please indicate so.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175004&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 18:09:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 18:09:27 2005
Subject: [Patches] [ python-Patches-1162023 ] don't add -OPT:Olimit=0 for icc
Message-ID: <E1DIU8i-0007BN-BN@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

Category: Build
Group: Python 2.5
Status: Open
Resolution: None
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: 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  Mon Apr  4 18:32:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 18:33:01 2005
Subject: [Patches] [ python-Patches-1173245 ] unicodedata docstrings
Message-ID: <E1DIUVW-0008WC-CA@sc8-sf-web1.sourceforge.net>

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

Category: Modules
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jeremy Yallop (yallop)
Assigned to: Nobody/Anonymous (nobody)
Summary: unicodedata docstrings

Initial Comment:
Docstrings for unicodedata, extracted from the tex
documentation.

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

>Comment By: Hye-Shik Chang (perky)
Date: 2005-04-05 01:32

Message:
Logged In: YES 
user_id=55188

Committed in Modules/unicodedata.c 2.33.

Thank you for the patch!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173245&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 19:29:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 19:29:32 2005
Subject: [Patches] [ python-Patches-1176504 ] locale._build_localename
	treatment for utf8
Message-ID: <E1DIVOE-00031O-6I@sc8-sf-web1.sourceforge.net>

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

Category: Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: M.-A. Lemburg (lemburg)
Summary: locale._build_localename treatment for utf8

Initial Comment:
Due to encoding name normalization of locale module,
UTF-8 locales are normalized to xx_XX.UTF8.  But most
of BSD systems and some other *nixes doesn't allow
normalized forms of locale names such as xx_XX.UTF8. 
So we need to restore the name on _build_localename to
'UTF-8' to make it work on such systems.

>>> import os; os.environ['LC_ALL']='ko_KR.UTF-8'
[25369 refs]
>>> import locale; locale.resetlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/perky/cvs/python/Lib/locale.py", line
402, in resetlocale
    _setlocale(category,
_build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting
[28822 refs]


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176504&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 21:26:00 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 21:26:02 2005
Subject: [Patches] [ python-Patches-1176019 ] Implemented new 'class
	foo():pass' syntax
Message-ID: <E1DIXCy-0002v2-5A@sc8-sf-web4.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Brett Cannon (bcannon)
Summary: Implemented new 'class foo():pass' syntax

Initial Comment:
This patch implements the new 'class foo():pass' syntax 
for the ast branch.  It also includes minor modifications 
required to run build graminit.c on windows machines.

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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-04 12:25

Message:
Logged In: YES 
user_id=357491

Do you know why graminit.c stopped working on Windows? 
Kurt's report on the merger didn't show any issues on
Windows and so I wonder if the problem goes back to the main
branch as well.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176019&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 21:27:00 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 21:27:02 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DIXDw-0002xk-0J@sc8-sf-web4.sourceforge.net>

Patches item #1097671, was opened at 2005-01-06 22:28
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470

Category: Core (C code)
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
>Assigned to: Brett Cannon (bcannon)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

Comment By: logistix (logistix)
Date: 2005-04-03 15:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-06 22:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 21:47:08 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 21:47:14 2005
Subject: [Patches] [ python-Patches-1176578 ] Clarify unicode.(en|de)code.()
	docstrings
Message-ID: <E1DIXXQ-0001kT-PL@sc8-sf-web3.sourceforge.net>

Patches item #1176578, was opened at 2005-04-04 12: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=1176578&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clarify unicode.(en|de)code.() docstrings

Initial Comment:
I was reading the docstrings for unicode.encode() and
unicode.decode() and they were making no sense to me
since I kept expecting ``unicode("hi",
"utf-8").encode("utf-16")`` to return a unicode object,
just with an internal representation of UTF-16.  Then I
started playing with them some more and I realized the
methods encoded and decoded into and out of a byte
stream.  Then it made sense.

Attached is a patch to mention that they are working
with byte streams.  I also capitalized the first words
in all the sentences.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176578&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 22:53:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 22:53:47 2005
Subject: [Patches] [ python-Patches-1176019 ] Implemented new 'class
	foo():pass' syntax
Message-ID: <E1DIYZs-0004lp-T7@sc8-sf-web3.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Brett Cannon (bcannon)
Summary: Implemented new 'class foo():pass' syntax

Initial Comment:
This patch implements the new 'class foo():pass' syntax 
for the ast branch.  It also includes minor modifications 
required to run build graminit.c on windows machines.

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

>Comment By: logistix (logistix)
Date: 2005-04-04 15:53

Message:
Logged In: YES 
user_id=699438

graminit.c is generated by pgen.exe.  This process isn't fully 
automated on a windows build (like I'm guessing it is on 
linux).  There is a provided makefile that works with visual 
studio's nmake for windows users.  It just referenced an older 
version of the python lib file (2.3 instead of 2.5).

I presume this hasn't caused problems in the past becuase 
people modifying grammar/grammar have been running some 
form of *nix.

Now I'm starting to wonder if pgen generates any other files 
(i.e. header files) that I didn't include in the patch.  I'll verify 
when I get home.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-04 14:25

Message:
Logged In: YES 
user_id=357491

Do you know why graminit.c stopped working on Windows? 
Kurt's report on the merger didn't show any issues on
Windows and so I wonder if the problem goes back to the main
branch as well.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176019&group_id=5470
From noreply at sourceforge.net  Mon Apr  4 23:49:28 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  4 23:49:30 2005
Subject: [Patches] [ python-Patches-1176019 ] Implemented new 'class
	foo():pass' syntax
Message-ID: <E1DIZRo-0000pu-62@sc8-sf-web4.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Brett Cannon (bcannon)
Summary: Implemented new 'class foo():pass' syntax

Initial Comment:
This patch implements the new 'class foo():pass' syntax 
for the ast branch.  It also includes minor modifications 
required to run build graminit.c on windows machines.

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

>Comment By: logistix (logistix)
Date: 2005-04-04 16:49

Message:
Logged In: YES 
user_id=699438

Just to confirm, pgen did generate a new graminit.h file, but 
there were no changes to it because we didn't add any new 
symbols.  The patch I submitted is fine.

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

Comment By: logistix (logistix)
Date: 2005-04-04 15:53

Message:
Logged In: YES 
user_id=699438

graminit.c is generated by pgen.exe.  This process isn't fully 
automated on a windows build (like I'm guessing it is on 
linux).  There is a provided makefile that works with visual 
studio's nmake for windows users.  It just referenced an older 
version of the python lib file (2.3 instead of 2.5).

I presume this hasn't caused problems in the past becuase 
people modifying grammar/grammar have been running some 
form of *nix.

Now I'm starting to wonder if pgen generates any other files 
(i.e. header files) that I didn't include in the patch.  I'll verify 
when I get home.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-04 14:25

Message:
Logged In: YES 
user_id=357491

Do you know why graminit.c stopped working on Windows? 
Kurt's report on the merger didn't show any issues on
Windows and so I wonder if the problem goes back to the main
branch as well.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176019&group_id=5470
From noreply at sourceforge.net  Tue Apr  5 02:00:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr  5 02:01:01 2005
Subject: [Patches] [ python-Patches-1174589 ] hierarchical regular expression
Message-ID: <E1DIbV4-0005qj-IG@sc8-sf-web4.sourceforge.net>

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

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Chris Ottrey (ottrey)
Assigned to: Nobody/Anonymous (nobody)
Summary: hierarchical regular expression

Initial Comment:
( from the re2 sourceforge project
http://pyre2.sourceforge.net )

The re2 library provides a hierarchical regular
expression extension to the re library.

re2 extracts a hierarchy of named groups from a string,
rather than the flat, incomplete dictionary that the
standard re module returns. 

>>> import re
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat1=re.compile(regex)
>>> m=pat1.match(buf)
>>> m.groupdict()
{'verse': '10 lords a-leaping', 'number': '10',
'activity': 'lords a-leaping'}

>>> import re2
>>> buf='12 drummers drumming, 11 pipers piping, 10
lords a-leaping'
>>> regex='^((?P<verse>(?P<number>\d+)
(?P<activity>[^,]+))(, )?)*$'
>>> pat2=re2.compile(regex)
>>> x=pat2.extract(buf)
>>> x
{'verse': [{'number': '12', 'activity': 'drummers
drumming'}, {'number': '11', 'activity': 'pipers
piping'}, {'number': '10', 'activity': 'lords a-leaping'}]}

(See http://pyre2.sourceforge.net/ for more details.)

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

>Comment By: Martin v. L?wis (loewis)
Date: 2005-04-05 02:00

Message:
Logged In: YES 
user_id=21627

Given the discussion of python-dev, it appears that you want
to rework the code and come back if you have something
you'ld like to contribute. So I'm rejecting this patch for
now; please open a new one when you are ready (but likely,
you'ld write a PEP first, anyhow).

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

Comment By: Chris Ottrey (ottrey)
Date: 2005-04-02 09:16

Message:
Logged In: YES 
user_id=609576

Ok.
I'll ask on python-dev then.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-02 01:49

Message:
Logged In: YES 
user_id=21627

We accept extensions only by means of patches. So you would
create a patch (as a unified or context diff) for the
current CVS;for completely new files, providing a tar ball
is also reasonable. I expect that you don't suggest literal
inclusion of the svn trunk directory into the dist/src
directory of the Python distribution.

However, in the specific case, I think whether or not the
new functionality should  be added to Python at all probably
needs discussion. I recommend to ask on python-dev; be
prepared to write a PEP. As a starting point, I'm personally
concerned to have a module named "re2" in the standard
library. This will cause confusion to the users; it might be
better to merge the functionality into the re module.

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

Comment By: Chris Ottrey (ottrey)
Date: 2005-04-02 01:10

Message:
Logged In: YES 
user_id=609576

Sorry, it's more an extension than a patch.
(Although maybe it could be applied as a patch to the re
library.)
(BTW Where is the correct place to submit extensions?)

The code is in this subversion repository:
  http://pintje.servebeer.com/svn/pyre2/trunk/

Or available for download here:
  http://sourceforge.net/project/showfiles.php?group_id=134583

And has a development wiki here:
  http://py.redsoft.be/pyre2/wiki/

And yes, I'm the author.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 21:57

Message:
Logged In: YES 
user_id=21627

Is this a patch? If so, where is the code, and are you its
author?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174589&group_id=5470
From noreply at sourceforge.net  Tue Apr  5 04:56:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr  5 04:56:07 2005
Subject: [Patches] [ python-Patches-1176578 ] Clarify unicode.(en|de)code.()
	docstrings
Message-ID: <E1DIeEV-0001xy-Q4@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clarify unicode.(en|de)code.() docstrings

Initial Comment:
I was reading the docstrings for unicode.encode() and
unicode.decode() and they were making no sense to me
since I kept expecting ``unicode("hi",
"utf-8").encode("utf-16")`` to return a unicode object,
just with an internal representation of UTF-16.  Then I
started playing with them some more and I realized the
methods encoded and decoded into and out of a byte
stream.  Then it made sense.

Attached is a patch to mention that they are working
with byte streams.  I also capitalized the first words
in all the sentences.

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

>Comment By: Hye-Shik Chang (perky)
Date: 2005-04-05 11:56

Message:
Logged In: YES 
user_id=55188

That's not true. While the most unicode codecs are doing
such, some doesn't.  It's up to each codec's design what it
gets in its unicode.decode and what it returns in its
unicode.encode.

eg:

>>> u'hello, \uAC00!'.encode('breaker')
u'hello, \xea\xb0\x80!'
>>> _.decode('breaker')
u'hello, \uac00!'


class Codec(codecs.Codec):
....def encode(self, data, errors='strict'):
........return
data.encode('utf-8').decode('iso8859-1'),len(data)
....def decode(self, data, errors='strict'):
........return data.encode('iso8859-1').decode('utf-8'),
len(data)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176578&group_id=5470
From noreply at sourceforge.net  Tue Apr  5 18:29:33 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr  5 18:29:38 2005
Subject: [Patches] [ python-Patches-784089 ] A program to scan python files
	and list those require coding
Message-ID: <E1DIqvl-0007w2-7e@sc8-sf-web1.sourceforge.net>

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

Category: Demos and tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Oleg Broytmann (phd)
Assigned to: Raymond Hettinger (rhettinger)
Summary: A program to scan python files and list those require coding

Initial Comment:
A program to scan python files (recursively) and list
those that require coding directive (pseudocomment)
because there non-ASCII characters in the file
(including comments).

The program treats files as python files if the
extension is .py or there is &quot;python&quot; in the first line
of the file.


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

>Comment By: Oleg Broytmann (phd)
Date: 2005-04-05 20:29

Message:
Logged In: YES 
user_id=4799

I've reworked and advanced the patch. See the attached
bzipped tarball.

The pysource.py module exports three functions.
looks_like_python() takes a quick look and recognizes a
Python source file if it is not too big, has .py expension
and has the word "python" in the first line.

The function can_be_compiled() tries to compile the file.

The generator python_files() runs through all paths whether
they are files or directories, descends into directories,
test if all encountered files are python source files and
yield them.

find-nocoding.py now has an option -c to use
can_be_compiled() instead of the default loks_like_python().
The arguments can be files or directories.

There are also 3 simple tests. "find-nocoding.py ." must
find test/test2.py; "find-nocoding.py -c ." must find
test/test2.py and test/test3.py.

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

Comment By: Oleg Broytmann (phd)
Date: 2005-03-03 18:42

Message:
Logged In: YES 
user_id=4799

Sorry for my poor English. "Can have" and "may have"...

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

Comment By: Oleg Broytmann (phd)
Date: 2005-03-03 18:41

Message:
Logged In: YES 
user_id=4799

Thank you for pointing the regex. I fixed both programs.

But you are wrong about .py extension. A python module
really can only has .py extension, but a python program may
has any, for example, .cgi, or no extension at all.

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

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-03-03 18:35

Message:
Logged In: YES 
user_id=1188172

Also, perhaps there could be another mode of operation in
which the files in question are checked if they need an
encoding declaration anyways.

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

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-03-03 18:18

Message:
Logged In: YES 
user_id=1188172

The script only checks for "-*- coding", while the docs
state that the correct regex is "coding[=:]\s*([-\w.]+)".

In the pysource.py, I don't know if it is useful to open the
file and check the first line for "python". Normally, Python
files should be given the extension .py, so there is a great
probability of false positives.

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

Comment By: Oleg Broytmann (phd)
Date: 2004-12-17 22:52

Message:
Logged In: YES 
user_id=4799

Added pysource.py module and an alternative implementation
using the module. The pysource.py module is, probably, of a
general interest and can be added to the standard library.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-20 10:04

Message:
Logged In: YES 
user_id=80475

Will make a few cleanups, replace the recursion and fileext
guessing to a glob.glob format, and will add to Tools/scripts.

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

Comment By: Oleg Broytmann (phd)
Date: 2004-10-07 11:49

Message:
Logged In: YES 
user_id=4799

And don't forget to make it executable.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-08 01:50

Message:
Logged In: YES 
user_id=11375

So, does something need to be done with this script, like adding it to the 
distribution?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-06 16:36

Message:
Logged In: YES 
user_id=38388

Thanks.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470
From noreply at sourceforge.net  Tue Apr  5 21:26:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr  5 21:26:14 2005
Subject: [Patches] [ python-Patches-1177307 ] UTF-8-Sig codec
Message-ID: <E1DItgh-0007kc-Is@sc8-sf-web2.sourceforge.net>

Patches item #1177307, was opened at 2005-04-05 21: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=1177307&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: UTF-8-Sig codec

Initial Comment:
This patch implements a UTF-8-Sig codec. This codec
works like UTF-8 but adds a BOM on writing and skips
(at most) one BOM on reading.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177307&group_id=5470
From noreply at sourceforge.net  Tue Apr  5 22:28:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr  5 22:28:59 2005
Subject: [Patches] [ python-Patches-1177307 ] UTF-8-Sig codec
Message-ID: <E1DIufQ-0004Be-0H@sc8-sf-web1.sourceforge.net>

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

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: UTF-8-Sig codec

Initial Comment:
This patch implements a UTF-8-Sig codec. This codec
works like UTF-8 but adds a BOM on writing and skips
(at most) one BOM on reading.

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

>Comment By: Walter D?rwald (doerwalter)
Date: 2005-04-05 22:28

Message:
Logged In: YES 
user_id=89016

This second version of the patch will return starting bytes
immediately, if they don't look like a BOM.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177307&group_id=5470
From noreply at sourceforge.net  Wed Apr  6 00:31:43 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr  6 00:31:47 2005
Subject: [Patches] [ python-Patches-1176578 ] Clarify unicode.(en|de)code.()
	docstrings
Message-ID: <E1DIwaF-0002SZ-D4@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clarify unicode.(en|de)code.() docstrings

Initial Comment:
I was reading the docstrings for unicode.encode() and
unicode.decode() and they were making no sense to me
since I kept expecting ``unicode("hi",
"utf-8").encode("utf-16")`` to return a unicode object,
just with an internal representation of UTF-16.  Then I
started playing with them some more and I realized the
methods encoded and decoded into and out of a byte
stream.  Then it made sense.

Attached is a patch to mention that they are working
with byte streams.  I also capitalized the first words
in all the sentences.

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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-05 15:31

Message:
Logged In: YES 
user_id=357491

That figures.  OK, closed as rejected.

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

Comment By: Hye-Shik Chang (perky)
Date: 2005-04-04 19:56

Message:
Logged In: YES 
user_id=55188

That's not true. While the most unicode codecs are doing
such, some doesn't.  It's up to each codec's design what it
gets in its unicode.decode and what it returns in its
unicode.encode.

eg:

>>> u'hello, \uAC00!'.encode('breaker')
u'hello, \xea\xb0\x80!'
>>> _.decode('breaker')
u'hello, \uac00!'


class Codec(codecs.Codec):
....def encode(self, data, errors='strict'):
........return
data.encode('utf-8').decode('iso8859-1'),len(data)
....def decode(self, data, errors='strict'):
........return data.encode('iso8859-1').decode('utf-8'),
len(data)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176578&group_id=5470
From noreply at sourceforge.net  Wed Apr  6 10:37:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr  6 10:37:47 2005
Subject: [Patches] [ python-Patches-1177597 ] Complex commented
Message-ID: <E1DJ62j-0005oR-3B@sc8-sf-web3.sourceforge.net>

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

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: engelbert gruber (grubert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Complex commented

Initial Comment:
i ran pychecker over Complex.py

1. "i is not defined": in the constructor, but __init__ looks 
   strange to me, so i only made a comment and changed
   the second if to elif.
2. "sys" is not defined: in __hash__, moved import sys to the top.
3. "re" and "im" attributes dont exist: probably a pychecker
   problem, but i did add a comment.




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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177597&group_id=5470
From noreply at sourceforge.net  Wed Apr  6 15:47:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr  6 15:47:54 2005
Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for
	longs
Message-ID: <E1DJAsp-00064E-NQ@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Tim Peters (tim_one)
Summary: explicit sign variable for longs

Initial Comment:
This patch removes longobject.c abuse of ob_size to store the sign 
in favour of an explicit sign member, as mentioned on python-dev.

The only other file that needed modifying is marshal.c (but the 
marshal format isn't changed).

It doesn't touch all the various code that handles ob_size 
generically.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470
From noreply at sourceforge.net  Wed Apr  6 15:51:19 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr  6 15:51:22 2005
Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for
	longs
Message-ID: <E1DJAwB-0006I7-31@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Tim Peters (tim_one)
Summary: explicit sign variable for longs

Initial Comment:
This patch removes longobject.c abuse of ob_size to store the sign 
in favour of an explicit sign member, as mentioned on python-dev.

The only other file that needed modifying is marshal.c (but the 
marshal format isn't changed).

It doesn't touch all the various code that handles ob_size 
generically.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-06 14:51

Message:
Logged In: YES 
user_id=6656

Oh, and I meant to say, it passes make test but more testing is certainly 
welcome -- some mistakes show up in pretty obscure ways...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470
From noreply at sourceforge.net  Thu Apr  7 10:33:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr  7 10:34:01 2005
Subject: [Patches] [ python-Patches-1174614 ] site enhancements
Message-ID: <E1DJSSb-0004NG-Rd@sc8-sf-web2.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: site enhancements

Initial Comment:
The current site.py has three major deficiencies:

(1) All site dirs must exist on the filesystem:  Since PEP 302 (New 
Import Hooks) was adopted, this is not necessarily true.  
sys.meta_path and sys.path_hooks can have valid uses for non-
existent paths.  Even the standard zipimport hook supports in-zip-
file paths (i.e. foo.zip/bar).

(2) The directories added to sys.path by .pth files are not scanned 
for further .pth files.  If they were, you could make life much easier 
on developers and users of multi-user systems.  For example, it 
would be possible for an administrator to drop in a .pth file into the 
system-wide site-packages to allow users to have their own local 
site-packages folder.  Currently, you could try this, but it wouldn't 
work because many packages such as PIL, Numeric, and PyObjC 
take advantage of .pth files during their installation.

(3) To support the above use case, .pth files should be allowed to 
use os.path.expanduser(), so you can toss a tilde in front and do the 
right thing.  Currently, the only way to support (2) is to use an ugly 
"import" pth hook.

Attached is a patch to CVS HEAD that:
(1) Removes the os.path.exists() / os.path.isdir() restrictions
(2) Changes the .pth reader to use addsitedir() (top down) rather than 
sys.path.append()
(3) makepath() uses os.path.expanduser() after the os.path.join().

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

>Comment By: Just van Rossum (jvr)
Date: 2005-04-07 10:33

Message:
Logged In: YES 
user_id=92689

Patch looks good, the new functionality is great to have, recommend apply.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1174614&group_id=5470
From noreply at sourceforge.net  Fri Apr  8 01:00:02 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  8 01:00:05 2005
Subject: [Patches] [ python-Patches-1177597 ] Complex commented
Message-ID: <E1DJfyk-0002dl-Kv@sc8-sf-web4.sourceforge.net>

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

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: engelbert gruber (grubert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Complex commented

Initial Comment:
i ran pychecker over Complex.py

1. "i is not defined": in the constructor, but __init__ looks 
   strange to me, so i only made a comment and changed
   the second if to elif.
2. "sys" is not defined: in __hash__, moved import sys to the top.
3. "re" and "im" attributes dont exist: probably a pychecker
   problem, but i did add a comment.




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

>Comment By: Martin v. L?wis (loewis)
Date: 2005-04-08 01:00

Message:
Logged In: YES 
user_id=21627

Please review __init__ with the understanding that it is
meant to compute

  re + im*1j

even provided re or im could be complex. So "i" should
probably be "im", and both re and im can be complex.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177597&group_id=5470
From noreply at sourceforge.net  Fri Apr  8 01:53:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  8 01:53:37 2005
Subject: [Patches] [ python-Patches-1172711 ] long long support for array
	module
Message-ID: <E1DJgoY-00049y-L9@sc8-sf-web3.sourceforge.net>

Patches item #1172711, was opened at 2005-03-29 18:58
Message generated for change (Comment added) made by orenti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1172711&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Oren Tirosh (orenti)
Assigned to: Nobody/Anonymous (nobody)
Summary: long long support for array module

Initial Comment:
This patch adds signed and unsigned long long support
to the array module. These types are already supported
by the struct module and use the same format characters
(q/Q).

Also corrects a minor bug in PyLong_AsUnsignedLongLong
which reports a BadInternalCall for arguments of
inappropriate type rather than a mere TypeError as
reported by the other conversion functions.


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

>Comment By: Oren Tirosh (orenti)
Date: 2005-04-07 23:53

Message:
Logged In: YES 
user_id=562624

My patch was against 2.4... (duh!)

The other bug is already fixed on 2.5.


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

Comment By: Armin Rigo (arigo)
Date: 2005-04-03 14:24

Message:
Logged In: YES 
user_id=4771

No two conversion function in longobject.c seem to have the same rules for what to do about non-long objects :-(  I'm afraid some clean-up would be useful, but also difficult for fear of breaking existing user C code :-(

In fact, your patch doesn't apply with today's CVS because someone already tried to add some magic in PyObject_AsLongLong().  It also fails on test_array.py and applies uncleanly on arraymodule.c.

Also, it needs to update the array module documentation.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1172711&group_id=5470
From noreply at sourceforge.net  Fri Apr  8 16:20:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  8 16:21:01 2005
Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for
	longs
Message-ID: <E1DJuLv-0004Xw-EU@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Tim Peters (tim_one)
Summary: explicit sign variable for longs

Initial Comment:
This patch removes longobject.c abuse of ob_size to store the sign 
in favour of an explicit sign member, as mentioned on python-dev.

The only other file that needed modifying is marshal.c (but the 
marshal format isn't changed).

It doesn't touch all the various code that handles ob_size 
generically.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-08 14:20

Message:
Logged In: YES 
user_id=4771

Unlike Tim I have a use case for lots of small longs in memory: to store unsigned machine integers.  It's exactly the case where it would be nice that the extra field didn't cross the malloc 8-byte boundary.  Of course, it's exactly NOT what is happening here on 32-bit machines, and this patch makes program relying on this kind of longs suddenly consume 8 extra bytes per long.  Damn.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-06 13:51

Message:
Logged In: YES 
user_id=6656

Oh, and I meant to say, it passes make test but more testing is certainly 
welcome -- some mistakes show up in pretty obscure ways...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470
From noreply at sourceforge.net  Fri Apr  8 17:39:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  8 17:39:20 2005
Subject: [Patches] [ python-Patches-1177597 ] Complex commented
Message-ID: <E1DJvZl-00084Z-7T@sc8-sf-web1.sourceforge.net>

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

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: engelbert gruber (grubert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Complex commented

Initial Comment:
i ran pychecker over Complex.py

1. "i is not defined": in the constructor, but __init__ looks 
   strange to me, so i only made a comment and changed
   the second if to elif.
2. "sys" is not defined: in __hash__, moved import sys to the top.
3. "re" and "im" attributes dont exist: probably a pychecker
   problem, but i did add a comment.




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

>Comment By: engelbert gruber (grubert)
Date: 2005-04-08 17:39

Message:
Logged In: YES 
user_id=147070

a liitle greedy arnt we :-)

i tried harder, hope it will be more like it

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-08 01:00

Message:
Logged In: YES 
user_id=21627

Please review __init__ with the understanding that it is
meant to compute

  re + im*1j

even provided re or im could be complex. So "i" should
probably be "im", and both re and im can be complex.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177597&group_id=5470
From noreply at sourceforge.net  Fri Apr  8 20:29:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  8 20:29:40 2005
Subject: [Patches] [ python-Patches-1177597 ] Complex commented
Message-ID: <E1DJyEa-0001BQ-Ts@sc8-sf-web2.sourceforge.net>

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

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: engelbert gruber (grubert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Complex commented

Initial Comment:
i ran pychecker over Complex.py

1. "i is not defined": in the constructor, but __init__ looks 
   strange to me, so i only made a comment and changed
   the second if to elif.
2. "sys" is not defined: in __hash__, moved import sys to the top.
3. "re" and "im" attributes dont exist: probably a pychecker
   problem, but i did add a comment.




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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-08 13:29

Message:
Logged In: YES 
user_id=80475

Sure, that is, if high standards of quality can be called
greed ;-)

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

Comment By: engelbert gruber (grubert)
Date: 2005-04-08 10:39

Message:
Logged In: YES 
user_id=147070

a liitle greedy arnt we :-)

i tried harder, hope it will be more like it

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-07 18:00

Message:
Logged In: YES 
user_id=21627

Please review __init__ with the understanding that it is
meant to compute

  re + im*1j

even provided re or im could be complex. So "i" should
probably be "im", and both re and im can be complex.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177597&group_id=5470
From noreply at sourceforge.net  Fri Apr  8 20:30:26 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  8 20:30:30 2005
Subject: [Patches] [ python-Patches-1175984 ] Make subprocess.Popen support
	file-like objects (win)
Message-ID: <E1DJyFO-0001Dv-RN@sc8-sf-web2.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicolas Fleury (nidoizo)
>Assigned to: Peter ?strand (astrand)
Summary: Make subprocess.Popen support file-like objects (win)

Initial Comment:
This patch make subprocess.Popen support file-like
objects without fileno for stdout and stderr on Windows
(intend to do Unix once patch accepted).  It makes
subprocess.Popen able to redirect stdout and stderr to
objects like StringIO or other objects with file
objects interface.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175984&group_id=5470
From noreply at sourceforge.net  Sat Apr  9 00:15:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  9 00:15:20 2005
Subject: [Patches] [ python-Patches-1179503 ] typos in rpc.py
Message-ID: <E1DK1l0-0005Fq-OA@sc8-sf-web4.sourceforge.net>

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

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: engelbert gruber (grubert)
Assigned to: Nobody/Anonymous (nobody)
Summary: typos in rpc.py

Initial Comment:
pychecker says ::

  rpc/rpc.py:99: No global (BadRPCVerspion) found

definately a typo

and ::

  rpc/rpc.py:93: Invalid arguments to (unpack_uint), got 1,  
  expected 0
  rpc/rpc.py:93: Variable (xid) used before being set

an error in an unused procedure.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1179503&group_id=5470
From noreply at sourceforge.net  Sat Apr  9 00:43:07 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  9 00:43:10 2005
Subject: [Patches] [ python-Patches-1179513 ] [AST] Fix for core in
	test_grammar.py
Message-ID: <E1DK2Bv-0000nI-VJ@sc8-sf-web1.sourceforge.net>

Patches item #1179513, was opened at 2005-04-08 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=1179513&group_id=5470

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: [AST] Fix for core in test_grammar.py

Initial Comment:
Executing statements like:

compile("lambda x:x=1")

is causing a coredump on windows when it attempts to 
free an uninitialized ast_sequence.  Making sure that an 
appropriate null value is added to the sequence before 
cleaning up fixes this.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1179513&group_id=5470
From noreply at sourceforge.net  Sat Apr  9 00:45:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  9 00:45:16 2005
Subject: [Patches] [ python-Patches-1179513 ] [AST] Fix for core in
	test_grammar.py
Message-ID: <E1DK2Dx-0007LO-CK@sc8-sf-web3.sourceforge.net>

Patches item #1179513, was opened at 2005-04-08 17:43
Message generated for change (Settings changed) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1179513&group_id=5470

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Brett Cannon (bcannon)
Summary: [AST] Fix for core in test_grammar.py

Initial Comment:
Executing statements like:

compile("lambda x:x=1")

is causing a coredump on windows when it attempts to 
free an uninitialized ast_sequence.  Making sure that an 
appropriate null value is added to the sequence before 
cleaning up fixes this.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1179513&group_id=5470
From Lthecaptain2 at aol.com  Sat Apr  9 01:36:02 2005
From: Lthecaptain2 at aol.com (Lthecaptain2@aol.com)
Date: Sat Apr  9 01:46:19 2005
Subject: [Patches] Old lady gets ass fucked really hard!...portent 
Message-ID: <111.47b04749.2f886f62@aol.com>

how-hard-do-you-get-it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20050408/9349a366/attachment.htm
From noreply at sourceforge.net  Sat Apr  9 12:53:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  9 12:53:51 2005
Subject: [Patches] [ python-Patches-1177597 ] Complex commented
Message-ID: <E1DKDb1-0006nq-Qc@sc8-sf-web4.sourceforge.net>

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

Category: Demos and tools
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: engelbert gruber (grubert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Complex commented

Initial Comment:
i ran pychecker over Complex.py

1. "i is not defined": in the constructor, but __init__ looks 
   strange to me, so i only made a comment and changed
   the second if to elif.
2. "sys" is not defined: in __hash__, moved import sys to the top.
3. "re" and "im" attributes dont exist: probably a pychecker
   problem, but i did add a comment.




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

>Comment By: Martin v. L?wis (loewis)
Date: 2005-04-09 12:53

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, committed as Complex.py  1.8, NEWS 1.1284

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-08 20:29

Message:
Logged In: YES 
user_id=80475

Sure, that is, if high standards of quality can be called
greed ;-)

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

Comment By: engelbert gruber (grubert)
Date: 2005-04-08 17:39

Message:
Logged In: YES 
user_id=147070

a liitle greedy arnt we :-)

i tried harder, hope it will be more like it

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-08 01:00

Message:
Logged In: YES 
user_id=21627

Please review __init__ with the understanding that it is
meant to compute

  re + im*1j

even provided re or im could be complex. So "i" should
probably be "im", and both re and im can be complex.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177597&group_id=5470
From noreply at sourceforge.net  Sat Apr  9 22:43:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  9 22:43:58 2005
Subject: [Patches] [ python-Patches-1006238 ] cross compile patch
Message-ID: <E1DKMo4-0005Qc-U8@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Goertzen (goertzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cross compile patch

Initial Comment:
Here's a cross compile patch I prepared a while ago but
never got around to submitting.  I've been using it
happily for months to cross compile python for embedded
systems.

Below is a descriptive excerpt from the patch.  Also
note that the patch modifies configure.in, but not
configure.  You will need to regenerate configure with
something like 

autoconf configure.in >configure

This patch is inpsired from work by Klaus Reimer at
http://www.ailis.de/~k/docs/crosscompiling/python.php

+ Cross Compiling
+ ---------------
+ 
+ Python can be cross compiled by supplying different
--host and --build
+ parameters to configure.  (Python is compiled on the
"build" system
+ and executed on the "host" system, in case you forgot
:).  Python is
+ tricky to cross compile because it needs to execute
parts of itself
+ during construction.  To work around this, make's
VPATH feature is
+ used to compile a native python in the subdirectory
"buildpython".
+ When parts of python need to be executed during
construction, the
+ "buildpython" versions are used.
+ 
+ A consequence of using the VPATH feature is that you
may not do a
+ cross compile build in the source directory.  In
other words, do this:
+ 
+ mkdir mydir
+ cd mydir
+ ../Python/configure --host=powerpc-405-linux-gnu
--build=i686-pc-linux-gnu
+ make
+ 
+ Cross compiling works well under linux, mileage may
vary for other
+ platforms.
+ 
+ A few reminders on using configure to cross compile:
+ - Cross compile tools must be in the PATH.
+ - Cross compile tools must be prefixed with the host type
+ (ie powerpc-405-linux-gnu-cc,
powerpc-405-linux-gnu-ranlib, ...)
+ - CC, CXX, AR, and RANLIB must be undefined when
running configure and
+ make.  Configure will detect them.
+ 
+ If you need a cross compiler, check out Dan Kegel's
crosstool:
+ http://www.kegel.com/crosstool
+ 
+ 


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

Comment By: Ned Ludd (solarx)
Date: 2005-04-09 20:43

Message:
Logged In: YES 
user_id=148412

Any progress with this on? 
python and perl are two of the last major things to overcome
in the x-compile world.

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

Comment By: Mike Frysinger (vapier)
Date: 2004-10-26 16:00

Message:
Logged In: YES 
user_id=114429

we've been using this with uClibc for a while now and it
works great ...

ive personally built (on amd64) & deployed (on
x86/ppc/arm/mips/sh4) python ... would great if this finally
made it into the official sources :)

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

Comment By: Jeff Epler (jepler)
Date: 2004-10-21 01:08

Message:
Logged In: YES 
user_id=2772

This patch applies cleanly to today's CVS head.

If building in the source directory while cross compiling
fails, please make configure complain about it.

This patch makes the build process invoke make recursively,
which is a big minus.  I'd rather see pgen built with a
HOSTCC and just assume python is available on $PATH for the
setup.py step.  There's no reason to build all the shared
modules in buildpython, either, which would speed things up
a fair bit.

On to how it worked for me:
Not cross-compiling, this produces no unexpected test
failures in "make test". (redhat9)

Cross compiling for i386-pc-bsdi2.1 everything goes fine
until it tries to run buildpython and make shared modules,
but shared modules don't work in the first place on bsdi2. 
I did not test the resulting Python binary.

Cross compiling for i386-redhat-linux (libc6) some
extensions fail to build, but this could be because my
header files for the cross-development environment are not
complete.  Running "make test" tries to invoke the
"buildpython/python" and doesn't work.  Running it manually
I get some skips due to modules that did not build, but
everything that did build seems to pass. (OK, so I wrote
this before the tests completed, but they're off to a good
start)

I currently cross-compile python 2.3 for win32 (mingw), and
until recently cross-compiled it for bsdi2 and redhat6. 
However, I did not use configure or the included makefiles
to do this (in order to integrate in a non-recursive build
procedure that builds several packages), so this patch is
unlikely to benefit me directly.

I don't think this patch is ready to be applied.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 04:18:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 04:18:40 2005
Subject: [Patches] [ python-Patches-1180012 ] no html file for modulefinder
Message-ID: <E1DKS23-0004Xw-2p@sc8-sf-web1.sourceforge.net>

Patches item #1180012, was opened at 2005-04-10 11: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=1180012&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: no html file for modulefinder

Initial Comment:
libmodulefinder.tex exists from 2.4 branch but 
html file is not created and modulefinder is not listed in 
Global Module Index.

 http://www.python.org/doc/2.4.1/modindex.html

The fix is trivial. Just add \input{modulefinder} to 
Doc/lib/lib.tex.

My only concern is where modulefinder should reside.

Since its main purpose is to parse source 
codes, "Python Language Services" seems best. But it 
also seems reasonable to put it in "Python Runtime 
Services" along with imp or zipimport modules that also 
do import-related jobs.

If this is intentional(the doc is just a draft and not 
completed yet), feel free to mark this invalid or whatever. 
Status of bug #914375 is still open.

 [modulefinder is not documented]
 http://www.python.org/sf/914375


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180012&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 06:28:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 06:28:34 2005
Subject: [Patches] [ python-Patches-1180012 ] no html file for modulefinder
Message-ID: <E1DKU3j-0007jc-Vo@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: no html file for modulefinder

Initial Comment:
libmodulefinder.tex exists from 2.4 branch but 
html file is not created and modulefinder is not listed in 
Global Module Index.

 http://www.python.org/doc/2.4.1/modindex.html

The fix is trivial. Just add \input{modulefinder} to 
Doc/lib/lib.tex.

My only concern is where modulefinder should reside.

Since its main purpose is to parse source 
codes, "Python Language Services" seems best. But it 
also seems reasonable to put it in "Python Runtime 
Services" along with imp or zipimport modules that also 
do import-related jobs.

If this is intentional(the doc is just a draft and not 
completed yet), feel free to mark this invalid or whatever. 
Status of bug #914375 is still open.

 [modulefinder is not documented]
 http://www.python.org/sf/914375


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

>Comment By: George Yoshida (quiver)
Date: 2005-04-10 13:28

Message:
Logged In: YES 
user_id=671362

My fault.

  \input{modulefinder}
should be ::
  \input{libmodulefinder}

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180012&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 08:13:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 08:13:10 2005
Subject: [Patches] [ python-Patches-1180062 ] fix typos in Library Reference
Message-ID: <E1DKVgw-0002LP-WE@sc8-sf-web2.sourceforge.net>

Patches item #1180062, was opened at 2005-04-10 15: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=1180062&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix typos in Library Reference

Initial Comment:
* Doc/lib/libfunctional.tex
 - "in an new object" should read "in a new object"

* Doc/lib/libsubprocess.tex
 - argument name is wrong
 - comma is missing

patch for release24-maint branch is also attached.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180062&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 18:02:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 18:02:52 2005
Subject: [Patches] [ python-Patches-1175850 ] Allow weak referencing of
	classic classes
Message-ID: <E1DKetd-0006Ty-Bi@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow weak referencing of classic classes

Initial Comment:
In Python 2.4, you can weakref instances of classic
classes but not the classes themselves.  Attached is a
patch which adds weakref support to classic classes.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 11:02

Message:
Logged In: YES 
user_id=80475

I'm curious why you would ever want to do this.  It is
somewhat rare to delete a class reference and, I presume,
rarer still to need a weak-reference to such a class.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 18:35:46 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 18:35:48 2005
Subject: [Patches] [ python-Patches-1179503 ] typos in rpc.py
Message-ID: <E1DKfPW-000489-0I@sc8-sf-web3.sourceforge.net>

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

Category: Demos and tools
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: engelbert gruber (grubert)
Assigned to: Nobody/Anonymous (nobody)
Summary: typos in rpc.py

Initial Comment:
pychecker says ::

  rpc/rpc.py:99: No global (BadRPCVerspion) found

definately a typo

and ::

  rpc/rpc.py:93: Invalid arguments to (unpack_uint), got 1,  
  expected 0
  rpc/rpc.py:93: Variable (xid) used before being set

an error in an unused procedure.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 11:35

Message:
Logged In: YES 
user_id=80475

Thanks for the patch.

Applied as:
   Demo/rpc/rpc.py 1.14 and 1.13.4.1

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1179503&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 18:44:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 18:45:00 2005
Subject: [Patches] [ python-Patches-1166602 ] Decimal interaction with
	__rop__
Message-ID: <E1DKfYP-0004SK-GP@sc8-sf-web3.sourceforge.net>

Patches item #1166602, was opened at 2005-03-19 14:10
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166602&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Facundo Batista (facundobatista)
>Assigned to: Facundo Batista (facundobatista)
Summary: Decimal interaction with __rop__

Initial Comment:
Ok, this is the result of last discussion in python-dev.

I changed _convert_other() to make it return
NotImplemented, and check in every place where it's
called to pass back the NotImplemented (something
similar suggested Michael Hudson in the discussion: he
passed back "other", but I think is cleaner just to
pass the signal, and let the architecture to do
whatever it should).

The tests runs ok, seeing a +1.8% in test_decimal time.

I'm sending this to you, because I...

- Don't get to understand from the discussion if this
is something that should be fixed at this level or at
another.

- Don't really know if this solution is as clean as it
seems.

Thanks! 

.    Facundo



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 11:44

Message:
Logged In: YES 
user_id=80475

I had checked in my own patch for the rop issue.  Please cross-
check these two patches to see if one did something that the 
other had not.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166602&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 19:05:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 19:05:59 2005
Subject: [Patches] [ python-Patches-1175850 ] Allow weak referencing of
	classic classes
Message-ID: <E1DKfsi-00058T-CL@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow weak referencing of classic classes

Initial Comment:
In Python 2.4, you can weakref instances of classic
classes but not the classes themselves.  Attached is a
patch which adds weakref support to classic classes.

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

>Comment By: Greg Chapman (glchapman)
Date: 2005-04-10 09:05

Message:
Logged In: YES 
user_id=86307

Here's my use case.  I've been experimenting with the
multimethods module written by David Mertz (part of his
gnosis utilities).  This uses mros from a declared signature
and from the actual parameter types to determine which
overload to call.  Classic classes don't have an mro, so I
needed to calculate one to accomodate them.  Having done so,
I wanted to cache it.  The best solution might be the one
I'm using now, which is simply to assign the calculated mro
to a __mro__ attribute of the classic class.  However, it
seemed better to me to use an external cache, rather than
modifying the class.  I wanted this external cache to be a
WeakKeyDictionary, because, if a module containing a classic
class is reloaded, I didn't want the old version of the
class kept alive solely by my cache (it avoided a reference
cycle with the mro itself by storing a list with the first
element set to None; then, when fetched,  copying the list
and putting the class in the copy's first element).

Anyway, feel free to reject this.  It was so easy to do, I
just thought I'd go ahead and post it in case the lack was
simply an oversight.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 08:02

Message:
Logged In: YES 
user_id=80475

I'm curious why you would ever want to do this.  It is
somewhat rare to delete a class reference and, I presume,
rarer still to need a weak-reference to such a class.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 20:00:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 20:00:09 2005
Subject: [Patches] [ python-Patches-1180296 ] great improvement for
	locale.py formatting functions
Message-ID: <E1DKgj6-0001z7-Am@sc8-sf-web1.sourceforge.net>

Patches item #1180296, was opened at 2005-04-10 18:00
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=1180296&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
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  Sun Apr 10 20:15:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 20:15:50 2005
Subject: [Patches] [ python-Patches-1180305 ] clarify behavior of StringIO
	objects when preinitialized
Message-ID: <E1DKgyK-0007Nb-0R@sc8-sf-web3.sourceforge.net>

Patches item #1180305, was opened at 2005-04-10 18: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=1180305&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: clarify behavior of StringIO objects when preinitialized

Initial Comment:
This patch clarifies that a StringIO object, when given
a value in the constructor, behaves like a file opened
with mode 'r+': the file pointer is positioned at the
beginning, and write() overwrites the previous string.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180305&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 20:51:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 20:51:55 2005
Subject: [Patches] [ python-Patches-1175850 ] Allow weak referencing of
	classic classes
Message-ID: <E1DKhXE-00063v-Oc@sc8-sf-web4.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Allow weak referencing of classic classes

Initial Comment:
In Python 2.4, you can weakref instances of classic
classes but not the classes themselves.  Attached is a
patch which adds weakref support to classic classes.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 13:51

Message:
Logged In: YES 
user_id=80475

Be sure to add Py_TPFLAGS_HAVE_WEAKREFS to tp_flags.

Beef-up the unittest.  See test_weakref() in
test.test_deque.py for an example.

Add classic classes to the list of weak referencables in
libweakref.tex.  Include a \versionadded tag.

Add an entry to Misc/NEWS.


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

Comment By: Greg Chapman (glchapman)
Date: 2005-04-10 12:05

Message:
Logged In: YES 
user_id=86307

Here's my use case.  I've been experimenting with the
multimethods module written by David Mertz (part of his
gnosis utilities).  This uses mros from a declared signature
and from the actual parameter types to determine which
overload to call.  Classic classes don't have an mro, so I
needed to calculate one to accomodate them.  Having done so,
I wanted to cache it.  The best solution might be the one
I'm using now, which is simply to assign the calculated mro
to a __mro__ attribute of the classic class.  However, it
seemed better to me to use an external cache, rather than
modifying the class.  I wanted this external cache to be a
WeakKeyDictionary, because, if a module containing a classic
class is reloaded, I didn't want the old version of the
class kept alive solely by my cache (it avoided a reference
cycle with the mro itself by storing a list with the first
element set to None; then, when fetched,  copying the list
and putting the class in the copy's first element).

Anyway, feel free to reject this.  It was so easy to do, I
just thought I'd go ahead and post it in case the lack was
simply an oversight.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 11:02

Message:
Logged In: YES 
user_id=80475

I'm curious why you would ever want to do this.  It is
somewhat rare to delete a class reference and, I presume,
rarer still to need a weak-reference to such a class.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 20:53:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 20:53:44 2005
Subject: [Patches] [ python-Patches-725569 ] Improved output for unittest
	failUnlessEqual
Message-ID: <E1DKhYz-00066X-1v@sc8-sf-web4.sourceforge.net>

Patches item #725569, was opened at 2003-04-22 11:33
Message generated for change (Comment added) made by purcell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Duncan Booth (duncanb)
Assigned to: Steve Purcell (purcell)
Summary: Improved output for unittest failUnlessEqual

Initial Comment:
The failUnlessEqual method in unittest.TestCase 
doesn't handle well the case where the objects being 
compared have a long string representation. The 
whole repr for each object is printed no matter how 
long, and no indication is given of where any 
differences occur.

This patch uses difflib on long representations to 
provide a short output that highlights where the first 
difference actually is. It also limits the output for each 
value to fit on a single line (with the differences 
indicated on the line following).

e.g.
FAIL: test_failunlessEqual4 (__main__.Test)
----------------------------------------------------------------------
TestFailed: failUnlessEqual
{'A': 65, 'C': 67, ...0, 'P ': 0, 'R': 82, 'U': 85, 'T': 84, 'W': 
87, 'V': 8...
                   ...    ^^   ^                                            ...
{'A': 65, 'C': 67, ...0, 'S': 83, 'R': 82, 'U': 85, 'T': 84, 'W': 
87, 'V': 8...
                   ...    ^   ^^                                            ...
  File &quot;F:\temp\test.py&quot;, line 59, in test_failunlessEqual4
    self.failUnlessEqual(d2, d1)

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

The attached file contains the changes, assuming that 
patch &quot;722638 Better output for unittest&quot; has already 
been applied.


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

>Comment By: Steve Purcell (purcell)
Date: 2005-04-10 19:53

Message:
Logged In: YES 
user_id=21477

The idea of using difflib to contract the failure   
messages is a great one.  Having had some   
exposure to GUI front-ends for JUnit, such as those   
available in IDEA and Eclipse, it seems to me that all   
the information available at the point of failure should   
be stored, and only formatted for display by the   
TestRunner at a later point. Eclipse, for example, can  
show long expected and actual value panes in a  
colour-code side-by-side diff viewer, which is even  
better than the difflib output.  
  
Neither the current nor the patched version of unittest  
take the approach of delegating failure message  
formatting to the Runner, but I'd prefer to see things  
move in that direction that to merge this patch in its  
current form.  
  
I guess that a richer hierarchy of failure exceptions  
would be required, so that TestRunners could elect  
to treat specific failures in their own preferred way. 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-20 03:25

Message:
Logged In: YES 
user_id=80475

Steve, do you care to pronounce on this?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-06 08:27

Message:
Logged In: YES 
user_id=80475

The patch should wrap &quot;import difflib&quot; in a try/except and 
revert to prior behavior upon an ImportError.  This will 
make sure unittest still runs on old Pythons.

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

Comment By: Duncan Booth (duncanb)
Date: 2003-04-25 11:35

Message:
Logged In: YES 
user_id=74031

Oops. I forgot to test for the case where the string didn't 
need shortening in the middle. New patch uploaded.

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

Comment By: Thomas Heller (theller)
Date: 2003-04-25 11:03

Message:
Logged In: YES 
user_id=11105

There's a bug in your patch:

!     else:
!         x, y = s[:LINELEN+1], t[:LINELEN+1]
!         left = 0

s and t are not defined here (UnboundLocal exception is raised),

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470
From noreply at sourceforge.net  Sun Apr 10 21:47:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 10 21:48:01 2005
Subject: [Patches] [ python-Patches-1175850 ] Allow weak referencing of
	classic classes
Message-ID: <E1DKiPV-0001ax-GV@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Allow weak referencing of classic classes

Initial Comment:
In Python 2.4, you can weakref instances of classic
classes but not the classes themselves.  Attached is a
patch which adds weakref support to classic classes.

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

>Comment By: Greg Chapman (glchapman)
Date: 2005-04-10 11:47

Message:
Logged In: YES 
user_id=86307

Ah, I see, not so easy to do it properly.  Fair enough.  One
quick question though: Py_TPFLAGS_HAVE_WEAKREFS is included
in Py_TPFLAGS_DEFAULT.  I didn't include it explicitly
because of that and because neither of the other two types
in classobject.c explicitly uses it (though I see other
types do explicitly use it).  So are PyInstance_Type and
PyMethod_Type wrong?  (Should I include a change to their
definitions?)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 10:51

Message:
Logged In: YES 
user_id=80475

Be sure to add Py_TPFLAGS_HAVE_WEAKREFS to tp_flags.

Beef-up the unittest.  See test_weakref() in
test.test_deque.py for an example.

Add classic classes to the list of weak referencables in
libweakref.tex.  Include a \versionadded tag.

Add an entry to Misc/NEWS.


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

Comment By: Greg Chapman (glchapman)
Date: 2005-04-10 09:05

Message:
Logged In: YES 
user_id=86307

Here's my use case.  I've been experimenting with the
multimethods module written by David Mertz (part of his
gnosis utilities).  This uses mros from a declared signature
and from the actual parameter types to determine which
overload to call.  Classic classes don't have an mro, so I
needed to calculate one to accomodate them.  Having done so,
I wanted to cache it.  The best solution might be the one
I'm using now, which is simply to assign the calculated mro
to a __mro__ attribute of the classic class.  However, it
seemed better to me to use an external cache, rather than
modifying the class.  I wanted this external cache to be a
WeakKeyDictionary, because, if a module containing a classic
class is reloaded, I didn't want the old version of the
class kept alive solely by my cache (it avoided a reference
cycle with the mro itself by storing a list with the first
element set to None; then, when fetched,  copying the list
and putting the class in the copy's first element).

Anyway, feel free to reject this.  It was so easy to do, I
just thought I'd go ahead and post it in case the lack was
simply an oversight.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 08:02

Message:
Logged In: YES 
user_id=80475

I'm curious why you would ever want to do this.  It is
somewhat rare to delete a class reference and, I presume,
rarer still to need a weak-reference to such a class.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&group_id=5470
From noreply at sourceforge.net  Mon Apr 11 01:28:16 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 11 01:28:21 2005
Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for
	longs
Message-ID: <E1DKlqi-0004pH-Gi@sc8-sf-web2.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Armin Rigo (arigo)
Summary: explicit sign variable for longs

Initial Comment:
This patch removes longobject.c abuse of ob_size to store the sign 
in favour of an explicit sign member, as mentioned on python-dev.

The only other file that needed modifying is marshal.c (but the 
marshal format isn't changed).

It doesn't touch all the various code that handles ob_size 
generically.

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

>Comment By: Tim Peters (tim_one)
Date: 2005-04-10 19:28

Message:
Logged In: YES 
user_id=31435

Armin, I don't understand your use case.  Can you be more 
explicit?  Best I can guess, you're using Python longs on a 
32-bit box to store positive integers with bit 2**31 set.  But 
there's no change in memory burden for those (rounds up to 
24 bytes either way), so that can't be what you mean.  
Maybe you're using Python longs to store _all_ integers, no 
matter how small they are?  But in that case you weren't 
serious about memory use to begin with.

Michael, I got confused at the start of the patch.  When you 
changed the comment

SUM(for i=0 through abs(ob_size)-1) ob_digit[i] * 2**(SHIFT*i)

to

sign * SUM(for i=0 through ob_size) ob_digit[i] * 2**(SHIFT*i)

you dropped the "-1" as well as the "abs()".  That wasn't 
intended, was it?

Was also confused by why you dropped the "zero is 
represented by ob_size == 0." comment.

It would be very helpful to rename the new member, e.g., 
as "long_sign".  Then it's easy to find references in the code 
with an editor search.


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

Comment By: Armin Rigo (arigo)
Date: 2005-04-08 10:20

Message:
Logged In: YES 
user_id=4771

Unlike Tim I have a use case for lots of small longs in memory: to store unsigned machine integers.  It's exactly the case where it would be nice that the extra field didn't cross the malloc 8-byte boundary.  Of course, it's exactly NOT what is happening here on 32-bit machines, and this patch makes program relying on this kind of longs suddenly consume 8 extra bytes per long.  Damn.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-06 09:51

Message:
Logged In: YES 
user_id=6656

Oh, and I meant to say, it passes make test but more testing is certainly 
welcome -- some mistakes show up in pretty obscure ways...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470
From noreply at sourceforge.net  Mon Apr 11 01:44:19 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 11 01:44:21 2005
Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for
	longs
Message-ID: <E1DKm6F-0005BR-4a@sc8-sf-web2.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Armin Rigo (arigo)
Summary: explicit sign variable for longs

Initial Comment:
This patch removes longobject.c abuse of ob_size to store the sign 
in favour of an explicit sign member, as mentioned on python-dev.

The only other file that needed modifying is marshal.c (but the 
marshal format isn't changed).

It doesn't touch all the various code that handles ob_size 
generically.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-11 00:44

Message:
Logged In: YES 
user_id=6656

Good, I didn't really understand Armin's point either :)

Here's a new version of the patch that pays a bit more attention to the 
comments (I changed my mind over a few details while writing it, I'm not 
entirely surprised that clarity suffered) and renames the sign member to 
long_sign -- but it turns out that you could find all references by searching 
for "->sign"...

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-11 00:28

Message:
Logged In: YES 
user_id=31435

Armin, I don't understand your use case.  Can you be more 
explicit?  Best I can guess, you're using Python longs on a 
32-bit box to store positive integers with bit 2**31 set.  But 
there's no change in memory burden for those (rounds up to 
24 bytes either way), so that can't be what you mean.  
Maybe you're using Python longs to store _all_ integers, no 
matter how small they are?  But in that case you weren't 
serious about memory use to begin with.

Michael, I got confused at the start of the patch.  When you 
changed the comment

SUM(for i=0 through abs(ob_size)-1) ob_digit[i] * 2**(SHIFT*i)

to

sign * SUM(for i=0 through ob_size) ob_digit[i] * 2**(SHIFT*i)

you dropped the "-1" as well as the "abs()".  That wasn't 
intended, was it?

Was also confused by why you dropped the "zero is 
represented by ob_size == 0." comment.

It would be very helpful to rename the new member, e.g., 
as "long_sign".  Then it's easy to find references in the code 
with an editor search.


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

Comment By: Armin Rigo (arigo)
Date: 2005-04-08 15:20

Message:
Logged In: YES 
user_id=4771

Unlike Tim I have a use case for lots of small longs in memory: to store unsigned machine integers.  It's exactly the case where it would be nice that the extra field didn't cross the malloc 8-byte boundary.  Of course, it's exactly NOT what is happening here on 32-bit machines, and this patch makes program relying on this kind of longs suddenly consume 8 extra bytes per long.  Damn.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-06 14:51

Message:
Logged In: YES 
user_id=6656

Oh, and I meant to say, it passes make test but more testing is certainly 
welcome -- some mistakes show up in pretty obscure ways...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470
From noreply at sourceforge.net  Mon Apr 11 02:00:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 11 02:00:12 2005
Subject: [Patches] [ python-Patches-1175004 ] Export more libreadline API
	functions
Message-ID: <E1DKmLZ-0000gx-QK@sc8-sf-web3.sourceforge.net>

Patches item #1175004, was opened at 2005-04-01 20:30
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175004&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Edge (bruce_edge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Export more libreadline API functions

Initial Comment:
The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-11 01:00

Message:
Logged In: YES 
user_id=6656

I've just broken this patch by changing the signature of the set_hook/
on_hook functions.

There seem to be some whitespace oddities (e.g. right at the start of the 
patch).

The docstrings should use the PyDoc_STRVAR macros.

I'm not sure about some of the details of the py_callback stuff (although 
the functionality seems desirable):

1) the name -- I think I'd find python_command more transparent
2) it would be nice to pass the count and key arguments to the Python 
callable
3) the comments around it's implementation don't make much sense to 
me.
4) the example in the docs -- which is what finally clued me in to what the 
function did :) -- isn't self-contained.

None of this should be very hard to deal with, but I don't know when/if I'd 
get round to it myself.

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

Comment By: Bruce Edge (bruce_edge)
Date: 2005-04-04 16:25

Message:
Logged In: YES 
user_id=1251183

I got the OK to work on the docs. Here's the patch
resubmitted with the libreadline.tex changes.

-Bruce

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 22:31

Message:
Logged In: YES 
user_id=21627

As incomplete work, we might have to reject it, unless
somebody volunteers to complete it. Let's give it one month
from now.

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

Comment By: Bruce Edge (bruce_edge)
Date: 2005-04-01 22:16

Message:
Logged In: YES 
user_id=1251183

AFAIK, yes, they have always been available, at least in
Linux. I've been carrying this patch around since python 2.1.
I have not looked into this on other platforms.
I can't commit to providing doc changes. With my schedule,
it was all I could do to package it up and send it in. 
I'm sorry, I know this is incomplete work, but I figure
someone may be able to use it.

-Bruce

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-04-01 21:57

Message:
Logged In: YES 
user_id=21627

Have these function always been available in readline (i.e.
all readline versions)? If not, please provide configure.in
changes.

Also, please provide Doc/lib/libreadline.tex changes.

If you cannot provide these things, please indicate so.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175004&group_id=5470
From noreply at sourceforge.net  Mon Apr 11 05:09:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 11 05:09:50 2005
Subject: [Patches] [ python-Patches-1180305 ] clarify behavior of StringIO
	objects when preinitialized
Message-ID: <E1DKpJ5-0001q1-BG@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: clarify behavior of StringIO objects when preinitialized

Initial Comment:
This patch clarifies that a StringIO object, when given
a value in the constructor, behaves like a file opened
with mode 'r+': the file pointer is positioned at the
beginning, and write() overwrites the previous string.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-10 22:09

Message:
Logged In: YES 
user_id=80475

Already fixed.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180305&group_id=5470
From noreply at sourceforge.net  Mon Apr 11 11:38:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 11 11:38:55 2005
Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for
	longs
Message-ID: <E1DKvNc-0006uB-Gn@sc8-sf-web2.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Armin Rigo (arigo)
Summary: explicit sign variable for longs

Initial Comment:
This patch removes longobject.c abuse of ob_size to store the sign 
in favour of an explicit sign member, as mentioned on python-dev.

The only other file that needed modifying is marshal.c (but the 
marshal format isn't changed).

It doesn't touch all the various code that handles ob_size 
generically.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-11 09:38

Message:
Logged In: YES 
user_id=4771

Sorry, I tested the memory overhead of adding an "int" field long_sign, and forgot that the digits were "short".

(mwh, your patch #2 forgot to rename "sign" in marshal.c)



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

Comment By: Michael Hudson (mwh)
Date: 2005-04-10 23:44

Message:
Logged In: YES 
user_id=6656

Good, I didn't really understand Armin's point either :)

Here's a new version of the patch that pays a bit more attention to the 
comments (I changed my mind over a few details while writing it, I'm not 
entirely surprised that clarity suffered) and renames the sign member to 
long_sign -- but it turns out that you could find all references by searching 
for "->sign"...

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-10 23:28

Message:
Logged In: YES 
user_id=31435

Armin, I don't understand your use case.  Can you be more 
explicit?  Best I can guess, you're using Python longs on a 
32-bit box to store positive integers with bit 2**31 set.  But 
there's no change in memory burden for those (rounds up to 
24 bytes either way), so that can't be what you mean.  
Maybe you're using Python longs to store _all_ integers, no 
matter how small they are?  But in that case you weren't 
serious about memory use to begin with.

Michael, I got confused at the start of the patch.  When you 
changed the comment

SUM(for i=0 through abs(ob_size)-1) ob_digit[i] * 2**(SHIFT*i)

to

sign * SUM(for i=0 through ob_size) ob_digit[i] * 2**(SHIFT*i)

you dropped the "-1" as well as the "abs()".  That wasn't 
intended, was it?

Was also confused by why you dropped the "zero is 
represented by ob_size == 0." comment.

It would be very helpful to rename the new member, e.g., 
as "long_sign".  Then it's easy to find references in the code 
with an editor search.


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

Comment By: Armin Rigo (arigo)
Date: 2005-04-08 14:20

Message:
Logged In: YES 
user_id=4771

Unlike Tim I have a use case for lots of small longs in memory: to store unsigned machine integers.  It's exactly the case where it would be nice that the extra field didn't cross the malloc 8-byte boundary.  Of course, it's exactly NOT what is happening here on 32-bit machines, and this patch makes program relying on this kind of longs suddenly consume 8 extra bytes per long.  Damn.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-06 13:51

Message:
Logged In: YES 
user_id=6656

Oh, and I meant to say, it passes make test but more testing is certainly 
welcome -- some mistakes show up in pretty obscure ways...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470
From noreply at sourceforge.net  Mon Apr 11 15:04:11 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 11 15:04:14 2005
Subject: [Patches] [ python-Patches-1180695 ] st_gen and st_birthtime
	support for FreeBSD
Message-ID: <E1DKyaJ-0002jf-1U@sc8-sf-web3.sourceforge.net>

Patches item #1180695, was opened at 2005-04-11 05:04
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=1180695&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antti Louko (alouko)
Assigned to: Nobody/Anonymous (nobody)
Summary: st_gen and st_birthtime support for FreeBSD

Initial Comment:
This patch implements nanosecond resolution in stat
results for FreeBSD systems.  It also adds st_birthtime
and st_gen (only seen by root) fields.

Tested on FreeBSD 5.3

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180695&group_id=5470
From noreply at sourceforge.net  Mon Apr 11 21:50:33 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 11 21:50:36 2005
Subject: [Patches] [ python-Patches-1180995 ] binary formats for marshalling
	floats
Message-ID: <E1DL4vZ-000262-Sd@sc8-sf-web1.sourceforge.net>

Patches item #1180995, was opened at 2005-04-11 20: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=1180995&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: binary formats for marshalling floats

Initial Comment:
This patch makes marshal.c use a binary format for floats when 
version > 1 using _PyFloat_Pack8, _PyFloat_Unpack8 (as 
suggested on python-dev).

It doesn't actually update the default version yet, so you have to be 
explicit about it:

>>> marshal.dumps(1.0, 2) 
'g\x00\x00\x00\x00\x00\x00\xf0?'

This almost certainly falls in the realm of platform-depedent accident 
-- what does frexp do with special values? -- but on my system:

>>> inf = 1e308*1e308
>>> inf
inf
>>> marshal.dumps(inf, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: unmarshallable object



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180995&group_id=5470
From noreply at sourceforge.net  Mon Apr 11 22:10:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 11 22:10:18 2005
Subject: [Patches] [ python-Patches-1180995 ] binary formats for marshalling
	floats
Message-ID: <E1DL5ES-00038E-Ck@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: binary formats for marshalling floats

Initial Comment:
This patch makes marshal.c use a binary format for floats when 
version > 1 using _PyFloat_Pack8, _PyFloat_Unpack8 (as 
suggested on python-dev).

It doesn't actually update the default version yet, so you have to be 
explicit about it:

>>> marshal.dumps(1.0, 2) 
'g\x00\x00\x00\x00\x00\x00\xf0?'

This almost certainly falls in the realm of platform-depedent accident 
-- what does frexp do with special values? -- but on my system:

>>> inf = 1e308*1e308
>>> inf
inf
>>> marshal.dumps(inf, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: unmarshallable object



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

>Comment By: Tim Peters (tim_one)
Date: 2005-04-11 16:10

Message:
Logged In: YES 
user_id=31435

Yes, C89 says nothing about what frexp() does in the 
presence of infinities, NaNs or signed zeroes.  That's why 
whether pickling/unpickling (proto >= 1), or struct 
packing/unpacking (std mode), such things appears to work-- 
or how it fails --have always been platform-dependent 
accidents,

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180995&group_id=5470
From noreply at sourceforge.net  Tue Apr 12 09:37:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 12 09:37:43 2005
Subject: [Patches] [ python-Patches-1181301 ] make float packing copy bytes
	when they can
Message-ID: <E1DLFxs-0006JK-8U@sc8-sf-web4.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: make float packing copy bytes when they can

Initial Comment:
As discussed on python-dev, this makes the 
_PyFloat_{Pack,Unpack}{4,8} functions copy bytes around when 
peering at 1.5 has the right result.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470
From noreply at sourceforge.net  Tue Apr 12 11:00:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 12 11:00:54 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DLHGO-0001oq-8V@sc8-sf-web4.sourceforge.net>

Patches item #1181334, was opened at 2005-04-12 09:00
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=1181334&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Tue Apr 12 13:03:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 12 13:03:38 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DLJBA-0000kp-Ms@sc8-sf-web2.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 07:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Tue Apr 12 13:34:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 12 13:34:35 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DLJf6-00025B-G5@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-12 11:34

Message:
Logged In: YES 
user_id=4771

Doesn't work, because the dict can be modified during iteration.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 11:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Tue Apr 12 17:43:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 12 17:43:42 2005
Subject: [Patches] [ python-Patches-1063914 ] Tkinter clipboard_get method
	(new in Tk 8.4)
Message-ID: <E1DLNY8-000683-42@sc8-sf-web4.sourceforge.net>

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

Category: Tkinter
Group: Python 2.5
Status: Open
Resolution: None
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: Jeff Epler (jepler)
Date: 2005-04-12 10: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 07: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 16: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 noreply at sourceforge.net  Tue Apr 12 19:18:40 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 12 19:18:43 2005
Subject: [Patches] [ python-Patches-1181301 ] make float packing copy bytes
	when they can
Message-ID: <E1DLP28-00053G-Bx@sc8-sf-web1.sourceforge.net>

Patches item #1181301, was opened at 2005-04-12 08:37
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: make float packing copy bytes when they can

Initial Comment:
As discussed on python-dev, this makes the 
_PyFloat_{Pack,Unpack}{4,8} functions copy bytes around when 
peering at 1.5 has the right result.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-12 18:18

Message:
Logged In: YES 
user_id=6656

New patch, which attacks comments in floatobject.h and implements Tim's 
idea of refusing to unpack an IEEE special on a non-IEEE platform.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470
From noreply at sourceforge.net  Tue Apr 12 19:24:17 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 12 19:24:19 2005
Subject: [Patches] [ python-Patches-1180995 ] binary formats for marshalling
	floats
Message-ID: <E1DLP7Z-00036o-88@sc8-sf-web4.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: binary formats for marshalling floats

Initial Comment:
This patch makes marshal.c use a binary format for floats when 
version > 1 using _PyFloat_Pack8, _PyFloat_Unpack8 (as 
suggested on python-dev).

It doesn't actually update the default version yet, so you have to be 
explicit about it:

>>> marshal.dumps(1.0, 2) 
'g\x00\x00\x00\x00\x00\x00\xf0?'

This almost certainly falls in the realm of platform-depedent accident 
-- what does frexp do with special values? -- but on my system:

>>> inf = 1e308*1e308
>>> inf
inf
>>> marshal.dumps(inf, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: unmarshallable object



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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-12 18:24

Message:
Logged In: YES 
user_id=6656

New patch.  This attacks error handling in unmarshalling code objects to 
be more likely to reflect the real reason unmarshalling fails, and updates 
the default marshal version to 2.

Combined with my float packing changes this gives us a much more 
coherent float marshalling/unmarshalling story.

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-11 21:10

Message:
Logged In: YES 
user_id=31435

Yes, C89 says nothing about what frexp() does in the 
presence of infinities, NaNs or signed zeroes.  That's why 
whether pickling/unpickling (proto >= 1), or struct 
packing/unpacking (std mode), such things appears to work-- 
or how it fails --have always been platform-dependent 
accidents,

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180995&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 02:22:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 02:22:48 2005
Subject: [Patches] [ python-Patches-1167628 ] [AST] Generator expressions
Message-ID: <E1DLVeX-00022l-1M@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: AST
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Brett Cannon (bcannon)
Summary: [AST] Generator expressions

Initial Comment:
Adds generator expression support to the AST branch. 
Support is sufficient to allow test_grammar to pass. 
 
Also eliminates the display of interim results within functions 
compiled at the interactive prompt, and the allocation of large 
amounts of memory when zero is passed to asdl_seq_new. 

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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-12 17:22

Message:
Logged In: YES 
user_id=357491

OK, I have applied the patch and tweaked it some, but I have
no committed yet because I can't run test_grammar to
completion yet; need to get to the other patches before I
can get that far.

Couple comments on the patch, though, Nick.  First, please
use unified diffs if you can.  I personally find them easier
to read and they are the agreed-upon standard for patches. 
Another is to please use PEP 7 as a coding guideline when
possible.  And if the surrounding code isn't huge and breaks
the coding standard please fix it.  I am going to go through
and fix all the code eventually during final code review,
but whatever can get done now would be great.

And now I see what you mean about the grammar for genexps. 
All of that duplicate work between listcomps and genexps
just because of some REQ() statements seems wasteful.

Thanks for the hard work on the AST branch so far!

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-22 05:18

Message:
Logged In: YES 
user_id=1038590

I'm going to be out of the country until late next week, so
if you want to incorporate this (or parts of it) into the
PyCon AST sprint, please do. I'll be interested to see the
results of the sprint when I get back.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-22 00:37

Message:
Logged In: YES 
user_id=1038590

Correcting a previous comment: the check that ensures an 
unparenthesised generator expression is a sole argument is in 
ast_for_call. 

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-21 20:04

Message:
Logged In: YES 
user_id=1038590

Updated patch ast_genexp_2.diff which correctly allows generator 
expressions to be part of a testlist_gexp node or an argument node. 
 
Removed old patch which failed for debug builds. 

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-21 19:42

Message:
Logged In: YES 
user_id=1038590

I'm actually wondering if the grammar is entirely correct
here. Really, what is allowed for an argument is:

argument: test [gen_for | ('=' test)]

But that still permits generator expressions that are not
the sole argument. So I'd be tempted to move the 'gen_for'
up to the arglist level:

arglist: (test gen_for) | ((argument ',')* (argument [','] |
'*' test [',' '**' test] |  '**' test))
argument: test ['=' test]

As it is, I simply have a check in ast_gen_exp which imposes
the above rule (i.e. a generator expression as an argument
must be the sole argument, or parenthesised so that it
becomes a 'test' node in its own right)

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-21 19:22

Message:
Logged In: YES 
user_id=1038590

I did wonder about that, but the assert wasn't triggering
for me. The offending line is REQ(n, testlist_gexpr) in
ast_for_genexp.

I'll setup a debug build to check all of the assertions
properly.

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

Comment By: John Ehresman (jpe)
Date: 2005-03-21 10:02

Message:
Logged In: YES 
user_id=22785

This triggers an assert with a genexp in an argument because
the node is not a testlist_gexp, e.g. foo(i for i in
range(5)).  It's unclear what to do with foo(a = i for i in
range(5); see bug # 1167751

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1167628&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 02:31:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 02:31:23 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DLVmr-00006P-0V@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-12 17:31

Message:
Logged In: YES 
user_id=357491

I vote for a patch to special-case range().  This won't be
an issue in Python 3000 when stuff like this become
generators.  Still wish there was a way to come up with a
range object that has ``type(range(1)) == list`` be true,
but check the refcount on the object so that if it is 1 it
can act as a generator instead.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-12 04:34

Message:
Logged In: YES 
user_id=4771

Doesn't work, because the dict can be modified during iteration.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 04:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 07:58:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 07:58:32 2005
Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only
	file-like obj for files in archive
Message-ID: <E1DLatR-0003T3-4t@sc8-sf-web3.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Alan McIntyre (ESRG) (alanmcintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile.open - read-only file-like obj for files in archive

Initial Comment:
I originally started working on updating patch 992750,
but decided after a short while to just start from
scratch, so I'm posting it as a new patch.  Sorry if
this isn't appropriate.

This patch provides a new open() method on ZipFile;
this method returns a file-like object for the
requested item in the archive.  This file-like object
only provides a read() method.

ZipFile.read was modified to use the new open method
(this was suggested by loewis in reference to patch
992750).

The patched zipfile.py passed the existing tests in the
test_zipfile.py from CVS.  New tests were added to
verify the operation of the object returned by open().
These tests were modeled after existing tests for
ZipFile.read(); two read fixed-size chunks from the
file-like object, and two others read random-sized chunks.

I have only run the tests on Windows XP, using
Python2.4 from the official Windows installer.  I will
test the patch out on Linux over the weekend.

If the patch is accepted I'll also generate and submit
patches for the appropriate documentation as well.

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

>Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-04-13 00:58

Message:
Logged In: YES 
user_id=1115903

Uploaded the third revision of this patch; passes all
regression tests against current CVS on WinXP.  I think all
the issues Martin brought up have been addressed except
perhaps for the case of compression rate <1.  I will have a
look at that when I have time; just wanted to get an update
here before the patch started to look abandoned. :)

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-03-14 09:37

Message:
Logged In: YES 
user_id=1115903

Hmm...I could have sworn I did the diff in the correct
order. I'll make sure next time. :)

Here's my comments on your remarks (in order):
- I'm adding support for universal newlines, and will reject
all modes that aren't legal combinations of r, U, and b.
- I'll see if I can make a Zip file store something with
compression < 1, and if I can I'll add a test case for it.
- I'll try work a .flush() in there on the compression
object and come up with a test case if possible
- .read(0) and .readline(0) will both return an empty string
with no side-effects, since this seems to be what builtin
files do.  

Right now ZipExtFile uses the ZipFile's file object, so you
pretty much have to do whatever you're going to do with the
ZipExtFile instance you get back from .open() before you use
that ZipFile instance in a way that moves the file pointer
around. 

I'm sure that somebody will eventually try to use the
ZipFile in this way, so it appears my options are either to
(1) give the ZipExtFile its own file object to use (when
possible), or (2) make sure this limitation is documented. 
#1 feels (to me) to be the "right thing" to do, so that's
what I'll try unless there's a good reason I shouldn't.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-01 02:59

Message:
Logged In: YES 
user_id=21627

The patch is reversed: usually, diff is invoked as "-c old new".

I think it is almost right, but I have a few remarks:
- by tradition, open() should have a mode argument,
defaulting to 'r'; it would be ok to raise exceptions if it
is anything else. However, do consider implementing
universal newlines; allowing 'b' as a no-op might also be
reasonable.
- I wonder what happens if the compression rate is < 1. It
would appear that the code might use too few rawbytes. I
suggest to recursively invoke read in this case.
- I wonder whether it could ever happen that there is still
data to uncompress in the zlib object, ie. whether it might
be necessary to invoke .flush() after exhausting the
rawbytes (and discard the zlib object afterwards)
- it appears that atleast the builtin file object implements
.read(0) as returning an empty string; the manual says that
the entire file is meant only if size is omitted or negative.

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-02-27 01:28

Message:
Logged In: YES 
user_id=1115903

zipfile_patch2.tgz: I updated the file-like object to
support readline, readlines, __iter__ and next().  Added
tests for those new methods.  Also added a patch for the
documentation.

Passes regression tests on 2.5a0 built from CVS HEAD with
MSVC .NET on Windows XP.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 12:24:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 12:24:06 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DLf2S-0003ds-9Y@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-13 10:24

Message:
Logged In: YES 
user_id=4771

Ok, here is a patch special-casing range() only.  It's a bit simpler, and faster too.

Did I already mention around here that the class/type unification of Python 2.2 might have been better done, in my opinion, simply by replacing the built-in type() with lambda x: x.__class__?

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 00:31

Message:
Logged In: YES 
user_id=357491

I vote for a patch to special-case range().  This won't be
an issue in Python 3000 when stuff like this become
generators.  Still wish there was a way to come up with a
range object that has ``type(range(1)) == list`` be true,
but check the refcount on the object so that if it is 1 it
can act as a generator instead.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-12 11:34

Message:
Logged In: YES 
user_id=4771

Doesn't work, because the dict can be modified during iteration.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 11:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 18:34:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 18:35:02 2005
Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only
	file-like obj for files in archive
Message-ID: <E1DLkpP-0007dl-PX@sc8-sf-web3.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Alan McIntyre (ESRG) (alanmcintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile.open - read-only file-like obj for files in archive

Initial Comment:
I originally started working on updating patch 992750,
but decided after a short while to just start from
scratch, so I'm posting it as a new patch.  Sorry if
this isn't appropriate.

This patch provides a new open() method on ZipFile;
this method returns a file-like object for the
requested item in the archive.  This file-like object
only provides a read() method.

ZipFile.read was modified to use the new open method
(this was suggested by loewis in reference to patch
992750).

The patched zipfile.py passed the existing tests in the
test_zipfile.py from CVS.  New tests were added to
verify the operation of the object returned by open().
These tests were modeled after existing tests for
ZipFile.read(); two read fixed-size chunks from the
file-like object, and two others read random-sized chunks.

I have only run the tests on Windows XP, using
Python2.4 from the official Windows installer.  I will
test the patch out on Linux over the weekend.

If the patch is accepted I'll also generate and submit
patches for the appropriate documentation as well.

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

>Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-04-13 11:34

Message:
Logged In: YES 
user_id=1115903

I found a problem with my universal newline handling code in
readline(); if the first byte of an '\r\n' pair was read
from file but the second byte didn't come in on that same
read, it resulted in the next line having an inappropriate
'\n' prepended to it.  zipfile_patch4.tgz has a fix for this
included (with everything else, of course).

I'm going to test the open() capability in a real
application with some reasonably large zip files (containing
files up to just short of 2GB) over the next few days, so if
any bugs or performance problems show up I may have some
more changes.

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-04-13 00:58

Message:
Logged In: YES 
user_id=1115903

Uploaded the third revision of this patch; passes all
regression tests against current CVS on WinXP.  I think all
the issues Martin brought up have been addressed except
perhaps for the case of compression rate <1.  I will have a
look at that when I have time; just wanted to get an update
here before the patch started to look abandoned. :)

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-03-14 09:37

Message:
Logged In: YES 
user_id=1115903

Hmm...I could have sworn I did the diff in the correct
order. I'll make sure next time. :)

Here's my comments on your remarks (in order):
- I'm adding support for universal newlines, and will reject
all modes that aren't legal combinations of r, U, and b.
- I'll see if I can make a Zip file store something with
compression < 1, and if I can I'll add a test case for it.
- I'll try work a .flush() in there on the compression
object and come up with a test case if possible
- .read(0) and .readline(0) will both return an empty string
with no side-effects, since this seems to be what builtin
files do.  

Right now ZipExtFile uses the ZipFile's file object, so you
pretty much have to do whatever you're going to do with the
ZipExtFile instance you get back from .open() before you use
that ZipFile instance in a way that moves the file pointer
around. 

I'm sure that somebody will eventually try to use the
ZipFile in this way, so it appears my options are either to
(1) give the ZipExtFile its own file object to use (when
possible), or (2) make sure this limitation is documented. 
#1 feels (to me) to be the "right thing" to do, so that's
what I'll try unless there's a good reason I shouldn't.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-01 02:59

Message:
Logged In: YES 
user_id=21627

The patch is reversed: usually, diff is invoked as "-c old new".

I think it is almost right, but I have a few remarks:
- by tradition, open() should have a mode argument,
defaulting to 'r'; it would be ok to raise exceptions if it
is anything else. However, do consider implementing
universal newlines; allowing 'b' as a no-op might also be
reasonable.
- I wonder what happens if the compression rate is < 1. It
would appear that the code might use too few rawbytes. I
suggest to recursively invoke read in this case.
- I wonder whether it could ever happen that there is still
data to uncompress in the zlib object, ie. whether it might
be necessary to invoke .flush() after exhausting the
rawbytes (and discard the zlib object afterwards)
- it appears that atleast the builtin file object implements
.read(0) as returning an empty string; the manual says that
the entire file is meant only if size is omitted or negative.

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-02-27 01:28

Message:
Logged In: YES 
user_id=1115903

zipfile_patch2.tgz: I updated the file-like object to
support readline, readlines, __iter__ and next().  Added
tests for those new methods.  Also added a patch for the
documentation.

Passes regression tests on 2.5a0 built from CVS HEAD with
MSVC .NET on Windows XP.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 19:08:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 19:08:22 2005
Subject: [Patches] [ python-Patches-1182394 ] HMAC hexdigest and general
	review
Message-ID: <E1DLlLg-0000rf-E0@sc8-sf-web3.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: HMAC hexdigest and general review

Initial Comment:
This patch is primarily aimed at speeding up the
HMAC.hexdigest method.  The current implementation is::

        return "".join([hex(ord(x))[2:].zfill(2)
                        for x in tuple(self.digest())])

Which is correct, but a little too clever.  Especially
when other tools are available.  The attached patch
adds HMAC._current that returns the hash object
combined from self.inner and self.outter to be used by
HMAC.digest and HMAC.hexdigest.  This results in an 11
fold speed improvement for md5 and sha digestmod's
while also making the code a little easier.


Other review points for the HMAC module include
removing "_secret_backdoor_key" in favor of using
"None" as the sentinel.  In this case, it makes sense
to use None because it is an invalid key, avoids a
global lookup in py2.4 and beyond, and is just as
readable.  

I also moved blocksize to a class level constant.  This
allows implementations to create different blocksize
hashes by inheriting and changing this value.  This
also involved a change to copy() to use
self.__class__(None) instead of directly calling
HMAC(None).

The final comment is that it would be nice to have a
C-level implementation of _strxor in binascii for this
module and possibly other uses.  However, I don't
really know a significantly faster way of implementing
this method in python.

Thanks,
-Shane Holloway

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 19:36:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 19:37:04 2005
Subject: [Patches] [ python-Patches-1006238 ] cross compile patch
Message-ID: <E1DLlnO-0001hB-CM@sc8-sf-web1.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Goertzen (goertzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cross compile patch

Initial Comment:
Here's a cross compile patch I prepared a while ago but
never got around to submitting.  I've been using it
happily for months to cross compile python for embedded
systems.

Below is a descriptive excerpt from the patch.  Also
note that the patch modifies configure.in, but not
configure.  You will need to regenerate configure with
something like 

autoconf configure.in >configure

This patch is inpsired from work by Klaus Reimer at
http://www.ailis.de/~k/docs/crosscompiling/python.php

+ Cross Compiling
+ ---------------
+ 
+ Python can be cross compiled by supplying different
--host and --build
+ parameters to configure.  (Python is compiled on the
"build" system
+ and executed on the "host" system, in case you forgot
:).  Python is
+ tricky to cross compile because it needs to execute
parts of itself
+ during construction.  To work around this, make's
VPATH feature is
+ used to compile a native python in the subdirectory
"buildpython".
+ When parts of python need to be executed during
construction, the
+ "buildpython" versions are used.
+ 
+ A consequence of using the VPATH feature is that you
may not do a
+ cross compile build in the source directory.  In
other words, do this:
+ 
+ mkdir mydir
+ cd mydir
+ ../Python/configure --host=powerpc-405-linux-gnu
--build=i686-pc-linux-gnu
+ make
+ 
+ Cross compiling works well under linux, mileage may
vary for other
+ platforms.
+ 
+ A few reminders on using configure to cross compile:
+ - Cross compile tools must be in the PATH.
+ - Cross compile tools must be prefixed with the host type
+ (ie powerpc-405-linux-gnu-cc,
powerpc-405-linux-gnu-ranlib, ...)
+ - CC, CXX, AR, and RANLIB must be undefined when
running configure and
+ make.  Configure will detect them.
+ 
+ If you need a cross compiler, check out Dan Kegel's
crosstool:
+ http://www.kegel.com/crosstool
+ 
+ 


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

>Comment By: Daniel Goertzen (goertzen)
Date: 2005-04-13 12:36

Message:
Logged In: YES 
user_id=843814

It still works for me, so I've had limited interest in
working on it further.

I think a "real" cross compile patch will involve
significant refactoring of distutils and the main setup.py
script.  Should this start with a PEP?


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

Comment By: Ned Ludd (solarx)
Date: 2005-04-09 15:43

Message:
Logged In: YES 
user_id=148412

Any progress with this on? 
python and perl are two of the last major things to overcome
in the x-compile world.

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

Comment By: Mike Frysinger (vapier)
Date: 2004-10-26 11:00

Message:
Logged In: YES 
user_id=114429

we've been using this with uClibc for a while now and it
works great ...

ive personally built (on amd64) & deployed (on
x86/ppc/arm/mips/sh4) python ... would great if this finally
made it into the official sources :)

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

Comment By: Jeff Epler (jepler)
Date: 2004-10-20 20:08

Message:
Logged In: YES 
user_id=2772

This patch applies cleanly to today's CVS head.

If building in the source directory while cross compiling
fails, please make configure complain about it.

This patch makes the build process invoke make recursively,
which is a big minus.  I'd rather see pgen built with a
HOSTCC and just assume python is available on $PATH for the
setup.py step.  There's no reason to build all the shared
modules in buildpython, either, which would speed things up
a fair bit.

On to how it worked for me:
Not cross-compiling, this produces no unexpected test
failures in "make test". (redhat9)

Cross compiling for i386-pc-bsdi2.1 everything goes fine
until it tries to run buildpython and make shared modules,
but shared modules don't work in the first place on bsdi2. 
I did not test the resulting Python binary.

Cross compiling for i386-redhat-linux (libc6) some
extensions fail to build, but this could be because my
header files for the cross-development environment are not
complete.  Running "make test" tries to invoke the
"buildpython/python" and doesn't work.  Running it manually
I get some skips due to modules that did not build, but
everything that did build seems to pass. (OK, so I wrote
this before the tests completed, but they're off to a good
start)

I currently cross-compile python 2.3 for win32 (mingw), and
until recently cross-compiled it for bsdi2 and redhat6. 
However, I did not use configure or the included makefiles
to do this (in order to integrate in a non-recursive build
procedure that builds several packages), so this patch is
unlikely to benefit me directly.

I don't think this patch is ready to be applied.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 20:01:05 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 20:01:12 2005
Subject: [Patches] [ python-Patches-1182394 ] HMAC hexdigest and general
	review
Message-ID: <E1DLmAj-0003H6-Gx@sc8-sf-web3.sourceforge.net>

Patches item #1182394, was opened at 2005-04-13 09:08
Message generated for change (Comment added) made by alouko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: HMAC hexdigest and general review

Initial Comment:
This patch is primarily aimed at speeding up the
HMAC.hexdigest method.  The current implementation is::

        return "".join([hex(ord(x))[2:].zfill(2)
                        for x in tuple(self.digest())])

Which is correct, but a little too clever.  Especially
when other tools are available.  The attached patch
adds HMAC._current that returns the hash object
combined from self.inner and self.outter to be used by
HMAC.digest and HMAC.hexdigest.  This results in an 11
fold speed improvement for md5 and sha digestmod's
while also making the code a little easier.


Other review points for the HMAC module include
removing "_secret_backdoor_key" in favor of using
"None" as the sentinel.  In this case, it makes sense
to use None because it is an invalid key, avoids a
global lookup in py2.4 and beyond, and is just as
readable.  

I also moved blocksize to a class level constant.  This
allows implementations to create different blocksize
hashes by inheriting and changing this value.  This
also involved a change to copy() to use
self.__class__(None) instead of directly calling
HMAC(None).

The final comment is that it would be nice to have a
C-level implementation of _strxor in binascii for this
module and possibly other uses.  However, I don't
really know a significantly faster way of implementing
this method in python.

Thanks,
-Shane Holloway

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

Comment By: Antti Louko (alouko)
Date: 2005-04-13 10:01

Message:
Logged In: YES 
user_id=116402

This seems good.

I would also need strxor.  Should we add it to the string
type? ^ operator is not currently defined for strings.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 21:56:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 21:56:28 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DLnyJ-0000NY-Ur@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 12:56

Message:
Logged In: YES 
user_id=357491

No, I don't remember you ever mentioning that, but that is a
good idea since that would allow easy faking of things.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-13 03:24

Message:
Logged In: YES 
user_id=4771

Ok, here is a patch special-casing range() only.  It's a bit simpler, and faster too.

Did I already mention around here that the class/type unification of Python 2.2 might have been better done, in my opinion, simply by replacing the built-in type() with lambda x: x.__class__?

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-12 17:31

Message:
Logged In: YES 
user_id=357491

I vote for a patch to special-case range().  This won't be
an issue in Python 3000 when stuff like this become
generators.  Still wish there was a way to come up with a
range object that has ``type(range(1)) == list`` be true,
but check the refcount on the object so that if it is 1 it
can act as a generator instead.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-12 04:34

Message:
Logged In: YES 
user_id=4771

Doesn't work, because the dict can be modified during iteration.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 04:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 21:59:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 22:00:02 2005
Subject: [Patches] [ python-Patches-1167628 ] [AST] Generator expressions
Message-ID: <E1DLo1l-0007rs-36@sc8-sf-web2.sourceforge.net>

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

Category: Core (C code)
Group: AST
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Brett Cannon (bcannon)
Summary: [AST] Generator expressions

Initial Comment:
Adds generator expression support to the AST branch. 
Support is sufficient to allow test_grammar to pass. 
 
Also eliminates the display of interim results within functions 
compiled at the interactive prompt, and the allocation of large 
amounts of memory when zero is passed to asdl_seq_new. 

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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 12:59

Message:
Logged In: YES 
user_id=357491

OK, I went ahead and applied the patch realizing that if I
waited until test_grammar didn't segfault I would have one
massive commit and that would be bad.

So applied as rev. 1.1.2.12 for Python-ast.(c|h), 1.1.2.6
for asdl.c, 1.1.2.59 for ast.c, 2.247.2.3 for compile.c,
1.1.2.106 for newcompile.c, 2.10.8.32 for symtable.c,
1.1.2.11 for Python.asdl, 1.1.2.7 for asdl_c.py, and
1.1.2.14 for compile.txt .

I also went ahead and cleaned up all references to
GeneratorComp to be GeneratorExp instead.

Once again, thanks, Nick, for the patch!

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-12 17:22

Message:
Logged In: YES 
user_id=357491

OK, I have applied the patch and tweaked it some, but I have
no committed yet because I can't run test_grammar to
completion yet; need to get to the other patches before I
can get that far.

Couple comments on the patch, though, Nick.  First, please
use unified diffs if you can.  I personally find them easier
to read and they are the agreed-upon standard for patches. 
Another is to please use PEP 7 as a coding guideline when
possible.  And if the surrounding code isn't huge and breaks
the coding standard please fix it.  I am going to go through
and fix all the code eventually during final code review,
but whatever can get done now would be great.

And now I see what you mean about the grammar for genexps. 
All of that duplicate work between listcomps and genexps
just because of some REQ() statements seems wasteful.

Thanks for the hard work on the AST branch so far!

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-22 05:18

Message:
Logged In: YES 
user_id=1038590

I'm going to be out of the country until late next week, so
if you want to incorporate this (or parts of it) into the
PyCon AST sprint, please do. I'll be interested to see the
results of the sprint when I get back.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-22 00:37

Message:
Logged In: YES 
user_id=1038590

Correcting a previous comment: the check that ensures an 
unparenthesised generator expression is a sole argument is in 
ast_for_call. 

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-21 20:04

Message:
Logged In: YES 
user_id=1038590

Updated patch ast_genexp_2.diff which correctly allows generator 
expressions to be part of a testlist_gexp node or an argument node. 
 
Removed old patch which failed for debug builds. 

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-21 19:42

Message:
Logged In: YES 
user_id=1038590

I'm actually wondering if the grammar is entirely correct
here. Really, what is allowed for an argument is:

argument: test [gen_for | ('=' test)]

But that still permits generator expressions that are not
the sole argument. So I'd be tempted to move the 'gen_for'
up to the arglist level:

arglist: (test gen_for) | ((argument ',')* (argument [','] |
'*' test [',' '**' test] |  '**' test))
argument: test ['=' test]

As it is, I simply have a check in ast_gen_exp which imposes
the above rule (i.e. a generator expression as an argument
must be the sole argument, or parenthesised so that it
becomes a 'test' node in its own right)

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-21 19:22

Message:
Logged In: YES 
user_id=1038590

I did wonder about that, but the assert wasn't triggering
for me. The offending line is REQ(n, testlist_gexpr) in
ast_for_genexp.

I'll setup a debug build to check all of the assertions
properly.

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

Comment By: John Ehresman (jpe)
Date: 2005-03-21 10:02

Message:
Logged In: YES 
user_id=22785

This triggers an assert with a genexp in an argument because
the node is not a testlist_gexp, e.g. foo(i for i in
range(5)).  It's unclear what to do with foo(a = i for i in
range(5); see bug # 1167751

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1167628&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 22:06:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 22:06:49 2005
Subject: [Patches] [ python-Patches-1095541 ] fix for trivial flatten bug in
	astgen
Message-ID: <E1DLo8F-0001OU-9w@sc8-sf-web3.sourceforge.net>

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

Category: Parser/Compiler
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: DSM (dsm001)
>Assigned to: Jeremy Hylton (jhylton)
Summary: fix for trivial flatten bug in astgen

Initial Comment:
The flatten in compiler.ast (from astgen) doesn't work
for sublists, although the source shows it tries to:

>>> compiler.ast.flatten([1,2,(3,4)])
[1, 2, 3, 4]

>>> compiler.ast.flatten([1,2,[3,4]])
[1, 2, [3, 4]]

The dangers of calling your lists 'list'.. (type is
list check fails.)  A brief glance suggests it gets
called with tuples instead so I don't think the bug has
any obvious consequences.

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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 13:06

Message:
Logged In: YES 
user_id=357491

Accidentally assigned this as an AST patch when it actuality
it is for the compiler package.

Fixed to be the proper group and assigned to Jeremy.

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

Comment By: Bj?rn Lindqvist (sonderblade)
Date: 2005-02-11 19:00

Message:
Logged In: YES 
user_id=51702

The patch works but it would be nice if there was a test in
test_compiler.py that checks for correctness of the flattens
too.  

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1095541&group_id=5470
From noreply at sourceforge.net  Wed Apr 13 23:21:28 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 13 23:21:32 2005
Subject: [Patches] [ python-Patches-1182394 ] HMAC hexdigest and general
	review
Message-ID: <E1DLpIe-0006yr-BZ@sc8-sf-web4.sourceforge.net>

Patches item #1182394, was opened at 2005-04-13 11:08
Message generated for change (Comment added) made by shane_holloway
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: HMAC hexdigest and general review

Initial Comment:
This patch is primarily aimed at speeding up the
HMAC.hexdigest method.  The current implementation is::

        return "".join([hex(ord(x))[2:].zfill(2)
                        for x in tuple(self.digest())])

Which is correct, but a little too clever.  Especially
when other tools are available.  The attached patch
adds HMAC._current that returns the hash object
combined from self.inner and self.outter to be used by
HMAC.digest and HMAC.hexdigest.  This results in an 11
fold speed improvement for md5 and sha digestmod's
while also making the code a little easier.


Other review points for the HMAC module include
removing "_secret_backdoor_key" in favor of using
"None" as the sentinel.  In this case, it makes sense
to use None because it is an invalid key, avoids a
global lookup in py2.4 and beyond, and is just as
readable.  

I also moved blocksize to a class level constant.  This
allows implementations to create different blocksize
hashes by inheriting and changing this value.  This
also involved a change to copy() to use
self.__class__(None) instead of directly calling
HMAC(None).

The final comment is that it would be nice to have a
C-level implementation of _strxor in binascii for this
module and possibly other uses.  However, I don't
really know a significantly faster way of implementing
this method in python.

Thanks,
-Shane Holloway

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

>Comment By: Shane Holloway (shane_holloway)
Date: 2005-04-13 15:21

Message:
Logged In: YES 
user_id=283742

I would prefer to keep str's interface lean.  I think
binascii would be a nice home for strxor though.

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

Comment By: Antti Louko (alouko)
Date: 2005-04-13 12:01

Message:
Logged In: YES 
user_id=116402

This seems good.

I would also need strxor.  Should we add it to the string
type? ^ operator is not currently defined for strings.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 00:36:12 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 00:36:14 2005
Subject: [Patches] [ python-Patches-1180695 ] st_gen and st_birthtime
	support for FreeBSD
Message-ID: <E1DLqSy-0001ev-Ga@sc8-sf-web4.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: Antti Louko (alouko)
>Assigned to: Martin v. L?wis (loewis)
Summary: st_gen and st_birthtime support for FreeBSD

Initial Comment:
This patch implements nanosecond resolution in stat
results for FreeBSD systems.  It also adds st_birthtime
and st_gen (only seen by root) fields.

Tested on FreeBSD 5.3

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180695&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 09:51:57 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 09:52:00 2005
Subject: [Patches] [ python-Patches-1181301 ] make float packing copy bytes
	when they can
Message-ID: <E1DLz8n-0000e0-PS@sc8-sf-web3.sourceforge.net>

Patches item #1181301, was opened at 2005-04-12 08:37
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: make float packing copy bytes when they can

Initial Comment:
As discussed on python-dev, this makes the 
_PyFloat_{Pack,Unpack}{4,8} functions copy bytes around when 
peering at 1.5 has the right result.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-14 08:51

Message:
Logged In: YES 
user_id=6656

This version attacks comments some more, uses more interesting probe 
values and, um, actually works on a little-endian platform (previous 
versions had a very stupid bug).

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-12 18:18

Message:
Logged In: YES 
user_id=6656

New patch, which attacks comments in floatobject.h and implements Tim's 
idea of refusing to unpack an IEEE special on a non-IEEE platform.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 09:53:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 09:53:40 2005
Subject: [Patches] [ python-Patches-1180995 ] binary formats for marshalling
	floats
Message-ID: <E1DLzAP-0000jL-R0@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: binary formats for marshalling floats

Initial Comment:
This patch makes marshal.c use a binary format for floats when 
version > 1 using _PyFloat_Pack8, _PyFloat_Unpack8 (as 
suggested on python-dev).

It doesn't actually update the default version yet, so you have to be 
explicit about it:

>>> marshal.dumps(1.0, 2) 
'g\x00\x00\x00\x00\x00\x00\xf0?'

This almost certainly falls in the realm of platform-depedent accident 
-- what does frexp do with special values? -- but on my system:

>>> inf = 1e308*1e308
>>> inf
inf
>>> marshal.dumps(inf, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: unmarshallable object



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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-14 08:53

Message:
Logged In: YES 
user_id=6656

New patch.  Main difference is updating MAGIC.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-12 18:24

Message:
Logged In: YES 
user_id=6656

New patch.  This attacks error handling in unmarshalling code objects to 
be more likely to reflect the real reason unmarshalling fails, and updates 
the default marshal version to 2.

Combined with my float packing changes this gives us a much more 
coherent float marshalling/unmarshalling story.

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-11 21:10

Message:
Logged In: YES 
user_id=31435

Yes, C89 says nothing about what frexp() does in the 
presence of infinities, NaNs or signed zeroes.  That's why 
whether pickling/unpickling (proto >= 1), or struct 
packing/unpacking (std mode), such things appears to work-- 
or how it fails --have always been platform-dependent 
accidents,

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180995&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 09:54:12 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 09:54:15 2005
Subject: [Patches] [ python-Patches-1182394 ] HMAC hexdigest and general
	review
Message-ID: <E1DLzAy-0007e5-7y@sc8-sf-web2.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: HMAC hexdigest and general review

Initial Comment:
This patch is primarily aimed at speeding up the
HMAC.hexdigest method.  The current implementation is::

        return "".join([hex(ord(x))[2:].zfill(2)
                        for x in tuple(self.digest())])

Which is correct, but a little too clever.  Especially
when other tools are available.  The attached patch
adds HMAC._current that returns the hash object
combined from self.inner and self.outter to be used by
HMAC.digest and HMAC.hexdigest.  This results in an 11
fold speed improvement for md5 and sha digestmod's
while also making the code a little easier.


Other review points for the HMAC module include
removing "_secret_backdoor_key" in favor of using
"None" as the sentinel.  In this case, it makes sense
to use None because it is an invalid key, avoids a
global lookup in py2.4 and beyond, and is just as
readable.  

I also moved blocksize to a class level constant.  This
allows implementations to create different blocksize
hashes by inheriting and changing this value.  This
also involved a change to copy() to use
self.__class__(None) instead of directly calling
HMAC(None).

The final comment is that it would be nice to have a
C-level implementation of _strxor in binascii for this
module and possibly other uses.  However, I don't
really know a significantly faster way of implementing
this method in python.

Thanks,
-Shane Holloway

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-14 08:54

Message:
Logged In: YES 
user_id=6656

Attempting to add the ^ for strings is a non-starter.

No opinion on the rest of the patch.

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

Comment By: Shane Holloway (shane_holloway)
Date: 2005-04-13 22:21

Message:
Logged In: YES 
user_id=283742

I would prefer to keep str's interface lean.  I think
binascii would be a nice home for strxor though.

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

Comment By: Antti Louko (alouko)
Date: 2005-04-13 19:01

Message:
Logged In: YES 
user_id=116402

This seems good.

I would also need strxor.  Should we add it to the string
type? ^ operator is not currently defined for strings.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 10:05:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 10:05:58 2005
Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up
Message-ID: <E1DLzMJ-0001fK-6F@sc8-sf-web1.sourceforge.net>

Patches item #1153056, was opened at 2005-02-27 21:14
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check() speed-up

Initial Comment:
Once upon a time, the macros PyInt_Check(),
PyString_Check(), etc., used to be very fast: just a
pointer comparison.  But 2.2 came.  Suddenly, types
could inherit from each other.  Thus the macros became:

(ob->type == &PyXxx_Check ||
   PyType_IsSubType(ob->type, &PyXxx_Check)

Subtyping of built-in types still being rare, the
common cases here are: (1) ob is indeed exactly of type
Xxx, (2) ob is absolutely not an instance of Xxx.  The
macro is fast for case 1 but becomes a call to a slow
function in case 2.

It sounds minor -- but a program can make half a
million "case 2" calls in 5 seconds.

The following patch proposes to fix that, based on a few
measurements that show which are the more common
"case 2" calls in a few applications.  It adds a
family of type flags meaning "this type is not at all an
Xxx", for Xxx in [module, tuple, float, int, unicode,
long, complex, str].

I cannot measure the performance gain on this machine
(figures vary all the time) but it looks like some 0.2s
for the above-mentioned 5s program.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-14 09:05

Message:
Logged In: YES 
user_id=6656

(I haven't seen any mail about this patch!)

> array of N bits, where N is the number of C-level PyXxxObject
> structures

That's unbounded too, in the presence of extension modules.

(I still think my fix for #1153075 suffices, and is probably a good thing).

I can believe that special casing int and str subclasses is worth it -- but 
where to stop?

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

Comment By: Armin Rigo (arigo)
Date: 2005-02-28 09:26

Message:
Logged In: YES 
user_id=4771

Ah, but that's not so different: M can still be arbitrarily
large...

However, see also bug #1153075.  I think that PyInt_Check()
using PyType_IsSubtype() is essentially buggy: the purpose of
PyInt_Check() is to check if the PyObject* is a
PyIntObject*, not if its type pretends to have 'int' in its
mro.  If we fix this, then making PyType_IsSubtype()
faster will become unrelated to making PyXxx_Check()
faster.

If we want to fix PyXxx_Check() for the bug described above
and make it fast too, then we probably only need an
array of N bits, where N is the number of C-level PyXxxObject
structures.  The idea of only including the most common such
structures instead of all of them was based on simplicity and
performance (it's faster and easier to check for a known bit
than for a bit which itself is computed at run-time).

If we want to make PyType_IsSubtype() fast, it might be worth
the effort or not; we should measure it.  But I think it's
unrelated.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-02-28 06:20

Message:
Logged In: YES 
user_id=21627

No. Each type would have an array of M bits, where M is the
maximum number of a super class; each type would also store
the value of M. As types are created and deleted
dynamically, it might be necessary to keep track of assigned
type numbers, and recycle them as types are deleted.

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

Comment By: Armin Rigo (arigo)
Date: 2005-02-27 23:56

Message:
Logged In: YES 
user_id=4771

I'm not sure I understand your suggestion.  Would each type
have an array of N bits, where N is the total number of types
that exist?  That looks quite unreasonable in any program
that builds a lot of types (I know some that build them
programatically in loops).  What I did is a limited
version of that: a bitfield with room for only some commonly
checked-for superclasses.

(With some care, my patch could be modified to build the
bitfield in PyType_Ready(); this would allow the
PyXxx_Check() macros to become a single bit check operation.)

Changing the base classes isn't an issue in my limited patch
because you cannot ever add or remove the core built-in types
I check for from the bases of an existing type.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-02-27 23:44

Message:
Logged In: YES 
user_id=21627

I would rather see a constant-time subtype check implemented
in Python, using strategies that other interpreters have
been using for a long time.

Essentially, each type gets a unique number (e.g. in the
order of PyType_Ready calls), and a bit-field of all
supertypes, with a bit set for each type that is one of its
supertypes. Creation of the bitfield could be delayed until
a subtype check is actually needed.

The tricky part is to update the supertype bitmask when
__super__ is assigned.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 11:22:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 11:22:32 2005
Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up
Message-ID: <E1DM0YP-0005II-FZ@sc8-sf-web3.sourceforge.net>

Patches item #1153056, was opened at 2005-02-27 21:14
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check() speed-up

Initial Comment:
Once upon a time, the macros PyInt_Check(),
PyString_Check(), etc., used to be very fast: just a
pointer comparison.  But 2.2 came.  Suddenly, types
could inherit from each other.  Thus the macros became:

(ob->type == &PyXxx_Check ||
   PyType_IsSubType(ob->type, &PyXxx_Check)

Subtyping of built-in types still being rare, the
common cases here are: (1) ob is indeed exactly of type
Xxx, (2) ob is absolutely not an instance of Xxx.  The
macro is fast for case 1 but becomes a call to a slow
function in case 2.

It sounds minor -- but a program can make half a
million "case 2" calls in 5 seconds.

The following patch proposes to fix that, based on a few
measurements that show which are the more common
"case 2" calls in a few applications.  It adds a
family of type flags meaning "this type is not at all an
Xxx", for Xxx in [module, tuple, float, int, unicode,
long, complex, str].

I cannot measure the performance gain on this machine
(figures vary all the time) but it looks like some 0.2s
for the above-mentioned 5s program.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-14 09:22

Message:
Logged In: YES 
user_id=4771

I am convinced now by #1153075 that PyCheck_Xxx should not be semantically changed, and really means walking the mro.  So the patch here remains valid.

Yes, I know that N is unbounded, that's why the next sentence was "let's only include the most common of them".

Where to stop?  Don't guess, measure.  That's what I did, and in a few applications there were systematically a set of types that were PyChecked quite more often than the others.  So my patch special-cases exactly these types.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-14 08:05

Message:
Logged In: YES 
user_id=6656

(I haven't seen any mail about this patch!)

> array of N bits, where N is the number of C-level PyXxxObject
> structures

That's unbounded too, in the presence of extension modules.

(I still think my fix for #1153075 suffices, and is probably a good thing).

I can believe that special casing int and str subclasses is worth it -- but 
where to stop?

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

Comment By: Armin Rigo (arigo)
Date: 2005-02-28 09:26

Message:
Logged In: YES 
user_id=4771

Ah, but that's not so different: M can still be arbitrarily
large...

However, see also bug #1153075.  I think that PyInt_Check()
using PyType_IsSubtype() is essentially buggy: the purpose of
PyInt_Check() is to check if the PyObject* is a
PyIntObject*, not if its type pretends to have 'int' in its
mro.  If we fix this, then making PyType_IsSubtype()
faster will become unrelated to making PyXxx_Check()
faster.

If we want to fix PyXxx_Check() for the bug described above
and make it fast too, then we probably only need an
array of N bits, where N is the number of C-level PyXxxObject
structures.  The idea of only including the most common such
structures instead of all of them was based on simplicity and
performance (it's faster and easier to check for a known bit
than for a bit which itself is computed at run-time).

If we want to make PyType_IsSubtype() fast, it might be worth
the effort or not; we should measure it.  But I think it's
unrelated.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-02-28 06:20

Message:
Logged In: YES 
user_id=21627

No. Each type would have an array of M bits, where M is the
maximum number of a super class; each type would also store
the value of M. As types are created and deleted
dynamically, it might be necessary to keep track of assigned
type numbers, and recycle them as types are deleted.

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

Comment By: Armin Rigo (arigo)
Date: 2005-02-27 23:56

Message:
Logged In: YES 
user_id=4771

I'm not sure I understand your suggestion.  Would each type
have an array of N bits, where N is the total number of types
that exist?  That looks quite unreasonable in any program
that builds a lot of types (I know some that build them
programatically in loops).  What I did is a limited
version of that: a bitfield with room for only some commonly
checked-for superclasses.

(With some care, my patch could be modified to build the
bitfield in PyType_Ready(); this would allow the
PyXxx_Check() macros to become a single bit check operation.)

Changing the base classes isn't an issue in my limited patch
because you cannot ever add or remove the core built-in types
I check for from the bases of an existing type.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-02-27 23:44

Message:
Logged In: YES 
user_id=21627

I would rather see a constant-time subtype check implemented
in Python, using strategies that other interpreters have
been using for a long time.

Essentially, each type gets a unique number (e.g. in the
order of PyType_Ready calls), and a bit-field of all
supertypes, with a bit set for each type that is one of its
supertypes. Creation of the bitfield could be delayed until
a subtype check is actually needed.

The tricky part is to update the supertype bitmask when
__super__ is assigned.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 11:34:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 11:34:25 2005
Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for
	longs
Message-ID: <E1DM0jv-0006Rs-2m@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Nobody/Anonymous (nobody)
Summary: explicit sign variable for longs

Initial Comment:
This patch removes longobject.c abuse of ob_size to store the sign 
in favour of an explicit sign member, as mentioned on python-dev.

The only other file that needed modifying is marshal.c (but the 
marshal format isn't changed).

It doesn't touch all the various code that handles ob_size 
generically.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-14 09:34

Message:
Logged In: YES 
user_id=4771

Tim, I don't really have the motivation nor knowledge of the long implementation, so I can't review this patch any better than you did already.  Unassigned from me.  My general feeling is that mwh+tim+tests is quite safe already :-)

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-11 09:38

Message:
Logged In: YES 
user_id=4771

Sorry, I tested the memory overhead of adding an "int" field long_sign, and forgot that the digits were "short".

(mwh, your patch #2 forgot to rename "sign" in marshal.c)



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

Comment By: Michael Hudson (mwh)
Date: 2005-04-10 23:44

Message:
Logged In: YES 
user_id=6656

Good, I didn't really understand Armin's point either :)

Here's a new version of the patch that pays a bit more attention to the 
comments (I changed my mind over a few details while writing it, I'm not 
entirely surprised that clarity suffered) and renames the sign member to 
long_sign -- but it turns out that you could find all references by searching 
for "->sign"...

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-10 23:28

Message:
Logged In: YES 
user_id=31435

Armin, I don't understand your use case.  Can you be more 
explicit?  Best I can guess, you're using Python longs on a 
32-bit box to store positive integers with bit 2**31 set.  But 
there's no change in memory burden for those (rounds up to 
24 bytes either way), so that can't be what you mean.  
Maybe you're using Python longs to store _all_ integers, no 
matter how small they are?  But in that case you weren't 
serious about memory use to begin with.

Michael, I got confused at the start of the patch.  When you 
changed the comment

SUM(for i=0 through abs(ob_size)-1) ob_digit[i] * 2**(SHIFT*i)

to

sign * SUM(for i=0 through ob_size) ob_digit[i] * 2**(SHIFT*i)

you dropped the "-1" as well as the "abs()".  That wasn't 
intended, was it?

Was also confused by why you dropped the "zero is 
represented by ob_size == 0." comment.

It would be very helpful to rename the new member, e.g., 
as "long_sign".  Then it's easy to find references in the code 
with an editor search.


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

Comment By: Armin Rigo (arigo)
Date: 2005-04-08 14:20

Message:
Logged In: YES 
user_id=4771

Unlike Tim I have a use case for lots of small longs in memory: to store unsigned machine integers.  It's exactly the case where it would be nice that the extra field didn't cross the malloc 8-byte boundary.  Of course, it's exactly NOT what is happening here on 32-bit machines, and this patch makes program relying on this kind of longs suddenly consume 8 extra bytes per long.  Damn.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-06 13:51

Message:
Logged In: YES 
user_id=6656

Oh, and I meant to say, it passes make test but more testing is certainly 
welcome -- some mistakes show up in pretty obscure ways...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 12:57:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 12:57:59 2005
Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up
Message-ID: <E1DM22m-0001OX-Ge@sc8-sf-web3.sourceforge.net>

Patches item #1153056, was opened at 2005-02-27 21:14
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check() speed-up

Initial Comment:
Once upon a time, the macros PyInt_Check(),
PyString_Check(), etc., used to be very fast: just a
pointer comparison.  But 2.2 came.  Suddenly, types
could inherit from each other.  Thus the macros became:

(ob->type == &PyXxx_Check ||
   PyType_IsSubType(ob->type, &PyXxx_Check)

Subtyping of built-in types still being rare, the
common cases here are: (1) ob is indeed exactly of type
Xxx, (2) ob is absolutely not an instance of Xxx.  The
macro is fast for case 1 but becomes a call to a slow
function in case 2.

It sounds minor -- but a program can make half a
million "case 2" calls in 5 seconds.

The following patch proposes to fix that, based on a few
measurements that show which are the more common
"case 2" calls in a few applications.  It adds a
family of type flags meaning "this type is not at all an
Xxx", for Xxx in [module, tuple, float, int, unicode,
long, complex, str].

I cannot measure the performance gain on this machine
(figures vary all the time) but it looks like some 0.2s
for the above-mentioned 5s program.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-14 11:57

Message:
Logged In: YES 
user_id=6656

I suppose I should read the patch then :)

It seems very odd that _PyType_FastTypeCheck mutates a->tp_flags.

In fact, shoudn't it be possible to not have _PyType_FastTypeCheck at 
all?

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-14 10:22

Message:
Logged In: YES 
user_id=4771

I am convinced now by #1153075 that PyCheck_Xxx should not be semantically changed, and really means walking the mro.  So the patch here remains valid.

Yes, I know that N is unbounded, that's why the next sentence was "let's only include the most common of them".

Where to stop?  Don't guess, measure.  That's what I did, and in a few applications there were systematically a set of types that were PyChecked quite more often than the others.  So my patch special-cases exactly these types.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-14 09:05

Message:
Logged In: YES 
user_id=6656

(I haven't seen any mail about this patch!)

> array of N bits, where N is the number of C-level PyXxxObject
> structures

That's unbounded too, in the presence of extension modules.

(I still think my fix for #1153075 suffices, and is probably a good thing).

I can believe that special casing int and str subclasses is worth it -- but 
where to stop?

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

Comment By: Armin Rigo (arigo)
Date: 2005-02-28 09:26

Message:
Logged In: YES 
user_id=4771

Ah, but that's not so different: M can still be arbitrarily
large...

However, see also bug #1153075.  I think that PyInt_Check()
using PyType_IsSubtype() is essentially buggy: the purpose of
PyInt_Check() is to check if the PyObject* is a
PyIntObject*, not if its type pretends to have 'int' in its
mro.  If we fix this, then making PyType_IsSubtype()
faster will become unrelated to making PyXxx_Check()
faster.

If we want to fix PyXxx_Check() for the bug described above
and make it fast too, then we probably only need an
array of N bits, where N is the number of C-level PyXxxObject
structures.  The idea of only including the most common such
structures instead of all of them was based on simplicity and
performance (it's faster and easier to check for a known bit
than for a bit which itself is computed at run-time).

If we want to make PyType_IsSubtype() fast, it might be worth
the effort or not; we should measure it.  But I think it's
unrelated.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-02-28 06:20

Message:
Logged In: YES 
user_id=21627

No. Each type would have an array of M bits, where M is the
maximum number of a super class; each type would also store
the value of M. As types are created and deleted
dynamically, it might be necessary to keep track of assigned
type numbers, and recycle them as types are deleted.

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

Comment By: Armin Rigo (arigo)
Date: 2005-02-27 23:56

Message:
Logged In: YES 
user_id=4771

I'm not sure I understand your suggestion.  Would each type
have an array of N bits, where N is the total number of types
that exist?  That looks quite unreasonable in any program
that builds a lot of types (I know some that build them
programatically in loops).  What I did is a limited
version of that: a bitfield with room for only some commonly
checked-for superclasses.

(With some care, my patch could be modified to build the
bitfield in PyType_Ready(); this would allow the
PyXxx_Check() macros to become a single bit check operation.)

Changing the base classes isn't an issue in my limited patch
because you cannot ever add or remove the core built-in types
I check for from the bases of an existing type.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-02-27 23:44

Message:
Logged In: YES 
user_id=21627

I would rather see a constant-time subtype check implemented
in Python, using strategies that other interpreters have
been using for a long time.

Essentially, each type gets a unique number (e.g. in the
order of PyType_Ready calls), and a bit-field of all
supertypes, with a bit set for each type that is one of its
supertypes. Creation of the bitfield could be delayed until
a subtype check is actually needed.

The tricky part is to update the supertype bitmask when
__super__ is assigned.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 15:48:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 15:48:28 2005
Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up
Message-ID: <E1DM4hk-0003Be-Sq@sc8-sf-web4.sourceforge.net>

Patches item #1153056, was opened at 2005-02-27 21:14
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check() speed-up

Initial Comment:
Once upon a time, the macros PyInt_Check(),
PyString_Check(), etc., used to be very fast: just a
pointer comparison.  But 2.2 came.  Suddenly, types
could inherit from each other.  Thus the macros became:

(ob->type == &PyXxx_Check ||
   PyType_IsSubType(ob->type, &PyXxx_Check)

Subtyping of built-in types still being rare, the
common cases here are: (1) ob is indeed exactly of type
Xxx, (2) ob is absolutely not an instance of Xxx.  The
macro is fast for case 1 but becomes a call to a slow
function in case 2.

It sounds minor -- but a program can make half a
million "case 2" calls in 5 seconds.

The following patch proposes to fix that, based on a few
measurements that show which are the more common
"case 2" calls in a few applications.  It adds a
family of type flags meaning "this type is not at all an
Xxx", for Xxx in [module, tuple, float, int, unicode,
long, complex, str].

I cannot measure the performance gain on this machine
(figures vary all the time) but it looks like some 0.2s
for the above-mentioned 5s program.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-14 13:48

Message:
Logged In: YES 
user_id=4771

There might be problems with types that don't go through PyType_Ready().  We can't just compute the correct flags in there and do a single bit test in PyXxx_Check(), as far as I can see.  Hence the idea to add the flag to a type only when it is dynamically found not to be a subtype of the given base type.  I can't think of anything bad happening because of this mutation...

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-14 10:57

Message:
Logged In: YES 
user_id=6656

I suppose I should read the patch then :)

It seems very odd that _PyType_FastTypeCheck mutates a->tp_flags.

In fact, shoudn't it be possible to not have _PyType_FastTypeCheck at 
all?

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-14 09:22

Message:
Logged In: YES 
user_id=4771

I am convinced now by #1153075 that PyCheck_Xxx should not be semantically changed, and really means walking the mro.  So the patch here remains valid.

Yes, I know that N is unbounded, that's why the next sentence was "let's only include the most common of them".

Where to stop?  Don't guess, measure.  That's what I did, and in a few applications there were systematically a set of types that were PyChecked quite more often than the others.  So my patch special-cases exactly these types.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-14 08:05

Message:
Logged In: YES 
user_id=6656

(I haven't seen any mail about this patch!)

> array of N bits, where N is the number of C-level PyXxxObject
> structures

That's unbounded too, in the presence of extension modules.

(I still think my fix for #1153075 suffices, and is probably a good thing).

I can believe that special casing int and str subclasses is worth it -- but 
where to stop?

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

Comment By: Armin Rigo (arigo)
Date: 2005-02-28 09:26

Message:
Logged In: YES 
user_id=4771

Ah, but that's not so different: M can still be arbitrarily
large...

However, see also bug #1153075.  I think that PyInt_Check()
using PyType_IsSubtype() is essentially buggy: the purpose of
PyInt_Check() is to check if the PyObject* is a
PyIntObject*, not if its type pretends to have 'int' in its
mro.  If we fix this, then making PyType_IsSubtype()
faster will become unrelated to making PyXxx_Check()
faster.

If we want to fix PyXxx_Check() for the bug described above
and make it fast too, then we probably only need an
array of N bits, where N is the number of C-level PyXxxObject
structures.  The idea of only including the most common such
structures instead of all of them was based on simplicity and
performance (it's faster and easier to check for a known bit
than for a bit which itself is computed at run-time).

If we want to make PyType_IsSubtype() fast, it might be worth
the effort or not; we should measure it.  But I think it's
unrelated.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-02-28 06:20

Message:
Logged In: YES 
user_id=21627

No. Each type would have an array of M bits, where M is the
maximum number of a super class; each type would also store
the value of M. As types are created and deleted
dynamically, it might be necessary to keep track of assigned
type numbers, and recycle them as types are deleted.

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

Comment By: Armin Rigo (arigo)
Date: 2005-02-27 23:56

Message:
Logged In: YES 
user_id=4771

I'm not sure I understand your suggestion.  Would each type
have an array of N bits, where N is the total number of types
that exist?  That looks quite unreasonable in any program
that builds a lot of types (I know some that build them
programatically in loops).  What I did is a limited
version of that: a bitfield with room for only some commonly
checked-for superclasses.

(With some care, my patch could be modified to build the
bitfield in PyType_Ready(); this would allow the
PyXxx_Check() macros to become a single bit check operation.)

Changing the base classes isn't an issue in my limited patch
because you cannot ever add or remove the core built-in types
I check for from the bases of an existing type.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-02-27 23:44

Message:
Logged In: YES 
user_id=21627

I would rather see a constant-time subtype check implemented
in Python, using strategies that other interpreters have
been using for a long time.

Essentially, each type gets a unique number (e.g. in the
order of PyType_Ready calls), and a bit-field of all
supertypes, with a bit set for each type that is one of its
supertypes. Creation of the bitfield could be delayed until
a subtype check is actually needed.

The tricky part is to update the supertype bitmask when
__super__ is assigned.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470
From noreply at sourceforge.net  Thu Apr 14 22:24:20 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 14 22:24:22 2005
Subject: [Patches] [ python-Patches-1180062 ] fix typos in Library Reference
Message-ID: <E1DMAsu-0004F3-Ht@sc8-sf-web3.sourceforge.net>

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

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix typos in Library Reference

Initial Comment:
* Doc/lib/libfunctional.tex
 - "in an new object" should read "in a new object"

* Doc/lib/libsubprocess.tex
 - argument name is wrong
 - comma is missing

patch for release24-maint branch is also attached.


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

>Comment By: Walter D?rwald (doerwalter)
Date: 2005-04-14 22:24

Message:
Logged In: YES 
user_id=89016

Checked in as:
Doc/lib/libfunctional.tex 1.4
Doc/lib/libsubprocess.tex 1.6
Doc/lib/libsubprocess.tex 1.2.2.2

Thanks for the patch!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1180062&group_id=5470
From noreply at sourceforge.net  Fri Apr 15 04:13:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 15 04:13:49 2005
Subject: [Patches] [ python-Patches-1179513 ] [AST] Fix for core in
	test_grammar.py
Message-ID: <E1DMGL5-0007Ze-AF@sc8-sf-web1.sourceforge.net>

Patches item #1179513, was opened at 2005-04-08 22:43
Message generated for change (Settings changed) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1179513&group_id=5470

Category: Parser/Compiler
Group: AST
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Neil Schemenauer (nascheme)
Summary: [AST] Fix for core in test_grammar.py

Initial Comment:
Executing statements like:

compile("lambda x:x=1")

is causing a coredump on windows when it attempts to 
free an uninitialized ast_sequence.  Making sure that an 
appropriate null value is added to the sequence before 
cleaning up fixes this.

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-04-15 02:13

Message:
Logged In: YES 
user_id=35752

I think your fix only works when the length of the sequence
is one.  I checked in a different fix (i.e. initialize to
NULLs when allocating a new asdl_seq).  test_grammar now passes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1179513&group_id=5470
From noreply at sourceforge.net  Fri Apr 15 04:19:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 15 04:19:07 2005
Subject: [Patches] [ python-Patches-1176019 ] Implemented new 'class
	foo():pass' syntax
Message-ID: <E1DMGQC-0007Zo-Vm@sc8-sf-web4.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Neil Schemenauer (nascheme)
Summary: Implemented new 'class foo():pass' syntax

Initial Comment:
This patch implements the new 'class foo():pass' syntax 
for the ast branch.  It also includes minor modifications 
required to run build graminit.c on windows machines.

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-04-15 02:19

Message:
Logged In: YES 
user_id=35752

Looks good.  Check into the AST branch.  Thanks for the patch.

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

Comment By: logistix (logistix)
Date: 2005-04-04 21:49

Message:
Logged In: YES 
user_id=699438

Just to confirm, pgen did generate a new graminit.h file, but 
there were no changes to it because we didn't add any new 
symbols.  The patch I submitted is fine.

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

Comment By: logistix (logistix)
Date: 2005-04-04 20:53

Message:
Logged In: YES 
user_id=699438

graminit.c is generated by pgen.exe.  This process isn't fully 
automated on a windows build (like I'm guessing it is on 
linux).  There is a provided makefile that works with visual 
studio's nmake for windows users.  It just referenced an older 
version of the python lib file (2.3 instead of 2.5).

I presume this hasn't caused problems in the past becuase 
people modifying grammar/grammar have been running some 
form of *nix.

Now I'm starting to wonder if pgen generates any other files 
(i.e. header files) that I didn't include in the patch.  I'll verify 
when I get home.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-04 19:25

Message:
Logged In: YES 
user_id=357491

Do you know why graminit.c stopped working on Windows? 
Kurt's report on the merger didn't show any issues on
Windows and so I wonder if the problem goes back to the main
branch as well.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1176019&group_id=5470
From noreply at sourceforge.net  Fri Apr 15 07:11:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 15 07:12:03 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DMJ7W-0003kU-70@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-15 00:11

Message:
Logged In: YES 
user_id=80475

There are several builtins that could offer an iterator
alternative:
  range defers to xrange
  filter to itertools.ifilter
  map to itertools.imap (1)
  zip to itertools.izip

All of these offer huge space savings and a little speed
(with izip providing the best improvement because it avoids
tons of tuple allocations).

(1) an alternate imap needs to be provided since the
itertools version does not provide the None fill-in feature.


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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 14:56

Message:
Logged In: YES 
user_id=357491

No, I don't remember you ever mentioning that, but that is a
good idea since that would allow easy faking of things.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-13 05:24

Message:
Logged In: YES 
user_id=4771

Ok, here is a patch special-casing range() only.  It's a bit simpler, and faster too.

Did I already mention around here that the class/type unification of Python 2.2 might have been better done, in my opinion, simply by replacing the built-in type() with lambda x: x.__class__?

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-12 19:31

Message:
Logged In: YES 
user_id=357491

I vote for a patch to special-case range().  This won't be
an issue in Python 3000 when stuff like this become
generators.  Still wish there was a way to come up with a
range object that has ``type(range(1)) == list`` be true,
but check the refcount on the object so that if it is 1 it
can act as a generator instead.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-12 06:34

Message:
Logged In: YES 
user_id=4771

Doesn't work, because the dict can be modified during iteration.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 06:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Fri Apr 15 10:05:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 15 10:05:07 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DMLoz-0001Np-EJ@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-15 08:05

Message:
Logged In: YES 
user_id=4771

All these examples would imply a slight semantic change, I think:

   for x in filter(f, y):

if y is an iterator, the above line exhausts y before entering the loop.  The same for map and zip.

I want to avoid this at all costs, otherwise we'll see strange bug reports whose "solution" is: "well, just write instead

   seq=filter(f,y); for x in seq:

"... which would be very bad, in my opinion.

I'm already slightly concerned that

   r=range(10**7); for x in r: break

behaves quite differently than

   for x in range(10**7): break

with my patch.  I believe that in this case it is an acceptable tread-off, but I would certainly not check this patch in without explicit BDFL approval.

Guido, assigning to you for said principle approval or rejection...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-15 05:11

Message:
Logged In: YES 
user_id=80475

There are several builtins that could offer an iterator
alternative:
  range defers to xrange
  filter to itertools.ifilter
  map to itertools.imap (1)
  zip to itertools.izip

All of these offer huge space savings and a little speed
(with izip providing the best improvement because it avoids
tons of tuple allocations).

(1) an alternate imap needs to be provided since the
itertools version does not provide the None fill-in feature.


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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 19:56

Message:
Logged In: YES 
user_id=357491

No, I don't remember you ever mentioning that, but that is a
good idea since that would allow easy faking of things.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-13 10:24

Message:
Logged In: YES 
user_id=4771

Ok, here is a patch special-casing range() only.  It's a bit simpler, and faster too.

Did I already mention around here that the class/type unification of Python 2.2 might have been better done, in my opinion, simply by replacing the built-in type() with lambda x: x.__class__?

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 00:31

Message:
Logged In: YES 
user_id=357491

I vote for a patch to special-case range().  This won't be
an issue in Python 3000 when stuff like this become
generators.  Still wish there was a way to come up with a
range object that has ``type(range(1)) == list`` be true,
but check the refcount on the object so that if it is 1 it
can act as a generator instead.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-12 11:34

Message:
Logged In: YES 
user_id=4771

Doesn't work, because the dict can be modified during iteration.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 11:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Fri Apr 15 14:34:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 15 14:34:24 2005
Subject: [Patches] [ python-Patches-1183712 ] package_data chops off first
	char of default package
Message-ID: <E1DMQ1d-0004UY-VJ@sc8-sf-web2.sourceforge.net>

Patches item #1183712, was opened at 2005-04-15 14: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=1183712&group_id=5470

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.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470
From noreply at sourceforge.net  Fri Apr 15 23:53:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 15 23:53:45 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DMYkv-0007WH-OQ@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2005-04-15 17:53

Message:
Logged In: YES 
user_id=6380

I think we should leave all this alone until Python 3.0, and
there all these would always be iterators (or iterator
factories -- maybe the 3.0 range would behave like xrange
today).

For people wanting speed, there's already xrange().

For people who don't care, the subtle semantic differences
are more of a risk than a bonus.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-15 04:05

Message:
Logged In: YES 
user_id=4771

All these examples would imply a slight semantic change, I think:

   for x in filter(f, y):

if y is an iterator, the above line exhausts y before entering the loop.  The same for map and zip.

I want to avoid this at all costs, otherwise we'll see strange bug reports whose "solution" is: "well, just write instead

   seq=filter(f,y); for x in seq:

"... which would be very bad, in my opinion.

I'm already slightly concerned that

   r=range(10**7); for x in r: break

behaves quite differently than

   for x in range(10**7): break

with my patch.  I believe that in this case it is an acceptable tread-off, but I would certainly not check this patch in without explicit BDFL approval.

Guido, assigning to you for said principle approval or rejection...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-15 01:11

Message:
Logged In: YES 
user_id=80475

There are several builtins that could offer an iterator
alternative:
  range defers to xrange
  filter to itertools.ifilter
  map to itertools.imap (1)
  zip to itertools.izip

All of these offer huge space savings and a little speed
(with izip providing the best improvement because it avoids
tons of tuple allocations).

(1) an alternate imap needs to be provided since the
itertools version does not provide the None fill-in feature.


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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 15:56

Message:
Logged In: YES 
user_id=357491

No, I don't remember you ever mentioning that, but that is a
good idea since that would allow easy faking of things.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-13 06:24

Message:
Logged In: YES 
user_id=4771

Ok, here is a patch special-casing range() only.  It's a bit simpler, and faster too.

Did I already mention around here that the class/type unification of Python 2.2 might have been better done, in my opinion, simply by replacing the built-in type() with lambda x: x.__class__?

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-12 20:31

Message:
Logged In: YES 
user_id=357491

I vote for a patch to special-case range().  This won't be
an issue in Python 3000 when stuff like this become
generators.  Still wish there was a way to come up with a
range object that has ``type(range(1)) == list`` be true,
but check the refcount on the object so that if it is 1 it
can act as a generator instead.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-12 07:34

Message:
Logged In: YES 
user_id=4771

Doesn't work, because the dict can be modified during iteration.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 07:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Sat Apr 16 09:30:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 16 09:30:10 2005
Subject: [Patches] [ python-Patches-1181334 ] range() in for loops, again
Message-ID: <E1DMhki-0005oH-Lz@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: range() in for loops, again

Initial Comment:
Here is (yet) a(nother) patch to make range() lazy and fast in the context of for loops.

This implementation allows any built-in function or method to declare two C implementations if it wants to.  The second implementation, if present, is used when the caller can know for sure that it will only ever need an iterator over the result.  This is done with a new ml_flag_iter member of PyMethodDef.  To minimize compatibility issues a new METH_ITERABLE flag must be set when ml_flag_iter is valid.

The CALL_FUNCTION bytecode uses that if the immediately following bytecode is GET_ITER.

The patch updates range() to use this flag and build an xrange iterator object.

Of course the same technique could be applied to other built-in functions, but none spring to mind.  Maybe a simple patch that only special-cases range() would do just as well...

FWIW, I get a 5% speed-up on pystone with this patch.

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

>Comment By: Armin Rigo (arigo)
Date: 2005-04-16 07:30

Message:
Logged In: YES 
user_id=4771

Makes sense in this context.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-04-15 21:53

Message:
Logged In: YES 
user_id=6380

I think we should leave all this alone until Python 3.0, and
there all these would always be iterators (or iterator
factories -- maybe the 3.0 range would behave like xrange
today).

For people wanting speed, there's already xrange().

For people who don't care, the subtle semantic differences
are more of a risk than a bonus.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-15 08:05

Message:
Logged In: YES 
user_id=4771

All these examples would imply a slight semantic change, I think:

   for x in filter(f, y):

if y is an iterator, the above line exhausts y before entering the loop.  The same for map and zip.

I want to avoid this at all costs, otherwise we'll see strange bug reports whose "solution" is: "well, just write instead

   seq=filter(f,y); for x in seq:

"... which would be very bad, in my opinion.

I'm already slightly concerned that

   r=range(10**7); for x in r: break

behaves quite differently than

   for x in range(10**7): break

with my patch.  I believe that in this case it is an acceptable tread-off, but I would certainly not check this patch in without explicit BDFL approval.

Guido, assigning to you for said principle approval or rejection...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-15 05:11

Message:
Logged In: YES 
user_id=80475

There are several builtins that could offer an iterator
alternative:
  range defers to xrange
  filter to itertools.ifilter
  map to itertools.imap (1)
  zip to itertools.izip

All of these offer huge space savings and a little speed
(with izip providing the best improvement because it avoids
tons of tuple allocations).

(1) an alternate imap needs to be provided since the
itertools version does not provide the None fill-in feature.


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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 19:56

Message:
Logged In: YES 
user_id=357491

No, I don't remember you ever mentioning that, but that is a
good idea since that would allow easy faking of things.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-13 10:24

Message:
Logged In: YES 
user_id=4771

Ok, here is a patch special-casing range() only.  It's a bit simpler, and faster too.

Did I already mention around here that the class/type unification of Python 2.2 might have been better done, in my opinion, simply by replacing the built-in type() with lambda x: x.__class__?

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-13 00:31

Message:
Logged In: YES 
user_id=357491

I vote for a patch to special-case range().  This won't be
an issue in Python 3000 when stuff like this become
generators.  Still wish there was a way to come up with a
range object that has ``type(range(1)) == list`` be true,
but check the refcount on the object so that if it is 1 it
can act as a generator instead.

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

Comment By: Armin Rigo (arigo)
Date: 2005-04-12 11:34

Message:
Logged In: YES 
user_id=4771

Doesn't work, because the dict can be modified during iteration.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-04-12 11:03

Message:
Logged In: YES 
user_id=33168

dict.keys(), dict.values(), and dict.items() could also be
possibilities.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181334&group_id=5470
From noreply at sourceforge.net  Sat Apr 16 22:43:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 16 22:43:41 2005
Subject: [Patches] [ python-Patches-1010677 ] thread Module Breaks
	PyGILState_Ensure()
Message-ID: <E1DMu8Z-00043E-27@sc8-sf-web1.sourceforge.net>

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

Category: Modules
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Phil Thompson (philthompson10)
Assigned to: Mark Hammond (mhammond)
Summary: thread Module Breaks PyGILState_Ensure()

Initial Comment:
The thread module creates thread states that 
PyGILState_Ensure() doesn't know about. This means that the 
latter can try to acquire the GIL when it already has it - resulting 
in a deadlock. 

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

Comment By: John Belmonte (jbelmonte)
Date: 2005-04-17 05:43

Message:
Logged In: YES 
user_id=282299

This patch seems to have caused [ 1163563 ] Sub  
threads execute in restricted mode  
(http://sourceforge.net/tracker/?func=detail&aid=1163563&group_id=5470&atid=105470).    
  
I don't have an explanation-- I only know that when this 
patch is applied, the symptom appears.  
  

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

Comment By: Mark Hammond (mhammond)
Date: 2004-09-02 07:32

Message:
Logged In: YES 
user_id=14198

Checked into 2.3 maint branch:
Checking in Lib/test/test_capi.py;
new revision: 1.6.10.1; previous revision: 1.6
Checking in Modules/threadmodule.c;
new revision: 2.56.8.1; previous revision: 2.56


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

Comment By: Johan Dahlin (zilche)
Date: 2004-09-02 00:10

Message:
Logged In: YES 
user_id=132216

Can this be backported release23-maint as well? 
PyGTK suffers quite badly from this. 

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

Comment By: Mark Hammond (mhammond)
Date: 2004-08-25 07:24

Message:
Logged In: YES 
user_id=14198

Fixed - thanks!

Checking in Modules/threadmodule.c;
new revision: 2.59; previous revision: 2.58
Checking in Lib/test/test_capi.py;
new revision: 1.7; previous revision: 1.6


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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-24 22:14

Message:
Logged In: YES 
user_id=29957

Boosting to pri 7 for pre-2.4 inclusion.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1010677&group_id=5470
From noreply at sourceforge.net  Sun Apr 17 00:01:33 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 17 00:01:36 2005
Subject: [Patches] [ python-Patches-1184418 ] [ast] fix for 1183468:
	return/yield in class
Message-ID: <E1DMvM5-00024Z-IZ@sc8-sf-web3.sourceforge.net>

Patches item #1184418, was opened at 2005-04-16 17: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=1184418&group_id=5470

Category: None
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: [ast] fix for 1183468: return/yield in class

Initial Comment:
I've got a patch that may or may not be acceptable.  I've 
added a 'u_flags' field to the compiler_unit structure to 
track what sort of block we are in.

This doesn't seem much different that it is in the current 
compiler, there is a boolean  field called 'isfunction' that 
checks for this.

There is a 'block_type' tracked by the symbol table 
entries, but I can't figure out how to harvest it.

Fell free to accept or reject.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1184418&group_id=5470
From noreply at sourceforge.net  Sun Apr 17 00:04:38 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 17 00:04:42 2005
Subject: [Patches] [ python-Patches-1184418 ] [ast] fix for 1183468:
	return/yield in class
Message-ID: <E1DMvP4-00026x-Iv@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Neil Schemenauer (nascheme)
Summary: [ast] fix for 1183468: return/yield in class

Initial Comment:
I've got a patch that may or may not be acceptable.  I've 
added a 'u_flags' field to the compiler_unit structure to 
track what sort of block we are in.

This doesn't seem much different that it is in the current 
compiler, there is a boolean  field called 'isfunction' that 
checks for this.

There is a 'block_type' tracked by the symbol table 
entries, but I can't figure out how to harvest it.

Fell free to accept or reject.

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

>Comment By: logistix (logistix)
Date: 2005-04-16 17:04

Message:
Logged In: YES 
user_id=699438

Well, the patch attachment is failing due to a sf error with 
problems writing to an 'ArticleFile'.  I'll try again later.  Here it 
is in text for the curious:

Index: python/newcompile.c
=============================================
======================
RCS 
file: /cvsroot/python/python/dist/src/Python/Attic/newcompile.
c,v
retrieving revision 1.1.2.107
diff -u -r1.1.2.107 newcompile.c
--- python/newcompile.c	15 Apr 2005 01:49:23 -0000
	1.1.2.107
+++ python/newcompile.c	16 Apr 2005 21:47:22 -0000
@@ -104,6 +104,13 @@
 /* The following items change on entry and exit of code 
blocks.
    They must be saved and restored when returning to a 
block.
 */
+
+#define UNIT_SCOPE_MODULE	1
+#define UNIT_SCOPE_CLASS	2
+#define UNIT_SCOPE_FUNCTION	4
+#define UNIT_SCOPE_LAMBDA	8
+#define UNIT_SCOPE_GENEXP	16
+
 struct compiler_unit {
 	PySTEntryObject *u_ste;
 
@@ -132,6 +139,8 @@
 	int u_lineno;      /* the lineno for the current stmt */
 	bool u_lineno_set; /* boolean to indicate whether 
instr
 			      has been generated 
with current lineno */
+	
+	unsigned int u_flags; /* only tracks type now */
 };
 
 struct compiler {
@@ -159,7 +168,7 @@
 	int a_lineno_off;      /* bytecode offset of last lineno 
*/
 };
 
-static int compiler_enter_scope(struct compiler *, identifier, 
void *, int);
+static int compiler_enter_scope(struct compiler *, identifier, 
void *, int, unsigned int);
 static void compiler_free(struct compiler *);
 static basicblock *compiler_new_block(struct compiler *);
 static int compiler_next_instr(struct compiler *, basicblock *);
@@ -568,7 +577,7 @@
 
 static int
 compiler_enter_scope(struct compiler *c, identifier name, 
void *key,
-		     int lineno)
+		     int lineno, unsigned int flags)
 {
 	struct compiler_unit *u;
 
@@ -600,6 +609,8 @@
 
         u->u_private = NULL;
 
+	u->u_flags = flags;
+
 	/* A little debugging output */
 	compiler_display_symbols(name, u->u_ste-
>ste_symbols);
 
@@ -1252,7 +1263,7 @@
 		if (!module)
 			return NULL;
 	}
-	if (!compiler_enter_scope(c, module, mod, 1))
+	if (!compiler_enter_scope(c, module, mod, 1, 
UNIT_SCOPE_MODULE))
 		return NULL;
 	switch (mod->kind) {
 	case Module_kind: 
@@ -1396,7 +1407,7 @@
 	if (args->defaults)
 		VISIT_SEQ(c, expr, args->defaults);
 	if (!compiler_enter_scope(c, s-
>v.FunctionDef.name, (void *)s,
-				  s->lineno))
+				  s-
>lineno,UNIT_SCOPE_FUNCTION))
 		return 0;
 
         st = asdl_seq_GET(s->v.FunctionDef.body, 0);
@@ -1461,7 +1472,7 @@
 		VISIT_SEQ(c, expr, s-
>v.ClassDef.bases);
 	ADDOP_I(c, BUILD_TUPLE, n);
 	if (!compiler_enter_scope(c, s->v.ClassDef.name, 
(void *)s,
-				  s->lineno))
+				  s-
>lineno,UNIT_SCOPE_CLASS))
 		return 0;
         c->u->u_private = s->v.ClassDef.name;
         Py_INCREF(c->u->u_private);
@@ -1511,7 +1522,7 @@
 
 	if (args->defaults)
 		VISIT_SEQ(c, expr, args->defaults);
-	if (!compiler_enter_scope(c, name, (void *)e, c->u-
>u_lineno))
+	if (!compiler_enter_scope(c, name, (void *)e, c->u-
>u_lineno,UNIT_SCOPE_LAMBDA))
 		return 0;
 	c->u->u_argcount = asdl_seq_LEN(args->args);
 	VISIT(c, expr, e->v.Lambda.body);
@@ -1992,7 +2003,7 @@
         case ClassDef_kind:
 		return compiler_class(c, s);
         case Return_kind:
-                if (c->c_nestlevel <= 1)
+                if (!(c->u->u_flags & UNIT_SCOPE_FUNCTION))
                         return compiler_error(c, "'return' outside 
function");
 		if (s->v.Return.value) {
 			if (c->u->u_ste-
>ste_generator) {
@@ -2006,7 +2017,7 @@
 		ADDOP(c, RETURN_VALUE);
 		break;
         case Yield_kind:
-                if (c->c_nestlevel <= 1)
+                if (!(c->u->u_flags & UNIT_SCOPE_FUNCTION))
                         return compiler_error(c, "'yield' outside 
function");
 		for (i = 0; i < c->u->u_nfblocks; i++) {
 			if (c->u->u_fblock[i].fb_type 
== FINALLY_TRY)
@@ -2650,7 +2661,7 @@
 	if (!name)
     return 0;
 
-	if (!compiler_enter_scope(c, name, (void *)e, c->u-
>u_lineno))
+	if (!compiler_enter_scope(c, name, (void *)e, c->u-
>u_lineno,UNIT_SCOPE_GENEXP))
 		return 0;
 	compiler_genexp_generator(c, e-
>v.GeneratorExp.generators, 0,
 					e-
>v.GeneratorExp.elt);
Index: lib/test/test_grammar.py
=============================================
======================
RCS 
file: /cvsroot/python/python/dist/src/Lib/test/test_grammar.py,v
retrieving revision 1.40.8.3
diff -u -r1.40.8.3 test_grammar.py
--- lib/test/test_grammar.py	7 Jan 2005 06:59:09 -0000
	1.40.8.3
+++ lib/test/test_grammar.py	16 Apr 2005 21:51:39 -0000
@@ -413,6 +413,7 @@
 def g2(): return 1
 g1()
 x = g2()
+check_syntax("class foo:return 1")
 
 print 'raise_stmt' # 'raise' test [',' test]
 try: raise RuntimeError, 'just testing'
@@ -789,3 +790,7 @@
 x = 10; t = False; g = ((i,j) for i in range(x) if t for j in range(x))
 x = 5; t = True;
 verify([(i,j) for i in range(10) for j in range(5)] == list(g))
+
+print 'yield_stmt'
+check_syntax("class foo:yield 1")
+

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1184418&group_id=5470
From noreply at sourceforge.net  Mon Apr 18 23:07:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 18 23:07:50 2005
Subject: [Patches] [ python-Patches-1185444 ] urllib2 dloads failing through
	HTTP proxy w/ auth
Message-ID: <E1DNdTA-00020s-Db@sc8-sf-web1.sourceforge.net>

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

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@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.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185444&group_id=5470
From noreply at sourceforge.net  Mon Apr 18 23:10:24 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 18 23:10:27 2005
Subject: [Patches] [ python-Patches-1185447 ] binascii.b2a_qp does not
	handle binary data correctly
Message-ID: <E1DNdVg-00028z-St@sc8-sf-web1.sourceforge.net>

Patches item #1185447, was opened at 2005-04-18 14: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=1185447&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: binascii.b2a_qp does not handle binary data correctly

Initial Comment:
The binascii.b2a_qp function does not quote characters 
with ASCII values less than 32.

Attached is a patch to fix this problem.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185447&group_id=5470
From noreply at sourceforge.net  Tue Apr 19 02:18:33 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 19 02:18:35 2005
Subject: [Patches] [ python-Patches-1185529 ] Automatically build fpectl
	module from setup.py
Message-ID: <E1DNgRl-0008Ur-Mf@sc8-sf-web3.sourceforge.net>

Patches item #1185529, was opened at 2005-04-18 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=1185529&group_id=5470

Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Automatically build fpectl module from setup.py

Initial Comment:
Setup.py doesn't try to build the fpectl module.  This
patch changes that.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185529&group_id=5470
From noreply at sourceforge.net  Tue Apr 19 07:08:04 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 19 07:08:08 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DNkxw-0002hV-JO@sc8-sf-web2.sourceforge.net>

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

Category: Core (C code)
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Brett Cannon (bcannon)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-18 22:08

Message:
Logged In: YES 
user_id=357491

test_compile should have been merged; tests that the
compiler is doing its job at the bytecode level, not
Python/compile.c directly.

Need to remember to backport changes at some point.

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

Comment By: logistix (logistix)
Date: 2005-04-03 15:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-06 22:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470
From noreply at sourceforge.net  Tue Apr 19 16:42:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 19 16:42:33 2005
Subject: [Patches] [ python-Patches-1185529 ] Automatically build fpectl
	module from setup.py
Message-ID: <E1DNtvq-0005C8-P7@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Automatically build fpectl module from setup.py

Initial Comment:
Setup.py doesn't try to build the fpectl module.  This
patch changes that.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-19 15:42

Message:
Logged In: YES 
user_id=6656

I have to say, I thought that we were hoping people would forget about the 
fpectl module.  Is it actually useful?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185529&group_id=5470
From noreply at sourceforge.net  Tue Apr 19 17:04:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 19 17:04:56 2005
Subject: [Patches] [ python-Patches-1185529 ] Automatically build fpectl
	module from setup.py
Message-ID: <E1DNuHV-0004GZ-C9@sc8-sf-web1.sourceforge.net>

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

Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Automatically build fpectl module from setup.py

Initial Comment:
Setup.py doesn't try to build the fpectl module.  This
patch changes that.

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

>Comment By: Tim Peters (tim_one)
Date: 2005-04-19 11:04

Message:
Logged In: YES 
user_id=31435

NEWS for 2.3a1 said:

"""
- The fpectl module is not built by default; it's dangerous or
  useless except in the hands of experts.
"""

Nobody tries to keep it up to date either, and its primary 
author said he doesn't think it's used anymore in his 
institution (or something close to that).

I don't think anyone officially deprecated it, though (nobody 
touches it, not even for that <wink>).

It shouldn't be built by default, anyway.


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

Comment By: Michael Hudson (mwh)
Date: 2005-04-19 10:42

Message:
Logged In: YES 
user_id=6656

I have to say, I thought that we were hoping people would forget about the 
fpectl module.  Is it actually useful?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185529&group_id=5470
From noreply at sourceforge.net  Tue Apr 19 18:06:39 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 19 18:06:42 2005
Subject: [Patches] [ python-Patches-1181301 ] make float packing copy bytes
	when they can
Message-ID: <E1DNvFH-0001OT-N5@sc8-sf-web2.sourceforge.net>

Patches item #1181301, was opened at 2005-04-12 08:37
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: make float packing copy bytes when they can

Initial Comment:
As discussed on python-dev, this makes the 
_PyFloat_{Pack,Unpack}{4,8} functions copy bytes around when 
peering at 1.5 has the right result.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-19 17:06

Message:
Logged In: YES 
user_id=6656

Stop me if this is getting silly.

This adds class methods __getformat__ and __setformat__ to the float 
type and uses them in a new test file, test_float (they have docstrings that 
warn people not to use them).

I'd like to check this in soon.  Any objections?

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-14 08:51

Message:
Logged In: YES 
user_id=6656

This version attacks comments some more, uses more interesting probe 
values and, um, actually works on a little-endian platform (previous 
versions had a very stupid bug).

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-12 18:18

Message:
Logged In: YES 
user_id=6656

New patch, which attacks comments in floatobject.h and implements Tim's 
idea of refusing to unpack an IEEE special on a non-IEEE platform.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470
From noreply at sourceforge.net  Wed Apr 20 18:13:06 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 20 18:13:08 2005
Subject: [Patches] [ python-Patches-1186781 ] Typo in Curses-Function doc
Message-ID: <E1DOHp4-0003mh-Nc@sc8-sf-web4.sourceforge.net>

Patches item #1186781, was opened at 2005-04-20 16: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=1186781&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: grzankam (grzankam)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in Curses-Function doc

Initial Comment:
The description of the filter() method on
<http://docs.python.org/lib/curses-functions.html> says
"This may be used for enabling cgaracter-at-a-time line
editing without touching the rest of the screen."

cgaracter should likely be character

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1186781&group_id=5470
From noreply at sourceforge.net  Wed Apr 20 23:00:13 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 20 23:00:18 2005
Subject: [Patches] [ python-Patches-1159501 ] Improve %s support for unicode
Message-ID: <E1DOMIv-0001hd-Qr@sc8-sf-web1.sourceforge.net>

Patches item #1159501, was opened at 2005-03-09 01:43
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159501&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
>Assigned to: Fredrik Lundh (effbot)
Summary: Improve %s support for unicode

Initial Comment:
"'%s' % unicode_string" produces a unicode result.  I
think the following code should also return a unicode
string:

class Wrapper:
....def __str__(self):
........return unicode_string
'%s' % Wrapper()

That behavior would make it easier to write library
code that can work with either str objects or unicode
objects.

The fix is pretty simple (see that attached patch). 
Perhaps the PyObject_Text function should be called
_PyObject_Text instead.  Alternatively, if the function
is make public then we should document it and perhaps
also provide a builtin function called 'text' that uses it.




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

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-04-20 21:00

Message:
Logged In: YES 
user_id=35752

Assigning to effbot for review.  He had mentioned something
about __text__ at one point.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2005-03-10 21:13

Message:
Logged In: YES 
user_id=35752

attempt to attach patch again

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

Comment By: Neil Schemenauer (nascheme)
Date: 2005-03-10 21:12

Message:
Logged In: YES 
user_id=35752

Attaching a better patch.  Add a builtin function called
"text".  Change PyObject_Text to check the return types as
suggested by Mark.  Update the documentation and the tests.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-09 10:10

Message:
Logged In: YES 
user_id=38388

Nice patch. 

Only nit: PyObject_Text() should check that the result of
tp_str() is indeed either a string or unicode instance
(possibly from a subclass). Otherwise, the function wouldn't
be able to guarantee this feature - which is what it's all
about.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159501&group_id=5470
From noreply at sourceforge.net  Wed Apr 20 23:27:09 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 20 23:27:13 2005
Subject: [Patches] [ python-Patches-1159501 ] Improve %s support for unicode
Message-ID: <E1DOMiz-000710-Lt@sc8-sf-web3.sourceforge.net>

Patches item #1159501, was opened at 2005-03-09 02:43
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159501&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Fredrik Lundh (effbot)
Summary: Improve %s support for unicode

Initial Comment:
"'%s' % unicode_string" produces a unicode result.  I
think the following code should also return a unicode
string:

class Wrapper:
....def __str__(self):
........return unicode_string
'%s' % Wrapper()

That behavior would make it easier to write library
code that can work with either str objects or unicode
objects.

The fix is pretty simple (see that attached patch). 
Perhaps the PyObject_Text function should be called
_PyObject_Text instead.  Alternatively, if the function
is make public then we should document it and perhaps
also provide a builtin function called 'text' that uses it.




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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-04-20 23:27

Message:
Logged In: YES 
user_id=38388

Looks OK to me; not sure what you mean with __text__ -
__str__ already has taken that role long ago.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2005-04-20 23:00

Message:
Logged In: YES 
user_id=35752

Assigning to effbot for review.  He had mentioned something
about __text__ at one point.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2005-03-10 22:13

Message:
Logged In: YES 
user_id=35752

attempt to attach patch again

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

Comment By: Neil Schemenauer (nascheme)
Date: 2005-03-10 22:12

Message:
Logged In: YES 
user_id=35752

Attaching a better patch.  Add a builtin function called
"text".  Change PyObject_Text to check the return types as
suggested by Mark.  Update the documentation and the tests.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-09 11:10

Message:
Logged In: YES 
user_id=38388

Nice patch. 

Only nit: PyObject_Text() should check that the result of
tp_str() is indeed either a string or unicode instance
(possibly from a subclass). Otherwise, the function wouldn't
be able to guarantee this feature - which is what it's all
about.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159501&group_id=5470
From noreply at sourceforge.net  Wed Apr 20 23:46:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 20 23:46:25 2005
Subject: [Patches] [ python-Patches-1159501 ] Improve %s support for unicode
Message-ID: <E1DON1Z-0003uB-5g@sc8-sf-web2.sourceforge.net>

Patches item #1159501, was opened at 2005-03-09 01:43
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159501&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Fredrik Lundh (effbot)
Summary: Improve %s support for unicode

Initial Comment:
"'%s' % unicode_string" produces a unicode result.  I
think the following code should also return a unicode
string:

class Wrapper:
....def __str__(self):
........return unicode_string
'%s' % Wrapper()

That behavior would make it easier to write library
code that can work with either str objects or unicode
objects.

The fix is pretty simple (see that attached patch). 
Perhaps the PyObject_Text function should be called
_PyObject_Text instead.  Alternatively, if the function
is make public then we should document it and perhaps
also provide a builtin function called 'text' that uses it.




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

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-04-20 21:46

Message:
Logged In: YES 
user_id=35752

Here's a quote from him:
> I'm beginning to think that we need an extra method
(__text__), that
> can return any kind of string that's compatible with
Python's text model.
>
> (in today's CPython, that's an 8-bit string with ASCII
only, or a Uni-
> code string.  future Python's may support more string
types, at least at
> the C implementation level).
>
> I'm not sure we can change __str__ or __unicode__ without
breaking
> code in really obscure ways (but I'd be happy to be proven
wrong).

My idea is that we can change __str__ without breaking code.
 The reason is that no one should be calling tp_str
directly.  Instead they use PyObject_Str.

I don't know what he meant by "string that's compatible with
Python's text model".  With my change, Python can only deal
with str or unicode instances.  I have no idea how we could
support other string implementations.

I don't want to introduce a text() builtin that calls
__str__ and then later realize that __text__ would be a
useful.  Perhaps this change is big enough to require a PEP.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-04-20 21:27

Message:
Logged In: YES 
user_id=38388

Looks OK to me; not sure what you mean with __text__ -
__str__ already has taken that role long ago.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2005-04-20 21:00

Message:
Logged In: YES 
user_id=35752

Assigning to effbot for review.  He had mentioned something
about __text__ at one point.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2005-03-10 21:13

Message:
Logged In: YES 
user_id=35752

attempt to attach patch again

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

Comment By: Neil Schemenauer (nascheme)
Date: 2005-03-10 21:12

Message:
Logged In: YES 
user_id=35752

Attaching a better patch.  Add a builtin function called
"text".  Change PyObject_Text to check the return types as
suggested by Mark.  Update the documentation and the tests.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-09 10:10

Message:
Logged In: YES 
user_id=38388

Nice patch. 

Only nit: PyObject_Text() should check that the result of
tp_str() is indeed either a string or unicode instance
(possibly from a subclass). Otherwise, the function wouldn't
be able to guarantee this feature - which is what it's all
about.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159501&group_id=5470
From noreply at sourceforge.net  Thu Apr 21 13:40:18 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 21 13:40:21 2005
Subject: [Patches] [ python-Patches-1187312 ] subprocess: optional
	auto-reaping fixing os.wait() lossage
Message-ID: <E1DOa2c-0002Yl-1J@sc8-sf-web3.sourceforge.net>

Patches item #1187312, was opened at 2005-04-21 13: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=1187312&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
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.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1187312&group_id=5470
From noreply at sourceforge.net  Thu Apr 21 13:48:27 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 21 13:48:30 2005
Subject: [Patches] [ python-Patches-1187312 ] subprocess: optional
	auto-reaping fixing os.wait() lossage
Message-ID: <E1DOaAV-0006sl-IX@sc8-sf-web2.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
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: 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  Thu Apr 21 16:15:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 21 16:15:50 2005
Subject: [Patches] [ python-Patches-1187396 ] Add const specifier to
	PySpam_System prototype
Message-ID: <E1DOcT5-0006gq-I5@sc8-sf-web1.sourceforge.net>

Patches item #1187396, was opened at 2005-04-21 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=1187396&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Luis Bruno (lbruno)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add const specifier to PySpam_System prototype

Initial Comment:
Section 1.12 of Extending & Embedding needs a const
specifier for correct compilation (tested on Fedora
Core 3, py2.3).

Closes #1184380, submitted by bamoore@users.sf.net

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1187396&group_id=5470
From noreply at sourceforge.net  Thu Apr 21 16:16:37 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 21 16:16:38 2005
Subject: [Patches] [ python-Patches-1187396 ] Add const specifier to
	PySpam_System prototype
Message-ID: <E1DOcTt-0001gL-0R@sc8-sf-web3.sourceforge.net>

Patches item #1187396, was opened at 2005-04-21 14:15
Message generated for change (Settings changed) made by lbruno
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1187396&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 1
Submitted By: Luis Bruno (lbruno)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add const specifier to PySpam_System prototype

Initial Comment:
Section 1.12 of Extending & Embedding needs a const
specifier for correct compilation (tested on Fedora
Core 3, py2.3).

Closes #1184380, submitted by bamoore@users.sf.net

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1187396&group_id=5470
From noreply at sourceforge.net  Fri Apr 22 18:20:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 22 18:20:45 2005
Subject: [Patches] [ python-Patches-1187312 ] subprocess: optional
	auto-reaping fixing os.wait() lossage
Message-ID: <E1DP0tV-0004I8-A4@sc8-sf-web1.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
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: 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  Sat Apr 23 21:12:12 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 23 21:12:15 2005
Subject: [Patches] [ python-Patches-1184418 ] [ast] fix for 1183468:
	return/yield in class
Message-ID: <E1DPQ32-00068J-Fu@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Neil Schemenauer (nascheme)
Summary: [ast] fix for 1183468: return/yield in class

Initial Comment:
I've got a patch that may or may not be acceptable.  I've 
added a 'u_flags' field to the compiler_unit structure to 
track what sort of block we are in.

This doesn't seem much different that it is in the current 
compiler, there is a boolean  field called 'isfunction' that 
checks for this.

There is a 'block_type' tracked by the symbol table 
entries, but I can't figure out how to harvest it.

Fell free to accept or reject.

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

>Comment By: logistix (logistix)
Date: 2005-04-23 14:12

Message:
Logged In: YES 
user_id=699438

Sourceforge finally let me upload a real patch file.

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

Comment By: logistix (logistix)
Date: 2005-04-16 17:04

Message:
Logged In: YES 
user_id=699438

Well, the patch attachment is failing due to a sf error with 
problems writing to an 'ArticleFile'.  I'll try again later.  Here it 
is in text for the curious:

Index: python/newcompile.c
=============================================
======================
RCS 
file: /cvsroot/python/python/dist/src/Python/Attic/newcompile.
c,v
retrieving revision 1.1.2.107
diff -u -r1.1.2.107 newcompile.c
--- python/newcompile.c	15 Apr 2005 01:49:23 -0000
	1.1.2.107
+++ python/newcompile.c	16 Apr 2005 21:47:22 -0000
@@ -104,6 +104,13 @@
 /* The following items change on entry and exit of code 
blocks.
    They must be saved and restored when returning to a 
block.
 */
+
+#define UNIT_SCOPE_MODULE	1
+#define UNIT_SCOPE_CLASS	2
+#define UNIT_SCOPE_FUNCTION	4
+#define UNIT_SCOPE_LAMBDA	8
+#define UNIT_SCOPE_GENEXP	16
+
 struct compiler_unit {
 	PySTEntryObject *u_ste;
 
@@ -132,6 +139,8 @@
 	int u_lineno;      /* the lineno for the current stmt */
 	bool u_lineno_set; /* boolean to indicate whether 
instr
 			      has been generated 
with current lineno */
+	
+	unsigned int u_flags; /* only tracks type now */
 };
 
 struct compiler {
@@ -159,7 +168,7 @@
 	int a_lineno_off;      /* bytecode offset of last lineno 
*/
 };
 
-static int compiler_enter_scope(struct compiler *, identifier, 
void *, int);
+static int compiler_enter_scope(struct compiler *, identifier, 
void *, int, unsigned int);
 static void compiler_free(struct compiler *);
 static basicblock *compiler_new_block(struct compiler *);
 static int compiler_next_instr(struct compiler *, basicblock *);
@@ -568,7 +577,7 @@
 
 static int
 compiler_enter_scope(struct compiler *c, identifier name, 
void *key,
-		     int lineno)
+		     int lineno, unsigned int flags)
 {
 	struct compiler_unit *u;
 
@@ -600,6 +609,8 @@
 
         u->u_private = NULL;
 
+	u->u_flags = flags;
+
 	/* A little debugging output */
 	compiler_display_symbols(name, u->u_ste-
>ste_symbols);
 
@@ -1252,7 +1263,7 @@
 		if (!module)
 			return NULL;
 	}
-	if (!compiler_enter_scope(c, module, mod, 1))
+	if (!compiler_enter_scope(c, module, mod, 1, 
UNIT_SCOPE_MODULE))
 		return NULL;
 	switch (mod->kind) {
 	case Module_kind: 
@@ -1396,7 +1407,7 @@
 	if (args->defaults)
 		VISIT_SEQ(c, expr, args->defaults);
 	if (!compiler_enter_scope(c, s-
>v.FunctionDef.name, (void *)s,
-				  s->lineno))
+				  s-
>lineno,UNIT_SCOPE_FUNCTION))
 		return 0;
 
         st = asdl_seq_GET(s->v.FunctionDef.body, 0);
@@ -1461,7 +1472,7 @@
 		VISIT_SEQ(c, expr, s-
>v.ClassDef.bases);
 	ADDOP_I(c, BUILD_TUPLE, n);
 	if (!compiler_enter_scope(c, s->v.ClassDef.name, 
(void *)s,
-				  s->lineno))
+				  s-
>lineno,UNIT_SCOPE_CLASS))
 		return 0;
         c->u->u_private = s->v.ClassDef.name;
         Py_INCREF(c->u->u_private);
@@ -1511,7 +1522,7 @@
 
 	if (args->defaults)
 		VISIT_SEQ(c, expr, args->defaults);
-	if (!compiler_enter_scope(c, name, (void *)e, c->u-
>u_lineno))
+	if (!compiler_enter_scope(c, name, (void *)e, c->u-
>u_lineno,UNIT_SCOPE_LAMBDA))
 		return 0;
 	c->u->u_argcount = asdl_seq_LEN(args->args);
 	VISIT(c, expr, e->v.Lambda.body);
@@ -1992,7 +2003,7 @@
         case ClassDef_kind:
 		return compiler_class(c, s);
         case Return_kind:
-                if (c->c_nestlevel <= 1)
+                if (!(c->u->u_flags & UNIT_SCOPE_FUNCTION))
                         return compiler_error(c, "'return' outside 
function");
 		if (s->v.Return.value) {
 			if (c->u->u_ste-
>ste_generator) {
@@ -2006,7 +2017,7 @@
 		ADDOP(c, RETURN_VALUE);
 		break;
         case Yield_kind:
-                if (c->c_nestlevel <= 1)
+                if (!(c->u->u_flags & UNIT_SCOPE_FUNCTION))
                         return compiler_error(c, "'yield' outside 
function");
 		for (i = 0; i < c->u->u_nfblocks; i++) {
 			if (c->u->u_fblock[i].fb_type 
== FINALLY_TRY)
@@ -2650,7 +2661,7 @@
 	if (!name)
     return 0;
 
-	if (!compiler_enter_scope(c, name, (void *)e, c->u-
>u_lineno))
+	if (!compiler_enter_scope(c, name, (void *)e, c->u-
>u_lineno,UNIT_SCOPE_GENEXP))
 		return 0;
 	compiler_genexp_generator(c, e-
>v.GeneratorExp.generators, 0,
 					e-
>v.GeneratorExp.elt);
Index: lib/test/test_grammar.py
=============================================
======================
RCS 
file: /cvsroot/python/python/dist/src/Lib/test/test_grammar.py,v
retrieving revision 1.40.8.3
diff -u -r1.40.8.3 test_grammar.py
--- lib/test/test_grammar.py	7 Jan 2005 06:59:09 -0000
	1.40.8.3
+++ lib/test/test_grammar.py	16 Apr 2005 21:51:39 -0000
@@ -413,6 +413,7 @@
 def g2(): return 1
 g1()
 x = g2()
+check_syntax("class foo:return 1")
 
 print 'raise_stmt' # 'raise' test [',' test]
 try: raise RuntimeError, 'just testing'
@@ -789,3 +790,7 @@
 x = 10; t = False; g = ((i,j) for i in range(x) if t for j in range(x))
 x = 5; t = True;
 verify([(i,j) for i in range(10) for j in range(5)] == list(g))
+
+print 'yield_stmt'
+check_syntax("class foo:yield 1")
+

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1184418&group_id=5470
From noreply at sourceforge.net  Sat Apr 23 22:38:58 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 23 22:39:01 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DPRP0-0005NL-Dg@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Brett Cannon (bcannon)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

Comment By: logistix (logistix)
Date: 2005-04-23 15:38

Message:
Logged In: YES 
user_id=699438

I took a look at test_compile to see how bad the conflicts
were and it doesn't look good.  On the ast-branch, it was
rewritten to use doctests.  On the main branch, it was
rewritten to use unittest.  So everything is out of whack
due to two completely differnent rewrites.

Other than that, I don't see any critical changes to either
branch.  I recommend that you just copy the test from the
main branch as-is (from the last mergepoint, not HEAD)
instead of trying to do a proper backport and merge.

I can generate a patch if you need it.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-19 00:08

Message:
Logged In: YES 
user_id=357491

test_compile should have been merged; tests that the
compiler is doing its job at the bytecode level, not
Python/compile.c directly.

Need to remember to backport changes at some point.

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

Comment By: logistix (logistix)
Date: 2005-04-03 17:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-07 00:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470
From noreply at sourceforge.net  Sun Apr 24 20:23:29 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Apr 24 20:23:32 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DPllR-0001hC-PR@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Brett Cannon (bcannon)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 11:23

Message:
Logged In: YES 
user_id=357491

That was my plan.

And no need for the patch, logistix.  Easier for me to just
copy from release24-maint into ast-branch and check it in. 
Thanks for the offer, though.

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

Comment By: logistix (logistix)
Date: 2005-04-23 13:38

Message:
Logged In: YES 
user_id=699438

I took a look at test_compile to see how bad the conflicts
were and it doesn't look good.  On the ast-branch, it was
rewritten to use doctests.  On the main branch, it was
rewritten to use unittest.  So everything is out of whack
due to two completely differnent rewrites.

Other than that, I don't see any critical changes to either
branch.  I recommend that you just copy the test from the
main branch as-is (from the last mergepoint, not HEAD)
instead of trying to do a proper backport and merge.

I can generate a patch if you need it.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-18 22:08

Message:
Logged In: YES 
user_id=357491

test_compile should have been merged; tests that the
compiler is doing its job at the bytecode level, not
Python/compile.c directly.

Need to remember to backport changes at some point.

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

Comment By: logistix (logistix)
Date: 2005-04-03 15:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-06 22:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470
From noreply at sourceforge.net  Mon Apr 25 00:06:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 25 00:06:44 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DPpFR-0001LG-Df@sc8-sf-web1.sourceforge.net>

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

Category: Core (C code)
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Brett Cannon (bcannon)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 15:06

Message:
Logged In: YES 
user_id=357491

rev. 1.10.10.4 has the checked-in copy.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 11:23

Message:
Logged In: YES 
user_id=357491

That was my plan.

And no need for the patch, logistix.  Easier for me to just
copy from release24-maint into ast-branch and check it in. 
Thanks for the offer, though.

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

Comment By: logistix (logistix)
Date: 2005-04-23 13:38

Message:
Logged In: YES 
user_id=699438

I took a look at test_compile to see how bad the conflicts
were and it doesn't look good.  On the ast-branch, it was
rewritten to use doctests.  On the main branch, it was
rewritten to use unittest.  So everything is out of whack
due to two completely differnent rewrites.

Other than that, I don't see any critical changes to either
branch.  I recommend that you just copy the test from the
main branch as-is (from the last mergepoint, not HEAD)
instead of trying to do a proper backport and merge.

I can generate a patch if you need it.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-18 22:08

Message:
Logged In: YES 
user_id=357491

test_compile should have been merged; tests that the
compiler is doing its job at the bytecode level, not
Python/compile.c directly.

Need to remember to backport changes at some point.

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

Comment By: logistix (logistix)
Date: 2005-04-03 15:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-06 22:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470
From noreply at sourceforge.net  Mon Apr 25 03:26:25 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 25 03:26:28 2005
Subject: [Patches] [ python-Patches-1189210 ] Don't assume all exceptions
	are SyntaxError's
Message-ID: <E1DPsMj-00011v-Hk@sc8-sf-web3.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't assume all exceptions are SyntaxError's

Initial Comment:
Attached patch simple propagates non-syntax errors up
and allows ast_for_atom to return NULL.  Needed for
some of the unicode tests.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1189210&group_id=5470
From noreply at sourceforge.net  Mon Apr 25 04:05:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr 25 04:05:35 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DPsya-0001wj-0T@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: AST
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-04-24 21:05

Message:
Logged In: YES 
user_id=149084

The change to test_compile.py looks ok, probably
the best solution since there have been many
changes on MAIN.

There have been 11 updates to Python.c since the
merge from 5 Jan tag. The AST crew probably
should look at them so we don't get too far behind.

We will need to do another merge from MAIN at
some point.  Let me know.

Closing this Tracker item.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 17:06

Message:
Logged In: YES 
user_id=357491

rev. 1.10.10.4 has the checked-in copy.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 13:23

Message:
Logged In: YES 
user_id=357491

That was my plan.

And no need for the patch, logistix.  Easier for me to just
copy from release24-maint into ast-branch and check it in. 
Thanks for the offer, though.

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

Comment By: logistix (logistix)
Date: 2005-04-23 15:38

Message:
Logged In: YES 
user_id=699438

I took a look at test_compile to see how bad the conflicts
were and it doesn't look good.  On the ast-branch, it was
rewritten to use doctests.  On the main branch, it was
rewritten to use unittest.  So everything is out of whack
due to two completely differnent rewrites.

Other than that, I don't see any critical changes to either
branch.  I recommend that you just copy the test from the
main branch as-is (from the last mergepoint, not HEAD)
instead of trying to do a proper backport and merge.

I can generate a patch if you need it.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-19 00:08

Message:
Logged In: YES 
user_id=357491

test_compile should have been merged; tests that the
compiler is doing its job at the bytecode level, not
Python/compile.c directly.

Need to remember to backport changes at some point.

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

Comment By: logistix (logistix)
Date: 2005-04-03 17:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-07 01:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470
From noreply at sourceforge.net  Tue Apr 26 03:51:01 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 26 03:51:03 2005
Subject: [Patches] [ python-Patches-1189210 ] Don't assume all exceptions
	are SyntaxError's
Message-ID: <E1DQFE5-00085p-8l@sc8-sf-web2.sourceforge.net>

Patches item #1189210, was opened at 2005-04-24 18:26
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1189210&group_id=5470

Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
>Assigned to: Brett Cannon (bcannon)
Summary: Don't assume all exceptions are SyntaxError's

Initial Comment:
Attached patch simple propagates non-syntax errors up
and allows ast_for_atom to return NULL.  Needed for
some of the unicode tests.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1189210&group_id=5470
From noreply at sourceforge.net  Tue Apr 26 05:46:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 26 05:46:44 2005
Subject: [Patches] [ python-Patches-1109424 ] type conversion methods and
	subclasses
Message-ID: <E1DQH22-0003KK-Cu@sc8-sf-web3.sourceforge.net>

Patches item #1109424, was opened at 2005-01-25 14:04
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109424&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Brett Cannon (bcannon)
Summary: type conversion methods and subclasses

Initial Comment:
This patch fixes the classes int, long, float and
unicode so that type conversion methods (i.e. __int__,
__long__, __float__, __unicode__) are used for type
conversion in subclasses of int/long/float/unicode.
(See the following thread on python-dev for more info:
http://mail.python.org/pipermail/python-dev/2005-January/051175.html)

It also fixes the bug reported by Nick Coghlan here:
http://mail.python.org/pipermail/python-dev/2005-January/051196.html.

For int/long/float converting the instance of the
subclasses to the base class has been moved from
PyNumber_(Int|Long|Float) to the apropriate slot
nb_int, nb_long, nb_float of int/long/float.


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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-25 20:46

Message:
Logged In: YES 
user_id=357491

OK, checked in.  Thanks, Walter.

Checking in Objects/abstract.c;
/cvsroot/python/python/dist/src/Objects/abstract.c,v  <-- 
abstract.c
new revision: 2.136; previous revision: 2.135
done
Checking in Objects/floatobject.c;
/cvsroot/python/python/dist/src/Objects/floatobject.c,v  <--
 floatobject.c
new revision: 2.135; previous revision: 2.134
done
Checking in Objects/intobject.c;
/cvsroot/python/python/dist/src/Objects/intobject.c,v  <-- 
intobject.c
new revision: 2.114; previous revision: 2.113
done
Checking in Objects/longobject.c;
/cvsroot/python/python/dist/src/Objects/longobject.c,v  <--
 longobject.c
new revision: 1.167; previous revision: 1.166
done
Checking in Objects/object.c;
/cvsroot/python/python/dist/src/Objects/object.c,v  <-- 
object.c
new revision: 2.226; previous revision: 2.225
done
Checking in Lib/test/test_builtin.py;
/cvsroot/python/python/dist/src/Lib/test/test_builtin.py,v 
<--  test_builtin.py
new revision: 1.41; previous revision: 1.40
done
Checking in Lib/test/test_complex.py;
/cvsroot/python/python/dist/src/Lib/test/test_complex.py,v 
<--  test_complex.py
new revision: 1.16; previous revision: 1.15
done
Checking in Lib/test/test_str.py;
/cvsroot/python/python/dist/src/Lib/test/test_str.py,v  <--
 test_str.py
new revision: 1.5; previous revision: 1.4
done
Checking in Lib/test/test_unicode.py;
/cvsroot/python/python/dist/src/Lib/test/test_unicode.py,v 
<--  test_unicode.py
new revision: 1.94; previous revision: 1.93
done
Checking in Misc/NEWS;
/cvsroot/python/python/dist/src/Misc/NEWS,v  <--  NEWS
new revision: 1.1290; previous revision: 1.1289

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

Comment By: Brett Cannon (bcannon)
Date: 2005-02-24 18:57

Message:
Logged In: YES 
user_id=357491

OK, BDFL pronounced on this saying the semantic change was fine.  I will 
have a look at the patch when I can and get it in.  Won't touch 2.4 since it 
is a semantic change, though.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1109424&group_id=5470
From noreply at sourceforge.net  Tue Apr 26 05:53:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 26 05:53:54 2005
Subject: [Patches] [ python-Patches-1189210 ] Don't assume all exceptions
	are SyntaxError's
Message-ID: <E1DQH8x-0007jZ-LY@sc8-sf-web4.sourceforge.net>

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

Category: Parser/Compiler
Group: AST
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Brett Cannon (bcannon)
Summary: Don't assume all exceptions are SyntaxError's

Initial Comment:
Attached patch simple propagates non-syntax errors up
and allows ast_for_atom to return NULL.  Needed for
some of the unicode tests.

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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-25 20:53

Message:
Logged In: YES 
user_id=357491

Applied as rev. 1.1.2.61 .  Fixes bug #1186345.

Thanks, John.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1189210&group_id=5470
From noreply at sourceforge.net  Tue Apr 26 08:22:55 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 26 08:22:59 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DQJTD-00082z-Lx@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: AST
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

>Comment By: Brett Cannon (bcannon)
Date: 2005-04-25 23:22

Message:
Logged In: YES 
user_id=357491

Kurt, what happened to the logging package?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-04-24 19:05

Message:
Logged In: YES 
user_id=149084

The change to test_compile.py looks ok, probably
the best solution since there have been many
changes on MAIN.

There have been 11 updates to Python.c since the
merge from 5 Jan tag. The AST crew probably
should look at them so we don't get too far behind.

We will need to do another merge from MAIN at
some point.  Let me know.

Closing this Tracker item.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 15:06

Message:
Logged In: YES 
user_id=357491

rev. 1.10.10.4 has the checked-in copy.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 11:23

Message:
Logged In: YES 
user_id=357491

That was my plan.

And no need for the patch, logistix.  Easier for me to just
copy from release24-maint into ast-branch and check it in. 
Thanks for the offer, though.

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

Comment By: logistix (logistix)
Date: 2005-04-23 13:38

Message:
Logged In: YES 
user_id=699438

I took a look at test_compile to see how bad the conflicts
were and it doesn't look good.  On the ast-branch, it was
rewritten to use doctests.  On the main branch, it was
rewritten to use unittest.  So everything is out of whack
due to two completely differnent rewrites.

Other than that, I don't see any critical changes to either
branch.  I recommend that you just copy the test from the
main branch as-is (from the last mergepoint, not HEAD)
instead of trying to do a proper backport and merge.

I can generate a patch if you need it.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-18 22:08

Message:
Logged In: YES 
user_id=357491

test_compile should have been merged; tests that the
compiler is doing its job at the bytecode level, not
Python/compile.c directly.

Need to remember to backport changes at some point.

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

Comment By: logistix (logistix)
Date: 2005-04-03 15:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-06 22:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470
From noreply at sourceforge.net  Tue Apr 26 09:10:41 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 26 09:10:45 2005
Subject: [Patches] [ python-Patches-1182394 ] HMAC hexdigest and general
	review
Message-ID: <E1DQKDR-0005po-OY@sc8-sf-web4.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: HMAC hexdigest and general review

Initial Comment:
This patch is primarily aimed at speeding up the
HMAC.hexdigest method.  The current implementation is::

        return "".join([hex(ord(x))[2:].zfill(2)
                        for x in tuple(self.digest())])

Which is correct, but a little too clever.  Especially
when other tools are available.  The attached patch
adds HMAC._current that returns the hash object
combined from self.inner and self.outter to be used by
HMAC.digest and HMAC.hexdigest.  This results in an 11
fold speed improvement for md5 and sha digestmod's
while also making the code a little easier.


Other review points for the HMAC module include
removing "_secret_backdoor_key" in favor of using
"None" as the sentinel.  In this case, it makes sense
to use None because it is an invalid key, avoids a
global lookup in py2.4 and beyond, and is just as
readable.  

I also moved blocksize to a class level constant.  This
allows implementations to create different blocksize
hashes by inheriting and changing this value.  This
also involved a change to copy() to use
self.__class__(None) instead of directly calling
HMAC(None).

The final comment is that it would be nice to have a
C-level implementation of _strxor in binascii for this
module and possibly other uses.  However, I don't
really know a significantly faster way of implementing
this method in python.

Thanks,
-Shane Holloway

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-26 00:10

Message:
Logged In: YES 
user_id=341410

I think the patch looks good.  Though perhaps leaving a...
_secret_backdoor_key = None
... for backwards compatibility is a good idea.

The fastest method I've found (in pure Python) for xoring
strings is to use an array.array, with the largest typecode
that is a divisor of your sequence (cooking your strings to
always have a length of 4 and to use signed 4 byte longs
seems to work well on PII/PIII based systems).

Alternatively, writing it in C and compiling it with the new
GCC 4 will offer automatic vectorization, and save
allocating Python integers.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-14 00:54

Message:
Logged In: YES 
user_id=6656

Attempting to add the ^ for strings is a non-starter.

No opinion on the rest of the patch.

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

Comment By: Shane Holloway (shane_holloway)
Date: 2005-04-13 14:21

Message:
Logged In: YES 
user_id=283742

I would prefer to keep str's interface lean.  I think
binascii would be a nice home for strxor though.

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

Comment By: Antti Louko (alouko)
Date: 2005-04-13 11:01

Message:
Logged In: YES 
user_id=116402

This seems good.

I would also need strxor.  Should we add it to the string
type? ^ operator is not currently defined for strings.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470
From noreply at sourceforge.net  Tue Apr 26 12:50:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 26 12:50:32 2005
Subject: [Patches] [ python-Patches-1190163 ] Minimal cleanup of run.py
Message-ID: <E1DQNeA-0007Un-Hx@sc8-sf-web4.sourceforge.net>

Patches item #1190163, was opened at 2005-04-26 19: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=1190163&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michiel de Hoon (mdehoon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minimal cleanup of run.py

Initial Comment:
In the main function in run.py in Lib/idlelib, we have

try:
    seq, request = rpc.request_queue.get(0)
except Queue.Empty:
    time.sleep(0.05)
    continue

The get method of rpc.request_queue already has the
option of a timeout, so we can use that instead of
inlining time.sleep:

try:
    seq, request = rpc.request_queue.get(block=True, 
                                                      
     timeout=0.05)
except Queue.Empty:
    continue

resulting in a (small) simplication of the code. The
patch was tested on Windows, Linux, and Mac OS X.

In case you are wondering why I care about this:
My real interest is in PyOS_InputHook, a pointer to a
function which is called ten times per second when
Python is idle (e.g., waiting for user input).
Currently, calls to PyOS_InputHook are missing in some
cases where Python goes idle. I am going through the
code to fix this. Now, since both the original code in
run.py and rpc.request_queue.get cause Python to go
idle (by calling the sleep function), it means that I
would have to fix both cases. By making use of the
existing code in rpc.request_queue.get, I need to fix
this routine only (which I will do in a later patch),
and avoids having calls to PyOS_InputHook all over the
place.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1190163&group_id=5470
From pythonarchive at developershed.com  Tue Apr 26 17:07:50 2005
From: pythonarchive at developershed.com (pythonarchive)
Date: Tue Apr 26 17:35:04 2005
Subject: [Patches] Re: confirm 362251c3e7b256da758f6b0608f663ea40cd93e4
Message-ID: <009e01c54a71$b6bee1d0$7702a8c0@id10t>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20050426/69f2126e/attachment.html
From noreply at sourceforge.net  Tue Apr 26 18:32:34 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 26 18:32:37 2005
Subject: [Patches] [ python-Patches-1182394 ] HMAC hexdigest and general
	review
Message-ID: <E1DQSzC-0004lg-8f@sc8-sf-web2.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: HMAC hexdigest and general review

Initial Comment:
This patch is primarily aimed at speeding up the
HMAC.hexdigest method.  The current implementation is::

        return "".join([hex(ord(x))[2:].zfill(2)
                        for x in tuple(self.digest())])

Which is correct, but a little too clever.  Especially
when other tools are available.  The attached patch
adds HMAC._current that returns the hash object
combined from self.inner and self.outter to be used by
HMAC.digest and HMAC.hexdigest.  This results in an 11
fold speed improvement for md5 and sha digestmod's
while also making the code a little easier.


Other review points for the HMAC module include
removing "_secret_backdoor_key" in favor of using
"None" as the sentinel.  In this case, it makes sense
to use None because it is an invalid key, avoids a
global lookup in py2.4 and beyond, and is just as
readable.  

I also moved blocksize to a class level constant.  This
allows implementations to create different blocksize
hashes by inheriting and changing this value.  This
also involved a change to copy() to use
self.__class__(None) instead of directly calling
HMAC(None).

The final comment is that it would be nice to have a
C-level implementation of _strxor in binascii for this
module and possibly other uses.  However, I don't
really know a significantly faster way of implementing
this method in python.

Thanks,
-Shane Holloway

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-26 09:32

Message:
Logged In: YES 
user_id=341410

Obviously "always have a length of 4" should have been
"always have a length of zero modulo 4".

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-26 00:10

Message:
Logged In: YES 
user_id=341410

I think the patch looks good.  Though perhaps leaving a...
_secret_backdoor_key = None
... for backwards compatibility is a good idea.

The fastest method I've found (in pure Python) for xoring
strings is to use an array.array, with the largest typecode
that is a divisor of your sequence (cooking your strings to
always have a length of 4 and to use signed 4 byte longs
seems to work well on PII/PIII based systems).

Alternatively, writing it in C and compiling it with the new
GCC 4 will offer automatic vectorization, and save
allocating Python integers.

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-14 00:54

Message:
Logged In: YES 
user_id=6656

Attempting to add the ^ for strings is a non-starter.

No opinion on the rest of the patch.

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

Comment By: Shane Holloway (shane_holloway)
Date: 2005-04-13 14:21

Message:
Logged In: YES 
user_id=283742

I would prefer to keep str's interface lean.  I think
binascii would be a nice home for strxor though.

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

Comment By: Antti Louko (alouko)
Date: 2005-04-13 11:01

Message:
Logged In: YES 
user_id=116402

This seems good.

I would also need strxor.  Should we add it to the string
type? ^ operator is not currently defined for strings.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470
From noreply at sourceforge.net  Tue Apr 26 18:35:51 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr 26 18:35:53 2005
Subject: [Patches] [ python-Patches-1185529 ] Automatically build fpectl
	module from setup.py
Message-ID: <E1DQT2N-0007li-0e@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Automatically build fpectl module from setup.py

Initial Comment:
Setup.py doesn't try to build the fpectl module.  This
patch changes that.

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

>Comment By: Jeff Epler (jepler)
Date: 2005-04-26 11:35

Message:
Logged In: YES 
user_id=2772

given these responses I think the bug should be
closed/wontfix or closed/invalid.

No, the module wasn't useful to me---some python-list poster
wanted it, and I didn't look around to find out why it
wasn't building before filing this patch.

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-19 10:04

Message:
Logged In: YES 
user_id=31435

NEWS for 2.3a1 said:

"""
- The fpectl module is not built by default; it's dangerous or
  useless except in the hands of experts.
"""

Nobody tries to keep it up to date either, and its primary 
author said he doesn't think it's used anymore in his 
institution (or something close to that).

I don't think anyone officially deprecated it, though (nobody 
touches it, not even for that <wink>).

It shouldn't be built by default, anyway.


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

Comment By: Michael Hudson (mwh)
Date: 2005-04-19 09:42

Message:
Logged In: YES 
user_id=6656

I have to say, I thought that we were hoping people would forget about the 
fpectl module.  Is it actually useful?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185529&group_id=5470
From noreply at sourceforge.net  Wed Apr 27 04:23:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 27 04:23:45 2005
Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only
	file-like obj for files in archive
Message-ID: <E1DQcDG-0002zX-6o@sc8-sf-web4.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Alan McIntyre (ESRG) (alanmcintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile.open - read-only file-like obj for files in archive

Initial Comment:
I originally started working on updating patch 992750,
but decided after a short while to just start from
scratch, so I'm posting it as a new patch.  Sorry if
this isn't appropriate.

This patch provides a new open() method on ZipFile;
this method returns a file-like object for the
requested item in the archive.  This file-like object
only provides a read() method.

ZipFile.read was modified to use the new open method
(this was suggested by loewis in reference to patch
992750).

The patched zipfile.py passed the existing tests in the
test_zipfile.py from CVS.  New tests were added to
verify the operation of the object returned by open().
These tests were modeled after existing tests for
ZipFile.read(); two read fixed-size chunks from the
file-like object, and two others read random-sized chunks.

I have only run the tests on Windows XP, using
Python2.4 from the official Windows installer.  I will
test the patch out on Linux over the weekend.

If the patch is accepted I'll also generate and submit
patches for the appropriate documentation as well.

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

>Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-04-26 21:23

Message:
Logged In: YES 
user_id=1115903

After testing on my large batch of large Zip files, I made
one fix (version 4 of the patch didn't read all the content
of large compressed archive items).  The current set of
changes is attached as zipfile_patch5.tgz.

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-04-13 11:34

Message:
Logged In: YES 
user_id=1115903

I found a problem with my universal newline handling code in
readline(); if the first byte of an '\r\n' pair was read
from file but the second byte didn't come in on that same
read, it resulted in the next line having an inappropriate
'\n' prepended to it.  zipfile_patch4.tgz has a fix for this
included (with everything else, of course).

I'm going to test the open() capability in a real
application with some reasonably large zip files (containing
files up to just short of 2GB) over the next few days, so if
any bugs or performance problems show up I may have some
more changes.

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-04-13 00:58

Message:
Logged In: YES 
user_id=1115903

Uploaded the third revision of this patch; passes all
regression tests against current CVS on WinXP.  I think all
the issues Martin brought up have been addressed except
perhaps for the case of compression rate <1.  I will have a
look at that when I have time; just wanted to get an update
here before the patch started to look abandoned. :)

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-03-14 09:37

Message:
Logged In: YES 
user_id=1115903

Hmm...I could have sworn I did the diff in the correct
order. I'll make sure next time. :)

Here's my comments on your remarks (in order):
- I'm adding support for universal newlines, and will reject
all modes that aren't legal combinations of r, U, and b.
- I'll see if I can make a Zip file store something with
compression < 1, and if I can I'll add a test case for it.
- I'll try work a .flush() in there on the compression
object and come up with a test case if possible
- .read(0) and .readline(0) will both return an empty string
with no side-effects, since this seems to be what builtin
files do.  

Right now ZipExtFile uses the ZipFile's file object, so you
pretty much have to do whatever you're going to do with the
ZipExtFile instance you get back from .open() before you use
that ZipFile instance in a way that moves the file pointer
around. 

I'm sure that somebody will eventually try to use the
ZipFile in this way, so it appears my options are either to
(1) give the ZipExtFile its own file object to use (when
possible), or (2) make sure this limitation is documented. 
#1 feels (to me) to be the "right thing" to do, so that's
what I'll try unless there's a good reason I shouldn't.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-03-01 02:59

Message:
Logged In: YES 
user_id=21627

The patch is reversed: usually, diff is invoked as "-c old new".

I think it is almost right, but I have a few remarks:
- by tradition, open() should have a mode argument,
defaulting to 'r'; it would be ok to raise exceptions if it
is anything else. However, do consider implementing
universal newlines; allowing 'b' as a no-op might also be
reasonable.
- I wonder what happens if the compression rate is < 1. It
would appear that the code might use too few rawbytes. I
suggest to recursively invoke read in this case.
- I wonder whether it could ever happen that there is still
data to uncompress in the zlib object, ie. whether it might
be necessary to invoke .flush() after exhausting the
rawbytes (and discard the zlib object afterwards)
- it appears that atleast the builtin file object implements
.read(0) as returning an empty string; the manual says that
the entire file is meant only if size is omitted or negative.

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

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-02-27 01:28

Message:
Logged In: YES 
user_id=1115903

zipfile_patch2.tgz: I updated the file-like object to
support readline, readlines, __iter__ and next().  Added
tests for those new methods.  Also added a patch for the
documentation.

Passes regression tests on 2.5a0 built from CVS HEAD with
MSVC .NET on Windows XP.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470
From noreply at sourceforge.net  Wed Apr 27 11:10:42 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 27 11:10:46 2005
Subject: [Patches] [ python-Patches-1185529 ] Automatically build fpectl
	module from setup.py
Message-ID: <E1DQiZ8-0005PN-TQ@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Automatically build fpectl module from setup.py

Initial Comment:
Setup.py doesn't try to build the fpectl module.  This
patch changes that.

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

>Comment By: Michael Hudson (mwh)
Date: 2005-04-27 10:10

Message:
Logged In: YES 
user_id=6656

Well, as you submitted the bug report, you can do that yourself!

But as a special treat, I'll close this one for you <wink>.

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

Comment By: Jeff Epler (jepler)
Date: 2005-04-26 17:35

Message:
Logged In: YES 
user_id=2772

given these responses I think the bug should be
closed/wontfix or closed/invalid.

No, the module wasn't useful to me---some python-list poster
wanted it, and I didn't look around to find out why it
wasn't building before filing this patch.

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-19 16:04

Message:
Logged In: YES 
user_id=31435

NEWS for 2.3a1 said:

"""
- The fpectl module is not built by default; it's dangerous or
  useless except in the hands of experts.
"""

Nobody tries to keep it up to date either, and its primary 
author said he doesn't think it's used anymore in his 
institution (or something close to that).

I don't think anyone officially deprecated it, though (nobody 
touches it, not even for that <wink>).

It shouldn't be built by default, anyway.


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

Comment By: Michael Hudson (mwh)
Date: 2005-04-19 15:42

Message:
Logged In: YES 
user_id=6656

I have to say, I thought that we were hoping people would forget about the 
fpectl module.  Is it actually useful?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185529&group_id=5470
From noreply at sourceforge.net  Wed Apr 27 17:02:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 27 17:03:02 2005
Subject: [Patches] [ python-Patches-1191065 ] socketmodule.c's recvfrom on
	OSF/1 4.0
Message-ID: <E1DQo43-0007iQ-Ol@sc8-sf-web4.sourceforge.net>

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

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
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. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191065&group_id=5470
From noreply at sourceforge.net  Thu Apr 28 07:31:31 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 28 07:31:34 2005
Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py
Message-ID: <E1DR1cZ-0003m4-7p@sc8-sf-web3.sourceforge.net>

Patches item #1191489, was opened at 2005-04-28 00:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. L?wis (loewis)
Summary: Simplify logic in random.py

Initial Comment:
Simplify the logic in several methods for better
readability, maintainability, and speed:

* while True --> while 1
* apply de'morgan's theorem to simplify compound
conditionals
* factor out repeated test:  (p>1.0) and (p <= 1.0)
* replace pow() with **


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470
From noreply at sourceforge.net  Thu Apr 28 16:38:32 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 02:50:11 2005
Subject: [Patches] [ python-Patches-1191726 ] about shift key
Message-ID: <E1DRA9w-0001y9-Ce@sc8-sf-web3.sourceforge.net>

Patches item #1191726, was opened at 2005-04-28 22: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=1191726&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: yang (leeews)
Assigned to: Nobody/Anonymous (nobody)
Summary: about shift key

Initial Comment:
I'v wrote the following program
------------------------------------------------------------------------------
from Tkinter import *

class KeyDemo(Frame):
    """"""

    def __init__(self):
        """"""

        Frame.__init__(self)
        self.pack(expand=YES,fill=BOTH)
        self.master.title("Demonstrating Keystroke Events")
        self.master.geometry("350x100")

        self.message1=StringVar()
        self.line1=Label(self,textvariable=self.message1)
        self.message1.set("Type any key or shift")
        self.line1.pack()

        self.message2=StringVar()
        self.line2=Label(self,textvariable=self.message2)
        self.message2.set("")
        self.line2.pack()

        self.master.bind("<KeyPress>",self.keyPressed)
        self.master.bind("<KeyRelease>",self.keyReleased)

       
self.master.bind("<KeyPress-Shift_L>",self.shiftPressed)
       
self.master.bind("<KeyRelease-Shift_L>",self.shiftReleased)

    def keyPressed(self,event):
        """"""

        self.message1.set("Key pressed: "+ event.char)
        self.message2.set("This key is not left shift")

    def keyReleased(self,event):
        """"""

        self.message1.set("Key released: "+ event.char)
        self.message2.set("This key is not left shift")

    def shiftPressed(self,event):
        """"""

        self.message1.set("Shift pressed")
        self.message2.set("This key is left shift")

    def shiftReleased(self,event):
        """"""

        self.message1.set("Shift released")
        self.message2.set("This key is left shift")

def main():
    KeyDemo().mainloop()

if __name__=="__main__":
    main()

--------------------------------------------------------------------------
When I pressed right shift , it shows:
 Key pressed:
This key is not left shift

And when I released right shift ,it shows:
Shift released
This key is left shift
But what I release is right shift.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191726&group_id=5470
From noreply at sourceforge.net  Thu Apr 28 15:46:44 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 02:50:12 2005
Subject: [Patches] [ python-Patches-1191700 ] wrong offsets in bpprint()
Message-ID: <E1DR9Lo-0000k8-6V@sc8-sf-web2.sourceforge.net>

Patches item #1191700, was opened at 2005-04-28 16: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=1191700&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Pechkinzzz (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


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191700&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 02:46:25 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 02:53:16 2005
Subject: [Patches] [ python-Patches-1191726 ] about shift key
Message-ID: <E1DRJeD-00042q-TX@sc8-sf-web2.sourceforge.net>

Patches item #1191726, was opened at 2005-04-28 07:38
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191726&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: yang (leeews)
Assigned to: Nobody/Anonymous (nobody)
Summary: about shift key

Initial Comment:
I'v wrote the following program
------------------------------------------------------------------------------
from Tkinter import *

class KeyDemo(Frame):
    """"""

    def __init__(self):
        """"""

        Frame.__init__(self)
        self.pack(expand=YES,fill=BOTH)
        self.master.title("Demonstrating Keystroke Events")
        self.master.geometry("350x100")

        self.message1=StringVar()
        self.line1=Label(self,textvariable=self.message1)
        self.message1.set("Type any key or shift")
        self.line1.pack()

        self.message2=StringVar()
        self.line2=Label(self,textvariable=self.message2)
        self.message2.set("")
        self.line2.pack()

        self.master.bind("<KeyPress>",self.keyPressed)
        self.master.bind("<KeyRelease>",self.keyReleased)

       
self.master.bind("<KeyPress-Shift_L>",self.shiftPressed)
       
self.master.bind("<KeyRelease-Shift_L>",self.shiftReleased)

    def keyPressed(self,event):
        """"""

        self.message1.set("Key pressed: "+ event.char)
        self.message2.set("This key is not left shift")

    def keyReleased(self,event):
        """"""

        self.message1.set("Key released: "+ event.char)
        self.message2.set("This key is not left shift")

    def shiftPressed(self,event):
        """"""

        self.message1.set("Shift pressed")
        self.message2.set("This key is left shift")

    def shiftReleased(self,event):
        """"""

        self.message1.set("Shift released")
        self.message2.set("This key is left shift")

def main():
    KeyDemo().mainloop()

if __name__=="__main__":
    main()

--------------------------------------------------------------------------
When I pressed right shift , it shows:
 Key pressed:
This key is not left shift

And when I released right shift ,it shows:
Shift released
This key is left shift
But what I release is right shift.

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

Comment By: Ilya Sandler (isandler)
Date: 2005-04-28 17:46

Message:
Logged In: YES 
user_id=971153

This seems like a bug (not a patch) report..

So I guess it might be a good idea to close it and refile as
a bug...

And a few more suggestions:

  --try to minimize your code sample 
  --make sure that your sample code is formatted correctly
in your post
  --please indicate what platform/OS you are using

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191726&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 07:21:36 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 07:21:39 2005
Subject: [Patches] [ python-Patches-1191700 ] wrong offsets in bpprint()
Message-ID: <E1DRNwW-0002CP-FI@sc8-sf-web1.sourceforge.net>

Patches item #1191700, was opened at 2005-04-28 22:46
Message generated for change (Comment added) made by mdehoon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191700&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Pechkinzzz (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: Michiel de Hoon (mdehoon)
Date: 2005-04-29 14: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  Fri Apr 29 07:42:43 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 07:42:49 2005
Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py
Message-ID: <E1DROGx-0003Qs-82@sc8-sf-web2.sourceforge.net>

Patches item #1191489, was opened at 2005-04-28 14:31
Message generated for change (Comment added) made by mdehoon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. L?wis (loewis)
Summary: Simplify logic in random.py

Initial Comment:
Simplify the logic in several methods for better
readability, maintainability, and speed:

* while True --> while 1
* apply de'morgan's theorem to simplify compound
conditionals
* factor out repeated test:  (p>1.0) and (p <= 1.0)
* replace pow() with **


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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 14:42

Message:
Logged In: YES 
user_id=488897

* I don't see how "while 1" is more readable than "while
True". Note also that in older Python versions, this
actually was "while 1"; it was changed to "while True" in
revision 1.39. I can't recommend changing it back.

* This pertains to line 424. I agree that the line in the
patch is more readable and perhaps faster (though marginally
so).

* I agree with you that there is a repeated test in the
current code. In the patch, I would stick with pow() instead
of ** (see my next comment)

* Unnecessary change. Some people like pow(), others like
**. I see no reason to change.

General comment: It is usually better to have different
changes in separate patches. True, the changes in the patch
all apply to random.py, but otherwise they don't have much
in common.

(I'm just a patch reviewer, not an official Python
developer, so you don't need to take my comments too seriously.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 08:07:03 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 08:07:07 2005
Subject: [Patches] [ python-Patches-1187396 ] Add const specifier to
	PySpam_System prototype
Message-ID: <E1DROeV-0003WR-Hw@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 1
Submitted By: Luis Bruno (lbruno)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add const specifier to PySpam_System prototype

Initial Comment:
Section 1.12 of Extending & Embedding needs a const
specifier for correct compilation (tested on Fedora
Core 3, py2.3).

Closes #1184380, submitted by bamoore@users.sf.net

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 15:07

Message:
Logged In: YES 
user_id=488897

Patch looks fine to me. I'll write a patch review to the
python-dev mailing list in support of this patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1187396&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 08:10:50 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 08:10:52 2005
Subject: [Patches] [ python-Patches-1186781 ] Typo in Curses-Function doc
Message-ID: <E1DROiA-0004F2-3e@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: grzankam (grzankam)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in Curses-Function doc

Initial Comment:
The description of the filter() method on
<http://docs.python.org/lib/curses-functions.html> says
"This may be used for enabling cgaracter-at-a-time line
editing without touching the rest of the screen."

cgaracter should likely be character

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 15:10

Message:
Logged In: YES 
user_id=488897

Note that curses-functions.html is generated from
Doc/lib/libcurses.tex, so the patch should be against this
file instead of the HTML page. Otherwise, you're right of
course.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1186781&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 08:12:48 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 08:12:50 2005
Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py
Message-ID: <E1DROk4-0003ha-Bl@sc8-sf-web1.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Simplify logic in random.py

Initial Comment:
Simplify the logic in several methods for better
readability, maintainability, and speed:

* while True --> while 1
* apply de'morgan's theorem to simplify compound
conditionals
* factor out repeated test:  (p>1.0) and (p <= 1.0)
* replace pow() with **


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 01:12

Message:
Logged In: YES 
user_id=80475

Thanks for looking at the patch.  What I really need is for
a second person to verify that the transformations are
semantically neutral (no change in overall logic).

FWIW, I was the one who did rev 1.39.  It turns out that it
was a premature modernization that cost some performance. 
Only the while 1 form is optimized by CPython, Jython, and
Pysco.

Have to disagree with you on pow(). The operator form runs
faster and corresponds more closely to the way formulas are
written in math textbooks and in other languages (except C
which doesn't have a pow operator).  This is the reason we
write a+b instead operator.add(a, b).

If you can a chance, please look closely at the logic
transformations to make sure I did them accurately.  Thanks
again.
 

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 00:42

Message:
Logged In: YES 
user_id=488897

* I don't see how "while 1" is more readable than "while
True". Note also that in older Python versions, this
actually was "while 1"; it was changed to "while True" in
revision 1.39. I can't recommend changing it back.

* This pertains to line 424. I agree that the line in the
patch is more readable and perhaps faster (though marginally
so).

* I agree with you that there is a repeated test in the
current code. In the patch, I would stick with pow() instead
of ** (see my next comment)

* Unnecessary change. Some people like pow(), others like
**. I see no reason to change.

General comment: It is usually better to have different
changes in separate patches. True, the changes in the patch
all apply to random.py, but otherwise they don't have much
in common.

(I'm just a patch reviewer, not an official Python
developer, so you don't need to take my comments too seriously.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 08:59:23 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 08:59:26 2005
Subject: [Patches] [ python-Patches-1175933 ] threading.Condition.wait()
	return value indicates timeout
Message-ID: <E1DRPT9-00059U-5G@sc8-sf-web1.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Condition.wait() return value indicates timeout

Initial Comment:
A condition variable returns in two cases: it was
notified by another thread, or it timed out (if a
timeout was specified).  See an example in the popular
Boost C++ library:

http://boost.org/doc/html/condition.html

This patch adds this capability to the Python
threading.Condition.wait() method, which used to return
nothing.  I added the relevant couple of lines to the
documentaion as well (see patch).

(An example is using a condition variable as a sentinel
for exiting a loop or a polling thread.  Using the
return value one can decide whether to exit the loop or
not.)


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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 15:59

Message:
Logged In: YES 
user_id=488897

This looks like a good idea to me. It will help to clean up
the "get" method in Queue.py, which now has:

                while self._empty():
                    remaining = endtime - _time()
                    if remaining <= 0.0:
                        raise Empty
                    self.not_empty.wait(remaining)

Here, self.not_empty is an object of the class
threading.Condition. It seems odd that first we wait for
self.not_empty.wait to return, and then have to check
self._empty(), even though self.not_empty.wait could have
told us directly if it was notified or it timed out.

I'll write a message to python-dev in support of this patch
(I'm a mere patch reviewer, not an official Python developer).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175933&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 11:07:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 11:07:55 2005
Subject: [Patches] [ python-Patches-1191700 ] wrong offsets in bpprint()
Message-ID: <E1DRRTU-00018W-6u@sc8-sf-web3.sourceforge.net>

Patches item #1191700, was opened at 2005-04-28 16:46
Message generated for change (Comment added) made by mpech
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191700&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Pechkinzzz (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: Pechkinzzz (mpech)
Date: 2005-04-29 12: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 08: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  Fri Apr 29 13:47:21 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 13:47:23 2005
Subject: [Patches] [ python-Patches-1191726 ] about shift key
Message-ID: <E1DRTxp-0007jP-0t@sc8-sf-web3.sourceforge.net>

Patches item #1191726, was opened at 2005-04-28 22:38
Message generated for change (Comment added) made by leeews
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191726&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: yang (leeews)
Assigned to: Nobody/Anonymous (nobody)
Summary: about shift key

Initial Comment:
I'v wrote the following program
------------------------------------------------------------------------------
from Tkinter import *

class KeyDemo(Frame):
    """"""

    def __init__(self):
        """"""

        Frame.__init__(self)
        self.pack(expand=YES,fill=BOTH)
        self.master.title("Demonstrating Keystroke Events")
        self.master.geometry("350x100")

        self.message1=StringVar()
        self.line1=Label(self,textvariable=self.message1)
        self.message1.set("Type any key or shift")
        self.line1.pack()

        self.message2=StringVar()
        self.line2=Label(self,textvariable=self.message2)
        self.message2.set("")
        self.line2.pack()

        self.master.bind("<KeyPress>",self.keyPressed)
        self.master.bind("<KeyRelease>",self.keyReleased)

       
self.master.bind("<KeyPress-Shift_L>",self.shiftPressed)
       
self.master.bind("<KeyRelease-Shift_L>",self.shiftReleased)

    def keyPressed(self,event):
        """"""

        self.message1.set("Key pressed: "+ event.char)
        self.message2.set("This key is not left shift")

    def keyReleased(self,event):
        """"""

        self.message1.set("Key released: "+ event.char)
        self.message2.set("This key is not left shift")

    def shiftPressed(self,event):
        """"""

        self.message1.set("Shift pressed")
        self.message2.set("This key is left shift")

    def shiftReleased(self,event):
        """"""

        self.message1.set("Shift released")
        self.message2.set("This key is left shift")

def main():
    KeyDemo().mainloop()

if __name__=="__main__":
    main()

--------------------------------------------------------------------------
When I pressed right shift , it shows:
 Key pressed:
This key is not left shift

And when I released right shift ,it shows:
Shift released
This key is left shift
But what I release is right shift.

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

>Comment By: yang (leeews)
Date: 2005-04-29 19:47

Message:
Logged In: YES 
user_id=1268579

sorry,I'll be minimize my code sample next time

my code had formatted correctly when I edit it,but when I
post it , The spaces for format control had disappeared.

my platform is python 2.4 /winXP

This is the first time I report bug, so I don't know what is
the correct way. sorry to trouble you

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

Comment By: Ilya Sandler (isandler)
Date: 2005-04-29 08:46

Message:
Logged In: YES 
user_id=971153

This seems like a bug (not a patch) report..

So I guess it might be a good idea to close it and refile as
a bug...

And a few more suggestions:

  --try to minimize your code sample 
  --make sure that your sample code is formatted correctly
in your post
  --please indicate what platform/OS you are using

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191726&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 20:25:52 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 20:25:55 2005
Subject: [Patches] [ python-Patches-1192590 ] debugger ``condition`` and
	``ignore`` exception handling
Message-ID: <E1DRaBU-0008OU-Kg@sc8-sf-web3.sourceforge.net>

Patches item #1192590, was opened at 2005-04-29 18: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=1192590&group_id=5470

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Jones (jmjones)
Assigned to: Nobody/Anonymous (nobody)
Summary: debugger ``condition`` and ``ignore`` exception handling

Initial Comment:
Fixed ``ignore`` and ``condition`` functions in the
debugger (pdb.py) where  they were not handling an
``IndexError`` exception which occurs when an invalid
breakpoint number is passed in.

Added a function ``do_show()`` which lists all
breakpoints.  ``do_show()`` takes a filename pattern as
an argument.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192590&group_id=5470
From noreply at sourceforge.net  Fri Apr 29 23:36:30 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr 29 23:36:34 2005
Subject: [Patches] [ python-Patches-1173245 ] unicodedata docstrings
Message-ID: <E1DRd9y-00079I-Ou@sc8-sf-web3.sourceforge.net>

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

Category: Modules
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jeremy Yallop (yallop)
Assigned to: Nobody/Anonymous (nobody)
Summary: unicodedata docstrings

Initial Comment:
Docstrings for unicodedata, extracted from the tex
documentation.

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

Comment By: Darek Suchojad (dsuch)
Date: 2005-04-29 21:36

Message:
Logged In: YES 
user_id=954779

I think the module's docstring is wrong (and so is the tex
documentation, and this page too
http://docs.python.org/lib/module-unicodedata.html).

The URL for UnicodeData File Format 3.2.0 is
http://www.unicode.org/Public/3.2-Update/UnicodeData-3.2.0.html
now.

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

Comment By: Hye-Shik Chang (perky)
Date: 2005-04-04 16:32

Message:
Logged In: YES 
user_id=55188

Committed in Modules/unicodedata.c 2.33.

Thank you for the patch!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1173245&group_id=5470
From noreply at sourceforge.net  Sat Apr 30 01:46:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 30 01:47:01 2005
Subject: [Patches] [ python-Patches-1192789 ] Use GCC4 ELF symbol visibility
Message-ID: <E1DRfCF-0005HD-CR@sc8-sf-web4.sourceforge.net>

Patches item #1192789, was opened at 2005-04-30 07: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=1192789&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
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.

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

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 30 06:39:47 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 30 06:39:51 2005
Subject: [Patches] [ python-Patches-1175933 ] threading.Condition.wait()
	return value indicates timeout
Message-ID: <E1DRjlb-0002Ys-GV@sc8-sf-web1.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Condition.wait() return value indicates timeout

Initial Comment:
A condition variable returns in two cases: it was
notified by another thread, or it timed out (if a
timeout was specified).  See an example in the popular
Boost C++ library:

http://boost.org/doc/html/condition.html

This patch adds this capability to the Python
threading.Condition.wait() method, which used to return
nothing.  I added the relevant couple of lines to the
documentaion as well (see patch).

(An example is using a condition variable as a sentinel
for exiting a loop or a polling thread.  Using the
return value one can decide whether to exit the loop or
not.)


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

>Comment By: Tim Peters (tim_one)
Date: 2005-04-30 00:39

Message:
Logged In: YES 
user_id=31435

Sorry, I think this is a poor idea, and mdehoon's suggestion 
for turning a correct use of .wait() into a doubly buggy one 
illustrates why:  there's no guarantee that self._empty() will 
return false just because .wait() returns without timing out --
 .wait() returning just means that it may not be a waste of 
time to check for the desired condition.  "notifying" a condvar 
emphatically does not mean that the desired condition holds, 
and any number of other threads can run for any amount of 
time between the times a condvar is notified and some wait()
er wakes up (so even if the desired condition does hold at the 
time notify() is called, it may not anymore by the time a wait()
er wakes).

The check should always be done when .wait() doesn't time 
out, and even if .wait() does time out, self._empty() may 
return false anyway.

Note too that .wait()'s caller holds the associated mutex 
regardless of whether return is due to timeout or notify, and 
the caller needs to release it again in either case.  Creating a 
distinction based on return value creates a new opportunity to 
screw up that part too.

I don't understand this:

> An example is using a condition variable as a sentinel
> for exiting a loop or a polling thread. Using the
> return value one can decide whether to exit the loop or
> not.)

To the extent that I might understand it, it sounds like a 
condvar is gross overkill, and that you'd want something 
simpler (perhaps an Event) in those cases.  But I can't flesh 
out the code you have in mind there.

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 02:59

Message:
Logged In: YES 
user_id=488897

This looks like a good idea to me. It will help to clean up
the "get" method in Queue.py, which now has:

                while self._empty():
                    remaining = endtime - _time()
                    if remaining <= 0.0:
                        raise Empty
                    self.not_empty.wait(remaining)

Here, self.not_empty is an object of the class
threading.Condition. It seems odd that first we wait for
self.not_empty.wait to return, and then have to check
self._empty(), even though self.not_empty.wait could have
told us directly if it was notified or it timed out.

I'll write a message to python-dev in support of this patch
(I'm a mere patch reviewer, not an official Python developer).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175933&group_id=5470
From noreply at sourceforge.net  Sat Apr 30 07:07:53 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 30 07:07:56 2005
Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py
Message-ID: <E1DRkCn-0003HD-AL@sc8-sf-web1.sourceforge.net>

Patches item #1191489, was opened at 2005-04-28 01:31
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Simplify logic in random.py

Initial Comment:
Simplify the logic in several methods for better
readability, maintainability, and speed:

* while True --> while 1
* apply de'morgan's theorem to simplify compound
conditionals
* factor out repeated test:  (p>1.0) and (p <= 1.0)
* replace pow() with **


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

>Comment By: Tim Peters (tim_one)
Date: 2005-04-30 01:07

Message:
Logged In: YES 
user_id=31435

Raymond, I checked the semantics, and aver that all the 
transformations here are semantically correct.  Marked as 
Accepted -- go for it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 02:12

Message:
Logged In: YES 
user_id=80475

Thanks for looking at the patch.  What I really need is for
a second person to verify that the transformations are
semantically neutral (no change in overall logic).

FWIW, I was the one who did rev 1.39.  It turns out that it
was a premature modernization that cost some performance. 
Only the while 1 form is optimized by CPython, Jython, and
Pysco.

Have to disagree with you on pow(). The operator form runs
faster and corresponds more closely to the way formulas are
written in math textbooks and in other languages (except C
which doesn't have a pow operator).  This is the reason we
write a+b instead operator.add(a, b).

If you can a chance, please look closely at the logic
transformations to make sure I did them accurately.  Thanks
again.
 

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 01:42

Message:
Logged In: YES 
user_id=488897

* I don't see how "while 1" is more readable than "while
True". Note also that in older Python versions, this
actually was "while 1"; it was changed to "while True" in
revision 1.39. I can't recommend changing it back.

* This pertains to line 424. I agree that the line in the
patch is more readable and perhaps faster (though marginally
so).

* I agree with you that there is a repeated test in the
current code. In the patch, I would stick with pow() instead
of ** (see my next comment)

* Unnecessary change. Some people like pow(), others like
**. I see no reason to change.

General comment: It is usually better to have different
changes in separate patches. True, the changes in the patch
all apply to random.py, but otherwise they don't have much
in common.

(I'm just a patch reviewer, not an official Python
developer, so you don't need to take my comments too seriously.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470
From noreply at sourceforge.net  Sat Apr 30 07:29:14 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 30 07:29:17 2005
Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py
Message-ID: <E1DRkXS-0003rI-3t@sc8-sf-web1.sourceforge.net>

Patches item #1191489, was opened at 2005-04-28 14:31
Message generated for change (Comment added) made by mdehoon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Simplify logic in random.py

Initial Comment:
Simplify the logic in several methods for better
readability, maintainability, and speed:

* while True --> while 1
* apply de'morgan's theorem to simplify compound
conditionals
* factor out repeated test:  (p>1.0) and (p <= 1.0)
* replace pow() with **


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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-30 14:29

Message:
Logged In: YES 
user_id=488897

OK, if ** and "while 1" give better performance than pow and
"while true", I'm all for it.
To double-check if the logic is correct, I generated a
million variates with vonmisesvariate and gammavariate with
and without the patch, for various values for the
parameters. I found no problems with it.

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-30 14:07

Message:
Logged In: YES 
user_id=31435

Raymond, I checked the semantics, and aver that all the 
transformations here are semantically correct.  Marked as 
Accepted -- go for it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 15:12

Message:
Logged In: YES 
user_id=80475

Thanks for looking at the patch.  What I really need is for
a second person to verify that the transformations are
semantically neutral (no change in overall logic).

FWIW, I was the one who did rev 1.39.  It turns out that it
was a premature modernization that cost some performance. 
Only the while 1 form is optimized by CPython, Jython, and
Pysco.

Have to disagree with you on pow(). The operator form runs
faster and corresponds more closely to the way formulas are
written in math textbooks and in other languages (except C
which doesn't have a pow operator).  This is the reason we
write a+b instead operator.add(a, b).

If you can a chance, please look closely at the logic
transformations to make sure I did them accurately.  Thanks
again.
 

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 14:42

Message:
Logged In: YES 
user_id=488897

* I don't see how "while 1" is more readable than "while
True". Note also that in older Python versions, this
actually was "while 1"; it was changed to "while True" in
revision 1.39. I can't recommend changing it back.

* This pertains to line 424. I agree that the line in the
patch is more readable and perhaps faster (though marginally
so).

* I agree with you that there is a repeated test in the
current code. In the patch, I would stick with pow() instead
of ** (see my next comment)

* Unnecessary change. Some people like pow(), others like
**. I see no reason to change.

General comment: It is usually better to have different
changes in separate patches. True, the changes in the patch
all apply to random.py, but otherwise they don't have much
in common.

(I'm just a patch reviewer, not an official Python
developer, so you don't need to take my comments too seriously.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470
From noreply at sourceforge.net  Sat Apr 30 11:03:56 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 30 11:03:59 2005
Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py
Message-ID: <E1DRntE-0006r9-JJ@sc8-sf-web3.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.5
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Simplify logic in random.py

Initial Comment:
Simplify the logic in several methods for better
readability, maintainability, and speed:

* while True --> while 1
* apply de'morgan's theorem to simplify compound
conditionals
* factor out repeated test:  (p>1.0) and (p <= 1.0)
* replace pow() with **


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-30 04:03

Message:
Logged In: YES 
user_id=80475

Thanks.
Checked in as Lib/random.py 1.71

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-30 00:29

Message:
Logged In: YES 
user_id=488897

OK, if ** and "while 1" give better performance than pow and
"while true", I'm all for it.
To double-check if the logic is correct, I generated a
million variates with vonmisesvariate and gammavariate with
and without the patch, for various values for the
parameters. I found no problems with it.

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

Comment By: Tim Peters (tim_one)
Date: 2005-04-30 00:07

Message:
Logged In: YES 
user_id=31435

Raymond, I checked the semantics, and aver that all the 
transformations here are semantically correct.  Marked as 
Accepted -- go for it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 01:12

Message:
Logged In: YES 
user_id=80475

Thanks for looking at the patch.  What I really need is for
a second person to verify that the transformations are
semantically neutral (no change in overall logic).

FWIW, I was the one who did rev 1.39.  It turns out that it
was a premature modernization that cost some performance. 
Only the while 1 form is optimized by CPython, Jython, and
Pysco.

Have to disagree with you on pow(). The operator form runs
faster and corresponds more closely to the way formulas are
written in math textbooks and in other languages (except C
which doesn't have a pow operator).  This is the reason we
write a+b instead operator.add(a, b).

If you can a chance, please look closely at the logic
transformations to make sure I did them accurately.  Thanks
again.
 

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 00:42

Message:
Logged In: YES 
user_id=488897

* I don't see how "while 1" is more readable than "while
True". Note also that in older Python versions, this
actually was "while 1"; it was changed to "while True" in
revision 1.39. I can't recommend changing it back.

* This pertains to line 424. I agree that the line in the
patch is more readable and perhaps faster (though marginally
so).

* I agree with you that there is a repeated test in the
current code. In the patch, I would stick with pow() instead
of ** (see my next comment)

* Unnecessary change. Some people like pow(), others like
**. I see no reason to change.

General comment: It is usually better to have different
changes in separate patches. True, the changes in the patch
all apply to random.py, but otherwise they don't have much
in common.

(I'm just a patch reviewer, not an official Python
developer, so you don't need to take my comments too seriously.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470
From noreply at sourceforge.net  Sat Apr 30 16:03:59 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 30 16:04:01 2005
Subject: [Patches] [ python-Patches-1175933 ] threading.Condition.wait()
	return value indicates timeout
Message-ID: <E1DRsZb-0008QD-Bg@sc8-sf-web1.sourceforge.net>

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

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Condition.wait() return value indicates timeout

Initial Comment:
A condition variable returns in two cases: it was
notified by another thread, or it timed out (if a
timeout was specified).  See an example in the popular
Boost C++ library:

http://boost.org/doc/html/condition.html

This patch adds this capability to the Python
threading.Condition.wait() method, which used to return
nothing.  I added the relevant couple of lines to the
documentaion as well (see patch).

(An example is using a condition variable as a sentinel
for exiting a loop or a polling thread.  Using the
return value one can decide whether to exit the loop or
not.)


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

>Comment By: Martin Blais (blais)
Date: 2005-04-30 14:03

Message:
Logged In: YES 
user_id=10996

hi tim
thanks for the comments.

my use of a condition variable is exemplified in this
background thread, which computes something periodically,
and with which the main thread uses a condition variable to
communicate "pause" and "quit" states (there is
communication between only those two threads):

def background_thread( func, args, condvar, callbacks, delay ):
    """
    A background thread that computes something periodically.

    @func: function that computes something;
    @data: arguments for function that computes something;
    @condvar: a variable to indicate for the thread to stop
or pause.
              The variable is the 'pause' and 'quit' members
on the condvar.
    @callbacks: a list of functions to call when a new
result becomes available;
    """
    done = 0
    while not done:
        # compute something
        data = func(*args)
        
        # push the new data into the callbacks
        for cb in callbacks:
            cb(data)

        condvar.acquire()
        if condvar.pause:
            # this branch is used to pause the thread.
            condvar.wait()
        else:
            condvar.wait(delay)
        if condvar.quit:
            done = 1
        condvar.release()

instead of using the "quit" data member, i could instead use
the return value of the wait() call.  basically, exit the
loop when i've been signaled.

AFAIK this is a common usage pattern. i've seen it in a few
places.  do you see any problem with this usage?

not that it's really an argument, but i did see 3
independent implementations of wait() returning the
signaled/timeout boolean.

i think Event.wait() should also return the signaled/timeout
state.  it's information that should be returned to the
user, whether he uses it or not.  sure, people can screw up,
but if there is a legitimate case where it can be used, i
think it should be provided anyway.

also, you are correct about mdehoon's case, after returning
from wait(), one should check for the queue being empty or not.



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

Comment By: Tim Peters (tim_one)
Date: 2005-04-30 04:39

Message:
Logged In: YES 
user_id=31435

Sorry, I think this is a poor idea, and mdehoon's suggestion 
for turning a correct use of .wait() into a doubly buggy one 
illustrates why:  there's no guarantee that self._empty() will 
return false just because .wait() returns without timing out --
 .wait() returning just means that it may not be a waste of 
time to check for the desired condition.  "notifying" a condvar 
emphatically does not mean that the desired condition holds, 
and any number of other threads can run for any amount of 
time between the times a condvar is notified and some wait()
er wakes up (so even if the desired condition does hold at the 
time notify() is called, it may not anymore by the time a wait()
er wakes).

The check should always be done when .wait() doesn't time 
out, and even if .wait() does time out, self._empty() may 
return false anyway.

Note too that .wait()'s caller holds the associated mutex 
regardless of whether return is due to timeout or notify, and 
the caller needs to release it again in either case.  Creating a 
distinction based on return value creates a new opportunity to 
screw up that part too.

I don't understand this:

> An example is using a condition variable as a sentinel
> for exiting a loop or a polling thread. Using the
> return value one can decide whether to exit the loop or
> not.)

To the extent that I might understand it, it sounds like a 
condvar is gross overkill, and that you'd want something 
simpler (perhaps an Event) in those cases.  But I can't flesh 
out the code you have in mind there.

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-04-29 06:59

Message:
Logged In: YES 
user_id=488897

This looks like a good idea to me. It will help to clean up
the "get" method in Queue.py, which now has:

                while self._empty():
                    remaining = endtime - _time()
                    if remaining <= 0.0:
                        raise Empty
                    self.not_empty.wait(remaining)

Here, self.not_empty is an object of the class
threading.Condition. It seems odd that first we wait for
self.not_empty.wait to return, and then have to check
self._empty(), even though self.not_empty.wait could have
told us directly if it was notified or it timed out.

I'll write a message to python-dev in support of this patch
(I'm a mere patch reviewer, not an official Python developer).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175933&group_id=5470
From noreply at sourceforge.net  Sat Apr 30 20:21:49 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 30 20:21:52 2005
Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency
	on Windows
Message-ID: <E1DRwb7-0004VO-9b@sc8-sf-web2.sourceforge.net>

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

Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michiel de Hoon (mdehoon)
>Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_InputHook inconsistency on Windows

Initial Comment:
PyOS_InputHook is a pointer to a function to be called
periodically when Python is idle. It is used, for
example, to get messages delivered to graphics windows.
If I compile Python from source (which uses
Modules/readline.c), PyOS_InputHook is called ten times
per second. However, with the Windows-version of
Python, PyOS_InputHook is called only once for each
command typed by the user. It seems that the problem
resides in Parser/myreadline.c (which I presume is used
for the Windows-version of Python):

if (PyOS_InputHook != NULL)
       (void)(PyOS_InputHook)();
...
p = fgets(buf, len, fp);

Python idles at "fgets", but PyOS_InputHook is not
being called while Python is idle.

The attached patch solves this problem by using the
"select" function, basically in the same way as what is
in Module/readline.c. I don't know how to compile
Python for Windows, so I wasn't able to test this patch.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-04-30 13:21

Message:
Logged In: YES 
user_id=149084

The revised patch looks ok to me.

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

Comment By: Michiel de Hoon (mdehoon)
Date: 2005-03-26 08:33

Message:
Logged In: YES 
user_id=488897

I have now tested this patch. After fixing one error (I had
forgotton to declare one variable), the patch works
correctly. I have uploaded a fixed patch.
Note that this bug occurs not only on Windows, but on any
Python compiled without readline. (which allowed me to test
this patch by compiling Python without readline support).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470
From noreply at sourceforge.net  Sat Apr 30 21:12:45 2005
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr 30 21:12:49 2005
Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to
	AST
Message-ID: <E1DRxOP-0001yA-Q6@sc8-sf-web3.sourceforge.net>

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

Category: Core (C code)
Group: AST
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Info Associated with Merge to AST

Initial Comment:
Attached file is the output of the merge from MAIN to ast-branch.
-j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC)
   (estimated time of first merge)
-j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC)

C Include/compile.h
C Include/symtable.h
C Lib/distutils/sysconfig.py
C Lib/test/test_compile.py   NOT MERGED
C Lib/test/output/test_profile
C Modules/main.c
C Objects/listobject.c
C Objects/tupleobject.c
C Python/bltinmodule.c
C Python/compile.c   NOT MERGED
C Python/future.c
C Python/pythonrun.c
C Python/symtable.c

Other conflicts resolved.



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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-04-30 14:12

Message:
Logged In: YES 
user_id=149084

logging package missing: That's a good question.
It was added after the AST branch was created and
didn't get tagged with the mrg_to_ast-branch_24APR03
tag for some reason....

Researching.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-26 01:22

Message:
Logged In: YES 
user_id=357491

Kurt, what happened to the logging package?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-04-24 21:05

Message:
Logged In: YES 
user_id=149084

The change to test_compile.py looks ok, probably
the best solution since there have been many
changes on MAIN.

There have been 11 updates to Python.c since the
merge from 5 Jan tag. The AST crew probably
should look at them so we don't get too far behind.

We will need to do another merge from MAIN at
some point.  Let me know.

Closing this Tracker item.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 17:06

Message:
Logged In: YES 
user_id=357491

rev. 1.10.10.4 has the checked-in copy.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 13:23

Message:
Logged In: YES 
user_id=357491

That was my plan.

And no need for the patch, logistix.  Easier for me to just
copy from release24-maint into ast-branch and check it in. 
Thanks for the offer, though.

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

Comment By: logistix (logistix)
Date: 2005-04-23 15:38

Message:
Logged In: YES 
user_id=699438

I took a look at test_compile to see how bad the conflicts
were and it doesn't look good.  On the ast-branch, it was
rewritten to use doctests.  On the main branch, it was
rewritten to use unittest.  So everything is out of whack
due to two completely differnent rewrites.

Other than that, I don't see any critical changes to either
branch.  I recommend that you just copy the test from the
main branch as-is (from the last mergepoint, not HEAD)
instead of trying to do a proper backport and merge.

I can generate a patch if you need it.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-04-19 00:08

Message:
Logged In: YES 
user_id=357491

test_compile should have been merged; tests that the
compiler is doing its job at the bytecode level, not
Python/compile.c directly.

Need to remember to backport changes at some point.

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

Comment By: logistix (logistix)
Date: 2005-04-03 17:03

Message:
Logged In: YES 
user_id=699438

This can probably be closed.  People have been developing 
off of the branch post-merge.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-07 01:32

Message:
Logged In: YES 
user_id=149084

Hm, file was a little too big.  bzip2 it, 10x compression

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

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