From noreply at sourceforge.net  Sun Oct  1 04:38:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 30 Sep 2006 19:38:31 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GTrDr-0000pP-BZ@sc8-sf-web6.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 13:19
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-09-30 22:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 17:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Sun Oct  1 04:40:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 30 Sep 2006 19:40:22 -0700
Subject: [ python-Bugs-1563981 ] IDLE invokes completion even when running code
Message-ID: <E1GTrFe-00011H-C2@sc8-sf-web6.sourceforge.net>

Bugs item #1563981, was opened at 2006-09-23 07:23
Message generated for change (Settings changed) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563981&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L?wis (loewis)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE invokes completion even when running code

Initial Comment:
When you do

raw_input()
A<tab>

instead of putting the tab character into the input
buffer, IDLE opens the completion window. It should not
do this, since the user is interacting with its
application, not with the Python interpreter at this point.

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

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

From noreply at sourceforge.net  Sun Oct  1 08:39:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 30 Sep 2006 23:39:46 -0700
Subject: [ python-Bugs-1567450 ] tabs missing in idle options configure
Message-ID: <E1GTuzK-0005mi-7T@sc8-sf-web3.sourceforge.net>

Bugs item #1567450, was opened at 2006-09-28 23:34
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567450&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: IDLE
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: jrgutierrez (jrgutierrez)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: tabs missing in idle options configure

Initial Comment:
1)The option to select indentation type (insert 
spaces or tabs) is missing
2) The indented width is ignored 

As a result IDLE 2.5 always indents inserting tabs, 
width 8

Sources edited in IDLE 2.4 cannot be corrected with 
IDLE 2.5:

The tabbing errors cannot be corrected with IDLE 2.5. 
You must revert to IDLE 2.4 


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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 02:39

Message:
Logged In: YES 
user_id=149084

See IDLE NEWS for 1.2a1.

The ability to configure tab insertion as a default
didn't work, and was removed.  You can set the default
by changing config-main.def:  [Indent] use-spaces=0
but Python policy is to strongly encourage spaces 
instead of tabs.

For any edit window, you can switch to tab indentation
by using the Format / Toggle Tabs menu selection.  When
using Tabs in an edit window, the indent width must be
eight spaces because of Tk limitations.

If a file uses tabs, you have to toggle tabs 'on' before
you start editing it.  IDLE doesn't yet have the ability to
detect whether a file uses tabs or spaces.  (A TAB indicator
in the status line would be useful.)

Note that Tabs are always used in the Shell window.

I'm not sure what you mean by "cannot be corrected".
The Format menu has Tabify and Untabify.  I suspect it
might be clearer if the dialog asking for 'tab width'
was changed to ask for 'indent width'.  I am able to
change back and forth between tabs and spaces in any
region, but it does take some care.

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

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

From noreply at sourceforge.net  Sun Oct  1 18:42:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 09:42:19 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GU4OR-0005OP-VV@sc8-sf-web1.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 12:19
Message generated for change (Comment added) made by jordanramz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 11:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-09-30 21:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 16:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Sun Oct  1 20:10:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 11:10:40 -0700
Subject: [ python-Bugs-1568842 ] Test for uintptr_t seems to be incorrect
Message-ID: <E1GU5lw-0006i3-5d@sc8-sf-web2.sourceforge.net>

Bugs item #1568842, was opened at 2006-10-01 20:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568842&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Test for uintptr_t seems to be incorrect

Initial Comment:

Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't 
defined in pyconfig.h while it should have been defined. I'm looking into 
this and am now wondering whether the configure snipped below is 
correct:

AC_MSG_CHECKING(for uintptr_t support)
have_uintptr_t=no
AC_TRY_COMPILE([], [uintptr_t x; x = (uintptr_t)0;], [
  AC_DEFINE(HAVE_UINTPTR_T, 1, [Define this if you have the type 
uintptr_t.])
  have_uintptr_t=yes
])
AC_MSG_RESULT($have_uintptr_t)
if test "$have_uintptr_t" = yes ; then
AC_CHECK_SIZEOF(uintptr_t, 4)
fi

This seems to check for uintptr_t as a builtin type. Isn't one supposed to 
include <stdint.h> to get this type?

Chaning the AC_TRY_COMPILE line to the line below fixes the issue for me 
on OSX and Linux:

AC_TRY_COMPILE([#include <stdint.h>], [uintptr_t x; x = (uintptr_t)0;], [


BTW. This issue is also present in Python 2.4.

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

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

From noreply at sourceforge.net  Sun Oct  1 23:08:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 14:08:05 -0700
Subject: [ python-Bugs-1568897 ] http redirect does not pass 'post' data
Message-ID: <E1GU8Xd-00077a-DL@sc8-sf-web2.sourceforge.net>

Bugs item #1568897, was opened at 2006-10-02 10:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: hans_moleman (hans_moleman)
Assigned to: Nobody/Anonymous (nobody)
Summary: http redirect does not pass 'post' data

Initial Comment:
A HTTP(S) redirect does not pass POST 'data'.

Currently:
If a redirect is required, a new Request is created
with a URL that the redirect response has provided.
This new Request has the original headers.

Required:
For the new Request the data too will be copied from
the original Request.

I believe the following one line change is required in
'urllib2.HTTPRedirectHandler.redirect_request':

<code>
return Request(url     = newurl,
               headers = req.headers,
               data    = req.data,
               ...
</code>

Environment: Linux
Python 2.5

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

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

From noreply at sourceforge.net  Sun Oct  1 23:17:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 14:17:31 -0700
Subject: [ python-Bugs-1562716 ] Spurious Tabnanny error
Message-ID: <E1GU8gl-0007LU-Nt@sc8-sf-web4.sourceforge.net>

Bugs item #1562716, was opened at 2006-09-21 04:23
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562716&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: torhu (torhu)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Spurious Tabnanny error

Initial Comment:
IDLE 1.2, Py 2.5 on WinXP SP2.

The extra parenthesis on the second line triggers a
warning message box:

"Tabnanny Tokenizing Error"
"Token Error: EOF in multi-line statement"

for i in range(10):
        a = list("123"))


The second line is indented with 8 or 4 spaces, doesn't
matter which.

Can't recall this happening in the IDLE version bundled
with py2.4.  Don't know if IDLE or the tabnanny module
is the culprit.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 17:17

Message:
Logged In: YES 
user_id=149084

Problem is with the tokenize module.

A pre-run tabnanny check was added to 2.5. 

I've corrected this by doing the syntax check first.

Rev 52083

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

Comment By: torhu (torhu)
Date: 2006-09-21 04:25

Message:
Logged In: YES 
user_id=1038085

I also had somone on #python confirm this behavior for me.

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

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

From noreply at sourceforge.net  Sun Oct  1 23:19:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 14:19:23 -0700
Subject: [ python-Bugs-1562719 ] Spurious Tab/space error
Message-ID: <E1GU8iZ-0007Y2-Eu@sc8-sf-web4.sourceforge.net>

Bugs item #1562719, was opened at 2006-09-21 04:29
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562719&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: torhu (torhu)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Spurious Tab/space error

Initial Comment:
IDLE 1.2, Py 2.5 on WinXP SP2.

The extra parenthesis on the second line triggers a
warning message box:

"Tab/space error"
"Error: Inconsistent indentation detected!"
Etc.


for i in range(10):
        a = list("123"))
x = 5

The second line is indented with 8 spaces.

Can't recall this happening in the IDLE version bundled
with py2.4.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 17:19

Message:
Logged In: YES 
user_id=149084

see 1562716

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

Comment By: torhu (torhu)
Date: 2006-09-21 04:30

Message:
Logged In: YES 
user_id=1038085

I also had somone on #python confirm this.

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

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

From noreply at sourceforge.net  Mon Oct  2 00:23:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 15:23:25 -0700
Subject: [ python-Bugs-779460 ] plistlib should be moved out of plat-mac
Message-ID: <E1GU9iX-0004s4-Sm@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Sarwat Khan (sarwatfoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: plistlib should be moved out of plat-mac

Initial Comment:
plistlib doesn't (I think, it shouldn't anyway) have any Mac 
dependancies and should be moved out of plat-mac so 
plists can be generated and parsed on non-Mac platforms. 

I intend to use it, for example, on a Linux web server in 
CGI scripts for basic XML handling.


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-01 22:23

Message:
Logged In: YES 
user_id=849994

Duplicate of #1565129.

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

Comment By: Guido Guenther (guidog)
Date: 2006-09-13 13:12

Message:
Logged In: YES 
user_id=696207

Can this be done for python 2.5 please. It's need to run
apple's caldav server on e.g. Linux.

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

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

From noreply at sourceforge.net  Mon Oct  2 04:20:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 1 Oct 2006 19:20:09 -0700
Subject: [ python-Bugs-1552935 ] Pythonw doesn't get rebuilt if version number
	changes
Message-ID: <200610020220.k922K9ZV009346@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1552935, was opened at 2006-09-05 12:37
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552935&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.6
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Pythonw doesn't get rebuilt if version number changes

Initial Comment:
If the Python version number changes (as it did this week) Mac/pythonw 
should get rebuilt so it fires up the correct real Python executable.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-01 19:20

Message:
Logged In: YES 
user_id=1312539

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

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-17 12:23

Message:
Logged In: YES 
user_id=580910

This should be fixed in revision 51904.

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

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

Message:
Logged In: YES 
user_id=580910

pythonw should depend on the Makefile and the Makefile should be automaticly 
rebuild when config.status changes (just like the toplevel Makefile).

I'll check in a patch this weekend, I need to test before I do the checkin.

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

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

From noreply at sourceforge.net  Mon Oct  2 05:23:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 20:23:55 -0700
Subject: [ python-Bugs-1565797 ] 'all' documentation missing online
Message-ID: <E1GUEPL-0001Mm-HJ@sc8-sf-web2.sourceforge.net>

Bugs item #1565797, was opened at 2006-09-26 10:21
Message generated for change (Comment added) made by aisaac0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'all' documentation missing online

Initial Comment:
http://docs.python.org/lib/built-in-funcs.html
is missing a description of the new built-in 'all'
function.


On a separate note, contrary to the statement on the
bugs page, the search dialogue is not in the left
margin ...

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

>Comment By: Alan (aisaac0)
Date: 2006-10-01 22:23

Message:
Logged In: YES 
user_id=1025672

For reasons unknown to me my browser was displaying a cached
version of the Built-In Functions page.  Very sorry for the
noise.

As for the other matter: the page is
http://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470
where the first full line of text is
"Please try to see if the bug you are about to submit hasn't
already been submitted before. The search box in the left
margin can be used for this purpose."

But the search box is above this text, to the right.

fwiw

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

Comment By: Martin v. L?wis (loewis)
Date: 2006-09-26 11:06

Message:
Logged In: YES 
user_id=21627

Could it be that you had been looking at an old version of
the documentation (the new version wasn't online shortly
after the release). I can clearly see 'all' documented as 

all(  	iterable)
    Return True if all elements of the iterable are true.
Equivalent to:
  ...

As for the separate note: what bugs page are you referring to?

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

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

From noreply at sourceforge.net  Mon Oct  2 06:49:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 21:49:37 -0700
Subject: [ python-Bugs-1569057 ] Using .next() on file open in write mode
	writes junk to file
Message-ID: <E1GUFkH-00007l-1M@sc8-sf-web1.sourceforge.net>

Bugs item #1569057, was opened at 2006-10-01 23:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using .next() on file open in write mode writes junk to file

Initial Comment:
When you open a file in write mode and use .next(), it 
prints an error and writes many lines of junk to file. 
I tested on windows and python 2.5:

>>> f = open('test', 'w') 
>>> f.fileno() 
4 
>>> f.write('1\n') 
>>> f.write('2\n3\n4\n') 
>>> f.next() 


Traceback (most recent call last): 
  File "<pyshell#8>", line 1, in <module> 
    f.next() 
IOError: [Errno 9] Bad file descriptor 

>>> f.close() 
>>> f = open('test') 
>>> f.next() 
'1\n' 
>>> f.next() 
'2\n' 
>>> f.next() 
'3\n' 
>>> f.next() 
'4\n' 
>>> f.next() 


'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x?
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\?
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00 
...many more lines of junk...'



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

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

From noreply at sourceforge.net  Mon Oct  2 08:42:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Oct 2006 23:42:21 -0700
Subject: [ python-Bugs-1569084 ] External codecs no longer usable
Message-ID: <E1GUHVN-0004GB-W9@sc8-sf-web6.sourceforge.net>

Bugs item #1569084, was opened at 2006-10-02 08:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569084&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: M.-A. Lemburg (lemburg)
Summary: External codecs no longer usable

Initial Comment:
Up to Python 2.5, external codec packages could be used
just by dropping them somewhere in the $PYTHONPATH, as
long as they provided a ``getregentry()`` function and
the normalised encoding name matched the name of the
package.  For instance, having a ``myencoding`` package
with a ``getregentry()`` function in it made possible
executing::

    >>> u'something'.encode('myencoding')

without even importing ``myencoding``.  It was the
``__import__(modname, ...)`` statement in
``encodings.search_function()`` which made this possible.

However, in Python 2.5 the previous statement was
changed to the absolute one ``__import('encodings.' +
modname, ...)``, which makes external codec packages no
longer reachable in the way described above.  Is this a
bug, or has this been made on purpose?  In the later
case, what do you recommend to use external codecs as
transparently as possible?  I now manually enter the
registry tuple/CodecInfo into the encodings cache, but
tampering with it doesn't seem right (and it also means
that some initialisation code must be explicitly run).

By the way, this bug may be related with #223642. 
Maybe it should be reopened.

Thank you very much!

(I know, I should have checked the betas and release
candidates in case this was a bug.  I didn't have the
time, sorry!)

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

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

From noreply at sourceforge.net  Mon Oct  2 10:43:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 01:43:54 -0700
Subject: [ python-Bugs-1569084 ] External codecs no longer usable
Message-ID: <E1GUJP0-00060m-Ja@sc8-sf-web1.sourceforge.net>

Bugs item #1569084, was opened at 2006-10-02 08:42
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569084&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: M.-A. Lemburg (lemburg)
Summary: External codecs no longer usable

Initial Comment:
Up to Python 2.5, external codec packages could be used
just by dropping them somewhere in the $PYTHONPATH, as
long as they provided a ``getregentry()`` function and
the normalised encoding name matched the name of the
package.  For instance, having a ``myencoding`` package
with a ``getregentry()`` function in it made possible
executing::

    >>> u'something'.encode('myencoding')

without even importing ``myencoding``.  It was the
``__import__(modname, ...)`` statement in
``encodings.search_function()`` which made this possible.

However, in Python 2.5 the previous statement was
changed to the absolute one ``__import('encodings.' +
modname, ...)``, which makes external codec packages no
longer reachable in the way described above.  Is this a
bug, or has this been made on purpose?  In the later
case, what do you recommend to use external codecs as
transparently as possible?  I now manually enter the
registry tuple/CodecInfo into the encodings cache, but
tampering with it doesn't seem right (and it also means
that some initialisation code must be explicitly run).

By the way, this bug may be related with #223642. 
Maybe it should be reopened.

Thank you very much!

(I know, I should have checked the betas and release
candidates in case this was a bug.  I didn't have the
time, sorry!)

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-10-02 10:43

Message:
Logged In: YES 
user_id=38388

The encodings package codec search function was never
intended to be used by codecs other than the encodings package.

The 'encodings.' part for the module name was added to
prevent importing arbitrary modules as a result of looking
up a codec that's not defined in the encodings package which
could result in a security problem.

If you want to use your own codecs, please register a codec
search function with the codecs module first. It is
recommended to place the codecs into a package of its own -
again to prevent accidental import of non-codec modules.

See http://docs.python.org/lib/module-codecs.html for details.


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

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

From noreply at sourceforge.net  Mon Oct  2 11:14:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 02:14:52 -0700
Subject: [ python-Bugs-1568897 ] http redirect does not pass 'post' data
Message-ID: <E1GUJsy-0001gi-Vo@sc8-sf-web2.sourceforge.net>

Bugs item #1568897, was opened at 2006-10-01 23:08
Message generated for change (Comment added) made by calvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: hans_moleman (hans_moleman)
Assigned to: Nobody/Anonymous (nobody)
Summary: http redirect does not pass 'post' data

Initial Comment:
A HTTP(S) redirect does not pass POST 'data'.

Currently:
If a redirect is required, a new Request is created
with a URL that the redirect response has provided.
This new Request has the original headers.

Required:
For the new Request the data too will be copied from
the original Request.

I believe the following one line change is required in
'urllib2.HTTPRedirectHandler.redirect_request':

<code>
return Request(url     = newurl,
               headers = req.headers,
               data    = req.data,
               ...
</code>

Environment: Linux
Python 2.5

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

Comment By: Wummel (calvin)
Date: 2006-10-02 11:14

Message:
Logged In: YES 
user_id=9205

Automatic redirects are only allowed for GET and HEAD[1].
Sending POST data automatically to other hosts than the
original one is a security flaw.
[1]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

So I think the current behaviour of urllib2 is correct, and
should not be changed.

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

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

From noreply at sourceforge.net  Mon Oct  2 16:00:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 07:00:07 -0700
Subject: [ python-Bugs-1568243 ] init_types
Message-ID: <E1GUOL1-0004ur-IY@sc8-sf-web6.sourceforge.net>

Bugs item #1568243, was opened at 2006-09-30 11:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Bosko Vukov (bvukov)
Assigned to: Martin v. L?wis (loewis)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) ....
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 16:00

Message:
Logged In: YES 
user_id=21627

Notice that the PCbuild8 directory isn't really supported...

In any case, the bug is that PCbuild8 does not have the
reference to _typesmodule, not that init_types in
Python-ast.c is static.

If you revert your change to Python-ast.c, and change
pythoncore.vcproj, it should build fine.

This is already fixed in r51751 in the trunk; not sure
whether backporting it is necessary.


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

Comment By: Bosko Vukov (bvukov)
Date: 2006-09-30 19:50

Message:
Logged In: YES 
user_id=1292849

I opened solution file from folder PCbuild8, and inside
project file pythoncore.vcproj there is no reference to
_typesmodule.c. It exists in pythoncore.vcproj in the
PBbuild folder ( for older version's ). I added the missing
_typesmodule.c inside, and returned back the changes I made,
and aft er that linker reported 'Python-ast.obj : error
LNK2005: _init_types already defined in _typesmodule.obj'

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 13:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

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

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

From noreply at sourceforge.net  Mon Oct  2 16:12:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 07:12:40 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GUOXA-0007mb-Qu@sc8-sf-web3.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 17:19
Message generated for change (Comment added) made by daniboy22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

>Comment By: dani (daniboy22)
Date: 2006-10-02 14:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 16:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 02:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 21:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Mon Oct  2 16:13:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 07:13:49 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GUOYH-0007sp-3j@sc8-sf-web3.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 17:19
Message generated for change (Comment added) made by daniboy22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

>Comment By: dani (daniboy22)
Date: 2006-10-02 14:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 14:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 16:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 02:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 21:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Mon Oct  2 16:26:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 07:26:48 -0700
Subject: [ python-Bugs-1565797 ] 'all' documentation missing online
Message-ID: <E1GUOkq-00060G-NJ@sc8-sf-web1.sourceforge.net>

Bugs item #1565797, was opened at 2006-09-26 17:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Alan (aisaac0)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'all' documentation missing online

Initial Comment:
http://docs.python.org/lib/built-in-funcs.html
is missing a description of the new built-in 'all'
function.


On a separate note, contrary to the statement on the
bugs page, the search dialogue is not in the left
margin ...

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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 16:26

Message:
Logged In: YES 
user_id=21627

Thanks for the update; the text on the SF bug submission
page is now fixed.

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

Comment By: Alan (aisaac0)
Date: 2006-10-02 05:23

Message:
Logged In: YES 
user_id=1025672

For reasons unknown to me my browser was displaying a cached
version of the Built-In Functions page.  Very sorry for the
noise.

As for the other matter: the page is
http://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470
where the first full line of text is
"Please try to see if the bug you are about to submit hasn't
already been submitted before. The search box in the left
margin can be used for this purpose."

But the search box is above this text, to the right.

fwiw

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

Comment By: Martin v. L?wis (loewis)
Date: 2006-09-26 18:06

Message:
Logged In: YES 
user_id=21627

Could it be that you had been looking at an old version of
the documentation (the new version wasn't online shortly
after the release). I can clearly see 'all' documented as 

all(  	iterable)
    Return True if all elements of the iterable are true.
Equivalent to:
  ...

As for the separate note: what bugs page are you referring to?

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

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

From noreply at sourceforge.net  Mon Oct  2 16:57:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 07:57:48 -0700
Subject: [ python-Bugs-1568842 ] Test for uintptr_t seems to be incorrect
Message-ID: <E1GUPEq-0000bG-J1@sc8-sf-web1.sourceforge.net>

Bugs item #1568842, was opened at 2006-10-01 20:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568842&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Test for uintptr_t seems to be incorrect

Initial Comment:

Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't 
defined in pyconfig.h while it should have been defined. I'm looking into 
this and am now wondering whether the configure snipped below is 
correct:

AC_MSG_CHECKING(for uintptr_t support)
have_uintptr_t=no
AC_TRY_COMPILE([], [uintptr_t x; x = (uintptr_t)0;], [
  AC_DEFINE(HAVE_UINTPTR_T, 1, [Define this if you have the type 
uintptr_t.])
  have_uintptr_t=yes
])
AC_MSG_RESULT($have_uintptr_t)
if test "$have_uintptr_t" = yes ; then
AC_CHECK_SIZEOF(uintptr_t, 4)
fi

This seems to check for uintptr_t as a builtin type. Isn't one supposed to 
include <stdint.h> to get this type?

Chaning the AC_TRY_COMPILE line to the line below fixes the issue for me 
on OSX and Linux:

AC_TRY_COMPILE([#include <stdint.h>], [uintptr_t x; x = (uintptr_t)0;], [


BTW. This issue is also present in Python 2.4.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 16:57

Message:
Logged In: YES 
user_id=21627

Thanks for the report. fixed in r52086, 52087, 52088.

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

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

From noreply at sourceforge.net  Mon Oct  2 17:06:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 08:06:58 -0700
Subject: [ python-Bugs-1568429 ] broken info files generation
Message-ID: <E1GUPNi-0002Mp-5K@sc8-sf-web2.sourceforge.net>

Bugs item #1568429, was opened at 2006-09-30 20:49
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568429&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Arkadiusz Miskiewicz (arekm)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken info files generation

Initial Comment:
Hi,

Currently make -C Doc/info will not work. There are bugs 
in *.tex files which prevent py2texinfo from working. 
Also even after fixing these there are some weird 
constructs which later make makeinfo go mad.

Take a look at
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/python-
info.patch
which has some fixes for that.

This one is important:
-    level=1\optional{, parent\optional\{, 
directory\optional{,
-    attributes=0}}}}
+    level=1\optional{, parent\optional{, 
directory\optional{,
+    attributes=0}}}}}


- unmatched {} + one wrongly quoted {

The other thing is using quote enviroment which is 
unknown to py2texinfo - change it to quotation.



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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 17:06

Message:
Logged In: YES 
user_id=21627

Can you please attach your proposed change as an "svn diff"
for the version you are referring to?

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

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

From noreply at sourceforge.net  Mon Oct  2 17:08:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 08:08:01 -0700
Subject: [ python-Bugs-1568897 ] http redirect does not pass 'post' data
Message-ID: <E1GUPOj-0002TE-Fw@sc8-sf-web2.sourceforge.net>

Bugs item #1568897, was opened at 2006-10-01 23:08
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: hans_moleman (hans_moleman)
Assigned to: Nobody/Anonymous (nobody)
Summary: http redirect does not pass 'post' data

Initial Comment:
A HTTP(S) redirect does not pass POST 'data'.

Currently:
If a redirect is required, a new Request is created
with a URL that the redirect response has provided.
This new Request has the original headers.

Required:
For the new Request the data too will be copied from
the original Request.

I believe the following one line change is required in
'urllib2.HTTPRedirectHandler.redirect_request':

<code>
return Request(url     = newurl,
               headers = req.headers,
               data    = req.data,
               ...
</code>

Environment: Linux
Python 2.5

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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 17:08

Message:
Logged In: YES 
user_id=21627

I agree with calvin; this is not a bug.

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

Comment By: Wummel (calvin)
Date: 2006-10-02 11:14

Message:
Logged In: YES 
user_id=9205

Automatic redirects are only allowed for GET and HEAD[1].
Sending POST data automatically to other hosts than the
original one is a security flaw.
[1]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

So I think the current behaviour of urllib2 is correct, and
should not be changed.

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

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

From noreply at sourceforge.net  Mon Oct  2 17:26:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 08:26:21 -0700
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GUPgT-0006aM-NP@sc8-sf-web3.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

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

From noreply at sourceforge.net  Mon Oct  2 17:48:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 08:48:31 -0700
Subject: [ python-Bugs-1569374 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GUQ1v-00076V-7Z@sc8-sf-web6.sourceforge.net>

Bugs item #1569374, was opened at 2006-10-02 11:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

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

From noreply at sourceforge.net  Mon Oct  2 17:49:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 08:49:12 -0700
Subject: [ python-Bugs-1569374 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GUQ2a-0000Mz-Ua@sc8-sf-web3.sourceforge.net>

Bugs item #1569374, was opened at 2006-10-02 11:48
Message generated for change (Settings changed) made by scott_marks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
>Resolution: Duplicate
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

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

From noreply at sourceforge.net  Mon Oct  2 17:57:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 08:57:14 -0700
Subject: [ python-Bugs-1569374 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GUQAM-0005z1-0q@sc8-sf-web4.sourceforge.net>

Bugs item #1569374, was opened at 2006-10-02 11:48
Message generated for change (Comment added) made by scott_marks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

>Comment By: applebucks (scott_marks)
Date: 2006-10-02 11:57

Message:
Logged In: YES 
user_id=120857

Please ignore this refresh-button-generated duplicate.

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

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

From noreply at sourceforge.net  Mon Oct  2 18:02:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 09:02:21 -0700
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GUQFJ-0007qR-AN@sc8-sf-web2.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by scott_marks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

>Comment By: applebucks (scott_marks)
Date: 2006-10-02 12:02

Message:
Logged In: YES 
user_id=120857

This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation.  The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.

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

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

From noreply at sourceforge.net  Mon Oct  2 18:21:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 09:21:51 -0700
Subject: [ python-Bugs-1569374 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GUQYB-0001I6-7b@sc8-sf-web2.sourceforge.net>

Bugs item #1569374, was opened at 2006-10-02 15:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

Comment By: applebucks (scott_marks)
Date: 2006-10-02 15:57

Message:
Logged In: YES 
user_id=120857

Please ignore this refresh-button-generated duplicate.

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

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

From noreply at sourceforge.net  Mon Oct  2 20:28:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 11:28:25 -0700
Subject: [ python-Bugs-1568243 ] init_types
Message-ID: <E1GUSWf-0005EO-DN@sc8-sf-web2.sourceforge.net>

Bugs item #1568243, was opened at 2006-09-30 09:34
Message generated for change (Comment added) made by coatimundi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Bosko Vukov (bvukov)
Assigned to: Martin v. L?wis (loewis)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) ....
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 18:28

Message:
Logged In: YES 
user_id=1611513

I am expereincing the problem described by the original
poster.  I undertand that MSVC8 is not officially supported,
and I'm trying anyway.

I downloaded the 2.5.0 final tarball and began working in
the PCbuild8 directory.

Firts off, I found that I had to build two projects before
pythoncore would build: 

  make_versioninfo
  make_buildinfo

When I tried to build pythoncore, I got the linker error
saying that _init_types could not be found.  So I added
_typesmodule.c to the pythoncore project.  Finally,
pythoncore built cleanly.

Next up, I wanted to build pythoncore_pgo.  So I added 
_typesmodule to this project also.  But try as I might,
every attempt to build pythoncore_pgo produces the link
error on _init_types.  (I also did a 'clean' on pythoncore
just to be safe.)

I do not understand this.  Unlike the original poster, I
have not modified any source.  It seems like the definition
of pyMODINIT_FUNC as extern "C" void might be involved, but
I agree with gbrandl that the static int in Python-ast.c is
not the issue, because that is a different scope.  

So the linkage problem with pythoncore_pgo remains a mystery
to me.  I hope someone has more clues than me.



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

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 14:00

Message:
Logged In: YES 
user_id=21627

Notice that the PCbuild8 directory isn't really supported...

In any case, the bug is that PCbuild8 does not have the
reference to _typesmodule, not that init_types in
Python-ast.c is static.

If you revert your change to Python-ast.c, and change
pythoncore.vcproj, it should build fine.

This is already fixed in r51751 in the trunk; not sure
whether backporting it is necessary.


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

Comment By: Bosko Vukov (bvukov)
Date: 2006-09-30 17:50

Message:
Logged In: YES 
user_id=1292849

I opened solution file from folder PCbuild8, and inside
project file pythoncore.vcproj there is no reference to
_typesmodule.c. It exists in pythoncore.vcproj in the
PBbuild folder ( for older version's ). I added the missing
_typesmodule.c inside, and returned back the changes I made,
and aft er that linker reported 'Python-ast.obj : error
LNK2005: _init_types already defined in _typesmodule.obj'

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

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

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

From noreply at sourceforge.net  Mon Oct  2 21:08:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 12:08:32 -0700
Subject: [ python-Bugs-1568243 ] init_types
Message-ID: <E1GUT9U-0008Qj-7T@sc8-sf-web1.sourceforge.net>

Bugs item #1568243, was opened at 2006-09-30 11:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Bosko Vukov (bvukov)
Assigned to: Martin v. L?wis (loewis)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) ....
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 21:08

Message:
Logged In: YES 
user_id=21627

I think you should avoid building pythoncore_pgo; it's of no
use. 

Or else, study all documentation you can find on Microsoft's
profile-guided-optimization for a few days, read all web
logs about the bugs in this software, and perhaps you can
succeed in building it, by deleting the right files in the
right order.

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 20:28

Message:
Logged In: YES 
user_id=1611513

I am expereincing the problem described by the original
poster.  I undertand that MSVC8 is not officially supported,
and I'm trying anyway.

I downloaded the 2.5.0 final tarball and began working in
the PCbuild8 directory.

Firts off, I found that I had to build two projects before
pythoncore would build: 

  make_versioninfo
  make_buildinfo

When I tried to build pythoncore, I got the linker error
saying that _init_types could not be found.  So I added
_typesmodule.c to the pythoncore project.  Finally,
pythoncore built cleanly.

Next up, I wanted to build pythoncore_pgo.  So I added 
_typesmodule to this project also.  But try as I might,
every attempt to build pythoncore_pgo produces the link
error on _init_types.  (I also did a 'clean' on pythoncore
just to be safe.)

I do not understand this.  Unlike the original poster, I
have not modified any source.  It seems like the definition
of pyMODINIT_FUNC as extern "C" void might be involved, but
I agree with gbrandl that the static int in Python-ast.c is
not the issue, because that is a different scope.  

So the linkage problem with pythoncore_pgo remains a mystery
to me.  I hope someone has more clues than me.



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

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 16:00

Message:
Logged In: YES 
user_id=21627

Notice that the PCbuild8 directory isn't really supported...

In any case, the bug is that PCbuild8 does not have the
reference to _typesmodule, not that init_types in
Python-ast.c is static.

If you revert your change to Python-ast.c, and change
pythoncore.vcproj, it should build fine.

This is already fixed in r51751 in the trunk; not sure
whether backporting it is necessary.


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

Comment By: Bosko Vukov (bvukov)
Date: 2006-09-30 19:50

Message:
Logged In: YES 
user_id=1292849

I opened solution file from folder PCbuild8, and inside
project file pythoncore.vcproj there is no reference to
_typesmodule.c. It exists in pythoncore.vcproj in the
PBbuild folder ( for older version's ). I added the missing
_typesmodule.c inside, and returned back the changes I made,
and aft er that linker reported 'Python-ast.obj : error
LNK2005: _init_types already defined in _typesmodule.obj'

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 13:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

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

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

From noreply at sourceforge.net  Mon Oct  2 21:10:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 12:10:21 -0700
Subject: [ python-Bugs-1567910 ] missing _typesmodule.c,
	Visual Studio 2005 pythoncore.vcproj
Message-ID: <E1GUTBF-0000B6-5e@sc8-sf-web1.sourceforge.net>

Bugs item #1567910, was opened at 2006-09-29 19:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: everbruin (everbruin)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing _typesmodule.c,Visual Studio 2005 pythoncore.vcproj

Initial Comment:
Python 2.5's Visual Studio 2005 pythoncore.vcproj (in
PCBuild8 folder) is missing Modules/_typesmodule.c
(note the VS 2003 pythoncore.vcproj in PCBuild
correctly has it).

The bug is that binaries built w/o the file will give a
SystemError when "import _types" is done (eg by types.py).

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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 21:10

Message:
Logged In: YES 
user_id=21627

I find it hard to believe that you get this precise error; I
would have expected that the pythoncore project would fail
to build instead.

Notice that PCbuild8 is not really supported.

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

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

From noreply at sourceforge.net  Mon Oct  2 21:22:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 12:22:35 -0700
Subject: [ python-Bugs-1568243 ] init_types
Message-ID: <E1GUTN5-0001NM-BU@sc8-sf-web1.sourceforge.net>

Bugs item #1568243, was opened at 2006-09-30 09:34
Message generated for change (Comment added) made by coatimundi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Bosko Vukov (bvukov)
Assigned to: Martin v. L?wis (loewis)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) ....
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 19:22

Message:
Logged In: YES 
user_id=1611513

Thanks, loewis.  I take your advice.  

I see that things have changed in SVN anyway.  I like the
new approach of using Visual STudio's configuration
management.  

When I (try to) build PGIRelease to instrument the python
dll, I get a curious error:

1>Compiling...
1>zlibmodule.c
1>Compiling resources...
1>Linking...
1>   Creating library
Win32\PGIRelease\pythoncore/python26.lib and object
Win32\PGIRelease\pythoncore/python26.exp
1>Generating code
1>c:\Documents and Settings\kferrio\My
Documents\Dev\Python-2.5\Modules\zipimport.c : fatal error
C1350: error loading dll 'pgodb80.dll': dll not found
1>LINK : fatal error LNK1257: code generation failed
1>Build log was saved at "file://c:\Documents and
Settings\kferrio\My
Documents\Dev\Python-2.5\PCbuild8\Win32\PGIRelease\pythoncore\BuildLog.htm"
1>pythoncore - 2 error(s), 2 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0
skipped ==========

I definitely do not understand this -- yet.  Meanwhile, any
clues would be welcome.

Thanks.

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

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

Message:
Logged In: YES 
user_id=21627

I think you should avoid building pythoncore_pgo; it's of no
use. 

Or else, study all documentation you can find on Microsoft's
profile-guided-optimization for a few days, read all web
logs about the bugs in this software, and perhaps you can
succeed in building it, by deleting the right files in the
right order.

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 18:28

Message:
Logged In: YES 
user_id=1611513

I am expereincing the problem described by the original
poster.  I undertand that MSVC8 is not officially supported,
and I'm trying anyway.

I downloaded the 2.5.0 final tarball and began working in
the PCbuild8 directory.

Firts off, I found that I had to build two projects before
pythoncore would build: 

  make_versioninfo
  make_buildinfo

When I tried to build pythoncore, I got the linker error
saying that _init_types could not be found.  So I added
_typesmodule.c to the pythoncore project.  Finally,
pythoncore built cleanly.

Next up, I wanted to build pythoncore_pgo.  So I added 
_typesmodule to this project also.  But try as I might,
every attempt to build pythoncore_pgo produces the link
error on _init_types.  (I also did a 'clean' on pythoncore
just to be safe.)

I do not understand this.  Unlike the original poster, I
have not modified any source.  It seems like the definition
of pyMODINIT_FUNC as extern "C" void might be involved, but
I agree with gbrandl that the static int in Python-ast.c is
not the issue, because that is a different scope.  

So the linkage problem with pythoncore_pgo remains a mystery
to me.  I hope someone has more clues than me.



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

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-02 14:00

Message:
Logged In: YES 
user_id=21627

Notice that the PCbuild8 directory isn't really supported...

In any case, the bug is that PCbuild8 does not have the
reference to _typesmodule, not that init_types in
Python-ast.c is static.

If you revert your change to Python-ast.c, and change
pythoncore.vcproj, it should build fine.

This is already fixed in r51751 in the trunk; not sure
whether backporting it is necessary.


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

Comment By: Bosko Vukov (bvukov)
Date: 2006-09-30 17:50

Message:
Logged In: YES 
user_id=1292849

I opened solution file from folder PCbuild8, and inside
project file pythoncore.vcproj there is no reference to
_typesmodule.c. It exists in pythoncore.vcproj in the
PBbuild folder ( for older version's ). I added the missing
_typesmodule.c inside, and returned back the changes I made,
and aft er that linker reported 'Python-ast.obj : error
LNK2005: _init_types already defined in _typesmodule.obj'

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

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

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

From noreply at sourceforge.net  Mon Oct  2 21:54:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 12:54:46 -0700
Subject: [ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Message-ID: <E1GUTsE-0002Pu-VA@sc8-sf-web5.sourceforge.net>

Bugs item #1569517, was opened at 2006-10-02 19:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Coatimundi (coatimundi)
Assigned to: Nobody/Anonymous (nobody)
Summary: PGIRelease linkage fails on pgodb80.dll

Initial Comment:
Hi.  I'm interested in learning how to optimize Python
for Windows.  I have made a similar report as a
follow-on to Bug 1568243, but it's really a  separate
issue.

Let me emphasize that what I am about to describe this
is *not* a bug in the Python build system.  But it may
be worth calling out in the README file for PCbuild8.

When building PGIRelease to instrument the pythoncore
DLL, the linker fails because it cannot find
pgodb80.dll.  This file is required for PGO with Visual
C++ under Visual Studio 2005 and is shipped with the
Professional version, but not with the Express version
or (apparently) the Standard version I have.  Looks
like upgrade time...

I hope this helps someone else.


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

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

From noreply at sourceforge.net  Mon Oct  2 23:48:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 14:48:24 -0700
Subject: [ python-Bugs-1232947 ] non-admin install may fail (win xp pro)
Message-ID: <E1GUVeC-0003Fx-ND@sc8-sf-web5.sourceforge.net>

Bugs item #1232947, was opened at 2005-07-05 20:31
Message generated for change (Comment added) made by pvrijlandt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Vrijlandt (pvrijlandt)
Assigned to: Martin v. L?wis (loewis)
Summary: non-admin install may fail (win xp pro)

Initial Comment:
concerns: python 2.4.1 msi

When trying to do a non-admin install on Windows XP 
Pro, the installer probably tries to make shortcuts in a 
non-accessible directory.

The status-window is displaying: creating shortcuts

A messagebox appears and says the installer lacks 
priveliges on a certain directory: please try again as an 
administrator, (which i am obviously not).

The cancel-option now leads to a rollback of the 
installation.

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

>Comment By: Patrick Vrijlandt (pvrijlandt)
Date: 2006-10-02 23:48

Message:
Logged In: YES 
user_id=1307917

This bug still exists with 2.5

As a workaround, I found out that I could install for all 
users.

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

Comment By: Patrick Vrijlandt (pvrijlandt)
Date: 2005-08-11 21:14

Message:
Logged In: YES 
user_id=1307917

These are difficult questions for me.
I don't know if my ACL (access control list?) is on that folder.

I'm almost certain the sysadmins did this for us. They try to 
get as much userfiles as possible on the network. They are 
also pretty restrictive (and understaffed) Backup is done only 
for network drives. The advantage is that I can access my 
user files from different computers (without using a server OS)

My start menu is almost empty. All programs we are able to 
use, are accessible through a shortcut on the desktop. I 
probably can read the startmenu folder but not write it. 

"My documents" refers to a networked directory. I have full 
access there and can run programs from there.

I suppose a patch would be to make more configuration 
options in the installer (Do you want to make shortcuts? Do 
you want to make them here?). I would make shortcuts on 
my desktop. (Yes, I can write there. Files sometimes go to 
c:\windows\desktop, and sometimes to a networked drive)

What would be needed to run python (and pythonwin) from a 
memory-stick or cd-rom? If that would work, my problem 
would be solved too. Even better: one installation would make 
python accessible from any computer on our network I would 
login to.

BTW: some drives (like C:) are hidden from explorer. I cannot 
do start -> run (but I can make a shortcut to cmd on my 
desktop, and run from there). I'm not sure I can get to regedit 
and/or do anything useful there.

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

Comment By: Patrick Vrijlandt (pvrijlandt)
Date: 2005-08-11 21:11

Message:
Logged In: YES 
user_id=1307917

These are difficult questions for me.
I don't know if my ACL (access control list?) is on that folder.

I'm almost certain the sysadmins did this for us. They try to 
get as much userfiles as possible on the network. They are 
also pretty restrictive (and understaffed) Backup is done only 
for network drives. The advantage is that I can access my 
user files from different computers (without using a server OS)

My start menu is almost empty. All programs we are able to 
use, are accessible through a shortcut on the desktop. I 
probably can read the startmenu folder but not write it. 

"My documents" refers to a networked directory. I have full 
access there and can run programs from there.

I suppose a patch would be to make more configuration 
options in the installer (Do you want to make shortcuts? Do 
you want to make them here?). I would make shortcuts on 
my desktop. (Yes, I can write there. Files sometimes go to 
c:\windows\desktop, and sometimes to a networked drive)

What would be needed to run python (and pythonwin) from a 
memory-stick or cd-rom? If that would work, my problem 
would be solved too. Even better: one installation would make 
python accessible from any computer on our network I would 
login to.

BTW: some drives (like C:) are hidden from explorer. I cannot 
do start -> run (but I can make a shortcut to cmd on my 
desktop, and run from there). I'm not sure I can get to regedit 
and/or do anything useful there.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-08-06 14:58

Message:
Logged In: YES 
user_id=21627

According to the log file, there was an error accessing

\\bw2\snelkop\2003\info\programma's\Python 2.4

How come your Menu folder is on a network drive? What is the
ACL on that folder?

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-08-06 14:48

Message:
Logged In: YES 
user_id=21627

Oops, missed the attachment.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-08-06 14:47

Message:
Logged In: YES 
user_id=21627

Closed because of lack of response.

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

Comment By: Martin v. L?wis (loewis)
Date: 2005-07-06 07:16

Message:
Logged In: YES 
user_id=21627

It works fine for me...

Can you please install with

msiexec /i python-2.4.1.msi /l*v python.log

and attach a zipped version of python.log?

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

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

From noreply at sourceforge.net  Tue Oct  3 00:15:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 15:15:43 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GUW4d-0005ve-9h@sc8-sf-web5.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 12:19
Message generated for change (Comment added) made by jordanramz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-02 17:15

Message:
Logged In: YES 
user_id=1604497

Thanks for that, I found it.  However, I guess I'm not as 
skilled with the computer as I thought...  It won't let me 
change the name, open the folder etc.  It says access is 
denied.  Know why it's doing that when I try to modify it?

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

Comment By: dani (daniboy22)
Date: 2006-10-02 09:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 09:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 11:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-09-30 21:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 16:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Tue Oct  3 01:10:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 16:10:28 -0700
Subject: [ python-Bugs-1569622 ] Backward incompatibility in logging.py
Message-ID: <E1GUWvc-0007X3-RZ@sc8-sf-web2.sourceforge.net>

Bugs item #1569622, was opened at 2006-10-02 16:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backward incompatibility in logging.py

Initial Comment:
LogRecord.__init__ changed in a backward incompatible
way in python 2.5 (added one parameter).  

There is no mention of this breakage in the release
notes, nor has the documentation of the module been
updated (http://docs.python.org/lib/node424.html)

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

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

From noreply at sourceforge.net  Tue Oct  3 01:16:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 16:16:35 -0700
Subject: [ python-Bugs-1569623 ] datetime.datetime subtraction bug
Message-ID: <E1GUX1X-00087G-3c@sc8-sf-web2.sourceforge.net>

Bugs item #1569623, was opened at 2006-10-02 23:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569623&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David Fugate (dfugate_ms)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.datetime subtraction bug

Initial Comment:
Python version: 2.5
OS name and version: Windows XP SP2
Email: dfugate at microsoft.com

The datetime.datetime subtraction operator seems to
have a bug in it:

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import datetime
>>> x = datetime.datetime(2006, 9, 29, 15, 37, 28, 686001)
>>> y = datetime.datetime(2006, 9, 29, 15, 37, 28, 686000)
>>> x - y
datetime.timedelta(0, 0, 1)
>>> y - x
datetime.timedelta(-1, 86399, 999999)

Here, the result of y - x should be timedelta(0, 0, -1).

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

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

From noreply at sourceforge.net  Tue Oct  3 01:27:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 16:27:51 -0700
Subject: [ python-Bugs-1569623 ] datetime.datetime subtraction bug
Message-ID: <E1GUXCR-0000kx-HD@sc8-sf-web2.sourceforge.net>

Bugs item #1569623, was opened at 2006-10-02 19:16
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569623&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: David Fugate (dfugate_ms)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.datetime subtraction bug

Initial Comment:
Python version: 2.5
OS name and version: Windows XP SP2
Email: dfugate at microsoft.com

The datetime.datetime subtraction operator seems to
have a bug in it:

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import datetime
>>> x = datetime.datetime(2006, 9, 29, 15, 37, 28, 686001)
>>> y = datetime.datetime(2006, 9, 29, 15, 37, 28, 686000)
>>> x - y
datetime.timedelta(0, 0, 1)
>>> y - x
datetime.timedelta(-1, 86399, 999999)

Here, the result of y - x should be timedelta(0, 0, -1).

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

>Comment By: Tim Peters (tim_one)
Date: 2006-10-02 19:27

Message:
Logged In: YES 
user_id=31435

Sorry, nope.  As the timedelta docs say:

"""
...

days, seconds and microseconds are then normalized so that
the representation is unique, with 

0 <= microseconds < 1000000 
0 <= seconds < 3600*24 (the number of seconds in one day) 
-999999999 <= days <= 999999999 

...

If the normalized value of days lies outside the indicated
range, OverflowError is raised. 

Note that normalization of negative values may be surprising
at first. For example, 

>>> d = timedelta(microseconds=-1)
>>> (d.days, d.seconds, d.microseconds)
(-1, 86399, 999999)
"""

Which is exactly what you're seeing.

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

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

From noreply at sourceforge.net  Tue Oct  3 08:11:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 23:11:11 -0700
Subject: [ python-Bugs-1569622 ] Backward incompatibility in logging.py
Message-ID: <E1GUdUl-0005UN-M4@sc8-sf-web1.sourceforge.net>

Bugs item #1569622, was opened at 2006-10-02 23:10
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Klaas (mklaas)
>Assigned to: Vinay Sajip (vsajip)
Summary: Backward incompatibility in logging.py

Initial Comment:
LogRecord.__init__ changed in a backward incompatible
way in python 2.5 (added one parameter).  

There is no mention of this breakage in the release
notes, nor has the documentation of the module been
updated (http://docs.python.org/lib/node424.html)

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 06:11

Message:
Logged In: YES 
user_id=849994

I don't see why adding one parameter is backwards
incompatible, but it's true that the docs must be updated.
Assigning to Vinay.

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

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

From noreply at sourceforge.net  Tue Oct  3 08:49:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Oct 2006 23:49:23 -0700
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GUe5j-0008Rn-So@sc8-sf-web4.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
>Assigned to: Martin v. L?wis (loewis)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 06:49

Message:
Logged In: YES 
user_id=849994

I'm afraid that this cannot be fixed.

In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.

If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.

Martin, do you you have an additional opinion?

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

Comment By: applebucks (scott_marks)
Date: 2006-10-02 16:02

Message:
Logged In: YES 
user_id=120857

This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation.  The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.

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

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

From noreply at sourceforge.net  Tue Oct  3 10:16:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 01:16:24 -0700
Subject: [ python-Bugs-1569790 ] mailbox.Maildir.get_folder() loses factory
	information
Message-ID: <E1GUfRw-0000kr-Cq@sc8-sf-web1.sourceforge.net>

Bugs item #1569790, was opened at 2006-10-03 10:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569790&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: mailbox.Maildir.get_folder() loses factory information

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

the factory defines what class the mails have that are
returned.

So for two nested folders a and a.b, the following code
will return
messages with two different classes:

# factory = None to get mailbox.MaildirMessage objects
md = mailbox.Maildir("a", factory=None)
print md["somemessage"].__class__
# will print mailbox.MaildirMessage
md2 = md.get_folder("b")
print md2["someothermessage"].__class__
# will print rfc822.Message

i.e. the factory= parameter passed to the outer Maildir
class upon
creation is not passed on to the subfolder creation in
get_folder()

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

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

From noreply at sourceforge.net  Tue Oct  3 10:24:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 01:24:16 -0700
Subject: [ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Message-ID: <E1GUfZY-0002J5-8z@sc8-sf-web2.sourceforge.net>

Bugs item #1484556, was opened at 2006-05-09 13:14
Message generated for change (Comment added) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Output of KlocWork on Python2.4.3 sources

Initial Comment:
We're evaluating KlocWork (http://www.klocwork.com),
I've ran it on the source of Python 2.4.3 and the
output is attached (1562 warnings).

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

>Comment By: Miki Tebeka (tebeka)
Date: 2006-10-03 10:24

Message:
Logged In: YES 
user_id=358087

I don't know, currently KlocWork is way down in my "todo"
list :(

Looks like I won't be able to continue in this matter any
longer, if anyone else want to give a hand ...

Miki

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 14:34

Message:
Logged In: YES 
user_id=849994

Have all KlocWork issues been fixed now, Neal?

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

Comment By: Miki Tebeka (tebeka)
Date: 2006-06-04 12:53

Message:
Logged In: YES 
user_id=358087

I'll try to see if I can sneak it in, can't promise anything
though

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 17:26

Message:
Logged In: YES 
user_id=11375

The Coverity scans also probably report some of the same
bugs, so many of these problems may be fixed in the 2.5 trunk.  

If you're still evaluating, you could try running the tool
on the 2.5 trunk (snapshot available from
http://svn.python.org/snapshots/) and see if the results are
shorter.


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

Comment By: Martin v. L?wis (loewis)
Date: 2006-05-10 07:45

Message:
Logged In: YES 
user_id=21627

Thanks for these results. Unfortunately, they seem to
contain many false positives, so it is unclear how one
should proceed with them.

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

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

From noreply at sourceforge.net  Tue Oct  3 12:10:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 03:10:55 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1GUhEl-0003SN-9c@sc8-sf-web1.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 17:39
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

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

>Comment By: Armin Rigo (arigo)
Date: 2006-10-03 10:10

Message:
Logged In: YES 
user_id=4771

Based on the other bug I guess that casting an arbitrary
long to unsigned long is allowed.  If so, then maybe we could
use the following test:

  if (sign == '-' && uresult == 0-(unsigned long)LONG_MIN) {
      result = LONG_MIN;
  }

which states the intention a bit more clearly and without the
assert().

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

Comment By: Tim Peters (tim_one)
Date: 2006-09-05 05:21

Message:
Logged In: YES 
user_id=31435

Well, I deliberately avoided using LONG_MIN in the patches
for the other bug, so that should answer your question ;-)

If someone wants to take the small risk of backporting it,
fine by me -- it's not going to break on Windows, and if it
doesn't break on your box either ...

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-05 05:12

Message:
Logged In: YES 
user_id=33168

Tim, how do you feel about backporting now?  (Not sure if
your opinion changed based on the other bug.)  That and I'm
cleaning out my mailbox, so I don't have to look at this any
more. :-)

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

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 21:00

Message:
Logged In: YES 
user_id=31435

Neal, as I said in the checkin comment, I expect it's no
less likely that we'll get screwed by goofy platform values
for LONG_MIN and LONG_MAX than that we /got/ screwed by an
"over ambitious" compiler optimizing away "result ==
-result", so I'm not sure backporting is a good idea.  I
stuck in an assert that might fail if a platform is insane;
if there are no reports of that assert triggering, then I'd
feel better about backporting the change.

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-27 10:49

Message:
Logged In: YES 
user_id=1126061

Fixed for me on NetBSD -current AMD64, gcc 4.1.2

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

Comment By: Nick Maclaren (nmm)
Date: 2006-07-27 08:31

Message:
Logged In: YES 
user_id=42444

Fixed for me, too, and the code looks solid.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:48

Message:
Logged In: YES 
user_id=33168

I reopened this bug as it still affects 2.4.  Tim's fix
should be backported.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

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

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 01:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

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

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

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

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

From noreply at sourceforge.net  Tue Oct  3 12:17:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 03:17:47 -0700
Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer
	overflows
Message-ID: <E1GUhLP-0000Nt-64@sc8-sf-web5.sourceforge.net>

Bugs item #1545668, was opened at 2006-08-24 03:14
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 9
Submitted By: Jack Howarth (jwhowarth)
>Assigned to: Armin Rigo (arigo)
Summary: gcc trunk (4.2) exposes a signed integer overflows

Initial Comment:
While building python 2.4.3 with the current gcc trunk (soon to be 4.2), 
I uncovered a signed integer overflows bug in Python with the help of 
one of the gcc developers. The bug I observed is documented in this 
gcc mailing list message...

http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html

The gcc developer comments about its origin are in the messages...

http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html

which in short says...

It *is* a bug in python, here is the proof:
https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/
Objects/intobject.c?revision=25647&view=markup
Function

* i_divmod*(*register* *long* x, *register* *long* y,

the following lines:

/        /* (-sys.maxint-1)/-1 is the only overflow case. *//
	*if* (y == -1 && x < 0 && x == -x)
		*return* DIVMOD_OVERFLOW;

If overflow is barred then x==-x may happen only when x==0.
This conflicts with x<0, which means that the compiler may assume
that
  x<0 && x==-x
always yields false. This may allow the compiler to eliminate the whole 
if
statement. Hence, clearly python is at fault.

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

>Comment By: Armin Rigo (arigo)
Date: 2006-10-03 10:17

Message:
Logged In: YES 
user_id=4771

I'd like to review this in 2.4/2.5/trunk before the 2.4.4
release.

Debian "testing" ships with everything compiled with the
faulty gcc -- even though this gcc is not released yet!  I
hate Debian's policies.  "Fixing" 2.4.4 would help me a bit
to get a reasonable Python installation on Debian machines
where I have to log to (assuming the sysadmin knew he had
to fish 72 small packages to get just a complete stdlib,
that is, but that's another matter).

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

Comment By: Armin Rigo (arigo)
Date: 2006-09-16 11:28

Message:
Logged In: YES 
user_id=4771

More of the same kind of problem:
abs(-sys.maxint-1) sometimes gives -sys.maxint-1.
It would be a good idea to review all places that need
to special-case -sys.maxint-1 for overflow detection.
(It would be a still better idea to review all overflow
detection code, but that may have to wait after the
2.5 release).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-05 04:04

Message:
Logged In: YES 
user_id=33168

Tim checked in fixes for 2.6 (r51716), 2.5 (r51711), and 2.4.



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

Comment By: David Hopwood (dhopwood)
Date: 2006-08-26 23:24

Message:
Logged In: YES 
user_id=634468

The correct patch is the one that uses

if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)

The one that uses (unsigned int)x will break some 64-bit
platforms where int != long.

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

Comment By: Tim Peters (tim_one)
Date: 2006-08-26 20:33

Message:
Logged In: YES 
user_id=31435

Boosted priority to 8 since it was brought up on python-dev
as a suggested 2.5 release-blocker.  The patch in the first
comment looks fine, if a release manager wants to apply it.

Python 2.4 surely has the same "issue".

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

Comment By: Tim Peters (tim_one)
Date: 2006-08-26 20:25

Message:
Logged In: YES 
user_id=31435

Looks like the same deal as bug 1521947 (which was about
similar code in PyOS_strtol()).

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

Comment By: Jack Howarth (jwhowarth)
Date: 2006-08-24 15:22

Message:
Logged In: YES 
user_id=403009

Everyone involved in reviewing this patch should definitely
read the following sequence of gcc mailing list messages
which show the process by which this patch was arrived at...

http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html

So we have had lots of gcc developer eyes on this
problem and they all agree on the flaw and the fix
as posted. It's unfortunate that I had to abuse their
mailing list to get this addressed before python 2.5
gets released.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 15:00

Message:
Logged In: YES 
user_id=33168

I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't
spot any other occurrences.

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2006-08-24 14:54

Message:
Logged In: YES 
user_id=43607

Just a comment, I'm not claiming this bug.

The test (x < 0 && x == -x) tests whether x is equal to the
smallest negative number.  If x is equal to -2147483648,
then -x is also equal to -2147483648 due to overflow.

What does this version of gcc do with this code when x =
-2147483648?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 14:54

Message:
Logged In: YES 
user_id=33168

Assigning to Tim, he likes these problems. :-)
He recently fixed a similar problem in another piece of
code.  I'm going to try to grep and see if I can find more
occurrences of this.

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

Comment By: Jack Jansen (jackjansen)
Date: 2006-08-24 14:37

Message:
Logged In: YES 
user_id=45365

Hmm... intobject.c doesn't really have a "champion"...

Neal, I'm assigning this to you purely on the ground that you're the last person 
to have edited this file. Feel free to pass on (but not back:-).

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

Comment By: Jack Howarth (jwhowarth)
Date: 2006-08-24 11:22

Message:
Logged In: YES 
user_id=403009

The was a few other comments from the gcc developers on the proposed 
fix...

http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html

...so that since x is a long the more correct fix is...

--- Python-2.4.3/Objects/intobject.c.org        2006-08-24 
07:06:51.000000000 -0400
+++ Python-2.4.3/Objects/intobject.c    2006-08-24 07:08:06.000000000 
-0400
@@ -479,7 +479,7 @@
                return DIVMOD_ERROR;
        }
        /* (-sys.maxint-1)/-1 is the only overflow case. */
-       if (y == -1 && x < 0 && x == -x)
+       if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x)
                return DIVMOD_OVERFLOW;
        xdivy = x / y;
        xmody = x - xdivy * y;

I have tested this form of the patch and it works as well. My main concern is 
that we get this fix in python 2.5 before release. Jack, could you reassign this 
to the person you think might be most appropriate out of the list of python 
developers? I really should be a pretty simple review for the patch.


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

Comment By: Jack Jansen (jackjansen)
Date: 2006-08-24 09:14

Message:
Logged In: YES 
user_id=45365

I don't think this is a mac-specific bug, and I'm also not really the right person 
to look into this...

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

Comment By: Jack Howarth (jwhowarth)
Date: 2006-08-24 04:13

Message:
Logged In: YES 
user_id=403009

As suggested by another gcc developer in...

http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html

...the following patch eliminates the error when python is built with gcc 
trunk...

--- Python-2.4.3/Objects/intobject.c.org        2006-08-23 
23:49:33.000000000 -0400
+++ Python-2.4.3/Objects/intobject.c    2006-08-23 23:52:01.000000000 
-0400
@@ -479,7 +479,7 @@
                return DIVMOD_ERROR;
        }
        /* (-sys.maxint-1)/-1 is the only overflow case. */
-       if (y == -1 && x < 0 && x == -x)
+       if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x)
                return DIVMOD_OVERFLOW;
        xdivy = x / y;
        xmody = x - xdivy * y;

This change allows python to completely pass its make check now when built 
with gcc trunk.

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

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

From noreply at sourceforge.net  Tue Oct  3 12:35:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 03:35:40 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1GUhci-0005sQ-Ga@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

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

>Comment By: Tim Peters (tim_one)
Date: 2006-10-03 06:35

Message:
Logged In: YES 
user_id=31435

> Based on the other bug I guess that casting an arbitrary
> long to unsigned long is allowed.

Right, C defines the result of casting any integral type to
any unsigned integral type.

> If so, then maybe we could use the following test:
>
>  if (sign == '-' && uresult == 0-(unsigned
long)LONG_MIN) {
>      result = LONG_MIN;
>  }
>
> which states the intention a bit more clearly and
> without the assert().

We could.  It's not really clearer to me, given that the
current code is explained in a comment block before
PyOS_strtol(), and I couldn't care less about removing an
assert, so I'm not going to bother.  I wouldn't object to
changing it, although "0-" instead of plain unary "-" also
begs for an explanation lest someone delete the "0" because
it looks plain silly.

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

Comment By: Armin Rigo (arigo)
Date: 2006-10-03 06:10

Message:
Logged In: YES 
user_id=4771

Based on the other bug I guess that casting an arbitrary
long to unsigned long is allowed.  If so, then maybe we could
use the following test:

  if (sign == '-' && uresult == 0-(unsigned long)LONG_MIN) {
      result = LONG_MIN;
  }

which states the intention a bit more clearly and without the
assert().

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

Comment By: Tim Peters (tim_one)
Date: 2006-09-05 01:21

Message:
Logged In: YES 
user_id=31435

Well, I deliberately avoided using LONG_MIN in the patches
for the other bug, so that should answer your question ;-)

If someone wants to take the small risk of backporting it,
fine by me -- it's not going to break on Windows, and if it
doesn't break on your box either ...

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-05 01:12

Message:
Logged In: YES 
user_id=33168

Tim, how do you feel about backporting now?  (Not sure if
your opinion changed based on the other bug.)  That and I'm
cleaning out my mailbox, so I don't have to look at this any
more. :-)

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

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:00

Message:
Logged In: YES 
user_id=31435

Neal, as I said in the checkin comment, I expect it's no
less likely that we'll get screwed by goofy platform values
for LONG_MIN and LONG_MAX than that we /got/ screwed by an
"over ambitious" compiler optimizing away "result ==
-result", so I'm not sure backporting is a good idea.  I
stuck in an assert that might fail if a platform is insane;
if there are no reports of that assert triggering, then I'd
feel better about backporting the change.

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-27 06:49

Message:
Logged In: YES 
user_id=1126061

Fixed for me on NetBSD -current AMD64, gcc 4.1.2

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

Comment By: Nick Maclaren (nmm)
Date: 2006-07-27 04:31

Message:
Logged In: YES 
user_id=42444

Fixed for me, too, and the code looks solid.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 00:48

Message:
Logged In: YES 
user_id=33168

I reopened this bug as it still affects 2.4.  Tim's fix
should be backported.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 00:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

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

Comment By: Tim Peters (tim_one)
Date: 2006-07-26 21:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

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

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 05:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 21:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

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

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

From noreply at sourceforge.net  Tue Oct  3 12:59:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 03:59:29 -0700
Subject: [ python-Bugs-1569886 ] distutils don't respect standard env variables
Message-ID: <E1GUhzl-0004UO-MN@sc8-sf-web5.sourceforge.net>

Bugs item #1569886, was opened at 2006-10-03 12:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils don't respect standard env variables

Initial Comment:
Using environment variables INCLUDE and LIB is a
standard way to set system-wide paths for C compilers.
However distutils.msvccompiler always overwrites these
variables with it's own values, which means users have
no way to customize their MSVC setups. It should
*append* the Python-specific stuff to the variables,
not overwrite them.

--- msvccompiler.py.orig	2006-10-03 12:56:15.812500000
+0200
+++ msvccompiler.py	2006-10-03 12:56:22.718750000 +0200
@@ -635,4 +635,7 @@
         else:
             p = self.get_msvc_paths(name)
         if p:
-            os.environ[name] = string.join(p, ';')
+            p = string.join(p, ';')
+            if name in os.environ:
+                p = os.environ[name] + ';' + p
+            os.environ[name] = p


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

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

From noreply at sourceforge.net  Tue Oct  3 14:02:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 05:02:55 -0700
Subject: [ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Message-ID: <E1GUiz9-0005Fz-Ea@sc8-sf-web4.sourceforge.net>

Bugs item #1484556, was opened at 2006-05-09 12:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Output of KlocWork on Python2.4.3 sources

Initial Comment:
We're evaluating KlocWork (http://www.klocwork.com),
I've ran it on the source of Python 2.4.3 and the
output is attached (1562 warnings).

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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-03 14:02

Message:
Logged In: YES 
user_id=21627

Ok, let's close this report, then. We continue to monitor
Klocwork, regardless.

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

Comment By: Miki Tebeka (tebeka)
Date: 2006-10-03 10:24

Message:
Logged In: YES 
user_id=358087

I don't know, currently KlocWork is way down in my "todo"
list :(

Looks like I won't be able to continue in this matter any
longer, if anyone else want to give a hand ...

Miki

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 13:34

Message:
Logged In: YES 
user_id=849994

Have all KlocWork issues been fixed now, Neal?

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

Comment By: Miki Tebeka (tebeka)
Date: 2006-06-04 11:53

Message:
Logged In: YES 
user_id=358087

I'll try to see if I can sneak it in, can't promise anything
though

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 16:26

Message:
Logged In: YES 
user_id=11375

The Coverity scans also probably report some of the same
bugs, so many of these problems may be fixed in the 2.5 trunk.  

If you're still evaluating, you could try running the tool
on the 2.5 trunk (snapshot available from
http://svn.python.org/snapshots/) and see if the results are
shorter.


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

Comment By: Martin v. L?wis (loewis)
Date: 2006-05-10 06:45

Message:
Logged In: YES 
user_id=21627

Thanks for these results. Unfortunately, they seem to
contain many false positives, so it is unclear how one
should proceed with them.

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

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

From noreply at sourceforge.net  Tue Oct  3 14:11:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 05:11:19 -0700
Subject: [ python-Bugs-1568243 ] init_types
Message-ID: <E1GUj7H-00067W-EL@sc8-sf-web4.sourceforge.net>

Bugs item #1568243, was opened at 2006-09-30 11:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Bosko Vukov (bvukov)
>Assigned to: Kristj?n Valur (krisvale)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) ....
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 14:11

Message:
Logged In: YES 
user_id=21627

Kristijan, can you please backport your changes to the 2.5
trunk and then close this report?

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 21:22

Message:
Logged In: YES 
user_id=1611513

Thanks, loewis.  I take your advice.  

I see that things have changed in SVN anyway.  I like the
new approach of using Visual STudio's configuration
management.  

When I (try to) build PGIRelease to instrument the python
dll, I get a curious error:

1>Compiling...
1>zlibmodule.c
1>Compiling resources...
1>Linking...
1>   Creating library
Win32\PGIRelease\pythoncore/python26.lib and object
Win32\PGIRelease\pythoncore/python26.exp
1>Generating code
1>c:\Documents and Settings\kferrio\My
Documents\Dev\Python-2.5\Modules\zipimport.c : fatal error
C1350: error loading dll 'pgodb80.dll': dll not found
1>LINK : fatal error LNK1257: code generation failed
1>Build log was saved at "file://c:\Documents and
Settings\kferrio\My
Documents\Dev\Python-2.5\PCbuild8\Win32\PGIRelease\pythoncore\BuildLog.htm"
1>pythoncore - 2 error(s), 2 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0
skipped ==========

I definitely do not understand this -- yet.  Meanwhile, any
clues would be welcome.

Thanks.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-02 21:08

Message:
Logged In: YES 
user_id=21627

I think you should avoid building pythoncore_pgo; it's of no
use. 

Or else, study all documentation you can find on Microsoft's
profile-guided-optimization for a few days, read all web
logs about the bugs in this software, and perhaps you can
succeed in building it, by deleting the right files in the
right order.

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 20:28

Message:
Logged In: YES 
user_id=1611513

I am expereincing the problem described by the original
poster.  I undertand that MSVC8 is not officially supported,
and I'm trying anyway.

I downloaded the 2.5.0 final tarball and began working in
the PCbuild8 directory.

Firts off, I found that I had to build two projects before
pythoncore would build: 

  make_versioninfo
  make_buildinfo

When I tried to build pythoncore, I got the linker error
saying that _init_types could not be found.  So I added
_typesmodule.c to the pythoncore project.  Finally,
pythoncore built cleanly.

Next up, I wanted to build pythoncore_pgo.  So I added 
_typesmodule to this project also.  But try as I might,
every attempt to build pythoncore_pgo produces the link
error on _init_types.  (I also did a 'clean' on pythoncore
just to be safe.)

I do not understand this.  Unlike the original poster, I
have not modified any source.  It seems like the definition
of pyMODINIT_FUNC as extern "C" void might be involved, but
I agree with gbrandl that the static int in Python-ast.c is
not the issue, because that is a different scope.  

So the linkage problem with pythoncore_pgo remains a mystery
to me.  I hope someone has more clues than me.



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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-02 16:00

Message:
Logged In: YES 
user_id=21627

Notice that the PCbuild8 directory isn't really supported...

In any case, the bug is that PCbuild8 does not have the
reference to _typesmodule, not that init_types in
Python-ast.c is static.

If you revert your change to Python-ast.c, and change
pythoncore.vcproj, it should build fine.

This is already fixed in r51751 in the trunk; not sure
whether backporting it is necessary.


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

Comment By: Bosko Vukov (bvukov)
Date: 2006-09-30 19:50

Message:
Logged In: YES 
user_id=1292849

I opened solution file from folder PCbuild8, and inside
project file pythoncore.vcproj there is no reference to
_typesmodule.c. It exists in pythoncore.vcproj in the
PBbuild folder ( for older version's ). I added the missing
_typesmodule.c inside, and returned back the changes I made,
and aft er that linker reported 'Python-ast.obj : error
LNK2005: _init_types already defined in _typesmodule.obj'

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 13:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

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

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

From noreply at sourceforge.net  Tue Oct  3 14:12:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 05:12:06 -0700
Subject: [ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Message-ID: <E1GUj82-0003A5-Df@sc8-sf-web5.sourceforge.net>

Bugs item #1569517, was opened at 2006-10-02 21:54
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Coatimundi (coatimundi)
>Assigned to: Kristj?n Valur (krisvale)
Summary: PGIRelease linkage fails on pgodb80.dll

Initial Comment:
Hi.  I'm interested in learning how to optimize Python
for Windows.  I have made a similar report as a
follow-on to Bug 1568243, but it's really a  separate
issue.

Let me emphasize that what I am about to describe this
is *not* a bug in the Python build system.  But it may
be worth calling out in the README file for PCbuild8.

When building PGIRelease to instrument the pythoncore
DLL, the linker fails because it cannot find
pgodb80.dll.  This file is required for PGO with Visual
C++ under Visual Studio 2005 and is shipped with the
Professional version, but not with the Express version
or (apparently) the Standard version I have.  Looks
like upgrade time...

I hope this helps someone else.


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 14:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

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

From noreply at sourceforge.net  Tue Oct  3 14:12:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 05:12:41 -0700
Subject: [ python-Bugs-1567910 ] missing _typesmodule.c,
	Visual Studio 2005 pythoncore.vcproj
Message-ID: <E1GUj8b-0003EB-Cm@sc8-sf-web5.sourceforge.net>

Bugs item #1567910, was opened at 2006-09-29 19:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: everbruin (everbruin)
>Assigned to: Kristj?n Valur (krisvale)
Summary: missing _typesmodule.c,Visual Studio 2005 pythoncore.vcproj

Initial Comment:
Python 2.5's Visual Studio 2005 pythoncore.vcproj (in
PCBuild8 folder) is missing Modules/_typesmodule.c
(note the VS 2003 pythoncore.vcproj in PCBuild
correctly has it).

The bug is that binaries built w/o the file will give a
SystemError when "import _types" is done (eg by types.py).

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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 14:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-02 21:10

Message:
Logged In: YES 
user_id=21627

I find it hard to believe that you get this precise error; I
would have expected that the pythoncore project would fail
to build instead.

Notice that PCbuild8 is not really supported.

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

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

From noreply at sourceforge.net  Tue Oct  3 14:50:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 05:50:02 -0700
Subject: [ python-Bugs-1569886 ] distutils don't respect standard env variables
Message-ID: <E1GUjik-0002x6-3c@sc8-sf-web2.sourceforge.net>

Bugs item #1569886, was opened at 2006-10-03 12:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils don't respect standard env variables

Initial Comment:
Using environment variables INCLUDE and LIB is a
standard way to set system-wide paths for C compilers.
However distutils.msvccompiler always overwrites these
variables with it's own values, which means users have
no way to customize their MSVC setups. It should
*append* the Python-specific stuff to the variables,
not overwrite them.

--- msvccompiler.py.orig	2006-10-03 12:56:15.812500000
+0200
+++ msvccompiler.py	2006-10-03 12:56:22.718750000 +0200
@@ -635,4 +635,7 @@
         else:
             p = self.get_msvc_paths(name)
         if p:
-            os.environ[name] = string.join(p, ';')
+            p = string.join(p, ';')
+            if name in os.environ:
+                p = os.environ[name] + ';' + p
+            os.environ[name] = p


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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-03 14:50

Message:
Logged In: YES 
user_id=21627

This bug was fixed in Python 2.5. If the environment
variables MSSdk and DISTUTILS_USE_SDK are set, then
distutils doesn't attempt to overwrite LIB or INCLUDE.

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

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

From noreply at sourceforge.net  Tue Oct  3 15:02:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 06:02:53 -0700
Subject: [ python-Bugs-1569886 ] distutils don't respect standard env variables
Message-ID: <E1GUjvB-0003OU-DN@sc8-sf-web1.sourceforge.net>

Bugs item #1569886, was opened at 2006-10-03 12:59
Message generated for change (Comment added) made by luks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils don't respect standard env variables

Initial Comment:
Using environment variables INCLUDE and LIB is a
standard way to set system-wide paths for C compilers.
However distutils.msvccompiler always overwrites these
variables with it's own values, which means users have
no way to customize their MSVC setups. It should
*append* the Python-specific stuff to the variables,
not overwrite them.

--- msvccompiler.py.orig	2006-10-03 12:56:15.812500000
+0200
+++ msvccompiler.py	2006-10-03 12:56:22.718750000 +0200
@@ -635,4 +635,7 @@
         else:
             p = self.get_msvc_paths(name)
         if p:
-            os.environ[name] = string.join(p, ';')
+            p = string.join(p, ';')
+            if name in os.environ:
+                p = os.environ[name] + ';' + p
+            os.environ[name] = p


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

>Comment By: Lukas Lalinsky (luks)
Date: 2006-10-03 15:02

Message:
Logged In: YES 
user_id=587716

Oh, I didn't know about this. Thank you.

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

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-03 14:50

Message:
Logged In: YES 
user_id=21627

This bug was fixed in Python 2.5. If the environment
variables MSSdk and DISTUTILS_USE_SDK are set, then
distutils doesn't attempt to overwrite LIB or INCLUDE.

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

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

From noreply at sourceforge.net  Tue Oct  3 15:33:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 06:33:18 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GUkOc-0005lx-SN@sc8-sf-web4.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 17:19
Message generated for change (Comment added) made by daniboy22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

>Comment By: dani (daniboy22)
Date: 2006-10-03 13:33

Message:
Logged In: YES 
user_id=1604341

Well, I'm also not a specialist on the subject, but in my
case I don't have any problems in opening the folder. I just
had some problems to rename it (it didn't accepted a name
starting with a "."), but I resolve it (I rename it to "pinga").

Concerning your problem, my hint is that your account is not
an administrator one. Try to enter as an administrator and
make the necessary changes. Or else change the permissions
of your account to the "administrator" type (ask someone
that is already an administrator on that computer to do that).

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-02 22:15

Message:
Logged In: YES 
user_id=1604497

Thanks for that, I found it.  However, I guess I'm not as 
skilled with the computer as I thought...  It won't let me 
change the name, open the folder etc.  It says access is 
denied.  Know why it's doing that when I try to modify it?

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

Comment By: dani (daniboy22)
Date: 2006-10-02 14:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 14:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 16:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 02:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 21:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Tue Oct  3 16:04:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 07:04:52 -0700
Subject: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try
	statement
Message-ID: <E1GUktA-0002fd-3F@sc8-sf-web1.sourceforge.net>

Bugs item #1569998, was opened at 2006-10-04 00:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.5 incorrectly permits break inside try statement

Initial Comment:
The new AST compiler permits the break statement inside
*any* frame block, rather than requiring that there be
a loop somewhere on the block stack.

Will add examples in a comment where SF shouldn't
destroy the formatting.

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

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

From noreply at sourceforge.net  Tue Oct  3 16:05:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 07:05:15 -0700
Subject: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try
	statement
Message-ID: <E1GUktX-0002m6-Rb@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.5 incorrectly permits break inside try statement

Initial Comment:
The new AST compiler permits the break statement inside
*any* frame block, rather than requiring that there be
a loop somewhere on the block stack.

Will add examples in a comment where SF shouldn't
destroy the formatting.

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

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-10-04 00:05

Message:
Logged In: YES 
user_id=1038590

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
SyntaxError: 'break' outside loop

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
1
3

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

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

From noreply at sourceforge.net  Tue Oct  3 17:35:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 08:35:07 -0700
Subject: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try
	statement
Message-ID: <E1GUmIV-0001oC-Mq@sc8-sf-web3.sourceforge.net>

Bugs item #1569998, was opened at 2006-10-03 14:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 8
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.5 incorrectly permits break inside try statement

Initial Comment:
The new AST compiler permits the break statement inside
*any* frame block, rather than requiring that there be
a loop somewhere on the block stack.

Will add examples in a comment where SF shouldn't
destroy the formatting.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-10-03 14:05

Message:
Logged In: YES 
user_id=1038590

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
SyntaxError: 'break' outside loop

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
1
3

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

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

From noreply at sourceforge.net  Tue Oct  3 19:14:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 10:14:51 -0700
Subject: [ python-Bugs-1569622 ] Backward incompatibility in logging.py
Message-ID: <E1GUnr1-00080r-2Y@sc8-sf-web1.sourceforge.net>

Bugs item #1569622, was opened at 2006-10-02 16:10
Message generated for change (Comment added) made by mklaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Vinay Sajip (vsajip)
Summary: Backward incompatibility in logging.py

Initial Comment:
LogRecord.__init__ changed in a backward incompatible
way in python 2.5 (added one parameter).  

There is no mention of this breakage in the release
notes, nor has the documentation of the module been
updated (http://docs.python.org/lib/node424.html)

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

>Comment By: Mike Klaas (mklaas)
Date: 2006-10-03 10:14

Message:
Logged In: YES 
user_id=1611720

It is incompatible as code written for 2.4 will break in
2.5, and vice-versa (this is a required parameter, not an
optional parameter, and the change could have been made in a
backward-compatible way).

You're right that the documentation fix is the important thing.



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

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-02 23:11

Message:
Logged In: YES 
user_id=849994

I don't see why adding one parameter is backwards
incompatible, but it's true that the docs must be updated.
Assigning to Vinay.

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

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

From noreply at sourceforge.net  Tue Oct  3 20:22:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 11:22:26 -0700
Subject: [ python-Bugs-1569622 ] Backward incompatibility in logging.py
Message-ID: <E1GUouQ-0001tS-GS@sc8-sf-web1.sourceforge.net>

Bugs item #1569622, was opened at 2006-10-02 23:10
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Vinay Sajip (vsajip)
Summary: Backward incompatibility in logging.py

Initial Comment:
LogRecord.__init__ changed in a backward incompatible
way in python 2.5 (added one parameter).  

There is no mention of this breakage in the release
notes, nor has the documentation of the module been
updated (http://docs.python.org/lib/node424.html)

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

>Comment By: Vinay Sajip (vsajip)
Date: 2006-10-03 18:22

Message:
Logged In: YES 
user_id=308438

Documentation now updated in CVS. Also changed the added
"func" parameter to have a default value of None.

Sorry for the inconvenience caused.

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

Comment By: Mike Klaas (mklaas)
Date: 2006-10-03 17:14

Message:
Logged In: YES 
user_id=1611720

It is incompatible as code written for 2.4 will break in
2.5, and vice-versa (this is a required parameter, not an
optional parameter, and the change could have been made in a
backward-compatible way).

You're right that the documentation fix is the important thing.



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

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 06:11

Message:
Logged In: YES 
user_id=849994

I don't see why adding one parameter is backwards
incompatible, but it's true that the docs must be updated.
Assigning to Vinay.

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

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

From noreply at sourceforge.net  Tue Oct  3 20:27:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 11:27:33 -0700
Subject: [ python-Feature Requests-1567331 ] logging.RotatingFileHandler has
	no "infinite" backupCount
Message-ID: <E1GUozN-0002NY-U5@sc8-sf-web1.sourceforge.net>

Feature Requests item #1567331, was opened at 2006-09-28 21:36
Message generated for change (Settings changed) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.RotatingFileHandler has no "infinite" backupCount

Initial Comment:
It seems to me that logging.RotatingFileHandler should
have a way to spell "never delete old log files".  This
is useful in situations where you want an external
process (manual or automatic) make decisions about
deleting log files.


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

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

From noreply at sourceforge.net  Tue Oct  3 22:37:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 13:37:58 -0700
Subject: [ python-Bugs-1570255 ] redirected cookies
Message-ID: <E1GUr1a-00041x-NC@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: hans_moleman (hans_moleman)
Assigned to: Nobody/Anonymous (nobody)
Summary: redirected cookies

Initial Comment:
Cookies are not resend when a redirect is requested.

Blurb:
I've been trying to get a response off a server using
Python.
The response so far differs from the response using
Firefox.
In Python, I have set headers and cookies the way
Firefox does it.

I noticed that the server accepts the POST request, and
redirects the client to another address with the result
on it. This happens both with Python and Firefox correctly.

Cookie handling differs though:
The Python client, when redirected, using the standard
redirect handler, does not resend its cookies to the
redirected address.
Firefox does resend the cookies from the original request.

When I redefine the redirect handler and code it so
that it adds the cookies from the original request,
the response is the same as Firefox's response. This
confirms then that resending cookies is required to get
the server to respond correctly.

Is the default Python redirection cookie policy
different from Firefox's policy?
Could we improve the default redirection handler to
work like Firefox?
Is it a bug?

I noticed an old open bug report 511786, that looks
very much like this problem. It suggests it is fixed.

Cheers Hans Moleman. 


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

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

From noreply at sourceforge.net  Tue Oct  3 23:17:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 14:17:48 -0700
Subject: [ python-Bugs-1570284 ] Launcher reset to factory button provides bad
	command-line
Message-ID: <E1GUre8-0003uQ-Q0@sc8-sf-web4.sourceforge.net>

Bugs item #1570284, was opened at 2006-10-03 14:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: jjackson (jejackson)
Assigned to: Jack Jansen (jackjansen)
Summary: Launcher reset to factory button provides bad command-line

Initial Comment:
If I push the "Reset to factory settings" in Python Launcher's Preferences 
window, the command line gets a bogues "(null)" inserted, which makes a 
mess of things. I don't think that was what was intended.

In trying to debug this, I notice in the source for FileSettings.m, at line 
209
there are two duplicated lines:

            [NSNumber numberWithBool: nosite], @"nosite",
            [NSNumber numberWithBool: nosite], @"nosite",

Also, I notice at FileSettings.m:236

    value = [dict objectForKey: @"nosite"];
    if (value) nosite = [value boolValue];
    value = [dict objectForKey: @"nosite"];
    if (value) tabs = [value boolValue];

I'm wondering if these second "nosite"s should be "tabs", and if that 
would fix the problem.

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

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

From noreply at sourceforge.net  Tue Oct  3 23:54:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 14:54:40 -0700
Subject: [ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump
Message-ID: <E1GUsDo-0001go-VZ@sc8-sf-web6.sourceforge.net>

Bugs item #1558223, was opened at 2006-09-14 00:05
Message generated for change (Comment added) made by thurnerrupert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: 3rd Party
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ThurnerRupert (thurnerrupert)
Assigned to: Nobody/Anonymous (nobody)
Summary: apache2 - mod_python - python2.4 core dump

Initial Comment:
$ gdb bin/httpd
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) core core
Core was generated by `/usr/local/bin/httpd -k restart'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libssl.so.0.9.8...done.
Loaded symbols for /usr/local/lib/libssl.so.0.9.8
<... deleted the whole loaded libraries>

#0  0xfebb3218 in strlen () from /usr/lib/libc.so.1

(gdb) bt

#0  0xfebb3218 in strlen () from /usr/lib/libc.so.1
#1  0xfda6ac4c in PyString_FromString (
    str=0xfef65ec0 "unexpected parser state - please
send a bug report")
    at Objects/stringobject.c:106
#2  0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0,
    name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE",
value=0x0)
    at Python/modsupport.c:589
#3  0xfe57cec4 in initpyexpat ()
    at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973

this happens when running moinmoin 1.5.4, and doing a
gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8,
compile with gcc-3.4.6.



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

>Comment By: ThurnerRupert (thurnerrupert)
Date: 2006-10-03 23:54

Message:
Logged In: YES 
user_id=1597584

ok ... i will.

we noticed similar errors when running:
 * edgewall trac 0.11-dev (which uses edgewall ghenshi)
 * xml-rpc plugin for edgewall trac

also, i filed the bug report after changing to newest 
mod_python. the old mod_python with apache 2.0.54 did not 
give a core, just segfaulted.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-14 05:34

Message:
Logged In: YES 
user_id=33168

Please file this bug report with mod_python.  That's
typically the cause and it will likely be very hard for any
Python developer to create this setup and much less try to
reproduce the error.

If you can provoke the same error without mod_python or
other third party C extensions, please file a bug report
with the minimal test case to reproduce.

If you need a work-around, I would suggest changing to a
different version of mod_python.

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

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

From noreply at sourceforge.net  Wed Oct  4 00:47:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 15:47:30 -0700
Subject: [ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump
Message-ID: <E1GUt2w-000050-Jr@sc8-sf-web1.sourceforge.net>

Bugs item #1558223, was opened at 2006-09-14 00:05
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: 3rd Party
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ThurnerRupert (thurnerrupert)
Assigned to: Nobody/Anonymous (nobody)
Summary: apache2 - mod_python - python2.4 core dump

Initial Comment:
$ gdb bin/httpd
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) core core
Core was generated by `/usr/local/bin/httpd -k restart'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libssl.so.0.9.8...done.
Loaded symbols for /usr/local/lib/libssl.so.0.9.8
<... deleted the whole loaded libraries>

#0  0xfebb3218 in strlen () from /usr/lib/libc.so.1

(gdb) bt

#0  0xfebb3218 in strlen () from /usr/lib/libc.so.1
#1  0xfda6ac4c in PyString_FromString (
    str=0xfef65ec0 "unexpected parser state - please
send a bug report")
    at Objects/stringobject.c:106
#2  0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0,
    name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE",
value=0x0)
    at Python/modsupport.c:589
#3  0xfe57cec4 in initpyexpat ()
    at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973

this happens when running moinmoin 1.5.4, and doing a
gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8,
compile with gcc-3.4.6.



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

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-04 00:47

Message:
Logged In: YES 
user_id=1326842

This looks like another problem with pyexpat getting
the export symbols from an older expat version.  See:
http://www.python.org/sf/1295808 and
http://www.python.org/sf/1075984
for details.


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

Comment By: ThurnerRupert (thurnerrupert)
Date: 2006-10-03 23:54

Message:
Logged In: YES 
user_id=1597584

ok ... i will.

we noticed similar errors when running:
 * edgewall trac 0.11-dev (which uses edgewall ghenshi)
 * xml-rpc plugin for edgewall trac

also, i filed the bug report after changing to newest 
mod_python. the old mod_python with apache 2.0.54 did not 
give a core, just segfaulted.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-14 05:34

Message:
Logged In: YES 
user_id=33168

Please file this bug report with mod_python.  That's
typically the cause and it will likely be very hard for any
Python developer to create this setup and much less try to
reproduce the error.

If you can provoke the same error without mod_python or
other third party C extensions, please file a bug report
with the minimal test case to reproduce.

If you need a work-around, I would suggest changing to a
different version of mod_python.

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

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

From noreply at sourceforge.net  Wed Oct  4 03:23:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 18:23:30 -0700
Subject: [ python-Bugs-1569057 ] Using .next() on file open in write mode
	writes junk to file
Message-ID: <E1GUvTu-0006pV-4F@sc8-sf-web1.sourceforge.net>

Bugs item #1569057, was opened at 2006-10-01 23:49
Message generated for change (Comment added) made by rainy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using .next() on file open in write mode writes junk to file

Initial Comment:
When you open a file in write mode and use .next(), it 
prints an error and writes many lines of junk to file. 
I tested on windows and python 2.5:

>>> f = open('test', 'w') 
>>> f.fileno() 
4 
>>> f.write('1\n') 
>>> f.write('2\n3\n4\n') 
>>> f.next() 


Traceback (most recent call last): 
  File "<pyshell#8>", line 1, in <module> 
    f.next() 
IOError: [Errno 9] Bad file descriptor 

>>> f.close() 
>>> f = open('test') 
>>> f.next() 
'1\n' 
>>> f.next() 
'2\n' 
>>> f.next() 
'3\n' 
>>> f.next() 
'4\n' 
>>> f.next() 


'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x?
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\?
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00 
...many more lines of junk...'



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

>Comment By: andrei kulakov (rainy)
Date: 2006-10-03 20:23

Message:
Logged In: YES 
user_id=511010

Python newsgroup folks said that this is normal because when 
switching between write/read modes without doing flush() 
first, result is undefined. There was a suggestion from 
Terry Ready to add this to documentation on file methods:

"When switching from reading or writing (or vice versa), 
call flush(), or 
the result will be undefined."

thx, -andrei

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

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

From scott.c.marks at gmail.com  Sun Oct  1 18:32:46 2006
From: scott.c.marks at gmail.com (Scott Marks)
Date: Sun, 1 Oct 2006 12:32:46 -0400
Subject: sys.settrace closure interaction bug
Message-ID: <e3f9e0dd0610010932l30594867pd8d6b862759986d@mail.gmail.com>

The code below exhibits different behavior depending on whether it invokes
sys.settrace ('-t' option) or not.  This means that (in a more complicated
case) debugging the code (which uses sys.settrace) makes it fail.  Any
ideas?

""" Demonstrace that tracing messes up curried class definitions """

# Some simple command line parsing: -t or --trace means trace, nothing means
don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-bugs-list/attachments/20061001/4b8bfa09/attachment.html 

From jeremy at alum.mit.edu  Wed Oct  4 04:07:06 2006
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 3 Oct 2006 22:07:06 -0400
Subject: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try
	statement
In-Reply-To: <E1GUmIV-0001oC-Mq@sc8-sf-web3.sourceforge.net>
References: <E1GUmIV-0001oC-Mq@sc8-sf-web3.sourceforge.net>
Message-ID: <e8bf7a530610031907mb689eacnb5a67559eeeaea90@mail.gmail.com>

I'm working on this bug now, but can't get an SF login to update the bug report.

Jeremy

On 10/3/06, SourceForge.net <noreply at sourceforge.net> wrote:
> Bugs item #1569998, was opened at 2006-10-03 14:04
> Message generated for change (Settings changed) made by gbrandl
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470
>
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: Parser/Compiler
> Group: Python 2.5
> Status: Open
> Resolution: None
> >Priority: 8
> Submitted By: Nick Coghlan (ncoghlan)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: 2.5 incorrectly permits break inside try statement
>
> Initial Comment:
> The new AST compiler permits the break statement inside
> *any* frame block, rather than requiring that there be
> a loop somewhere on the block stack.
>
> Will add examples in a comment where SF shouldn't
> destroy the formatting.
>
> ----------------------------------------------------------------------
>
> Comment By: Nick Coghlan (ncoghlan)
> Date: 2006-10-03 14:05
>
> Message:
> Logged In: YES
> user_id=1038590
>
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more
> information.
> >>> try:
> ...     print 1
> ...     break
> ...     print 2
> ... finally:
> ...     print 3
> ...
> SyntaxError: 'break' outside loop
>
> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
> bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more
> information.>>> try:
> ...     print 1
> ...     break
> ...     print 2
> ... finally:
> ...     print 3
> ...
> 1
> 3
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From noreply at sourceforge.net  Wed Oct  4 04:32:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 19:32:30 -0700
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GUwYg-00046b-Fh@sc8-sf-web6.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by scott_marks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Martin v. L?wis (loewis)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

>Comment By: applebucks (scott_marks)
Date: 2006-10-03 22:32

Message:
Logged In: YES 
user_id=120857

"Cannot be fixed" sounds pretty final, and also a little
pessimistic.  From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does.  In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.

Not to mention that the workaround ("be sure to rename your
class factory function parameters so that they don't collide
with intended attributes of the created class") just makes
Python seem ... lame.

I hope for a more optimistic reply.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 02:49

Message:
Logged In: YES 
user_id=849994

I'm afraid that this cannot be fixed.

In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.

If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.

Martin, do you you have an additional opinion?

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

Comment By: applebucks (scott_marks)
Date: 2006-10-02 12:02

Message:
Logged In: YES 
user_id=120857

This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation.  The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.

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

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

From noreply at sourceforge.net  Wed Oct  4 04:45:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 19:45:05 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GUwkr-0004VQ-SO@sc8-sf-web2.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 12:19
Message generated for change (Comment added) made by jordanramz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-03 21:45

Message:
Logged In: YES 
user_id=1604497

The problem is that it is my laptop, so I am the 
administrator.  I booted up in safe mode so that I could 
log on as the administrator, and even then it wouldn't let 
me access any of my (username) documents, so I couldn't 
even get in to view that folder let alone change the 
name.  

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

Comment By: dani (daniboy22)
Date: 2006-10-03 08:33

Message:
Logged In: YES 
user_id=1604341

Well, I'm also not a specialist on the subject, but in my
case I don't have any problems in opening the folder. I just
had some problems to rename it (it didn't accepted a name
starting with a "."), but I resolve it (I rename it to "pinga").

Concerning your problem, my hint is that your account is not
an administrator one. Try to enter as an administrator and
make the necessary changes. Or else change the permissions
of your account to the "administrator" type (ask someone
that is already an administrator on that computer to do that).

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-02 17:15

Message:
Logged In: YES 
user_id=1604497

Thanks for that, I found it.  However, I guess I'm not as 
skilled with the computer as I thought...  It won't let me 
change the name, open the folder etc.  It says access is 
denied.  Know why it's doing that when I try to modify it?

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

Comment By: dani (daniboy22)
Date: 2006-10-02 09:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 09:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 11:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-09-30 21:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 16:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Wed Oct  4 05:45:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 20:45:52 -0700
Subject: [ python-Bugs-1570417 ] 2.4 & 2.5 can't create win installer on linux
Message-ID: <E1GUxhg-0004hG-NR@sc8-sf-web5.sourceforge.net>

Bugs item #1570417, was opened at 2006-10-04 13:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4 & 2.5 can't create win installer on linux

Initial Comment:
With python 2.4.3 and 2.5 I can't build a Windows 
installer on Linux. I get the following error:

Warning: Can't read registry to find the necessary 
compiler setting
Make sure that Python modules _winreg, win32api or 
win32con are installed.
removing 'build/bdist.linux-i686/wininst' (and 
everything under it)


I can still create an installer with 2.3.5

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

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

From noreply at sourceforge.net  Wed Oct  4 07:02:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 22:02:48 -0700
Subject: [ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Message-ID: <E1GUyu8-0001ll-3g@sc8-sf-web6.sourceforge.net>

Bugs item #1484556, was opened at 2006-05-09 03:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Output of KlocWork on Python2.4.3 sources

Initial Comment:
We're evaluating KlocWork (http://www.klocwork.com),
I've ran it on the source of Python 2.4.3 and the
output is attached (1562 warnings).

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-03 22:02

Message:
Logged In: YES 
user_id=33168

Right, all the important changes have been fixed AFAIK. 
There might be a few that slipped through, but we are in
good enough shape.

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

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-03 05:02

Message:
Logged In: YES 
user_id=21627

Ok, let's close this report, then. We continue to monitor
Klocwork, regardless.

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

Comment By: Miki Tebeka (tebeka)
Date: 2006-10-03 01:24

Message:
Logged In: YES 
user_id=358087

I don't know, currently KlocWork is way down in my "todo"
list :(

Looks like I won't be able to continue in this matter any
longer, if anyone else want to give a hand ...

Miki

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 04:34

Message:
Logged In: YES 
user_id=849994

Have all KlocWork issues been fixed now, Neal?

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

Comment By: Miki Tebeka (tebeka)
Date: 2006-06-04 02:53

Message:
Logged In: YES 
user_id=358087

I'll try to see if I can sneak it in, can't promise anything
though

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 07:26

Message:
Logged In: YES 
user_id=11375

The Coverity scans also probably report some of the same
bugs, so many of these problems may be fixed in the 2.5 trunk.  

If you're still evaluating, you could try running the tool
on the 2.5 trunk (snapshot available from
http://svn.python.org/snapshots/) and see if the results are
shorter.


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

Comment By: Martin v. L?wis (loewis)
Date: 2006-05-09 21:45

Message:
Logged In: YES 
user_id=21627

Thanks for these results. Unfortunately, they seem to
contain many false positives, so it is unclear how one
should proceed with them.

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

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

From noreply at sourceforge.net  Wed Oct  4 07:47:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 22:47:27 -0700
Subject: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try
	statement
Message-ID: <E1GUzbL-00084B-FK@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 8
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.5 incorrectly permits break inside try statement

Initial Comment:
The new AST compiler permits the break statement inside
*any* frame block, rather than requiring that there be
a loop somewhere on the block stack.

Will add examples in a comment where SF shouldn't
destroy the formatting.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-03 22:47

Message:
Logged In: YES 
user_id=33168

Jeremy checked in r52129 on head.  Needs backport to 2.5.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-10-03 07:05

Message:
Logged In: YES 
user_id=1038590

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
SyntaxError: 'break' outside loop

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
1
3

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

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

From noreply at sourceforge.net  Wed Oct  4 07:48:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 22:48:35 -0700
Subject: [ python-Bugs-1570284 ] Launcher reset to factory button provides bad
	command-line
Message-ID: <E1GUzcR-0008AG-J0@sc8-sf-web5.sourceforge.net>

Bugs item #1570284, was opened at 2006-10-03 14:17
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: jjackson (jejackson)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Launcher reset to factory button provides bad command-line

Initial Comment:
If I push the "Reset to factory settings" in Python Launcher's Preferences 
window, the command line gets a bogues "(null)" inserted, which makes a 
mess of things. I don't think that was what was intended.

In trying to debug this, I notice in the source for FileSettings.m, at line 
209
there are two duplicated lines:

            [NSNumber numberWithBool: nosite], @"nosite",
            [NSNumber numberWithBool: nosite], @"nosite",

Also, I notice at FileSettings.m:236

    value = [dict objectForKey: @"nosite"];
    if (value) nosite = [value boolValue];
    value = [dict objectForKey: @"nosite"];
    if (value) tabs = [value boolValue];

I'm wondering if these second "nosite"s should be "tabs", and if that 
would fix the problem.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-03 22:48

Message:
Logged In: YES 
user_id=33168

Ronald, I'm guessing that Jack still doesn't have time.  Do
you know anything about this?

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

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

From noreply at sourceforge.net  Wed Oct  4 07:58:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 22:58:13 -0700
Subject: [ python-Bugs-1446043 ] unicode('foo',
	'.utf99') does not raise LookupError 
Message-ID: <E1GUzll-00014m-50@sc8-sf-web3.sourceforge.net>

Bugs item #1446043, was opened at 2006-03-08 16:55
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 8
Submitted By: osvenskan (osvenskan)
>Assigned to: A.M. Kuchling (akuchling)
Summary: unicode('foo', '.utf99') does not raise LookupError 

Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.

I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-03 22:58

Message:
Logged In: YES 
user_id=33168

I thought part of this was reverted, but I'm not sure if it
was reverted in 2.4.  I know I had starred this for some
reason, but I don't recall exactly.  This should be
investigated.  I'm not sure there was a test for this either.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 04:22

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 52075, 52076 (2.4), 52077 (2.5).

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 12:17

Message:
Logged In: YES 
user_id=849994

I'd say that this should be fixed before 2.5 final.

Attached patch (the modname that's used for import may not
contain a dot anymore...)

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

Comment By: osvenskan (osvenskan)
Date: 2006-04-06 07:45

Message:
Logged In: YES 
user_id=1119995

I noticed that the documentation for unicode() says, "if the
encoding is not known, LookupError is raised". Regarding the
3rd parameter ("errors") to unicode(), the docs say, "Error
handling is done according to errors; this specifies the
treatment of characters which are invalid in the input
encoding. If errors is 'strict' (the default), a ValueError
is raised on errors..."
ref: http://docs.python.org/lib/built-in-funcs.html

That makes the code's current behavior doubly confusing
because a the documentation says that a ValueError is
reserved for indicating an undecodable byte sequence, not an
unknown encoding name.


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

Comment By: osvenskan (osvenskan)
Date: 2006-03-09 07:04

Message:
Logged In: YES 
user_id=1119995

There are encoding names that contain dots, such as
ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as
reported by iconv). There are none in iconv's list that
begin with a dot. 

Please note that the behavior of this function has been
discussed before in Python bugs 513666 and 960874. Apologies
for not referencing them in my original report. 

Having stepped through the code, I understand how the
ValueError is getting generated. My frustration with this as
a programmer is that I want to write specific except clauses
for each possible exception that a method can raise, but
that's impractical if any exception is fair game on any
method. So I'm forced to use a catch-all except clause about
which the Python documentation says (wisely, IMHO), "Use
this with extreme caution, since it is easy to mask a real
programming error in this way!" While it is helpful to
document errors that a method is *likely* to raise, my code
needs to handle all possibilities, not just likely ones.

Perhaps the answer is just, "This is how Python works" and
if I feel it is a weakness in the language I need to take it
up on a different level. 

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 00:16

Message:
Logged In: YES 
user_id=849994

Is it possible for an encoding name to contain dots at all?

If not, this would do too:
if '.' in modname: continue

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

Comment By: Walter D?rwald (doerwalter)
Date: 2006-03-09 00:12

Message:
Logged In: YES 
user_id=89016

The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:

if ".".join(filter(None, modname.split("."))) != modname:
   return None


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

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

From noreply at sourceforge.net  Wed Oct  4 08:30:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Oct 2006 23:30:03 -0700
Subject: [ python-Bugs-1570417 ] 2.4 & 2.5 can't create win installer on linux
Message-ID: <E1GV0GZ-0000tL-4T@sc8-sf-web2.sourceforge.net>

Bugs item #1570417, was opened at 2006-10-04 05:45
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
>Assigned to: Thomas Heller (theller)
Summary: 2.4 & 2.5 can't create win installer on linux

Initial Comment:
With python 2.4.3 and 2.5 I can't build a Windows 
installer on Linux. I get the following error:

Warning: Can't read registry to find the necessary 
compiler setting
Make sure that Python modules _winreg, win32api or 
win32con are installed.
removing 'build/bdist.linux-i686/wininst' (and 
everything under it)


I can still create an installer with 2.3.5

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

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-04 08:30

Message:
Logged In: YES 
user_id=21627

The message you get is a warning only; you can ignore it.

However, it still fails because it can't determine what
msvcrt version the target python was built with. It needs to
find that out because it needs to decide whether to use
wininst-6.exe or wininst-7.1.exe.

Thomas, can you think of a way to fix this?

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

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

From noreply at sourceforge.net  Wed Oct  4 14:22:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 05:22:28 -0700
Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer
	overflows
Message-ID: <E1GV5lc-0004TM-FM@sc8-sf-web5.sourceforge.net>

Bugs item #1545668, was opened at 2006-08-24 03:14
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 9
Submitted By: Jack Howarth (jwhowarth)
Assigned to: Armin Rigo (arigo)
Summary: gcc trunk (4.2) exposes a signed integer overflows

Initial Comment:
While building python 2.4.3 with the current gcc trunk (soon to be 4.2), 
I uncovered a signed integer overflows bug in Python with the help of 
one of the gcc developers. The bug I observed is documented in this 
gcc mailing list message...

http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html

The gcc developer comments about its origin are in the messages...

http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html

which in short says...

It *is* a bug in python, here is the proof:
https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/
Objects/intobject.c?revision=25647&view=markup
Function

* i_divmod*(*register* *long* x, *register* *long* y,

the following lines:

/        /* (-sys.maxint-1)/-1 is the only overflow case. *//
	*if* (y == -1 && x < 0 && x == -x)
		*return* DIVMOD_OVERFLOW;

If overflow is barred then x==-x may happen only when x==0.
This conflicts with x<0, which means that the compiler may assume
that
  x<0 && x==-x
always yields false. This may allow the compiler to eliminate the whole 
if
statement. Hence, clearly python is at fault.

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

>Comment By: Armin Rigo (arigo)
Date: 2006-10-04 12:22

Message:
Logged In: YES 
user_id=4771

Checked in: r52136 (2.4)
            r52138 (2.5)
            r52139 (2.6)

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

Comment By: Armin Rigo (arigo)
Date: 2006-10-03 10:17

Message:
Logged In: YES 
user_id=4771

I'd like to review this in 2.4/2.5/trunk before the 2.4.4
release.

Debian "testing" ships with everything compiled with the
faulty gcc -- even though this gcc is not released yet!  I
hate Debian's policies.  "Fixing" 2.4.4 would help me a bit
to get a reasonable Python installation on Debian machines
where I have to log to (assuming the sysadmin knew he had
to fish 72 small packages to get just a complete stdlib,
that is, but that's another matter).

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

Comment By: Armin Rigo (arigo)
Date: 2006-09-16 11:28

Message:
Logged In: YES 
user_id=4771

More of the same kind of problem:
abs(-sys.maxint-1) sometimes gives -sys.maxint-1.
It would be a good idea to review all places that need
to special-case -sys.maxint-1 for overflow detection.
(It would be a still better idea to review all overflow
detection code, but that may have to wait after the
2.5 release).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-05 04:04

Message:
Logged In: YES 
user_id=33168

Tim checked in fixes for 2.6 (r51716), 2.5 (r51711), and 2.4.



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

Comment By: David Hopwood (dhopwood)
Date: 2006-08-26 23:24

Message:
Logged In: YES 
user_id=634468

The correct patch is the one that uses

if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)

The one that uses (unsigned int)x will break some 64-bit
platforms where int != long.

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

Comment By: Tim Peters (tim_one)
Date: 2006-08-26 20:33

Message:
Logged In: YES 
user_id=31435

Boosted priority to 8 since it was brought up on python-dev
as a suggested 2.5 release-blocker.  The patch in the first
comment looks fine, if a release manager wants to apply it.

Python 2.4 surely has the same "issue".

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

Comment By: Tim Peters (tim_one)
Date: 2006-08-26 20:25

Message:
Logged In: YES 
user_id=31435

Looks like the same deal as bug 1521947 (which was about
similar code in PyOS_strtol()).

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

Comment By: Jack Howarth (jwhowarth)
Date: 2006-08-24 15:22

Message:
Logged In: YES 
user_id=403009

Everyone involved in reviewing this patch should definitely
read the following sequence of gcc mailing list messages
which show the process by which this patch was arrived at...

http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html

So we have had lots of gcc developer eyes on this
problem and they all agree on the flaw and the fix
as posted. It's unfortunate that I had to abuse their
mailing list to get this addressed before python 2.5
gets released.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 15:00

Message:
Logged In: YES 
user_id=33168

I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't
spot any other occurrences.

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2006-08-24 14:54

Message:
Logged In: YES 
user_id=43607

Just a comment, I'm not claiming this bug.

The test (x < 0 && x == -x) tests whether x is equal to the
smallest negative number.  If x is equal to -2147483648,
then -x is also equal to -2147483648 due to overflow.

What does this version of gcc do with this code when x =
-2147483648?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 14:54

Message:
Logged In: YES 
user_id=33168

Assigning to Tim, he likes these problems. :-)
He recently fixed a similar problem in another piece of
code.  I'm going to try to grep and see if I can find more
occurrences of this.

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

Comment By: Jack Jansen (jackjansen)
Date: 2006-08-24 14:37

Message:
Logged In: YES 
user_id=45365

Hmm... intobject.c doesn't really have a "champion"...

Neal, I'm assigning this to you purely on the ground that you're the last person 
to have edited this file. Feel free to pass on (but not back:-).

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

Comment By: Jack Howarth (jwhowarth)
Date: 2006-08-24 11:22

Message:
Logged In: YES 
user_id=403009

The was a few other comments from the gcc developers on the proposed 
fix...

http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html

...so that since x is a long the more correct fix is...

--- Python-2.4.3/Objects/intobject.c.org        2006-08-24 
07:06:51.000000000 -0400
+++ Python-2.4.3/Objects/intobject.c    2006-08-24 07:08:06.000000000 
-0400
@@ -479,7 +479,7 @@
                return DIVMOD_ERROR;
        }
        /* (-sys.maxint-1)/-1 is the only overflow case. */
-       if (y == -1 && x < 0 && x == -x)
+       if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x)
                return DIVMOD_OVERFLOW;
        xdivy = x / y;
        xmody = x - xdivy * y;

I have tested this form of the patch and it works as well. My main concern is 
that we get this fix in python 2.5 before release. Jack, could you reassign this 
to the person you think might be most appropriate out of the list of python 
developers? I really should be a pretty simple review for the patch.


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

Comment By: Jack Jansen (jackjansen)
Date: 2006-08-24 09:14

Message:
Logged In: YES 
user_id=45365

I don't think this is a mac-specific bug, and I'm also not really the right person 
to look into this...

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

Comment By: Jack Howarth (jwhowarth)
Date: 2006-08-24 04:13

Message:
Logged In: YES 
user_id=403009

As suggested by another gcc developer in...

http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html

...the following patch eliminates the error when python is built with gcc 
trunk...

--- Python-2.4.3/Objects/intobject.c.org        2006-08-23 
23:49:33.000000000 -0400
+++ Python-2.4.3/Objects/intobject.c    2006-08-23 23:52:01.000000000 
-0400
@@ -479,7 +479,7 @@
                return DIVMOD_ERROR;
        }
        /* (-sys.maxint-1)/-1 is the only overflow case. */
-       if (y == -1 && x < 0 && x == -x)
+       if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x)
                return DIVMOD_OVERFLOW;
        xdivy = x / y;
        xmody = x - xdivy * y;

This change allows python to completely pass its make check now when built 
with gcc trunk.

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

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

From noreply at sourceforge.net  Wed Oct  4 14:24:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 05:24:11 -0700
Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Message-ID: <E1GV5nH-00052P-4v@sc8-sf-web3.sourceforge.net>

Bugs item #1521947, was opened at 2006-07-13 17:39
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

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

>Comment By: Armin Rigo (arigo)
Date: 2006-10-04 12:24

Message:
Logged In: YES 
user_id=4771

Ok.  Done within the larger r52136-52139.

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

Comment By: Tim Peters (tim_one)
Date: 2006-10-03 10:35

Message:
Logged In: YES 
user_id=31435

> Based on the other bug I guess that casting an arbitrary
> long to unsigned long is allowed.

Right, C defines the result of casting any integral type to
any unsigned integral type.

> If so, then maybe we could use the following test:
>
>  if (sign == '-' && uresult == 0-(unsigned
long)LONG_MIN) {
>      result = LONG_MIN;
>  }
>
> which states the intention a bit more clearly and
> without the assert().

We could.  It's not really clearer to me, given that the
current code is explained in a comment block before
PyOS_strtol(), and I couldn't care less about removing an
assert, so I'm not going to bother.  I wouldn't object to
changing it, although "0-" instead of plain unary "-" also
begs for an explanation lest someone delete the "0" because
it looks plain silly.

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

Comment By: Armin Rigo (arigo)
Date: 2006-10-03 10:10

Message:
Logged In: YES 
user_id=4771

Based on the other bug I guess that casting an arbitrary
long to unsigned long is allowed.  If so, then maybe we could
use the following test:

  if (sign == '-' && uresult == 0-(unsigned long)LONG_MIN) {
      result = LONG_MIN;
  }

which states the intention a bit more clearly and without the
assert().

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

Comment By: Tim Peters (tim_one)
Date: 2006-09-05 05:21

Message:
Logged In: YES 
user_id=31435

Well, I deliberately avoided using LONG_MIN in the patches
for the other bug, so that should answer your question ;-)

If someone wants to take the small risk of backporting it,
fine by me -- it's not going to break on Windows, and if it
doesn't break on your box either ...

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-05 05:12

Message:
Logged In: YES 
user_id=33168

Tim, how do you feel about backporting now?  (Not sure if
your opinion changed based on the other bug.)  That and I'm
cleaning out my mailbox, so I don't have to look at this any
more. :-)

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

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 21:00

Message:
Logged In: YES 
user_id=31435

Neal, as I said in the checkin comment, I expect it's no
less likely that we'll get screwed by goofy platform values
for LONG_MIN and LONG_MAX than that we /got/ screwed by an
"over ambitious" compiler optimizing away "result ==
-result", so I'm not sure backporting is a good idea.  I
stuck in an assert that might fail if a platform is insane;
if there are no reports of that assert triggering, then I'd
feel better about backporting the change.

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-07-27 10:49

Message:
Logged In: YES 
user_id=1126061

Fixed for me on NetBSD -current AMD64, gcc 4.1.2

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

Comment By: Nick Maclaren (nmm)
Date: 2006-07-27 08:31

Message:
Logged In: YES 
user_id=42444

Fixed for me, too, and the code looks solid.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:48

Message:
Logged In: YES 
user_id=33168

I reopened this bug as it still affects 2.4.  Tim's fix
should be backported.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

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

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 01:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

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

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

    1) Casting and unsigned long to long above LONG_MAX.
    2) That test.
    3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

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

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

From noreply at sourceforge.net  Wed Oct  4 16:33:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 07:33:41 -0700
Subject: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try
	statement
Message-ID: <E1GV7ob-0004Y0-8Q@sc8-sf-web4.sourceforge.net>

Bugs item #1569998, was opened at 2006-10-03 14:04
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Nick Coghlan (ncoghlan)
>Assigned to: Jeremy Hylton (jhylton)
Summary: 2.5 incorrectly permits break inside try statement

Initial Comment:
The new AST compiler permits the break statement inside
*any* frame block, rather than requiring that there be
a loop somewhere on the block stack.

Will add examples in a comment where SF shouldn't
destroy the formatting.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2006-10-04 14:33

Message:
Logged In: YES 
user_id=31392

Fixed on the trunk by r52129. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-04 05:47

Message:
Logged In: YES 
user_id=33168

Jeremy checked in r52129 on head.  Needs backport to 2.5.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-10-03 14:05

Message:
Logged In: YES 
user_id=1038590

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
SyntaxError: 'break' outside loop

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
1
3

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

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

From noreply at sourceforge.net  Wed Oct  4 16:38:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 07:38:59 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GV7tj-0006aU-7E@sc8-sf-web2.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 17:19
Message generated for change (Comment added) made by daniboy22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

>Comment By: dani (daniboy22)
Date: 2006-10-04 14:38

Message:
Logged In: YES 
user_id=1604341

Usually I do not need to boot on safe mode to log in as
asministrator (I also work on a laptop)... The safe mode
reduces some of the Windows functionalities... Perhaps this
is the real reason for your problem.

Otherwise, I don't know what to tell you more... :-(

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-04 02:45

Message:
Logged In: YES 
user_id=1604497

The problem is that it is my laptop, so I am the 
administrator.  I booted up in safe mode so that I could 
log on as the administrator, and even then it wouldn't let 
me access any of my (username) documents, so I couldn't 
even get in to view that folder let alone change the 
name.  

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

Comment By: dani (daniboy22)
Date: 2006-10-03 13:33

Message:
Logged In: YES 
user_id=1604341

Well, I'm also not a specialist on the subject, but in my
case I don't have any problems in opening the folder. I just
had some problems to rename it (it didn't accepted a name
starting with a "."), but I resolve it (I rename it to "pinga").

Concerning your problem, my hint is that your account is not
an administrator one. Try to enter as an administrator and
make the necessary changes. Or else change the permissions
of your account to the "administrator" type (ask someone
that is already an administrator on that computer to do that).

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-02 22:15

Message:
Logged In: YES 
user_id=1604497

Thanks for that, I found it.  However, I guess I'm not as 
skilled with the computer as I thought...  It won't let me 
change the name, open the folder etc.  It says access is 
denied.  Know why it's doing that when I try to modify it?

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

Comment By: dani (daniboy22)
Date: 2006-10-02 14:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 14:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 16:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 02:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 21:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Wed Oct  4 22:29:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 13:29:38 -0700
Subject: [ python-Feature Requests-1567948 ] poplib.py list interface
Message-ID: <E1GVDN4-0007eA-Mk@sc8-sf-web2.sourceforge.net>

Feature Requests item #1567948, was opened at 2006-09-29 11:51
Message generated for change (Comment added) made by hdiwan650
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567948&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: poplib.py list interface

Initial Comment:
Adds a list-like interface to poplib.py, poplib_as_list.

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

>Comment By: Hasan Diwan (hdiwan650)
Date: 2006-10-04 13:29

Message:
Logged In: YES 
user_id=1185570

I changed it a little bit, added my name at the top of the
file as the maintainer. 

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

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

From noreply at sourceforge.net  Wed Oct  4 23:13:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 14:13:34 -0700
Subject: [ python-Feature Requests-1567948 ] poplib.py list interface
Message-ID: <E1GVE3a-0001s5-53@sc8-sf-web4.sourceforge.net>

Feature Requests item #1567948, was opened at 2006-09-29 14:51
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567948&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: poplib.py list interface

Initial Comment:
Adds a list-like interface to poplib.py, poplib_as_list.

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

Comment By: Jp Calderone (kuran)
Date: 2006-10-04 17:13

Message:
Logged In: YES 
user_id=366566

Some review comments:

  * poplib_as_list should have a class docstring explaining
its purpose.  The name is fairly suggestive, but some prose
would be better.

  * Why duplicate the arguments to POP3_SSL and POP3 in
poplib_as_list.__init__?  Wouldn't it be better if it took
an already-constructed POP3 or POP3_SSL instance?

  * Does subclassing list really buy much here?  None of the
overridden methods upcall, and many list methods aren't
implemented here at all: what if someone calls pop on a
poplib_as_list instance?  Ditto for a bunch of other
operations that one might expect to work on a list.

  * __getslice__ is buggy - the return statement is indented
too far.  __getitem__ and __delitem__ will also pass a slice
instance on the underlying pop method when extended slices
are used.

  * segue from the previous comment - unit tests?  Python
has pretty low overall coverage, but all new code at least
can benefit from being committed initially with a
comprehensive test suite.

  * The docstrings on all of the methods that have them are
pretty good, although the __getattribute__ docstring is more
of an implementation note.

  * Should the library reference be updated as well?

Overall, I'm not sure how useful this feature is.  A generic
wrapper class would probably be beneficial to more people.


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

Comment By: Hasan Diwan (hdiwan650)
Date: 2006-10-04 16:29

Message:
Logged In: YES 
user_id=1185570

I changed it a little bit, added my name at the top of the
file as the maintainer. 

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

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

From noreply at sourceforge.net  Thu Oct  5 00:38:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 15:38:09 -0700
Subject: [ python-Feature Requests-1567948 ] poplib.py list interface
Message-ID: <E1GVFNR-0005If-7G@sc8-sf-web1.sourceforge.net>

Feature Requests item #1567948, was opened at 2006-09-29 11:51
Message generated for change (Comment added) made by hdiwan650
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567948&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: poplib.py list interface

Initial Comment:
Adds a list-like interface to poplib.py, poplib_as_list.

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

>Comment By: Hasan Diwan (hdiwan650)
Date: 2006-10-04 15:38

Message:
Logged In: YES 
user_id=1185570

I'm going to address your points top to bottom:
1. Fixed, you're right it should and does now.
2. The idea of a list wrapper is to serve as a convenient
interface to the most commonly used methods of a poplib
instance while hiding the underlying class(es).
3. Subclassing list was a mistake, I was merely trying to
provide an idea for the interface. Summarily removed.
4. __getslice__ fixed.
5. Unit tests will take a little longer because we need to
make a dummy poplib instances to test with.
6. __getattribute__ docstring dropped.
7. I don't know, should it?

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

Comment By: Jp Calderone (kuran)
Date: 2006-10-04 14:13

Message:
Logged In: YES 
user_id=366566

Some review comments:

  * poplib_as_list should have a class docstring explaining
its purpose.  The name is fairly suggestive, but some prose
would be better.

  * Why duplicate the arguments to POP3_SSL and POP3 in
poplib_as_list.__init__?  Wouldn't it be better if it took
an already-constructed POP3 or POP3_SSL instance?

  * Does subclassing list really buy much here?  None of the
overridden methods upcall, and many list methods aren't
implemented here at all: what if someone calls pop on a
poplib_as_list instance?  Ditto for a bunch of other
operations that one might expect to work on a list.

  * __getslice__ is buggy - the return statement is indented
too far.  __getitem__ and __delitem__ will also pass a slice
instance on the underlying pop method when extended slices
are used.

  * segue from the previous comment - unit tests?  Python
has pretty low overall coverage, but all new code at least
can benefit from being committed initially with a
comprehensive test suite.

  * The docstrings on all of the methods that have them are
pretty good, although the __getattribute__ docstring is more
of an implementation note.

  * Should the library reference be updated as well?

Overall, I'm not sure how useful this feature is.  A generic
wrapper class would probably be beneficial to more people.


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

Comment By: Hasan Diwan (hdiwan650)
Date: 2006-10-04 13:29

Message:
Logged In: YES 
user_id=1185570

I changed it a little bit, added my name at the top of the
file as the maintainer. 

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

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

From noreply at sourceforge.net  Thu Oct  5 01:31:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 16:31:48 -0700
Subject: [ python-Bugs-1571023 ] _ssl module can't be built on windows
Message-ID: <E1GVGDM-00008H-Gk@sc8-sf-web2.sourceforge.net>

Bugs item #1571023, was opened at 2006-10-05 01:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571023&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: _ssl module can't be built on windows

Initial Comment:

Revision 52152 on the release24-maint branch
updated the OpenSSL package to version 0.9.7l,
which causes linking errors due to unresolved
symbols. 

This can be fixed with a backport of patch 1197150:
http://www.python.org/sf/1197150


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

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

From noreply at sourceforge.net  Thu Oct  5 01:58:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 16:58:07 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GVGcp-0006ZV-7u@sc8-sf-web3.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 12:19
Message generated for change (Comment added) made by jordanramz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-04 18:58

Message:
Logged In: YES 
user_id=1604497

Well I think there is just a problem with my OS files or 
something anyway.  There are a couple other things (i.e. 
my "Recent Documents" folder) that do the same thing, even 
when I'm logged on as myself.  Thanks for the help 
though.  I need something to run and find/fix errors with 
my system, but not sure what the best program is.  If you 
know of any, could you let me know. :)  Thanks

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

Comment By: dani (daniboy22)
Date: 2006-10-04 09:38

Message:
Logged In: YES 
user_id=1604341

Usually I do not need to boot on safe mode to log in as
asministrator (I also work on a laptop)... The safe mode
reduces some of the Windows functionalities... Perhaps this
is the real reason for your problem.

Otherwise, I don't know what to tell you more... :-(

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-03 21:45

Message:
Logged In: YES 
user_id=1604497

The problem is that it is my laptop, so I am the 
administrator.  I booted up in safe mode so that I could 
log on as the administrator, and even then it wouldn't let 
me access any of my (username) documents, so I couldn't 
even get in to view that folder let alone change the 
name.  

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

Comment By: dani (daniboy22)
Date: 2006-10-03 08:33

Message:
Logged In: YES 
user_id=1604341

Well, I'm also not a specialist on the subject, but in my
case I don't have any problems in opening the folder. I just
had some problems to rename it (it didn't accepted a name
starting with a "."), but I resolve it (I rename it to "pinga").

Concerning your problem, my hint is that your account is not
an administrator one. Try to enter as an administrator and
make the necessary changes. Or else change the permissions
of your account to the "administrator" type (ask someone
that is already an administrator on that computer to do that).

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-02 17:15

Message:
Logged In: YES 
user_id=1604497

Thanks for that, I found it.  However, I guess I'm not as 
skilled with the computer as I thought...  It won't let me 
change the name, open the folder etc.  It says access is 
denied.  Know why it's doing that when I try to modify it?

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

Comment By: dani (daniboy22)
Date: 2006-10-02 09:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 09:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 11:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-09-30 21:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 16:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Thu Oct  5 06:46:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 21:46:39 -0700
Subject: [ python-Bugs-1571112 ] simple moves freeze IDLE
Message-ID: <E1GVL83-0008FT-1N@sc8-sf-web5.sourceforge.net>

Bugs item #1571112, was opened at 2006-10-04 21:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas W. Goodall (douglas_goodall)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple moves freeze IDLE

Initial Comment:
Using version 2.5 for Windows...

import os

then type "print os." and wait for the 
hint window. then scroll to the bottom (spawnv).

That's it. At this point IDLE is frozen.

I have done it a few times in a row. It seems
very reproduceable to me.

Be well. Doug

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

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

From noreply at sourceforge.net  Thu Oct  5 07:38:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Oct 2006 22:38:15 -0700
Subject: [ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Message-ID: <E1GVLvz-0000Np-LA@sc8-sf-web4.sourceforge.net>

Bugs item #1569517, was opened at 2006-10-02 12:54
Message generated for change (Comment added) made by douglas_goodall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Coatimundi (coatimundi)
Assigned to: Kristj?n Valur (krisvale)
Summary: PGIRelease linkage fails on pgodb80.dll

Initial Comment:
Hi.  I'm interested in learning how to optimize Python
for Windows.  I have made a similar report as a
follow-on to Bug 1568243, but it's really a  separate
issue.

Let me emphasize that what I am about to describe this
is *not* a bug in the Python build system.  But it may
be worth calling out in the README file for PCbuild8.

When building PGIRelease to instrument the pythoncore
DLL, the linker fails because it cannot find
pgodb80.dll.  This file is required for PGO with Visual
C++ under Visual Studio 2005 and is shipped with the
Professional version, but not with the Express version
or (apparently) the Standard version I have.  Looks
like upgrade time...

I hope this helps someone else.


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

Comment By: Douglas W. Goodall (douglas_goodall)
Date: 2006-10-04 22:38

Message:
Logged In: YES 
user_id=1553177

I hate Microsoft. I have VS 2005 Standard also. Bill 
always sticks it to you in the end.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 05:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

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

From noreply at sourceforge.net  Thu Oct  5 09:31:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 00:31:51 -0700
Subject: [ python-Bugs-1571170 ] Some numeric characters are still not
	recognized
Message-ID: <E1GVNhv-0000tC-DF@sc8-sf-web3.sourceforge.net>

Bugs item #1571170, was opened at 2006-10-05 09:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571170&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Chrigstr?m (andersch)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Some numeric characters are still not recognized

Initial Comment:
Looking into the documentation of the unicode database
i found that there are some numeric characters that are
not listed in the UnicodeData.txt file. They are intead
listen in the Unihan.txt file. (See
http://www.unicode.org/Public/5.0.0/ucd/UCD.html#Numeric_Type_Han).

I have a patch for this in the works.



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

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

From noreply at sourceforge.net  Thu Oct  5 10:05:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 01:05:14 -0700
Subject: [ python-Bugs-1571170 ] Some numeric characters are still not
	recognized
Message-ID: <E1GVOEE-0002KL-Mz@sc8-sf-web5.sourceforge.net>

Bugs item #1571170, was opened at 2006-10-05 09:31
Message generated for change (Comment added) made by andersch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571170&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Chrigstr?m (andersch)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Some numeric characters are still not recognized

Initial Comment:
Looking into the documentation of the unicode database
i found that there are some numeric characters that are
not listed in the UnicodeData.txt file. They are intead
listen in the Unihan.txt file. (See
http://www.unicode.org/Public/5.0.0/ucd/UCD.html#Numeric_Type_Han).

I have a patch for this in the works.



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

>Comment By: Anders Chrigstr?m (andersch)
Date: 2006-10-05 10:05

Message:
Logged In: YES 
user_id=621306

I have uploaded patch #1571184 that fixes this.


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

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

From noreply at sourceforge.net  Thu Oct  5 11:14:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 02:14:41 -0700
Subject: [ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Message-ID: <E1GVPJR-00089B-J3@sc8-sf-web1.sourceforge.net>

Bugs item #1569517, was opened at 2006-10-02 19:54
Message generated for change (Comment added) made by krisvale
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Coatimundi (coatimundi)
Assigned to: Kristj?n Valur (krisvale)
Summary: PGIRelease linkage fails on pgodb80.dll

Initial Comment:
Hi.  I'm interested in learning how to optimize Python
for Windows.  I have made a similar report as a
follow-on to Bug 1568243, but it's really a  separate
issue.

Let me emphasize that what I am about to describe this
is *not* a bug in the Python build system.  But it may
be worth calling out in the README file for PCbuild8.

When building PGIRelease to instrument the pythoncore
DLL, the linker fails because it cannot find
pgodb80.dll.  This file is required for PGO with Visual
C++ under Visual Studio 2005 and is shipped with the
Professional version, but not with the Express version
or (apparently) the Standard version I have.  Looks
like upgrade time...

I hope this helps someone else.


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

>Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:14

Message:
Logged In: YES 
user_id=1262199

This has been fixed in the 2.6 trunk, where the PGO build is
done differently.  I will retrofit that project setting to
2.5 shortly.

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

Comment By: Douglas W. Goodall (douglas_goodall)
Date: 2006-10-05 05:38

Message:
Logged In: YES 
user_id=1553177

I hate Microsoft. I have VS 2005 Standard also. Bill 
always sticks it to you in the end.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 12:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

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

From noreply at sourceforge.net  Thu Oct  5 11:16:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 02:16:14 -0700
Subject: [ python-Bugs-1567910 ] missing _typesmodule.c,
	Visual Studio 2005 pythoncore.vcproj
Message-ID: <E1GVPKw-0008Kj-V1@sc8-sf-web1.sourceforge.net>

Bugs item #1567910, was opened at 2006-09-29 17:47
Message generated for change (Comment added) made by krisvale
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: everbruin (everbruin)
Assigned to: Kristj?n Valur (krisvale)
Summary: missing _typesmodule.c,Visual Studio 2005 pythoncore.vcproj

Initial Comment:
Python 2.5's Visual Studio 2005 pythoncore.vcproj (in
PCBuild8 folder) is missing Modules/_typesmodule.c
(note the VS 2003 pythoncore.vcproj in PCBuild
correctly has it).

The bug is that binaries built w/o the file will give a
SystemError when "import _types" is done (eg by types.py).

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

>Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:16

Message:
Logged In: YES 
user_id=1262199

Hi there.  The .vcproj in the python trunk has these issues
fixed.  I will backport them to 2.5 maintainance shortly.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 12:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

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

Message:
Logged In: YES 
user_id=21627

I find it hard to believe that you get this precise error; I
would have expected that the pythoncore project would fail
to build instead.

Notice that PCbuild8 is not really supported.

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

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

From noreply at sourceforge.net  Thu Oct  5 11:17:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 02:17:12 -0700
Subject: [ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Message-ID: <E1GVPLs-0008Qg-Ff@sc8-sf-web1.sourceforge.net>

Bugs item #1569517, was opened at 2006-10-02 19:54
Message generated for change (Comment added) made by krisvale
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Coatimundi (coatimundi)
Assigned to: Kristj?n Valur (krisvale)
Summary: PGIRelease linkage fails on pgodb80.dll

Initial Comment:
Hi.  I'm interested in learning how to optimize Python
for Windows.  I have made a similar report as a
follow-on to Bug 1568243, but it's really a  separate
issue.

Let me emphasize that what I am about to describe this
is *not* a bug in the Python build system.  But it may
be worth calling out in the README file for PCbuild8.

When building PGIRelease to instrument the pythoncore
DLL, the linker fails because it cannot find
pgodb80.dll.  This file is required for PGO with Visual
C++ under Visual Studio 2005 and is shipped with the
Professional version, but not with the Express version
or (apparently) the Standard version I have.  Looks
like upgrade time...

I hope this helps someone else.


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

>Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:17

Message:
Logged In: YES 
user_id=1262199

the pcbuild8.vcproj in the Python trunk has this fixed.  I
will backport that tho 2.5 shortly.

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

Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:14

Message:
Logged In: YES 
user_id=1262199

This has been fixed in the 2.6 trunk, where the PGO build is
done differently.  I will retrofit that project setting to
2.5 shortly.

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

Comment By: Douglas W. Goodall (douglas_goodall)
Date: 2006-10-05 05:38

Message:
Logged In: YES 
user_id=1553177

I hate Microsoft. I have VS 2005 Standard also. Bill 
always sticks it to you in the end.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 12:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

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

From noreply at sourceforge.net  Thu Oct  5 11:17:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 02:17:31 -0700
Subject: [ python-Bugs-1568243 ] init_types
Message-ID: <E1GVPMB-0008Qy-9U@sc8-sf-web1.sourceforge.net>

Bugs item #1568243, was opened at 2006-09-30 09:34
Message generated for change (Comment added) made by krisvale
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Bosko Vukov (bvukov)
Assigned to: Kristj?n Valur (krisvale)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) ....
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


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

>Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:17

Message:
Logged In: YES 
user_id=1262199

the pcbuild8.vcproj in the Python trunk has this fixed.  I
will backport that tho 2.5 shortly.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 12:11

Message:
Logged In: YES 
user_id=21627

Kristijan, can you please backport your changes to the 2.5
trunk and then close this report?

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 19:22

Message:
Logged In: YES 
user_id=1611513

Thanks, loewis.  I take your advice.  

I see that things have changed in SVN anyway.  I like the
new approach of using Visual STudio's configuration
management.  

When I (try to) build PGIRelease to instrument the python
dll, I get a curious error:

1>Compiling...
1>zlibmodule.c
1>Compiling resources...
1>Linking...
1>   Creating library
Win32\PGIRelease\pythoncore/python26.lib and object
Win32\PGIRelease\pythoncore/python26.exp
1>Generating code
1>c:\Documents and Settings\kferrio\My
Documents\Dev\Python-2.5\Modules\zipimport.c : fatal error
C1350: error loading dll 'pgodb80.dll': dll not found
1>LINK : fatal error LNK1257: code generation failed
1>Build log was saved at "file://c:\Documents and
Settings\kferrio\My
Documents\Dev\Python-2.5\PCbuild8\Win32\PGIRelease\pythoncore\BuildLog.htm"
1>pythoncore - 2 error(s), 2 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0
skipped ==========

I definitely do not understand this -- yet.  Meanwhile, any
clues would be welcome.

Thanks.

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

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

Message:
Logged In: YES 
user_id=21627

I think you should avoid building pythoncore_pgo; it's of no
use. 

Or else, study all documentation you can find on Microsoft's
profile-guided-optimization for a few days, read all web
logs about the bugs in this software, and perhaps you can
succeed in building it, by deleting the right files in the
right order.

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 18:28

Message:
Logged In: YES 
user_id=1611513

I am expereincing the problem described by the original
poster.  I undertand that MSVC8 is not officially supported,
and I'm trying anyway.

I downloaded the 2.5.0 final tarball and began working in
the PCbuild8 directory.

Firts off, I found that I had to build two projects before
pythoncore would build: 

  make_versioninfo
  make_buildinfo

When I tried to build pythoncore, I got the linker error
saying that _init_types could not be found.  So I added
_typesmodule.c to the pythoncore project.  Finally,
pythoncore built cleanly.

Next up, I wanted to build pythoncore_pgo.  So I added 
_typesmodule to this project also.  But try as I might,
every attempt to build pythoncore_pgo produces the link
error on _init_types.  (I also did a 'clean' on pythoncore
just to be safe.)

I do not understand this.  Unlike the original poster, I
have not modified any source.  It seems like the definition
of pyMODINIT_FUNC as extern "C" void might be involved, but
I agree with gbrandl that the static int in Python-ast.c is
not the issue, because that is a different scope.  

So the linkage problem with pythoncore_pgo remains a mystery
to me.  I hope someone has more clues than me.



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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-02 14:00

Message:
Logged In: YES 
user_id=21627

Notice that the PCbuild8 directory isn't really supported...

In any case, the bug is that PCbuild8 does not have the
reference to _typesmodule, not that init_types in
Python-ast.c is static.

If you revert your change to Python-ast.c, and change
pythoncore.vcproj, it should build fine.

This is already fixed in r51751 in the trunk; not sure
whether backporting it is necessary.


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

Comment By: Bosko Vukov (bvukov)
Date: 2006-09-30 17:50

Message:
Logged In: YES 
user_id=1292849

I opened solution file from folder PCbuild8, and inside
project file pythoncore.vcproj there is no reference to
_typesmodule.c. It exists in pythoncore.vcproj in the
PBbuild folder ( for older version's ). I added the missing
_typesmodule.c inside, and returned back the changes I made,
and aft er that linker reported 'Python-ast.obj : error
LNK2005: _init_types already defined in _typesmodule.obj'

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

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

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

From noreply at sourceforge.net  Thu Oct  5 12:44:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 03:44:15 -0700
Subject: [ python-Bugs-1571170 ] Some numeric characters are still not
	recognized
Message-ID: <E1GVQi7-0001Dd-In@sc8-sf-web5.sourceforge.net>

Bugs item #1571170, was opened at 2006-10-05 09:31
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571170&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Chrigstr?m (andersch)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Some numeric characters are still not recognized

Initial Comment:
Looking into the documentation of the unicode database
i found that there are some numeric characters that are
not listed in the UnicodeData.txt file. They are intead
listen in the Unihan.txt file. (See
http://www.unicode.org/Public/5.0.0/ucd/UCD.html#Numeric_Type_Han).

I have a patch for this in the works.



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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-10-05 12:44

Message:
Logged In: YES 
user_id=38388

For quick reference, here's the patch URL:

https://sourceforge.net/tracker/index.php?func=detail&aid=1571184&group_id=5470&atid=305470

I'll comment there.

It's really sad that the Unicode Consortium is separating
out all kinds of properties into separate files... makes
following the standard a lot harder.


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

Comment By: Anders Chrigstr?m (andersch)
Date: 2006-10-05 10:05

Message:
Logged In: YES 
user_id=621306

I have uploaded patch #1571184 that fixes this.


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

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

From noreply at sourceforge.net  Thu Oct  5 20:14:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 11:14:45 -0700
Subject: [ python-Bugs-1571620 ] round() producing -0.0
Message-ID: <E1GVXk5-0000MV-Ib@sc8-sf-web2.sourceforge.net>

Bugs item #1571620, was opened at 2006-10-05 13:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ron Frye (rrfsf01)
Assigned to: Nobody/Anonymous (nobody)
Summary: round() producing -0.0

Initial Comment:
python 2.2 on AIX 4.3 produces:

>>> round(-0.0001, 1)
0.0
>>>


python 2.4.1 on Linux Red Hat Enterprise 3 produces:

>>> round(-0.0001, 1)
-0.0
>>> round(-0.0001, 1) == 0.0
True
>>>


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

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

From noreply at sourceforge.net  Thu Oct  5 20:39:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 11:39:22 -0700
Subject: [ python-Bugs-1571620 ] round() producing -0.0
Message-ID: <E1GVY7u-0005ua-EQ@sc8-sf-web5.sourceforge.net>

Bugs item #1571620, was opened at 2006-10-05 13:14
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ron Frye (rrfsf01)
Assigned to: Nobody/Anonymous (nobody)
Summary: round() producing -0.0

Initial Comment:
python 2.2 on AIX 4.3 produces:

>>> round(-0.0001, 1)
0.0
>>>


python 2.4.1 on Linux Red Hat Enterprise 3 produces:

>>> round(-0.0001, 1)
-0.0
>>> round(-0.0001, 1) == 0.0
True
>>>


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-10-05 13:39

Message:
Logged In: YES 
user_id=80475

Since 0.0 == -0.0, the result in not wrong.  The underlying
C math library dictates whether signed zeroes are used, so
round(-0.0001, 1) returns the same result as 
math.ceil(-0.0001 * 10).

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

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

From noreply at sourceforge.net  Thu Oct  5 21:34:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 12:34:32 -0700
Subject: [ python-Bugs-1570417 ] 2.4 & 2.5 can't create win installer on linux
Message-ID: <E1GVYzI-0001hE-2z@sc8-sf-web1.sourceforge.net>

Bugs item #1570417, was opened at 2006-10-04 05:45
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Thomas Heller (theller)
Summary: 2.4 & 2.5 can't create win installer on linux

Initial Comment:
With python 2.4.3 and 2.5 I can't build a Windows 
installer on Linux. I get the following error:

Warning: Can't read registry to find the necessary 
compiler setting
Make sure that Python modules _winreg, win32api or 
win32con are installed.
removing 'build/bdist.linux-i686/wininst' (and 
everything under it)


I can still create an installer with 2.3.5

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

>Comment By: Thomas Heller (theller)
Date: 2006-10-05 21:34

Message:
Logged In: YES 
user_id=11105

For pure distributions, bdist_wininst should create
installers that are independent on the Python version.  This
worked up to Python 2.3, starting with 2.4 problems could
arise because different MS C runtime libs are used.

So, to fix this problem, even for pure distributions it
should be required to specify the target-version command
line switch.  When building on non-windows systems, or even
on Windows systems for another Python version than the one
used to build the installer, bdist_wininst.py could hardcode
the knowledge about Python version/MSVC version for the
official python.org releases.

This will fail if someone builds his own version of Python,
for example 2.5 with MSVC 8.  The real solution would be to
avoid having wininst-XXX.exe use the C runtime library at all.

OTOH, in my experience using the wrong C runtime library
only has small effects - the installer would fail to show
output from the pre- or post-install scripts (if they are
used at all).

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

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-04 08:30

Message:
Logged In: YES 
user_id=21627

The message you get is a warning only; you can ignore it.

However, it still fails because it can't determine what
msvcrt version the target python was built with. It needs to
find that out because it needs to decide whether to use
wininst-6.exe or wininst-7.1.exe.

Thomas, can you think of a way to fix this?

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

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

From noreply at sourceforge.net  Thu Oct  5 23:31:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 14:31:52 -0700
Subject: [ python-Bugs-1571754 ] Building using Sleepycat db 4.5.20 is broken
Message-ID: <E1GVaoq-0004pk-U2@sc8-sf-web1.sourceforge.net>

Bugs item #1571754, was opened at 2006-10-05 23:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Scheck (robert-scheck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building using Sleepycat db 4.5.20 is broken

Initial Comment:
Using latest Sleepycat db 4.5.20, I'm getting the 
following result during make of python 2.5:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes  -I. -I./Include  -fPIC -
DPy_BUILD_CORE  -I/usr/include/db4 -c ./Modules/_bsddb.
c -o Modules/_bsddb.o
./Modules/_bsddb.c: In function 'DBEnv_set_lk_max':
./Modules/_bsddb.c:4142: error: 'DB_ENV' has no member 
named 'set_lk_max'
./Modules/_bsddb.c: In function 'init_bsddb':
./Modules/_bsddb.c:5838: error: 'DB_CACHED_COUNTS' 
undeclared (first use in this function)
./Modules/_bsddb.c:5838: error: (Each undeclared 
identifier is reported only once
./Modules/_bsddb.c:5838: error: for each function it 
appears in.)
./Modules/_bsddb.c:5873: error: 'DB_RECORDCOUNT' 
undeclared (first use in this function)
make: *** [Modules/_bsddb.o] Error 1

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

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

From noreply at sourceforge.net  Thu Oct  5 23:34:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 14:34:27 -0700
Subject: [ python-Bugs-1571754 ] Building using Sleepycat db 4.5.20 is broken
Message-ID: <E1GVarL-0007iC-Bf@sc8-sf-web3.sourceforge.net>

Bugs item #1571754, was opened at 2006-10-05 23:31
Message generated for change (Comment added) made by robert-scheck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Scheck (robert-scheck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building using Sleepycat db 4.5.20 is broken

Initial Comment:
Using latest Sleepycat db 4.5.20, I'm getting the 
following result during make of python 2.5:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes  -I. -I./Include  -fPIC -
DPy_BUILD_CORE  -I/usr/include/db4 -c ./Modules/_bsddb.
c -o Modules/_bsddb.o
./Modules/_bsddb.c: In function 'DBEnv_set_lk_max':
./Modules/_bsddb.c:4142: error: 'DB_ENV' has no member 
named 'set_lk_max'
./Modules/_bsddb.c: In function 'init_bsddb':
./Modules/_bsddb.c:5838: error: 'DB_CACHED_COUNTS' 
undeclared (first use in this function)
./Modules/_bsddb.c:5838: error: (Each undeclared 
identifier is reported only once
./Modules/_bsddb.c:5838: error: for each function it 
appears in.)
./Modules/_bsddb.c:5873: error: 'DB_RECORDCOUNT' 
undeclared (first use in this function)
make: *** [Modules/_bsddb.o] Error 1

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

>Comment By: Robert Scheck (robert-scheck)
Date: 2006-10-05 23:34

Message:
Logged In: YES 
user_id=203809

Ah, python 2.4.3 has the same problem plus further errors:

./Modules/_bsddb.c: In function 'DB_length':
./Modules/_bsddb.c:2453: error: 'DB_CACHED_COUNTS' 
undeclared (first use in this function)
./Modules/_bsddb.c:2453: error: (Each undeclared identifier 
is reported only once
./Modules/_bsddb.c:2453: error: for each function it appears 
in.)
./Modules/_bsddb.c: In function 'DBEnv_set_lk_max':
./Modules/_bsddb.c:3811: error: 'DB_ENV' has no member named 
'set_lk_max'
./Modules/_bsddb.c: In function 'init_bsddb':
./Modules/_bsddb.c:5004: error: 'DB_CACHED_COUNTS' 
undeclared (first use in this function)
./Modules/_bsddb.c:5039: error: 'DB_RECORDCOUNT' undeclared 
(first use in this function)
make: *** [Modules/_bsddb.o] Error 1

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

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

From noreply at sourceforge.net  Fri Oct  6 03:30:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 18:30:57 -0700
Subject: [ python-Bugs-1571841 ] email module does not complay with RFC 2046:
	CRLF issue
Message-ID: <E1GVeYD-0005Ws-Kf@sc8-sf-web3.sourceforge.net>

Bugs item #1571841, was opened at 2006-10-05 20:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571841&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andy Leszczynski (andrzejl)
Assigned to: Nobody/Anonymous (nobody)
Summary: email module does not complay with RFC 2046: CRLF issue

Initial Comment:
According to rfc2046, line breaks in MIME are CRLF.
However python just
uses LF like in the following example:

from email.MIMEMultipart import MIMEMultipart
from email.MIMEText import MIMEText

msg = MIMEMultipart()
msg['Subject'] = 'Our family reunion'
msg['From'] = '... at a.b'
msg['To'] = '... at x.y'
msg.epilogue = ''

msg.attach(MIMEText('aaaaaaaaaaaaaaaaaaaaaaaa'))

print `msg.as_string()`

gives:
'Content-Type: multipart/mixed;
boundary="===============1018679223=="\nMIME-Version:
1.0\nSubject: Our
family reunion\nFrom: a... at a.b\nTo:
c... at x.y\n\n--===============1018679223==\nContent-Type:
text/plain;
charset="us-ascii"\nMIME-Version:
1.0\nContent-Transfer-Encoding:
7bit\n\naaaaaaaaaaaaaaaaaaaaaaaa\n--===============1018679223==--\n'


Found in version 2.3 and 2.4 


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

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

From noreply at sourceforge.net  Fri Oct  6 04:21:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 19:21:39 -0700
Subject: [ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Message-ID: <E1GVfLH-0000S2-62@sc8-sf-web5.sourceforge.net>

Bugs item #1569517, was opened at 2006-10-02 19:54
Message generated for change (Comment added) made by coatimundi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Coatimundi (coatimundi)
Assigned to: Kristj?n Valur (krisvale)
Summary: PGIRelease linkage fails on pgodb80.dll

Initial Comment:
Hi.  I'm interested in learning how to optimize Python
for Windows.  I have made a similar report as a
follow-on to Bug 1568243, but it's really a  separate
issue.

Let me emphasize that what I am about to describe this
is *not* a bug in the Python build system.  But it may
be worth calling out in the README file for PCbuild8.

When building PGIRelease to instrument the pythoncore
DLL, the linker fails because it cannot find
pgodb80.dll.  This file is required for PGO with Visual
C++ under Visual Studio 2005 and is shipped with the
Professional version, but not with the Express version
or (apparently) the Standard version I have.  Looks
like upgrade time...

I hope this helps someone else.


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

>Comment By: Coatimundi (coatimundi)
Date: 2006-10-06 02:21

Message:
Logged In: YES 
user_id=1611513

Excellent.  I really didn't expect much interest in this
report.  Thanks!

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

Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:17

Message:
Logged In: YES 
user_id=1262199

the pcbuild8.vcproj in the Python trunk has this fixed.  I
will backport that tho 2.5 shortly.

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

Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:14

Message:
Logged In: YES 
user_id=1262199

This has been fixed in the 2.6 trunk, where the PGO build is
done differently.  I will retrofit that project setting to
2.5 shortly.

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

Comment By: Douglas W. Goodall (douglas_goodall)
Date: 2006-10-05 05:38

Message:
Logged In: YES 
user_id=1553177

I hate Microsoft. I have VS 2005 Standard also. Bill 
always sticks it to you in the end.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 12:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

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

From noreply at sourceforge.net  Fri Oct  6 04:22:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 19:22:00 -0700
Subject: [ python-Bugs-660098 ] New style classes and __hash__
Message-ID: <E1GVfLc-00020f-8H@sc8-sf-web3.sourceforge.net>

Bugs item #660098, was opened at 2002-12-30 13:39
Message generated for change (Comment added) made by danielhs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: New style classes and __hash__

Initial Comment:
New style classes obviously inherit a __hash__ 
implementation from object which returns the id. Per 
default this allows using instances as dictionary keys, 
but usually with the wrong behaviour, because most 
often user classes are mutable, and their contained data 
should be used to calculate the hash value.

IMO one possible solution would be to change 
typeobject.c:object_hash() to raise TypeError, and 
change all the immutable (core) Python objects to use 
_Py_HashPointer in their tp_hash slot.

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

Comment By: Daniel (danielhs)
Date: 2006-10-05 22:22

Message:
Logged In: YES 
user_id=1609821

Still doesn't work as expected in 2.5.
Just wanted to bump along since I noticed this bug today,
and found this bug report (which hasn't changed in nearly 3
years).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-22 16:04

Message:
Logged In: YES 
user_id=6380

Anybody see a reason why I shouldn't check this in? See
python-dev discussion.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-05 13:30

Message:
Logged In: YES 
user_id=6380

Here's the patch I am thinking of.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-05 13:06

Message:
Logged In: YES 
user_id=6380

I wonder if the solution could be as simple as removing the
tp_hash slot from the object class? 
 
I just tried that and it passes the entire test suite, as
well as the tests that Tim added to the patch. 
 
The trick is that PyObject_Hash() has a fallback which does
the right thing. 
 
And when the base object class doesn't set tp_compare or
tp_richcompare, I think it should be allowed not to set
tp_hash either. 

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-11 09:41

Message:
Logged In: YES 
user_id=6380

Oops, not so fast. This also makes object.__hash__() calls
fail when it is explicitly invoked, e.g. when a class
overrides __eq__ to print a message and then call the base
class __eq__, it must do the same for __hash__, but
object.__hash__ will still fail in this case. I'll think of
a fix for that.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-11 06:16

Message:
Logged In: YES 
user_id=6380

OK, feel free to check it in.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-11 00:39

Message:
Logged In: YES 
user_id=31435

The patch seems fines to me.  I've attached a new patch, 
combining yours with new tests in test_class.py.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-09 14:04

Message:
Logged In: YES 
user_id=6380

A trick similar to what we do in object_new might work.
There, we raise an error if the tp_init slot is the default
function (object_init) and any arguments are passed.

I propose that object_hash checks that tp_compare and
tp_richcompare are both NULL. I'm attaching a patch -- let
me know if that works.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-09 13:54

Message:
Logged In: YES 
user_id=31435

&gt;&gt;&gt; class C:  # classic class complains
...   __cmp__ = lambda a, b: 0
...
&gt;&gt;&gt; {C(): 1}
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: unhashable instance
&gt;&gt;&gt; class C(object):   # new-style class does not complain
...   __cmp__ = lambda a, b: 0
...
&gt;&gt;&gt; {C(): 1}
{&lt;__main__.C object at 0x007F6970&gt;: 1}
&gt;&gt;&gt; 

That was under current CVS.  I see the same behavior in 
2.2.3, so this isn't new.

About Thomas's original report, I don't agree -- the default 
behavior is very useful.  The rule I've always lived by is that, to 
be usable as a dict key, an instance's class must either:

1. Implement none of {__cmp__, __eq__, __hash__}.

or

2. Implement __hash__ and (at least) one of {__cmp, __eq__}.

Classic classes still work this way.  New-style classes don't 
appear to outlaw any combination here.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-09 13:44

Message:
Logged In: YES 
user_id=6380

Yes, please paste an example here.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-05-09 13:32

Message:
Logged In: YES 
user_id=31392

Currently, a new-style class that defines __cmp__ but not
__hash__ is usable as a dictionary key.  That seems related
to this bug.  Should I paste the example here and bump the
priority?  Or should I open a separate bug report?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-11 18:01

Message:
Logged In: YES 
user_id=6380

I spent an afternoon looking into this, and I can't see an
easy solution. The idea of only inheriting __hash__ together
with certain other slots is really flawed; it may be better
if object DIDN'T define a default implementation for
__hash__, comparisons (both flavors), and other things, or
maybe the default __hash__ should raise an exception when
the comparisons are not those inherited from object, or
maybe PyType_Ready should insert a dummy __hash__ when it
sees that you redefine __eq__, or...  I really don't know.
I'm going to sleep on this some more, and lower the
priority. You can always get the right behavior by
explicitly defining __hash__.

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

Comment By: Thomas Heller (theller)
Date: 2002-12-30 13:50

Message:
Logged In: YES 
user_id=11105

You mean at the end of the inherit_slots() function?
For my extension which I'm currently debugging, tp_compare, 
tp_richcompare, and tp_hash are inherited from base, but 
only tp_hash is != NULL there.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-30 13:44

Message:
Logged In: YES 
user_id=6380

There seems to be code that tries to inherit tp_hash only
when tp_compare and tp_richcompare are also inherited, but
it seems to be failing.

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

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

From noreply at sourceforge.net  Fri Oct  6 05:40:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Oct 2006 20:40:42 -0700
Subject: [ python-Feature Requests-1571878 ] Improvements to socket module
	exceptions
Message-ID: <E1GVgZm-00074R-OT@sc8-sf-web1.sourceforge.net>

Feature Requests item #1571878, was opened at 2006-10-06 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=355470&aid=1571878&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improvements to socket module exceptions

Initial Comment:
The exceptions thrown by the socket module could be
better thought out.

1/ Inconsistent Parameters For socket error:
The python documentation for socket.error says "The
accompanying value is either a string telling what went
wrong or a pair (errno, string) representing an error
returned by a system call". I assume this is because an
errno is not always available in an error situation.

However, this inconsistency is annoying. If I want to
catch a socket error and (try to) do some
error-number-specific handling, I need to do something
like this:

try:
  someNetworkingFunc()
except socket.error, ex:
  if len(ex.args) == 2 and type(ex.args[0]) == IntType:
    errorNumber = ex.args[0]
    errorMsg = ex.args[1]
    handleSocketErrorByNumber(errorNumber, errorMsg)
  else:
    handleUnknownSocketError(ex)

Some different ways to resolve this:
  (a) Force socket.error to always have args of (errno,
message). We use a special errno value when none is
actually available.
  (b) Subclass socket.error to have one version with
errno and message, and one version with only a message


2/ Better Class Hierarchy:
It would be easier to handle the various socket errors
if we had more of a class hierarchy. eg.
EnvironmentError
  -> socket.error
    -> socket.timeout
  -> socket.AddressError
    -> socket.herror
    -> socket.gaierror

3/ Use Named Attributes:
It would be easier to access the parameters in
exceptions if we made them named attributes. eg.

class socket.error(EnvironmentError):
  def __init__(self, errno, msg):
    self.errno = errno
    self.msg = msg
    
    # Also pass on the params to the parent class,
    # to ensure compatibility with existing code
    # that accesses the params via ex.args
    EnvironmentError.__init__(self, errno, msg)


try:
  someNetworkingFunc()
except socket.error, ex:
  print "Error number is %d" % ex.errno
  

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

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

From noreply at sourceforge.net  Fri Oct  6 09:02:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 00:02:14 -0700
Subject: [ python-Bugs-1571023 ] _ssl module can't be built on windows
Message-ID: <E1GVjio-0002S8-BC@sc8-sf-web5.sourceforge.net>

Bugs item #1571023, was opened at 2006-10-05 01:31
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571023&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: _ssl module can't be built on windows

Initial Comment:

Revision 52152 on the release24-maint branch
updated the OpenSSL package to version 0.9.7l,
which causes linking errors due to unresolved
symbols. 

This can be fixed with a backport of patch 1197150:
http://www.python.org/sf/1197150


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

>Comment By: Martin v. L??wis (loewis)
Date: 2006-10-06 09:02

Message:
Logged In: YES 
user_id=21627

Thanks for the report. This is now fixed with r52201.

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

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

From noreply at sourceforge.net  Fri Oct  6 12:26:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 03:26:10 -0700
Subject: [ python-Bugs-1570284 ] Launcher reset to factory button provides bad
	command-line
Message-ID: <E1GVmuA-00072T-HB@sc8-sf-web3.sourceforge.net>

Bugs item #1570284, was opened at 2006-10-03 23:17
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: jjackson (jejackson)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Launcher reset to factory button provides bad command-line

Initial Comment:
If I push the "Reset to factory settings" in Python Launcher's Preferences 
window, the command line gets a bogues "(null)" inserted, which makes a 
mess of things. I don't think that was what was intended.

In trying to debug this, I notice in the source for FileSettings.m, at line 
209
there are two duplicated lines:

            [NSNumber numberWithBool: nosite], @"nosite",
            [NSNumber numberWithBool: nosite], @"nosite",

Also, I notice at FileSettings.m:236

    value = [dict objectForKey: @"nosite"];
    if (value) nosite = [value boolValue];
    value = [dict objectForKey: @"nosite"];
    if (value) tabs = [value boolValue];

I'm wondering if these second "nosite"s should be "tabs", and if that 
would fix the problem.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-06 12:26

Message:
Logged In: YES 
user_id=580910

I'll have a look at this this weekend. On first glance the analysis for the source 
code looks correct and both lines should be changed, but I don't have time just 
ow to do this and test the results just now (and then backport to the 2.5 and 2.4 
trees)

P.S. I'll be doing a huge checking on the 2.4 branch this weekend, backporting 
the universal python stuff to the official tree. Last week was busier than 
expected, hence the late checkin.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-04 07:48

Message:
Logged In: YES 
user_id=33168

Ronald, I'm guessing that Jack still doesn't have time.  Do
you know anything about this?

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

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

From noreply at sourceforge.net  Fri Oct  6 14:23:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 05:23:52 -0700
Subject: [ python-Bugs-1572084 ] .eml attachments in email
Message-ID: <E1GVok4-0006jm-2v@sc8-sf-web6.sourceforge.net>

Bugs item #1572084, was opened at 2006-10-06 14:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: rainwolf8472 (rainwolf8472)
Assigned to: Nobody/Anonymous (nobody)
Summary: .eml attachments in email

Initial Comment:
I think there's a bug somewhere in the email package. 
I wanted to write a 
script to send emails with certain attachments using
libgmail, and found 
this one, http://pramode.net/articles/lfy/fuse/4.txt ,
it works fine with 
most files, but it fails with .eml files, and what i
can't understand is 
that if I change the extension of those .eml files to
.txt, the script works 
fine.  However, when trying to mail a simple textfile
containing "hello", en 
changing the extension to .eml before sending, it fails
again. it doesn't 
fail when I don't change the extension to .eml.
Any help please? I pasted the output I get (over and
over again) in the attached textfile.

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

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

From noreply at sourceforge.net  Fri Oct  6 15:20:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 06:20:09 -0700
Subject: [ python-Bugs-1545341 ] setup() keyword have to be list (doesn't work
	with tuple)
Message-ID: <E1GVpcX-0005iw-ME@sc8-sf-web5.sourceforge.net>

Bugs item #1545341, was opened at 2006-08-23 10:49
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: STINNER Victor (haypo)
>Assigned to: A.M. Kuchling (akuchling)
Summary: setup() keyword have to be list (doesn't work with tuple)

Initial Comment:
Code:
====================== 8< =====================
from distutils.core import setup
setup(..., classifier=('Intended Audience :: 
Developers', 'Environment :: Console :: 
Curses'), ...)
====================== 8< =====================

The query: "./setup.py register" will create HTML 
request:
----------------GHSKFJDLGDS7543FJKLFHRE75642756743254
Content-Disposition: form-data; name="classifiers"

('Intended Audience :: Developers', 'Environment :: 
Console :: Curses')

Instead of a multipart part for each value.

====

The bug is stupid, see attached patch.

Haypo

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-06 09:20

Message:
Logged In: YES 
user_id=11375

Fix applied to trunk in rev. 52211; I'll backport to 2.5 and
2.4.  

The Distutils code is intended to be compatible with Python
2.1, so I've reworked the change to keep using type()
instead of isinstance().  Patch attached.



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

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

From noreply at sourceforge.net  Fri Oct  6 17:06:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 08:06:40 -0700
Subject: [ python-Feature Requests-1572210 ] help(x) for for keywords too
Message-ID: <E1GVrHc-0004cN-HW@sc8-sf-web2.sourceforge.net>

Feature Requests item #1572210, was opened at 2006-10-06 11:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help(x) for for keywords too

Initial Comment:
At the interactive prompt, help(object) is very useful.

It would be nice if it also worked on keywords.

"""
>>> help(object)
Help on class object in module __builtin__:

class object
 |  The most base type
"""

vs 

"""
>>> help(with)
SyntaxError: invalid syntax
"""

At the moment, the workaround is to open the 
documentation, pick a document that doesn't seem quite 
right (language reference?), go to the index, and look 
for the keyword.


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

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

From noreply at sourceforge.net  Fri Oct  6 17:07:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 08:07:07 -0700
Subject: [ python-Feature Requests-1572210 ] help(x) for keywords too
Message-ID: <E1GVrI3-0006oq-AD@sc8-sf-web1.sourceforge.net>

Feature Requests item #1572210, was opened at 2006-10-06 11:06
Message generated for change (Settings changed) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
>Summary: help(x) for keywords too

Initial Comment:
At the interactive prompt, help(object) is very useful.

It would be nice if it also worked on keywords.

"""
>>> help(object)
Help on class object in module __builtin__:

class object
 |  The most base type
"""

vs 

"""
>>> help(with)
SyntaxError: invalid syntax
"""

At the moment, the workaround is to open the 
documentation, pick a document that doesn't seem quite 
right (language reference?), go to the index, and look 
for the keyword.


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

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

From noreply at sourceforge.net  Fri Oct  6 17:59:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 08:59:59 -0700
Subject: [ python-Feature Requests-1572210 ] help(x) for keywords too
Message-ID: <E1GVs7D-0003UR-CC@sc8-sf-web1.sourceforge.net>

Feature Requests item #1572210, was opened at 2006-10-06 15:06
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help(x) for keywords too

Initial Comment:
At the interactive prompt, help(object) is very useful.

It would be nice if it also worked on keywords.

"""
>>> help(object)
Help on class object in module __builtin__:

class object
 |  The most base type
"""

vs 

"""
>>> help(with)
SyntaxError: invalid syntax
"""

At the moment, the workaround is to open the 
documentation, pick a document that doesn't seem quite 
right (language reference?), go to the index, and look 
for the keyword.


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-06 15:59

Message:
Logged In: YES 
user_id=849994

Doesn't help("if") work for you?

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

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

From noreply at sourceforge.net  Fri Oct  6 18:12:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 09:12:33 -0700
Subject: [ python-Bugs-1545341 ] setup() keyword have to be list (doesn't work
	with tuple)
Message-ID: <E1GVsJN-0005lc-1x@sc8-sf-web5.sourceforge.net>

Bugs item #1545341, was opened at 2006-08-23 16:49
Message generated for change (Comment added) made by haypo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: STINNER Victor (haypo)
Assigned to: A.M. Kuchling (akuchling)
Summary: setup() keyword have to be list (doesn't work with tuple)

Initial Comment:
Code:
====================== 8< =====================
from distutils.core import setup
setup(..., classifier=('Intended Audience :: 
Developers', 'Environment :: Console :: 
Curses'), ...)
====================== 8< =====================

The query: "./setup.py register" will create HTML 
request:
----------------GHSKFJDLGDS7543FJKLFHRE75642756743254
Content-Disposition: form-data; name="classifiers"

('Intended Audience :: Developers', 'Environment :: 
Console :: Curses')

Instead of a multipart part for each value.

====

The bug is stupid, see attached patch.

Haypo

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

>Comment By: STINNER Victor (haypo)
Date: 2006-10-06 18:12

Message:
Logged In: YES 
user_id=365388

Ok nice ;-)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-06 15:20

Message:
Logged In: YES 
user_id=11375

Fix applied to trunk in rev. 52211; I'll backport to 2.5 and
2.4.  

The Distutils code is intended to be compatible with Python
2.1, so I've reworked the change to keep using type()
instead of isinstance().  Patch attached.



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

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

From noreply at sourceforge.net  Fri Oct  6 18:26:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 09:26:54 -0700
Subject: [ python-Feature Requests-1572210 ] help(x) for keywords too
Message-ID: <E1GVsXG-00042q-6Q@sc8-sf-web2.sourceforge.net>

Feature Requests item #1572210, was opened at 2006-10-06 11:06
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help(x) for keywords too

Initial Comment:
At the interactive prompt, help(object) is very useful.

It would be nice if it also worked on keywords.

"""
>>> help(object)
Help on class object in module __builtin__:

class object
 |  The most base type
"""

vs 

"""
>>> help(with)
SyntaxError: invalid syntax
"""

At the moment, the workaround is to open the 
documentation, pick a document that doesn't seem quite 
right (language reference?), go to the index, and look 
for the keyword.


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

>Comment By: Jim Jewett (jimjjewett)
Date: 2006-10-06 12:26

Message:
Logged In: YES 
user_id=764593

No, it doesn't -- but putting the keyword in quotes does at 
least change the error message to saying that topic and 
keyword documentation is not available because the Python 
HTML documentation files could not be found.  

I'm using Windows XP, the 2.4 and 2.5 binaries from 
python.org, if I changed anything it was just the install 
directory to be Python2.5 (or 2.4 for 2.4))

The documentation (as a chm file) is found by the F1 key.  
Is this likely to be a windows build issue?


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

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-06 11:59

Message:
Logged In: YES 
user_id=849994

Doesn't help("if") work for you?

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

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

From noreply at sourceforge.net  Fri Oct  6 20:37:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 11:37:13 -0700
Subject: [ python-Bugs-1572320 ] parser stack overflow
Message-ID: <E1GVuZN-00029o-Sw@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: j?rgen urner (cereb_00)
Assigned to: Nobody/Anonymous (nobody)
Summary: parser stack overflow

Initial Comment:
Executing this raw (malformed) tuple
raises:

s_push: parser stack overflow
MemoryError 

instead of SyntaxError.
Sorry for not tracking it down more, but the tuple was
actually much longer, so I did at least a bit of that.
Removing the last member raises SyntaxError
as expected.



(
	("indigo", "#4B0082)",
	("gold", "#FFD700)",
	("firebrick", "#B22222)",
	("indianred", "#CD5C5C)",
	("yellow", "#FFFF00)",
	("darkolivegreen", "#556B2F)",
	("darkseagreen", "#8FBC8F)",
	("mediumvioletred", "#C71585)",
	("mediumorchid", "#BA55D3)",
	("chartreuse", "#7FFF00)",
	("mediumslateblue", "#7B68EE)",
	("black", "#000000)",
	("springgreen", "#00FF7F)",
	("crimson", "#DC143C)",
	("lightsalmon", "#FFA07A)",
	("brown", "#A52A2A)",
	("turquoise", "#40E0D0)",
	("olivedrab", "#6B8E23)",
	("silver", "#C0C0C0)",
	("skyblue", "#87CEEB)",
	("gray", "#808080)",
	("darkturquoise", "#00CED1)",
	("goldenrod", "#DAA520)",
	("darkgreen", "#006400)",
	("darkviolet", "#9400D3)",
	("darkgray", "#A9A9A9)",
	("lime", "#00FF00)",
	("lightpink", "#FFB6C1)",
	("teal", "#008080)",
	("darkmagenta", "#8B008B)",
	("lightgoldenrodyellow", "#FAFAD2)",
	("lavender", "#E6E6FA)",
)


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

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

From noreply at sourceforge.net  Fri Oct  6 21:25:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 12:25:45 -0700
Subject: [ python-Feature Requests-1572210 ] help(x) for keywords too
Message-ID: <E1GVvKL-0004mi-86@sc8-sf-web2.sourceforge.net>

Feature Requests item #1572210, was opened at 2006-10-06 17:06
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help(x) for keywords too

Initial Comment:
At the interactive prompt, help(object) is very useful.

It would be nice if it also worked on keywords.

"""
>>> help(object)
Help on class object in module __builtin__:

class object
 |  The most base type
"""

vs 

"""
>>> help(with)
SyntaxError: invalid syntax
"""

At the moment, the workaround is to open the 
documentation, pick a document that doesn't seem quite 
right (language reference?), go to the index, and look 
for the keyword.


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

>Comment By: Thomas Heller (theller)
Date: 2006-10-06 21:25

Message:
Logged In: YES 
user_id=11105

> Is this likely to be a windows build issue?

No.  pydoc cannot use the .chm file.  Either you should
download the HTML files yourself, or you can compile the
.chm file in a windows command shell (note that the
decompilation runs in the background, and has no user
interface):

C:\Python24\Doc>hh -decompile . Python24.chm

C:\Python24\Doc>dir *.chm
 Datentr?ger in Laufwerk C: ist ...
 Volumeseriennummer: ...

 Verzeichnis von C:\Python24\Doc

06.10.2006  21:23             3.732 about.html
06.10.2006  21:23             8.689 acks.html
06.10.2006  21:23             4.445 index.html
06.10.2006  21:23            35.525 modindex.html
               4 Datei(en)         52.391 Bytes
               0 Verzeichnis(se),  8.506.798.080 Bytes frei

C:\Python24\Doc>

The other HTML files are created in subdirectories, and
help("if") now works.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-10-06 18:26

Message:
Logged In: YES 
user_id=764593

No, it doesn't -- but putting the keyword in quotes does at 
least change the error message to saying that topic and 
keyword documentation is not available because the Python 
HTML documentation files could not be found.  

I'm using Windows XP, the 2.4 and 2.5 binaries from 
python.org, if I changed anything it was just the install 
directory to be Python2.5 (or 2.4 for 2.4))

The documentation (as a chm file) is found by the F1 key.  
Is this likely to be a windows build issue?


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

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-06 17:59

Message:
Logged In: YES 
user_id=849994

Doesn't help("if") work for you?

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

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

From noreply at sourceforge.net  Fri Oct  6 23:19:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 14:19:15 -0700
Subject: [ python-Bugs-660098 ] New style classes and __hash__
Message-ID: <E1GVx6B-00019W-6t@sc8-sf-web1.sourceforge.net>

Bugs item #660098, was opened at 2002-12-30 13:39
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: New style classes and __hash__

Initial Comment:
New style classes obviously inherit a __hash__ 
implementation from object which returns the id. Per 
default this allows using instances as dictionary keys, 
but usually with the wrong behaviour, because most 
often user classes are mutable, and their contained data 
should be used to calculate the hash value.

IMO one possible solution would be to change 
typeobject.c:object_hash() to raise TypeError, and 
change all the immutable (core) Python objects to use 
_Py_HashPointer in their tp_hash slot.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-10-06 17:19

Message:
Logged In: YES 
user_id=6380

I don't recall what was wrong with the patch.

I do know that I fixed this in Python 3000; but the fix
there was only possible due to other unrelated fixes that
couldn't possibly be backported.

I propose to leave this broken until Py3k, so let's close
this bug.

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

Comment By: Daniel (danielhs)
Date: 2006-10-05 22:22

Message:
Logged In: YES 
user_id=1609821

Still doesn't work as expected in 2.5.
Just wanted to bump along since I noticed this bug today,
and found this bug report (which hasn't changed in nearly 3
years).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-22 16:04

Message:
Logged In: YES 
user_id=6380

Anybody see a reason why I shouldn't check this in? See
python-dev discussion.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-05 13:30

Message:
Logged In: YES 
user_id=6380

Here's the patch I am thinking of.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-05 13:06

Message:
Logged In: YES 
user_id=6380

I wonder if the solution could be as simple as removing the
tp_hash slot from the object class? 
 
I just tried that and it passes the entire test suite, as
well as the tests that Tim added to the patch. 
 
The trick is that PyObject_Hash() has a fallback which does
the right thing. 
 
And when the base object class doesn't set tp_compare or
tp_richcompare, I think it should be allowed not to set
tp_hash either. 

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-11 09:41

Message:
Logged In: YES 
user_id=6380

Oops, not so fast. This also makes object.__hash__() calls
fail when it is explicitly invoked, e.g. when a class
overrides __eq__ to print a message and then call the base
class __eq__, it must do the same for __hash__, but
object.__hash__ will still fail in this case. I'll think of
a fix for that.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-11 06:16

Message:
Logged In: YES 
user_id=6380

OK, feel free to check it in.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-11 00:39

Message:
Logged In: YES 
user_id=31435

The patch seems fines to me.  I've attached a new patch, 
combining yours with new tests in test_class.py.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-09 14:04

Message:
Logged In: YES 
user_id=6380

A trick similar to what we do in object_new might work.
There, we raise an error if the tp_init slot is the default
function (object_init) and any arguments are passed.

I propose that object_hash checks that tp_compare and
tp_richcompare are both NULL. I'm attaching a patch -- let
me know if that works.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-09 13:54

Message:
Logged In: YES 
user_id=31435

&gt;&gt;&gt; class C:  # classic class complains
...   __cmp__ = lambda a, b: 0
...
&gt;&gt;&gt; {C(): 1}
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: unhashable instance
&gt;&gt;&gt; class C(object):   # new-style class does not complain
...   __cmp__ = lambda a, b: 0
...
&gt;&gt;&gt; {C(): 1}
{&lt;__main__.C object at 0x007F6970&gt;: 1}
&gt;&gt;&gt; 

That was under current CVS.  I see the same behavior in 
2.2.3, so this isn't new.

About Thomas's original report, I don't agree -- the default 
behavior is very useful.  The rule I've always lived by is that, to 
be usable as a dict key, an instance's class must either:

1. Implement none of {__cmp__, __eq__, __hash__}.

or

2. Implement __hash__ and (at least) one of {__cmp, __eq__}.

Classic classes still work this way.  New-style classes don't 
appear to outlaw any combination here.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-09 13:44

Message:
Logged In: YES 
user_id=6380

Yes, please paste an example here.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-05-09 13:32

Message:
Logged In: YES 
user_id=31392

Currently, a new-style class that defines __cmp__ but not
__hash__ is usable as a dictionary key.  That seems related
to this bug.  Should I paste the example here and bump the
priority?  Or should I open a separate bug report?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-11 18:01

Message:
Logged In: YES 
user_id=6380

I spent an afternoon looking into this, and I can't see an
easy solution. The idea of only inheriting __hash__ together
with certain other slots is really flawed; it may be better
if object DIDN'T define a default implementation for
__hash__, comparisons (both flavors), and other things, or
maybe the default __hash__ should raise an exception when
the comparisons are not those inherited from object, or
maybe PyType_Ready should insert a dummy __hash__ when it
sees that you redefine __eq__, or...  I really don't know.
I'm going to sleep on this some more, and lower the
priority. You can always get the right behavior by
explicitly defining __hash__.

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

Comment By: Thomas Heller (theller)
Date: 2002-12-30 13:50

Message:
Logged In: YES 
user_id=11105

You mean at the end of the inherit_slots() function?
For my extension which I'm currently debugging, tp_compare, 
tp_richcompare, and tp_hash are inherited from base, but 
only tp_hash is != NULL there.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-30 13:44

Message:
Logged In: YES 
user_id=6380

There seems to be code that tries to inherit tp_hash only
when tp_compare and tp_richcompare are also inherited, but
it seems to be failing.

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

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

From noreply at sourceforge.net  Fri Oct  6 23:29:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 14:29:35 -0700
Subject: [ python-Bugs-660098 ] New style classes and __hash__
Message-ID: <E1GVxGB-0008SQ-EG@sc8-sf-web2.sourceforge.net>

Bugs item #660098, was opened at 2002-12-30 13:39
Message generated for change (Comment added) made by danielhs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: New style classes and __hash__

Initial Comment:
New style classes obviously inherit a __hash__ 
implementation from object which returns the id. Per 
default this allows using instances as dictionary keys, 
but usually with the wrong behaviour, because most 
often user classes are mutable, and their contained data 
should be used to calculate the hash value.

IMO one possible solution would be to change 
typeobject.c:object_hash() to raise TypeError, and 
change all the immutable (core) Python objects to use 
_Py_HashPointer in their tp_hash slot.

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

Comment By: Daniel (danielhs)
Date: 2006-10-06 17:29

Message:
Logged In: YES 
user_id=1609821

I don't know if this is the right answer or not, but, this
post seems to indicate that the fix would break Jython.  But
a later post in the thread notes that since the latest
version of Jython is only version 2.1 this shouldn't be an
issue.

First post:
http://mail.python.org/pipermail/python-list/2004-December/257637.html

Second post:
http://mail.python.org/pipermail/python-list/2004-December/257690.html

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-10-06 17:19

Message:
Logged In: YES 
user_id=6380

I don't recall what was wrong with the patch.

I do know that I fixed this in Python 3000; but the fix
there was only possible due to other unrelated fixes that
couldn't possibly be backported.

I propose to leave this broken until Py3k, so let's close
this bug.

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

Comment By: Daniel (danielhs)
Date: 2006-10-05 22:22

Message:
Logged In: YES 
user_id=1609821

Still doesn't work as expected in 2.5.
Just wanted to bump along since I noticed this bug today,
and found this bug report (which hasn't changed in nearly 3
years).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-22 16:04

Message:
Logged In: YES 
user_id=6380

Anybody see a reason why I shouldn't check this in? See
python-dev discussion.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-05 13:30

Message:
Logged In: YES 
user_id=6380

Here's the patch I am thinking of.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-12-05 13:06

Message:
Logged In: YES 
user_id=6380

I wonder if the solution could be as simple as removing the
tp_hash slot from the object class? 
 
I just tried that and it passes the entire test suite, as
well as the tests that Tim added to the patch. 
 
The trick is that PyObject_Hash() has a fallback which does
the right thing. 
 
And when the base object class doesn't set tp_compare or
tp_richcompare, I think it should be allowed not to set
tp_hash either. 

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-11 09:41

Message:
Logged In: YES 
user_id=6380

Oops, not so fast. This also makes object.__hash__() calls
fail when it is explicitly invoked, e.g. when a class
overrides __eq__ to print a message and then call the base
class __eq__, it must do the same for __hash__, but
object.__hash__ will still fail in this case. I'll think of
a fix for that.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-11 06:16

Message:
Logged In: YES 
user_id=6380

OK, feel free to check it in.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-11 00:39

Message:
Logged In: YES 
user_id=31435

The patch seems fines to me.  I've attached a new patch, 
combining yours with new tests in test_class.py.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-09 14:04

Message:
Logged In: YES 
user_id=6380

A trick similar to what we do in object_new might work.
There, we raise an error if the tp_init slot is the default
function (object_init) and any arguments are passed.

I propose that object_hash checks that tp_compare and
tp_richcompare are both NULL. I'm attaching a patch -- let
me know if that works.

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-09 13:54

Message:
Logged In: YES 
user_id=31435

&gt;&gt;&gt; class C:  # classic class complains
...   __cmp__ = lambda a, b: 0
...
&gt;&gt;&gt; {C(): 1}
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: unhashable instance
&gt;&gt;&gt; class C(object):   # new-style class does not complain
...   __cmp__ = lambda a, b: 0
...
&gt;&gt;&gt; {C(): 1}
{&lt;__main__.C object at 0x007F6970&gt;: 1}
&gt;&gt;&gt; 

That was under current CVS.  I see the same behavior in 
2.2.3, so this isn't new.

About Thomas's original report, I don't agree -- the default 
behavior is very useful.  The rule I've always lived by is that, to 
be usable as a dict key, an instance's class must either:

1. Implement none of {__cmp__, __eq__, __hash__}.

or

2. Implement __hash__ and (at least) one of {__cmp, __eq__}.

Classic classes still work this way.  New-style classes don't 
appear to outlaw any combination here.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-05-09 13:44

Message:
Logged In: YES 
user_id=6380

Yes, please paste an example here.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-05-09 13:32

Message:
Logged In: YES 
user_id=31392

Currently, a new-style class that defines __cmp__ but not
__hash__ is usable as a dictionary key.  That seems related
to this bug.  Should I paste the example here and bump the
priority?  Or should I open a separate bug report?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-11 18:01

Message:
Logged In: YES 
user_id=6380

I spent an afternoon looking into this, and I can't see an
easy solution. The idea of only inheriting __hash__ together
with certain other slots is really flawed; it may be better
if object DIDN'T define a default implementation for
__hash__, comparisons (both flavors), and other things, or
maybe the default __hash__ should raise an exception when
the comparisons are not those inherited from object, or
maybe PyType_Ready should insert a dummy __hash__ when it
sees that you redefine __eq__, or...  I really don't know.
I'm going to sleep on this some more, and lower the
priority. You can always get the right behavior by
explicitly defining __hash__.

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

Comment By: Thomas Heller (theller)
Date: 2002-12-30 13:50

Message:
Logged In: YES 
user_id=11105

You mean at the end of the inherit_slots() function?
For my extension which I'm currently debugging, tp_compare, 
tp_richcompare, and tp_hash are inherited from base, but 
only tp_hash is != NULL there.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-30 13:44

Message:
Logged In: YES 
user_id=6380

There seems to be code that tries to inherit tp_hash only
when tp_compare and tp_richcompare are also inherited, but
it seems to be failing.

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

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

From noreply at sourceforge.net  Sat Oct  7 02:06:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Oct 2006 17:06:00 -0700
Subject: [ python-Bugs-1572471 ] csv "dialect = 'excel-tab'" to use excel_tab
Message-ID: <E1GVzhY-0006kA-4E@sc8-sf-web2.sourceforge.net>

Bugs item #1572471, was opened at 2006-10-06 17:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572471&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Goldner (goldner)
Assigned to: Nobody/Anonymous (nobody)
Summary: csv "dialect = 'excel-tab'" to use excel_tab

Initial Comment:
Python Library Reference v2.5 (19 September 2006),
section 9.1.1, entry for class excel_tab: 

Documentation should note that though the class is
excel_tab (with an underscore), the dialect name is
'excel-tab' (with a hyphen). 

Possible fix is to add a sentence: 

class excel_tab(  	)
    The excel_tab class defines the usual properties of
an Excel-generated TAB-delimited file. Specify in
reader, writer, etc. with "dialect = 'excel-tab'" (with
a hyphen, not an underscore). 

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

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

From noreply at sourceforge.net  Sat Oct  7 12:38:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 03:38:46 -0700
Subject: [ python-Bugs-1569057 ] Using .next() on file open in write mode
	writes junk to file
Message-ID: <E1GW9Zu-00084g-J0@sc8-sf-web1.sourceforge.net>

Bugs item #1569057, was opened at 2006-10-01 23:49
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using .next() on file open in write mode writes junk to file

Initial Comment:
When you open a file in write mode and use .next(), it 
prints an error and writes many lines of junk to file. 
I tested on windows and python 2.5:

>>> f = open('test', 'w') 
>>> f.fileno() 
4 
>>> f.write('1\n') 
>>> f.write('2\n3\n4\n') 
>>> f.next() 


Traceback (most recent call last): 
  File "<pyshell#8>", line 1, in <module> 
    f.next() 
IOError: [Errno 9] Bad file descriptor 

>>> f.close() 
>>> f = open('test') 
>>> f.next() 
'1\n' 
>>> f.next() 
'2\n' 
>>> f.next() 
'3\n' 
>>> f.next() 
'4\n' 
>>> f.next() 


'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x?
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\?
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00 
...many more lines of junk...'



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

>Comment By: Skip Montanaro (montanaro)
Date: 2006-10-07 05:38

Message:
Logged In: YES 
user_id=44345

Works for me.  (Nearly current build from SVN.) I find it implausible that your 
explanation of failing to flush the file is the cause of the problem since closing 
the file will cause it to be flushed.  You didn't open the file for "w+" so there's no 
opportunity to switch between writing and reading.

What platform are you using?


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

Comment By: andrei kulakov (rainy)
Date: 2006-10-03 20:23

Message:
Logged In: YES 
user_id=511010

Python newsgroup folks said that this is normal because when 
switching between write/read modes without doing flush() 
first, result is undefined. There was a suggestion from 
Terry Ready to add this to documentation on file methods:

"When switching from reading or writing (or vice versa), 
call flush(), or 
the result will be undefined."

thx, -andrei

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

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

From noreply at sourceforge.net  Sat Oct  7 13:21:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 04:21:40 -0700
Subject: [ python-Bugs-1572471 ] csv "dialect = 'excel-tab'" to use excel_tab
Message-ID: <E1GWAFQ-0000NT-UC@sc8-sf-web4.sourceforge.net>

Bugs item #1572471, was opened at 2006-10-06 19:06
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572471&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dan Goldner (goldner)
>Assigned to: Skip Montanaro (montanaro)
Summary: csv "dialect = 'excel-tab'" to use excel_tab

Initial Comment:
Python Library Reference v2.5 (19 September 2006),
section 9.1.1, entry for class excel_tab: 

Documentation should note that though the class is
excel_tab (with an underscore), the dialect name is
'excel-tab' (with a hyphen). 

Possible fix is to add a sentence: 

class excel_tab(  	)
    The excel_tab class defines the usual properties of
an Excel-generated TAB-delimited file. Specify in
reader, writer, etc. with "dialect = 'excel-tab'" (with
a hyphen, not an underscore). 

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

>Comment By: Skip Montanaro (montanaro)
Date: 2006-10-07 06:21

Message:
Logged In: YES 
user_id=44345

Thanks.  Checked in as revision 52218 on svn trunk.  I'm having some
svn trouble with the 2.5 maintenance branch but will check it in there
as well once that's working again.


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

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

From noreply at sourceforge.net  Sat Oct  7 14:32:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 05:32:32 -0700
Subject: [ python-Bugs-1572710 ] cElementTree.SubElement doesn't recognize
	keyword "attrib"
Message-ID: <E1GWBM0-0003xH-CQ@sc8-sf-web2.sourceforge.net>

Bugs item #1572710, was opened at 2006-10-07 08:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572710&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Stephens (hugesmile)
Assigned to: Nobody/Anonymous (nobody)
Summary: cElementTree.SubElement doesn't recognize keyword "attrib"

Initial Comment:
Calling the c routine cElementTree with the keyword
"attrib" fails.  This works in the python version
(ElementTree).

Example:

head = ET.SubElement(root, "head", attrib={"dir":"ltr"})

Python version 2.5, Windows version XP Professional
2002, Service Pack 2

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

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

From noreply at sourceforge.net  Sat Oct  7 15:05:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 06:05:25 -0700
Subject: [ python-Bugs-1572710 ] cElementTree.SubElement doesn't recognize
	keyword "attrib"
Message-ID: <E1GWBrp-0002mW-7p@sc8-sf-web3.sourceforge.net>

Bugs item #1572710, was opened at 2006-10-07 14:32
Message generated for change (Comment added) made by effbot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572710&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mark Stephens (hugesmile)
Assigned to: Nobody/Anonymous (nobody)
Summary: cElementTree.SubElement doesn't recognize keyword "attrib"

Initial Comment:
Calling the c routine cElementTree with the keyword
"attrib" fails.  This works in the python version
(ElementTree).

Example:

head = ET.SubElement(root, "head", attrib={"dir":"ltr"})

Python version 2.5, Windows version XP Professional
2002, Service Pack 2

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

>Comment By: Fredrik Lundh (effbot)
Date: 2006-10-07 15:05

Message:
Logged In: YES 
user_id=38376

The first two arguments in the ET interface are positional
arguments, not keyword arguments.

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

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

From noreply at sourceforge.net  Sat Oct  7 18:04:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 09:04:50 -0700
Subject: [ python-Bugs-1569057 ] Using .next() on file open in write mode
	writes junk to file
Message-ID: <E1GWEfS-0003T2-2m@sc8-sf-web3.sourceforge.net>

Bugs item #1569057, was opened at 2006-10-01 23:49
Message generated for change (Comment added) made by rainy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using .next() on file open in write mode writes junk to file

Initial Comment:
When you open a file in write mode and use .next(), it 
prints an error and writes many lines of junk to file. 
I tested on windows and python 2.5:

>>> f = open('test', 'w') 
>>> f.fileno() 
4 
>>> f.write('1\n') 
>>> f.write('2\n3\n4\n') 
>>> f.next() 


Traceback (most recent call last): 
  File "<pyshell#8>", line 1, in <module> 
    f.next() 
IOError: [Errno 9] Bad file descriptor 

>>> f.close() 
>>> f = open('test') 
>>> f.next() 
'1\n' 
>>> f.next() 
'2\n' 
>>> f.next() 
'3\n' 
>>> f.next() 
'4\n' 
>>> f.next() 


'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x?
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\?
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00 
...many more lines of junk...'



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

>Comment By: andrei kulakov (rainy)
Date: 2006-10-07 11:04

Message:
Logged In: YES 
user_id=511010

I tried it on win2k sp4 running python 2.5 and right now 
tried it on winXP running python 2.4 - same error. Also, at 
least one user on python newsgroup tried it and got a 
slightly different result: he did not get the error on
 .next() but the junk was written to the file. I paste my 
latest attempt right out of IDLE, without any modification 
(my first paste was also straight from idle). Except that I 
trim the junk characters, because there's more than a 
screen of 'em.

IDLE 1.1.2      
>>> f = open('test', 'w')
>>> f.write('1\n')
>>> f.next()

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in -toplevel-
    f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
"\x95\x00\xc8\xe ......."


Please let me know if you need to know anything else...

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

Comment By: Skip Montanaro (montanaro)
Date: 2006-10-07 05:38

Message:
Logged In: YES 
user_id=44345

Works for me.  (Nearly current build from SVN.) I find it implausible that your 
explanation of failing to flush the file is the cause of the problem since closing 
the file will cause it to be flushed.  You didn't open the file for "w+" so there's no 
opportunity to switch between writing and reading.

What platform are you using?


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

Comment By: andrei kulakov (rainy)
Date: 2006-10-03 20:23

Message:
Logged In: YES 
user_id=511010

Python newsgroup folks said that this is normal because when 
switching between write/read modes without doing flush() 
first, result is undefined. There was a suggestion from 
Terry Ready to add this to documentation on file methods:

"When switching from reading or writing (or vice versa), 
call flush(), or 
the result will be undefined."

thx, -andrei

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

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

From noreply at sourceforge.net  Sat Oct  7 18:54:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 09:54:07 -0700
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GWFR9-00045i-DP@sc8-sf-web2.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 08:26
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Martin v. L?wis (loewis)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 09:54

Message:
Logged In: YES 
user_id=341410

I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:

..."just makes Python seem ... lame."

is insulting to those who have helped to develop Python over
the years.  In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).

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

Comment By: applebucks (scott_marks)
Date: 2006-10-03 19:32

Message:
Logged In: YES 
user_id=120857

"Cannot be fixed" sounds pretty final, and also a little
pessimistic.  From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does.  In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.

Not to mention that the workaround ("be sure to rename your
class factory function parameters so that they don't collide
with intended attributes of the created class") just makes
Python seem ... lame.

I hope for a more optimistic reply.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-02 23:49

Message:
Logged In: YES 
user_id=849994

I'm afraid that this cannot be fixed.

In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.

If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.

Martin, do you you have an additional opinion?

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

Comment By: applebucks (scott_marks)
Date: 2006-10-02 09:02

Message:
Logged In: YES 
user_id=120857

This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation.  The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.

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

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

From noreply at sourceforge.net  Sat Oct  7 18:58:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 09:58:15 -0700
Subject: [ python-Bugs-1571112 ] simple moves freeze IDLE
Message-ID: <E1GWFV9-0004Vr-VA@sc8-sf-web2.sourceforge.net>

Bugs item #1571112, was opened at 2006-10-04 21:46
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas W. Goodall (douglas_goodall)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple moves freeze IDLE

Initial Comment:
Using version 2.5 for Windows...

import os

then type "print os." and wait for the 
hint window. then scroll to the bottom (spawnv).

That's it. At this point IDLE is frozen.

I have done it a few times in a row. It seems
very reproduceable to me.

Be well. Doug

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 09:58

Message:
Logged In: YES 
user_id=341410

I can reproduce this on 2.5 beta 2, and it dies exactly when
'spawnv' is highlighted.  I have no suggested fixes, only
reproducing to verify that this is not user-specific bug.

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

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

From noreply at sourceforge.net  Sat Oct  7 19:41:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 10:41:24 -0700
Subject: [ python-Bugs-1571112 ] simple moves freeze IDLE
Message-ID: <E1GWGAu-0004BH-Tz@sc8-sf-web4.sourceforge.net>

Bugs item #1571112, was opened at 2006-10-05 00:46
Message generated for change (Settings changed) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 6
Submitted By: Douglas W. Goodall (douglas_goodall)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: simple moves freeze IDLE

Initial Comment:
Using version 2.5 for Windows...

import os

then type "print os." and wait for the 
hint window. then scroll to the bottom (spawnv).

That's it. At this point IDLE is frozen.

I have done it a few times in a row. It seems
very reproduceable to me.

Be well. Doug

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 12:58

Message:
Logged In: YES 
user_id=341410

I can reproduce this on 2.5 beta 2, and it dies exactly when
'spawnv' is highlighted.  I have no suggested fixes, only
reproducing to verify that this is not user-specific bug.

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

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

From noreply at sourceforge.net  Sat Oct  7 19:42:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 10:42:09 -0700
Subject: [ python-Bugs-1567450 ] tabs missing in idle options configure
Message-ID: <E1GWGBd-0004MG-P1@sc8-sf-web5.sourceforge.net>

Bugs item #1567450, was opened at 2006-09-28 23:34
Message generated for change (Settings changed) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567450&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: jrgutierrez (jrgutierrez)
Assigned to: Kurt B. Kaiser (kbk)
Summary: tabs missing in idle options configure

Initial Comment:
1)The option to select indentation type (insert 
spaces or tabs) is missing
2) The indented width is ignored 

As a result IDLE 2.5 always indents inserting tabs, 
width 8

Sources edited in IDLE 2.4 cannot be corrected with 
IDLE 2.5:

The tabbing errors cannot be corrected with IDLE 2.5. 
You must revert to IDLE 2.4 


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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 02:39

Message:
Logged In: YES 
user_id=149084

See IDLE NEWS for 1.2a1.

The ability to configure tab insertion as a default
didn't work, and was removed.  You can set the default
by changing config-main.def:  [Indent] use-spaces=0
but Python policy is to strongly encourage spaces 
instead of tabs.

For any edit window, you can switch to tab indentation
by using the Format / Toggle Tabs menu selection.  When
using Tabs in an edit window, the indent width must be
eight spaces because of Tk limitations.

If a file uses tabs, you have to toggle tabs 'on' before
you start editing it.  IDLE doesn't yet have the ability to
detect whether a file uses tabs or spaces.  (A TAB indicator
in the status line would be useful.)

Note that Tabs are always used in the Shell window.

I'm not sure what you mean by "cannot be corrected".
The Format menu has Tabify and Untabify.  I suspect it
might be clearer if the dialog asking for 'tab width'
was changed to ask for 'indent width'.  I am able to
change back and forth between tabs and spaces in any
region, but it does take some care.

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

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

From noreply at sourceforge.net  Sat Oct  7 19:45:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 10:45:17 -0700
Subject: [ python-Bugs-1442493 ] IDLE shell window gets very slow when
	displaying long lines
Message-ID: <E1GWGEf-0004Zq-3p@sc8-sf-web4.sourceforge.net>

Bugs item #1442493, was opened at 2006-03-03 09:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE shell window gets very slow when displaying long lines

Initial Comment:
I wrote a little python script that prints a large 
dictionary to stdout (simply using 'print 
mydictionary').

In fact, the type is irrelevant, what matters is that 
the resulting output had approx. 200,000 characters.

The shell prints the dictionary into a single line, 
which causes the window to be almost non-responding, 
e.g. when I try to scroll the window.

Even on a high-end PC it takes a minute or even 
longer to react to anything.

I use Python 2.4.2 on Windows XP SP2.

I am aware that it is not exactly wise to print such 
large objects, but I usually print return values to 
stdout when I debug a script, and I do not always 
expect an object to be that large.

The average text editor handles such long lines much 
better.

A quick workaround might be to break very long lines 
automagically (perhaps at around column 1000).

PS: I already observed the bug some years ago. I 
think I even submitted it to python or idlefork a 
long time ago but I was unable to find it in the 
buglist.


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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-07 13:45

Message:
Logged In: YES 
user_id=149084

Patch 1529353 by Tal Einat

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

Comment By: Tal Einat (taleinat)
Date: 2006-07-26 19:35

Message:
Logged In: YES 
user_id=1330769

Done.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-26 16:38

Message:
Logged In: YES 
user_id=149084

Sure, please open a patch and supply a diff against
Noam's version.

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

Comment By: Tal Einat (taleinat)
Date: 2006-07-26 13:56

Message:
Logged In: YES 
user_id=1330769

The Squeezer extension works like a charm! It's also been
thoroughly tested by tens of users over the past several years.

Why not include it as one of the default extensions, and
have it enabled by default?

BTW I have a tweaked version of Squeezer (I fixed the line
counting code), if you're interested.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-29 15:52

Message:
Logged In: YES 
user_id=149084

It's not that I don't consider it an issue, but I can't
do anything to improve the performance of the Tk text
widget.  IDLE is pure Python.

One thing that comes to mind is to set a maximum line 
length.  If the line exceeds that, print line(:(MAX -100)
+ '...' + line(:-100)  instead of printing the whole thing
which no one wants to look at anyway.

Another thing I've wanted to do is provide the ability
to clear the shell window when it gets too full, w/o
restarting IDLE.

Yes, you might ask the tkinter guys on their mail list,
I'd be interested in hearing their reply.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-29 15:35

Message:
Logged In: YES 
user_id=341410

You can close the window which includes the Shell that has
the huge output, or even reduce the priority of your Idle
shell (you can make it automatic by mucking about with the
shortcut; see the 'start' command).

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

Comment By: Heiko Selber (drhok)
Date: 2006-03-29 15:19

Message:
Logged In: YES 
user_id=865975

Hi kbk,

well, my use case is debugging. I write a script and run it
with IDLE. It doesn't behave as expected, so I insert a
print statement. Next time I run it, IDLE hangs. Oops, it
was a long array; it should have been an int. Line too long.
Duh.

OK, I wait through it, correct the bug, run it again. What
happens? IDLE hangs again, trying to scroll a long line (of
the previous run).

Never mind, I can always kill the process... Dammit, I
can't! It eats 100% CPU; task manager doesn't respond.

IMHO his takes away one of python's strengths, which is
making quick hacks really quick.

Would you suggest redirecting this issue to tkinter? You
don't seem to consider this an issue at all.

I will give squeezer a try. Or maybe PyDev?


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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-28 18:08

Message:
Logged In: YES 
user_id=149084

This is a known problem with Tk/Tcl/tkinter - large output 
scrolls slowly. It's not something that can be fixed in IDLE.  I 
tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4.  250,000 character 
output not too bad , 25 sec, but 10,000 lines of 25 char takes 
over twice that long, so breaking the lines doesn't help.

I don't see any response problem once the output completes.  The 
situation is exponentially worse at 500,000 char.

What is your use case?  IDLE is designed to be an IDE.  Why 
output such massive data?

You may be interested in Squeezer, a Noam Raphael extension to 
IDLEfork.

http://sourceforge.net/tracker/index.php?
func=detail&aid=704316&group_id=9579&atid=309579

I haven't tried it myself, but it might be what you're looking 
for.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-10 15:18

Message:
Logged In: YES 
user_id=341410

Generally speaking, most wrapping text controls have issues
with wrapping long lines.  It would seem reasonable to get
the width of the text control in characters, and manually
wrap all incoming lines regardless.  If the existance or not
of real line endings are important, one could mark which
lines are manually wrapped and remove the line endings on
copy (edit->copy, ctrl+c, etc.).

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

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-09 18:45

Message:
Logged In: YES 
user_id=593130

I verified this with print 100000*'a', also XP (home) sp2.
The sluggishness continued after getting the prompt back 
and trying to do something simple, like 2+2, taking maybe 
1/2 minute to print 4 and then the >>> prompt again.
The sluggishness *also* continued after restarting the 
shell (^F6).  This indicates that the problem is with the 
window, not with IDLE.  Hope someone can try same on *nix 
system to see if general with TKinter or specific to Win 
systems.

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

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

From noreply at sourceforge.net  Sat Oct  7 19:52:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 10:52:07 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GWGLH-0005Y7-Iv@sc8-sf-web3.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 13:19
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-07 13:52

Message:
Logged In: YES 
user_id=149084

I take it that the problem is gone now?  If it's real,
to have any hope of addressing it I need to be able
to reproduce it.  IDLE may be printing error messages
to stderr.  If you have more problems, start IDLE from
a command window so you can see the error messages:

cd to idlelib and run ..\..\python .\PyShell.py

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-04 19:58

Message:
Logged In: YES 
user_id=1604497

Well I think there is just a problem with my OS files or 
something anyway.  There are a couple other things (i.e. 
my "Recent Documents" folder) that do the same thing, even 
when I'm logged on as myself.  Thanks for the help 
though.  I need something to run and find/fix errors with 
my system, but not sure what the best program is.  If you 
know of any, could you let me know. :)  Thanks

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

Comment By: dani (daniboy22)
Date: 2006-10-04 10:38

Message:
Logged In: YES 
user_id=1604341

Usually I do not need to boot on safe mode to log in as
asministrator (I also work on a laptop)... The safe mode
reduces some of the Windows functionalities... Perhaps this
is the real reason for your problem.

Otherwise, I don't know what to tell you more... :-(

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-03 22:45

Message:
Logged In: YES 
user_id=1604497

The problem is that it is my laptop, so I am the 
administrator.  I booted up in safe mode so that I could 
log on as the administrator, and even then it wouldn't let 
me access any of my (username) documents, so I couldn't 
even get in to view that folder let alone change the 
name.  

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

Comment By: dani (daniboy22)
Date: 2006-10-03 09:33

Message:
Logged In: YES 
user_id=1604341

Well, I'm also not a specialist on the subject, but in my
case I don't have any problems in opening the folder. I just
had some problems to rename it (it didn't accepted a name
starting with a "."), but I resolve it (I rename it to "pinga").

Concerning your problem, my hint is that your account is not
an administrator one. Try to enter as an administrator and
make the necessary changes. Or else change the permissions
of your account to the "administrator" type (ask someone
that is already an administrator on that computer to do that).

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-02 18:15

Message:
Logged In: YES 
user_id=1604497

Thanks for that, I found it.  However, I guess I'm not as 
skilled with the computer as I thought...  It won't let me 
change the name, open the folder etc.  It says access is 
denied.  Know why it's doing that when I try to modify it?

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

Comment By: dani (daniboy22)
Date: 2006-10-02 10:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 10:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 12:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-09-30 22:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 17:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Sat Oct  7 21:11:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 12:11:56 -0700
Subject: [ python-Bugs-1571754 ] Building using Sleepycat db 4.5.20 is broken
Message-ID: <E1GWHaW-0000Z7-CD@sc8-sf-web2.sourceforge.net>

Bugs item #1571754, was opened at 2006-10-05 23:31
Message generated for change (Comment added) made by robert-scheck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Scheck (robert-scheck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building using Sleepycat db 4.5.20 is broken

Initial Comment:
Using latest Sleepycat db 4.5.20, I'm getting the 
following result during make of python 2.5:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes  -I. -I./Include  -fPIC -
DPy_BUILD_CORE  -I/usr/include/db4 -c ./Modules/_bsddb.
c -o Modules/_bsddb.o
./Modules/_bsddb.c: In function 'DBEnv_set_lk_max':
./Modules/_bsddb.c:4142: error: 'DB_ENV' has no member 
named 'set_lk_max'
./Modules/_bsddb.c: In function 'init_bsddb':
./Modules/_bsddb.c:5838: error: 'DB_CACHED_COUNTS' 
undeclared (first use in this function)
./Modules/_bsddb.c:5838: error: (Each undeclared 
identifier is reported only once
./Modules/_bsddb.c:5838: error: for each function it 
appears in.)
./Modules/_bsddb.c:5873: error: 'DB_RECORDCOUNT' 
undeclared (first use in this function)
make: *** [Modules/_bsddb.o] Error 1

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

>Comment By: Robert Scheck (robert-scheck)
Date: 2006-10-07 21:11

Message:
Logged In: YES 
user_id=203809

The attached patches are solving the problems for me and 
should be the correct fix when reading Sleepycat's upgrade 
documentation...

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

Comment By: Robert Scheck (robert-scheck)
Date: 2006-10-05 23:34

Message:
Logged In: YES 
user_id=203809

Ah, python 2.4.3 has the same problem plus further errors:

./Modules/_bsddb.c: In function 'DB_length':
./Modules/_bsddb.c:2453: error: 'DB_CACHED_COUNTS' 
undeclared (first use in this function)
./Modules/_bsddb.c:2453: error: (Each undeclared identifier 
is reported only once
./Modules/_bsddb.c:2453: error: for each function it appears 
in.)
./Modules/_bsddb.c: In function 'DBEnv_set_lk_max':
./Modules/_bsddb.c:3811: error: 'DB_ENV' has no member named 
'set_lk_max'
./Modules/_bsddb.c: In function 'init_bsddb':
./Modules/_bsddb.c:5004: error: 'DB_CACHED_COUNTS' 
undeclared (first use in this function)
./Modules/_bsddb.c:5039: error: 'DB_RECORDCOUNT' undeclared 
(first use in this function)
make: *** [Modules/_bsddb.o] Error 1

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

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

From noreply at sourceforge.net  Sun Oct  8 00:37:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 15:37:28 -0700
Subject: [ python-Bugs-691733 ] Let assign to as raise SyntaxWarning as well
Message-ID: <E1GWKnQ-0007kn-52@sc8-sf-web5.sourceforge.net>

Bugs item #691733, was opened at 2003-02-23 09:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 2
Submitted By: Gerrit Holl (gerrit)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Let assign to as raise SyntaxWarning as well

Initial Comment:
according to the Python Language Reference Manual:
&gt; In some future version of Python, the identifiers
&gt; as and None will both become keywords.

Hence, it seems natural to me to raise a SyntaxWarning
when assigning to
either of these. However, the current Python
implementation doesn't:

103 &gt;&gt;&gt; None=&quot;foo&quot;
&lt;stdin&gt;:1: SyntaxWarning: assignment to None
104 &gt;&gt;&gt; as=&quot;foo&quot;
105 &gt;&gt;&gt;

For consistency and cleanliness, assignment to 'as'
should raise a SyntaxWarning as well. Currently, it's
possible to not know it'll be a keyword and use it as a
variable; people shouldn't, so a SyntaxWarning would be
good.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-07 15:37

Message:
Logged In: YES 
user_id=33168

The warning was added for 2.5 and 2.6 this produces an error.

Python 2.5 (release25-maint:51996M, Sep 26 2006, 00:14:14)
>>> as = None
<stdin>:1: Warning: 'as' will become a reserved keyword in
Python 2.6

Python 2.6a0 (trunk:51986M, Oct  7 2006, 15:36:46)
>>> as = None
  File "<stdin>", line 1
    as = None
     ^
SyntaxError: invalid syntax


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

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-31 14:59

Message:
Logged In: YES 
user_id=1188172

For Py2.5, "with" and "as" will become keywords. However,
that will need "from __future__ import with_statement".

So I suggest to raise SyntaxWarning in 2.5 without this
statement if with or as are used as names.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2005-05-31 04:23

Message:
Logged In: YES 
user_id=1188172

This may be too late if as becomes a keyword in the new
with/do/whatever-statement...

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

Comment By: Gerrit Holl (gerrit)
Date: 2003-02-23 09:21

Message:
Logged In: YES 
user_id=13298

I'm not sure whether this should be considered as a feature.
I'd call it a minor wart... I'm also not sure about the
category, is this 'Python interpreter core' or am I right
with 'parser/compiler'?

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

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

From noreply at sourceforge.net  Sun Oct  8 00:44:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 15:44:06 -0700
Subject: [ python-Bugs-764447 ] cvs update warnings
Message-ID: <E1GWKtq-0008Nt-50@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Just van Rossum (jvr)
Summary: cvs update warnings

Initial Comment:
On Windows, when you do &quot;cvs update&quot; in the &quot;Mac/IDE
scripts&quot; directory, you get the following warnings
(example uses Cygwin, but it also happens with other
CVS clients):

$ cd &quot;Mac/IDE scripts&quot;; cvs update
? Hold option to open a script
? Insert file name
? Insert folder name
? Search Python Documentation
? Hack/Remove .pyc files
? Hack/Toolbox Assistant
cvs server: Updating .
cvs server: Updating Hack
cvs server: Updating Widget demos
$

This is due to the fact that Windows can't deal with
periods at the end of file names.  All files giving
warnings end in &quot;...&quot;.  These periods are removed when
the files get created, and so CVS sees the files
without periods and complains about them.

At one level the solution is simple: rename those
files.  At another level, I don't know what the
consequences are for the Mac, so assigning to Just
(Jack doesn't seem to want to deal with this :-)


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-07 15:44

Message:
Logged In: YES 
user_id=33168

Mac/IDE scripts is gone, so is CVS.  :-)

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-07-04 20:46

Message:
Logged In: YES 
user_id=1038590

The leading spaces on some filenames are causing Eclipse to
choke on the checkout, too (I'm guessing the spaces are
there to get the right sequencing of the filenames).

One possibility that would give a minimal change is to
prepend and append underscores to all of the filenames, then
modify the code that reads these files to remove the first
and last character before performing the same parsing it
does now.

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-09-09 07:12

Message:
Logged In: YES 
user_id=43607

It's now past 2.3 final, so can you look into this again?

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-07-02 03:36

Message:
Logged In: YES 
user_id=43607

I've lived with this for years.  A few more weeks won't matter.

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

Comment By: Just van Rossum (jvr)
Date: 2003-07-02 02:33

Message:
Logged In: YES 
user_id=92689

Any objections to postponing this to after 2.3 final? The thing is, 
currently these file names map to menu items directly, and to fix 
this I have to build a way to specify the menu item from within 
the file. This will cause way more changes than I'm comfortable 
with, just before 2.3. Removing the spaces from folder names can 
be done at the same time.

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

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

From noreply at sourceforge.net  Sun Oct  8 00:54:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 15:54:33 -0700
Subject: [ python-Bugs-789159 ] Minor floatobject.c bug
Message-ID: <E1GWL3x-0000xL-Kc@sc8-sf-web5.sourceforge.net>

Bugs item #789159, was opened at 2003-08-15 03:39
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789159&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor floatobject.c bug

Initial Comment:
The following is a previously reported bug that got
only half fixed.
The bug was closed before I could respond that the fix
was incomplete;
here is a complete fix.

The failure is when overflow checking is enabled on
integers, as is
good programming practice and permitted by the C
standard.  It could
also cause wrong answers if overflow is mishandled (as
is also permitted
and can happen).

*** ./Objects/floatobject.c.org Tue Jan 28 19:40:35
2003
--- ./Objects/floatobject.c     Tue Jun  3 13:02:48
2003
***************
*** 659,667 ****
           to long may yield gibberish in either case. 
What really matters
           is whether converting back to double again
reproduces what we
           started with. */
!       aslong = (long)wholepart;
!       if ((double)aslong == wholepart)
!               return PyInt_FromLong(aslong);
        PyErr_SetString(PyExc_OverflowError, &quot;float too
large to convert&quot;);
        return NULL;
  }
--- 659,669 ----
           to long may yield gibberish in either case. 
What really matters
           is whether converting back to double again
reproduces what we
           started with. */
!         if (wholepart &gt; LONG_MIN-1.0 &amp;&amp; wholepart &lt;
LONG_MAX+1.0) {
!               aslong = (long)wholepart;
!               if ((double)aslong == wholepart)
!                       return PyInt_FromLong(aslong);
!         }
        PyErr_SetString(PyExc_OverflowError, &quot;float too
large to convert&quot;);
        return NULL;
  }

        
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH,
England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-07 15:54

Message:
Logged In: YES 
user_id=33168

The code is out of date.  It looks like the problem has been
addressed.  Please provide an updated patch in a new report
if this is not the case.

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

Comment By: Nick Maclaren (nmm1)
Date: 2003-08-15 08:08

Message:
Logged In: YES 
user_id=652073

Thanks for the remark about closing.  I tried to append,
but Sourceforge wouldn't let me.  It is all a while ago
now, though.


Heck.  I remember the discussion.  That has problems when
rounding gets in the way.  The following is an improved
fix and SHOULD work on all machines, past, present and
future that support standard C and used a power of two
base floating-point (or base 10, actually):

*** floatobject.c.org   Tue Jan 28 19:40:35 2003
--- floatobject.c       Fri Aug 15 15:22:48 2003
***************
*** 645,667 ****
  {
        double x = PyFloat_AsDouble(v);
        double wholepart;       /* integral portion of x,
rounded toward 0 */
!       long aslong;            /* (long)wholepart */
  
        (void)modf(x, &amp;wholepart);
- #ifdef RISCOS
-       /* conversion from floating to integral type would
raise exception */
-       if (wholepart&gt;LONG_MAX || wholepart&lt;LONG_MIN) {
-               PyErr_SetString(PyExc_OverflowError, &quot;float
too large to convert&quot;);
-               return NULL;
-       }
- #endif
        /* doubles may have more bits than longs, or vice
versa; and casting
           to long may yield gibberish in either case.  What
really matters
           is whether converting back to double again
reproduces what we
!          started with. */
!       aslong = (long)wholepart;
!       if ((double)aslong == wholepart)
!               return PyInt_FromLong(aslong);
        PyErr_SetString(PyExc_OverflowError, &quot;float too
large to convert&quot;);
        return NULL;
  }
--- 645,675 ----
  {
        double x = PyFloat_AsDouble(v);
        double wholepart;       /* integral portion of x,
rounded toward 0 */
!       long aslong, z;         /* (long)wholepart */
!       int i, j, k;
  
        (void)modf(x, &amp;wholepart);
        /* doubles may have more bits than longs, or vice
versa; and casting
           to long may yield gibberish in either case.  What
really matters
           is whether converting back to double again
reproduces what we
!          started with.  And remember that exceptions can
always occur. */
!       if (wholepart &gt; LONG_MIN/2 &amp;&amp; wholepart &lt;
LONG_MAX/2)
!               x = 0.0;
!       else {
!               k = (x &gt;= 0.0);
!               x = wholepart;
!               for (i = (sizeof(long)*CHAR_BIT-1)/16; i &gt;=
0; --i) {
!                       z = LONG_MAX;
!                       for (j = 0; j &lt; i; ++j) z &gt;&gt;= 16;
!                       x -= (k ? 1.0 :
-1.0)*ldexp(z&amp;0xffff,16*i);
!               }
!               if (! k) x = (LONG_MAX+LONG_MIN)-x;
!       }
!         if (x &lt;= 0.0) {
!               aslong = (long)wholepart;
!               if ((double)aslong == wholepart)
!                       return PyInt_FromLong(aslong);
!         }
        PyErr_SetString(PyExc_OverflowError, &quot;float too
large to convert&quot;);
        return NULL;
  }

I have tested it, but don't know the internals well enough
to test it exhaustively.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-15 05:44

Message:
Logged In: YES 
user_id=33168

Nick, if we do close a bug, you can still make comments and
we'll see it.  Thanks.

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

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

From noreply at sourceforge.net  Sun Oct  8 01:25:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 16:25:30 -0700
Subject: [ python-Bugs-971213 ] another threads+readline+signals nasty
Message-ID: <E1GWLXu-0003yF-VT@sc8-sf-web5.sourceforge.net>

Bugs item #971213, was opened at 2004-06-11 08:30
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 7
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: another threads+readline+signals nasty

Initial Comment:
python -c "import time, readline, thread;
thread.start_new_thread(raw_input, ()); time.sleep(2)"

Segfaults on ^C<return>

Fails on Linux, freebsd.

On linux (FC - using kernel 2.6.1, glibc 2.3.3, gcc-3.3.3)

(gdb) where
#0  0x002627a2 in _dl_sysinfo_int80 () from
/lib/ld-linux.so.2
#1  0x008172b1 in ___newselect_nocancel () from
/lib/tls/libc.so.6
#2  0x0011280b in time_sleep (self=0x0, args=0xb7fe17ac)
    at Modules/timemodule.c:815

on FreeBSD 5.2.1-RC, a different error.

Fatal error 'longjmp()ing between thread contexts is
undefined by POSIX 1003.1' at line 72 in file
/usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = 2)
Abort (core dumped)


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-07 16:25

Message:
Logged In: YES 
user_id=33168

I'm closing this since it's presumably fixed.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-08-18 22:35

Message:
Logged In: YES 
user_id=849994

Not reproducable here either (Gentoo x86).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-18 20:09

Message:
Logged In: YES 
user_id=33168

This doesn't crash for me any more.  I remember there was
another fix for socket timeouts and Ctrl-C.  Maybe that
fixed this too?  Anthony, can you reproduce this?

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

Comment By: Michael Hudson (mwh)
Date: 2005-10-03 04:13

Message:
Logged In: YES 
user_id=6656

I can't, on OS X or debian.  

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 21:12

Message:
Logged In: YES 
user_id=33168

I can reproduce with cvs head (gentoo linux/amd64).

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

Comment By: Michael Hudson (mwh)
Date: 2005-04-07 02:03

Message:
Logged In: YES 
user_id=6656

I think this is fixed now, as in I can't reproduce it with CVS 
HEAD. Not sure why!  I can think of a few fixes that might be responsible.

It still messes the terminal up, though.

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

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 14:41

Message:
Logged In: YES 
user_id=6656

Bah, this still segfaults with CVS head.

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

Comment By: Michael Hudson (mwh)
Date: 2004-06-21 03:45

Message:
Logged In: YES 
user_id=6656

Can you try the patch that's *now* in 960406?  It seems to help 
for me (but I really would rather not think too hard about this!).

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

Comment By: Michal Pasternak (mpasternak)
Date: 2004-06-11 08:43

Message:
Logged In: YES 
user_id=799039

readline used on FreeBSD was readline-4.3pl5; everything else: gcc 3.3.3, 
ncurses, libc were standard from 5.2.1.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-06-11 08:39

Message:
Logged In: YES 
user_id=29957

The patch in #960406 doesn't help here.

The FC test system also has readline-4.3, if it helps, as
does the FreeBSD box. It apparently doesn't crash on OSX.



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

Comment By: Michael Hudson (mwh)
Date: 2004-06-11 08:38

Message:
Logged In: YES 
user_id=6656

Hmm.  Doesn't crash on OS X.  Messes the terminal up good and 
proper, though.

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

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

From noreply at sourceforge.net  Sun Oct  8 02:26:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 17:26:31 -0700
Subject: [ python-Feature Requests-1572968 ] release GIL while doing I/O
	operations in the mmap module
Message-ID: <E1GWMUx-0005n4-PD@sc8-sf-web2.sourceforge.net>

Feature Requests item #1572968, was opened at 2006-10-08 02:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572968&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: release GIL while doing I/O operations in the mmap module

Initial Comment:
There is a few system I/O calls in the mmap module that
can take some time. Would be be possible to put
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS around
these to release the GIL and allow other Python threads
to do their work?

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

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

From noreply at sourceforge.net  Sun Oct  8 05:16:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Oct 2006 20:16:42 -0700
Subject: [ python-Bugs-1571112 ] simple moves freeze IDLE
Message-ID: <E1GWP9e-00011o-4K@sc8-sf-web5.sourceforge.net>

Bugs item #1571112, was opened at 2006-10-04 23:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
>Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Douglas W. Goodall (douglas_goodall)
>Assigned to: Nobody/Anonymous (nobody)
Summary: simple moves freeze IDLE

Initial Comment:
Using version 2.5 for Windows...

import os

then type "print os." and wait for the 
hint window. then scroll to the bottom (spawnv).

That's it. At this point IDLE is frozen.

I have done it a few times in a row. It seems
very reproduceable to me.

Be well. Doug

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-10-07 22:16

Message:
Logged In: YES 
user_id=80475

I can reproduce this in Py2.5 final.  This may be a 
TkInter bug and not unique to IDLE or to Windows.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 11:58

Message:
Logged In: YES 
user_id=341410

I can reproduce this on 2.5 beta 2, and it dies exactly when
'spawnv' is highlighted.  I have no suggested fixes, only
reproducing to verify that this is not user-specific bug.

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

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

From noreply at sourceforge.net  Sun Oct  8 09:12:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 00:12:42 -0700
Subject: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try
	statement
Message-ID: <E1GWSq2-0004YP-UC@sc8-sf-web6.sourceforge.net>

Bugs item #1569998, was opened at 2006-10-03 14:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 8
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Jeremy Hylton (jhylton)
Summary: 2.5 incorrectly permits break inside try statement

Initial Comment:
The new AST compiler permits the break statement inside
*any* frame block, rather than requiring that there be
a loop somewhere on the block stack.

Will add examples in a comment where SF shouldn't
destroy the formatting.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-08 07:12

Message:
Logged In: YES 
user_id=849994

Backported to 2.5 in r52222.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2006-10-04 14:33

Message:
Logged In: YES 
user_id=31392

Fixed on the trunk by r52129. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-04 05:47

Message:
Logged In: YES 
user_id=33168

Jeremy checked in r52129 on head.  Needs backport to 2.5.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-10-03 14:05

Message:
Logged In: YES 
user_id=1038590

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
SyntaxError: 'break' outside loop

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.>>> try:
...     print 1
...     break
...     print 2
... finally:
...     print 3
...
1
3

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

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

From noreply at sourceforge.net  Sun Oct  8 09:14:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 00:14:51 -0700
Subject: [ python-Bugs-1568243 ] init_types
Message-ID: <E1GWSs6-0004kX-WE@sc8-sf-web6.sourceforge.net>

Bugs item #1568243, was opened at 2006-09-30 09:34
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Bosko Vukov (bvukov)
Assigned to: Kristj?n Valur (krisvale)
Summary: init_types

Initial Comment:
I tried to build the final version of Python 2.5, and
found that function init_types in file Python-ast.c is
created as
int init_types(void) ....
but in file config.c it's declared as
extern void init_types(void);
Visual Studio 2005 didn't want to build the project
until I changed the config.c to be the same...
extern int  init_types(void);
Nothing big ;)
Regards, Bosko


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-08 07:14

Message:
Logged In: YES 
user_id=849994

This is now fixed by rev. 52219.

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

Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:17

Message:
Logged In: YES 
user_id=1262199

the pcbuild8.vcproj in the Python trunk has this fixed.  I
will backport that tho 2.5 shortly.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 12:11

Message:
Logged In: YES 
user_id=21627

Kristijan, can you please backport your changes to the 2.5
trunk and then close this report?

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 19:22

Message:
Logged In: YES 
user_id=1611513

Thanks, loewis.  I take your advice.  

I see that things have changed in SVN anyway.  I like the
new approach of using Visual STudio's configuration
management.  

When I (try to) build PGIRelease to instrument the python
dll, I get a curious error:

1>Compiling...
1>zlibmodule.c
1>Compiling resources...
1>Linking...
1>   Creating library
Win32\PGIRelease\pythoncore/python26.lib and object
Win32\PGIRelease\pythoncore/python26.exp
1>Generating code
1>c:\Documents and Settings\kferrio\My
Documents\Dev\Python-2.5\Modules\zipimport.c : fatal error
C1350: error loading dll 'pgodb80.dll': dll not found
1>LINK : fatal error LNK1257: code generation failed
1>Build log was saved at "file://c:\Documents and
Settings\kferrio\My
Documents\Dev\Python-2.5\PCbuild8\Win32\PGIRelease\pythoncore\BuildLog.htm"
1>pythoncore - 2 error(s), 2 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0
skipped ==========

I definitely do not understand this -- yet.  Meanwhile, any
clues would be welcome.

Thanks.

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

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

Message:
Logged In: YES 
user_id=21627

I think you should avoid building pythoncore_pgo; it's of no
use. 

Or else, study all documentation you can find on Microsoft's
profile-guided-optimization for a few days, read all web
logs about the bugs in this software, and perhaps you can
succeed in building it, by deleting the right files in the
right order.

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-02 18:28

Message:
Logged In: YES 
user_id=1611513

I am expereincing the problem described by the original
poster.  I undertand that MSVC8 is not officially supported,
and I'm trying anyway.

I downloaded the 2.5.0 final tarball and began working in
the PCbuild8 directory.

Firts off, I found that I had to build two projects before
pythoncore would build: 

  make_versioninfo
  make_buildinfo

When I tried to build pythoncore, I got the linker error
saying that _init_types could not be found.  So I added
_typesmodule.c to the pythoncore project.  Finally,
pythoncore built cleanly.

Next up, I wanted to build pythoncore_pgo.  So I added 
_typesmodule to this project also.  But try as I might,
every attempt to build pythoncore_pgo produces the link
error on _init_types.  (I also did a 'clean' on pythoncore
just to be safe.)

I do not understand this.  Unlike the original poster, I
have not modified any source.  It seems like the definition
of pyMODINIT_FUNC as extern "C" void might be involved, but
I agree with gbrandl that the static int in Python-ast.c is
not the issue, because that is a different scope.  

So the linkage problem with pythoncore_pgo remains a mystery
to me.  I hope someone has more clues than me.



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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-02 14:00

Message:
Logged In: YES 
user_id=21627

Notice that the PCbuild8 directory isn't really supported...

In any case, the bug is that PCbuild8 does not have the
reference to _typesmodule, not that init_types in
Python-ast.c is static.

If you revert your change to Python-ast.c, and change
pythoncore.vcproj, it should build fine.

This is already fixed in r51751 in the trunk; not sure
whether backporting it is necessary.


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

Comment By: Bosko Vukov (bvukov)
Date: 2006-09-30 17:50

Message:
Logged In: YES 
user_id=1292849

I opened solution file from folder PCbuild8, and inside
project file pythoncore.vcproj there is no reference to
_typesmodule.c. It exists in pythoncore.vcproj in the
PBbuild folder ( for older version's ). I added the missing
_typesmodule.c inside, and returned back the changes I made,
and aft er that linker reported 'Python-ast.obj : error
LNK2005: _init_types already defined in _typesmodule.obj'

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 11:27

Message:
Logged In: YES 
user_id=849994

The problem is another one: The config.c init_types function
belongs to the _types module, while the Python-ast.c
init_types is an internal function. They shouldn't clash.

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

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

From noreply at sourceforge.net  Sun Oct  8 09:43:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 00:43:18 -0700
Subject: [ python-Feature Requests-1534942 ] Print identical floats
	consistently
Message-ID: <E1GWTJe-0007Y4-6M@sc8-sf-web6.sourceforge.net>

Feature Requests item #1534942, was opened at 2006-08-05 06:19
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534942&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.6
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Marc W. Abel (gihon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Print identical floats consistently

Initial Comment:
Hello again and thank you,

This is a rewrite of now-closed bug #1534769.

As you know, 

>>> print .1
>>> print (.1,)

give different results because the __str__ call from
print becomes a __repr__ call on the tuple, and it
stays a __repr__ beneath that point in any recursion. 
>From the previous discussion, we need behavior like
this so that strings are quoted inside tuples.

I suggest that print use a third builtin that is
neither __str__ nor __repr__.  The name isn't
important, but suppose we call it __strep__ in this
feature request.  __strep__ would pass __strep__ down
in the recursion, printing floats with __str__ and
everything else with __repr__.

This would then

>>> print .1                and
>>> print (.1,)

with the same precision.

Marc


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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-08 07:43

Message:
Logged In: YES 
user_id=849994

Closing due to lack of other opinions.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-08-09 20:35

Message:
Logged In: YES 
user_id=849994

I recommend closing this. Introducing yet another to-string
magic function is not going to make things simpler, and who
knows if the str/repr distinction is going to make it into
3.0 anyway.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-08-09 16:14

Message:
Logged In: YES 
user_id=341410

Please note that 'print non_string' is a convenience.  Its
output is neither part of the language spec, nor is the
propagation of str/repr calls.

If you want to control how items are formatted during print,
you should use the built-in string formatting mechanisms. 
The standard 'print "%.1f"%(.1,)' and 'print
"%(x).1f"%({x:.1})' works with all pythons, and there is an
updated templating mechanism available in more recent Python
versions.

I'm not the last word on this, but I don't see an actual
use-case that isn't satisfied by using built-in
string-formatting.

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

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

From noreply at sourceforge.net  Sun Oct  8 16:01:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 07:01:04 -0700
Subject: [ python-Bugs-1573180 ] import org.python.core imports local org.py
Message-ID: <E1GWZDE-0005uF-NH@sc8-sf-web1.sourceforge.net>

Bugs item #1573180, was opened at 2006-10-08 16:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573180&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: import org.python.core imports local org.py

Initial Comment:
It seems to me that the fact that "import
org.python.core" imports a local "org.py" file is not
the intended behavior.  Here are the details:

----------------------------------------
% python -m org.python.core
Traceback (most recent call last):
  File "/sw/lib/python2.5/runpy.py", line 85, in run_module
    loader = get_loader(mod_name)
  File "/sw/lib/python2.5/pkgutil.py", line 456, in
get_loader
    return find_loader(fullname)
  File "/sw/lib/python2.5/pkgutil.py", line 466, in
find_loader
    for importer in iter_importers(fullname):
  File "/sw/lib/python2.5/pkgutil.py", line 422, in
iter_importers
    __import__(pkg)
  File "org.py", line 1, in <module>
    test
NameError: name 'test' is not defined

% cat org.py
test
----------------------------------------

Best wishes,

EOL

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

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

From noreply at sourceforge.net  Sun Oct  8 17:41:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 08:41:45 -0700
Subject: [ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Message-ID: <E1GWamf-0003v9-BM@sc8-sf-web3.sourceforge.net>

Bugs item #1569517, was opened at 2006-10-02 19:54
Message generated for change (Comment added) made by krisvale
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Coatimundi (coatimundi)
Assigned to: Kristj?n Valur (krisvale)
Summary: PGIRelease linkage fails on pgodb80.dll

Initial Comment:
Hi.  I'm interested in learning how to optimize Python
for Windows.  I have made a similar report as a
follow-on to Bug 1568243, but it's really a  separate
issue.

Let me emphasize that what I am about to describe this
is *not* a bug in the Python build system.  But it may
be worth calling out in the README file for PCbuild8.

When building PGIRelease to instrument the pythoncore
DLL, the linker fails because it cannot find
pgodb80.dll.  This file is required for PGO with Visual
C++ under Visual Studio 2005 and is shipped with the
Professional version, but not with the Express version
or (apparently) the Standard version I have.  Looks
like upgrade time...

I hope this helps someone else.


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

>Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-08 15:41

Message:
Logged In: YES 
user_id=1262199

rev. 52219 backports the changes from the trunk to 2.5.  The
build process for PGO builds is now different.

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

Comment By: Coatimundi (coatimundi)
Date: 2006-10-06 02:21

Message:
Logged In: YES 
user_id=1611513

Excellent.  I really didn't expect much interest in this
report.  Thanks!

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

Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:17

Message:
Logged In: YES 
user_id=1262199

the pcbuild8.vcproj in the Python trunk has this fixed.  I
will backport that tho 2.5 shortly.

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

Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:14

Message:
Logged In: YES 
user_id=1262199

This has been fixed in the 2.6 trunk, where the PGO build is
done differently.  I will retrofit that project setting to
2.5 shortly.

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

Comment By: Douglas W. Goodall (douglas_goodall)
Date: 2006-10-05 05:38

Message:
Logged In: YES 
user_id=1553177

I hate Microsoft. I have VS 2005 Standard also. Bill 
always sticks it to you in the end.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 12:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

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

From noreply at sourceforge.net  Sun Oct  8 17:42:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 08:42:39 -0700
Subject: [ python-Bugs-1567910 ] missing _typesmodule.c,
	Visual Studio 2005 pythoncore.vcproj
Message-ID: <E1GWanX-000417-Tr@sc8-sf-web3.sourceforge.net>

Bugs item #1567910, was opened at 2006-09-29 17:47
Message generated for change (Comment added) made by krisvale
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
Resolution: None
Priority: 5
Submitted By: everbruin (everbruin)
Assigned to: Kristj?n Valur (krisvale)
Summary: missing _typesmodule.c,Visual Studio 2005 pythoncore.vcproj

Initial Comment:
Python 2.5's Visual Studio 2005 pythoncore.vcproj (in
PCBuild8 folder) is missing Modules/_typesmodule.c
(note the VS 2003 pythoncore.vcproj in PCBuild
correctly has it).

The bug is that binaries built w/o the file will give a
SystemError when "import _types" is done (eg by types.py).

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

>Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-08 15:42

Message:
Logged In: YES 
user_id=1262199

This is now fixed by rev. 52219.

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

Comment By: Kristj?n Valur (krisvale)
Date: 2006-10-05 09:16

Message:
Logged In: YES 
user_id=1262199

Hi there.  The .vcproj in the python trunk has these issues
fixed.  I will backport them to 2.5 maintainance shortly.

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

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-03 12:12

Message:
Logged In: YES 
user_id=21627

Kristjan, can you please take a look?

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

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

Message:
Logged In: YES 
user_id=21627

I find it hard to believe that you get this precise error; I
would have expected that the pythoncore project would fail
to build instead.

Notice that PCbuild8 is not really supported.

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

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

From noreply at sourceforge.net  Sun Oct  8 17:52:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 08:52:47 -0700
Subject: [ python-Bugs-1573180 ] import org.python.core imports local org.py
Message-ID: <E1GWaxL-0005K8-4E@sc8-sf-web6.sourceforge.net>

Bugs item #1573180, was opened at 2006-10-08 14:01
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573180&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: import org.python.core imports local org.py

Initial Comment:
It seems to me that the fact that "import
org.python.core" imports a local "org.py" file is not
the intended behavior.  Here are the details:

----------------------------------------
% python -m org.python.core
Traceback (most recent call last):
  File "/sw/lib/python2.5/runpy.py", line 85, in run_module
    loader = get_loader(mod_name)
  File "/sw/lib/python2.5/pkgutil.py", line 456, in
get_loader
    return find_loader(fullname)
  File "/sw/lib/python2.5/pkgutil.py", line 466, in
find_loader
    for importer in iter_importers(fullname):
  File "/sw/lib/python2.5/pkgutil.py", line 422, in
iter_importers
    __import__(pkg)
  File "org.py", line 1, in <module>
    test
NameError: name 'test' is not defined

% cat org.py
test
----------------------------------------

Best wishes,

EOL

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

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-08 15:52

Message:
Logged In: YES 
user_id=849994

Why shouldn't "import org.python.core" first import org.py,
the org/python.py, then org/python/core.py, in CPython?
The current directory is on sys.path for -m arguments, so
the "local" org.py is imported.

The name "org.python.core" somehow reminds me of Jython. If
this is a Jython issue, it doesn't belong in this tracker.

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

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

From noreply at sourceforge.net  Sun Oct  8 19:16:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 10:16:19 -0700
Subject: [ python-Bugs-1573180 ] import org.python.core imports local org.py
Message-ID: <E1GWcGB-0004sT-2n@sc8-sf-web5.sourceforge.net>

Bugs item #1573180, was opened at 2006-10-08 16:01
Message generated for change (Comment added) made by eolebigot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573180&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: import org.python.core imports local org.py

Initial Comment:
It seems to me that the fact that "import
org.python.core" imports a local "org.py" file is not
the intended behavior.  Here are the details:

----------------------------------------
% python -m org.python.core
Traceback (most recent call last):
  File "/sw/lib/python2.5/runpy.py", line 85, in run_module
    loader = get_loader(mod_name)
  File "/sw/lib/python2.5/pkgutil.py", line 456, in
get_loader
    return find_loader(fullname)
  File "/sw/lib/python2.5/pkgutil.py", line 466, in
find_loader
    for importer in iter_importers(fullname):
  File "/sw/lib/python2.5/pkgutil.py", line 422, in
iter_importers
    __import__(pkg)
  File "org.py", line 1, in <module>
    test
NameError: name 'test' is not defined

% cat org.py
test
----------------------------------------

Best wishes,

EOL

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

>Comment By: E.-O. Le Bigot (eolebigot)
Date: 2006-10-08 19:16

Message:
Logged In: YES 
user_id=1440667

>From the doc:
 
http://docs.python.org/tut/node8.html#SECTION008400000000000000000

I had understood that the search performed during the import
process involved looking in "subdirectories": I thought that
"import org.python.core" would first search for an "org/"
directory and not for an "org.py" file.

But I'm no expert in imports with "dotted" packages...

EOL

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-08 17:52

Message:
Logged In: YES 
user_id=849994

Why shouldn't "import org.python.core" first import org.py,
the org/python.py, then org/python/core.py, in CPython?
The current directory is on sys.path for -m arguments, so
the "local" org.py is imported.

The name "org.python.core" somehow reminds me of Jython. If
this is a Jython issue, it doesn't belong in this tracker.

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

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

From noreply at sourceforge.net  Sun Oct  8 19:44:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 10:44:25 -0700
Subject: [ python-Bugs-1570284 ] Launcher reset to factory button provides bad
	command-line
Message-ID: <E1GWchN-0007a7-8M@sc8-sf-web5.sourceforge.net>

Bugs item #1570284, was opened at 2006-10-03 23:17
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: jjackson (jejackson)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Launcher reset to factory button provides bad command-line

Initial Comment:
If I push the "Reset to factory settings" in Python Launcher's Preferences 
window, the command line gets a bogues "(null)" inserted, which makes a 
mess of things. I don't think that was what was intended.

In trying to debug this, I notice in the source for FileSettings.m, at line 
209
there are two duplicated lines:

            [NSNumber numberWithBool: nosite], @"nosite",
            [NSNumber numberWithBool: nosite], @"nosite",

Also, I notice at FileSettings.m:236

    value = [dict objectForKey: @"nosite"];
    if (value) nosite = [value boolValue];
    value = [dict objectForKey: @"nosite"];
    if (value) tabs = [value boolValue];

I'm wondering if these second "nosite"s should be "tabs", and if that 
would fix the problem.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 19:44

Message:
Logged In: YES 
user_id=580910

Fixed in revision 52229 (trunk), 52230 (2.5 branch) and 52231/52232 (2.4 
branch).

The latter checkin is a lot larger than just this fix, it is a backport of the entire 
universal binary support code from 2.5 to the official 2.4 tree (the 2.4.3. 
installer was build from an out-of-tree "branch").

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-06 12:26

Message:
Logged In: YES 
user_id=580910

I'll have a look at this this weekend. On first glance the analysis for the source 
code looks correct and both lines should be changed, but I don't have time just 
ow to do this and test the results just now (and then backport to the 2.5 and 2.4 
trees)

P.S. I'll be doing a huge checking on the 2.4 branch this weekend, backporting 
the universal python stuff to the official tree. Last week was busier than 
expected, hence the late checkin.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-04 07:48

Message:
Logged In: YES 
user_id=33168

Ronald, I'm guessing that Jack still doesn't have time.  Do
you know anything about this?

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

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

From noreply at sourceforge.net  Sun Oct  8 19:44:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 10:44:38 -0700
Subject: [ python-Bugs-1570284 ] Launcher reset to factory button provides bad
	command-line
Message-ID: <E1GWcha-0002On-C5@sc8-sf-web1.sourceforge.net>

Bugs item #1570284, was opened at 2006-10-03 23:17
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: jjackson (jejackson)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Launcher reset to factory button provides bad command-line

Initial Comment:
If I push the "Reset to factory settings" in Python Launcher's Preferences 
window, the command line gets a bogues "(null)" inserted, which makes a 
mess of things. I don't think that was what was intended.

In trying to debug this, I notice in the source for FileSettings.m, at line 
209
there are two duplicated lines:

            [NSNumber numberWithBool: nosite], @"nosite",
            [NSNumber numberWithBool: nosite], @"nosite",

Also, I notice at FileSettings.m:236

    value = [dict objectForKey: @"nosite"];
    if (value) nosite = [value boolValue];
    value = [dict objectForKey: @"nosite"];
    if (value) tabs = [value boolValue];

I'm wondering if these second "nosite"s should be "tabs", and if that 
would fix the problem.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 19:44

Message:
Logged In: YES 
user_id=580910

Fixed in revision 52229 (trunk), 52230 (2.5 branch) and 52231/52232 (2.4 
branch).

The latter checkin is a lot larger than just this fix, it is a backport of the entire 
universal binary support code from 2.5 to the official 2.4 tree (the 2.4.3. 
installer was build from an out-of-tree "branch").

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-06 12:26

Message:
Logged In: YES 
user_id=580910

I'll have a look at this this weekend. On first glance the analysis for the source 
code looks correct and both lines should be changed, but I don't have time just 
ow to do this and test the results just now (and then backport to the 2.5 and 2.4 
trees)

P.S. I'll be doing a huge checking on the 2.4 branch this weekend, backporting 
the universal python stuff to the official tree. Last week was busier than 
expected, hence the late checkin.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-04 07:48

Message:
Logged In: YES 
user_id=33168

Ronald, I'm guessing that Jack still doesn't have time.  Do
you know anything about this?

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

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

From noreply at sourceforge.net  Sun Oct  8 19:47:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 10:47:05 -0700
Subject: [ python-Bugs-1571112 ] simple moves freeze IDLE
Message-ID: <E1GWcjx-0003vP-4M@sc8-sf-web2.sourceforge.net>

Bugs item #1571112, was opened at 2006-10-05 06:46
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Douglas W. Goodall (douglas_goodall)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple moves freeze IDLE

Initial Comment:
Using version 2.5 for Windows...

import os

then type "print os." and wait for the 
hint window. then scroll to the bottom (spawnv).

That's it. At this point IDLE is frozen.

I have done it a few times in a row. It seems
very reproduceable to me.

Be well. Doug

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 19:47

Message:
Logged In: YES 
user_id=580910

As an additional data point: this seems to work just fine on Mac OS X.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-10-08 05:16

Message:
Logged In: YES 
user_id=80475

I can reproduce this in Py2.5 final.  This may be a 
TkInter bug and not unique to IDLE or to Windows.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 18:58

Message:
Logged In: YES 
user_id=341410

I can reproduce this on 2.5 beta 2, and it dies exactly when
'spawnv' is highlighted.  I have no suggested fixes, only
reproducing to verify that this is not user-specific bug.

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

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

From noreply at sourceforge.net  Sun Oct  8 20:10:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 11:10:08 -0700
Subject: [ python-Bugs-1544102 ] ctypes unit test fails (test_macholib.py)
	under MacOS 10.4.7
Message-ID: <E1GWd6G-0001az-4P@sc8-sf-web4.sourceforge.net>

Bugs item #1544102, was opened at 2006-08-21 19:59
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: M. J. Fromberger (njdibfm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: ctypes unit test fails (test_macholib.py) under MacOS 10.4.7

Initial Comment:
While building 2.5rc1 under MacOS 10.4.7, one of the ctypes module 
unit tests fails:

% ./python.exe -V
Python 2.5c1 (r25c1:51426, Aug 21 2006, 11:30:05) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin

% uname -a
Darwin chrysophylax 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 
15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power 
Macintosh powerpc

Output report:
===========================================
===========================
FAIL: test_find (ctypes.test.test_macholib.MachOTest)
------------------------------------------------------------
----------
Traceback (most recent call last):
  File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 
55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError

------------------------------------------------------------
----------
Ran 287 tests in 0.933s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_ctypes.py", line 12, in <module>
    test_main()
  File "Lib/test/test_ctypes.py", line 9, in test_main
    run_suite(unittest.TestSuite(suites))
  File "/usr/local/src/python2.5/Lib/test/test_support.py", line 426, in 
run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 
55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 20:10

Message:
Logged In: YES 
user_id=580910

This is a rather annoying, but shallow, failure. Dlopen on osx is quite touchy 
about the flags you use to open a shared library.

Anyway, all tests pass on the trunk and 2.5 branch, I guess this was fixed before 
2.5 was released. I have had an e-mail exchange with Thomas Heller about a 
simular issue and he has checked in a fixed for that before 2.5 was released.\

I'm therefore closing this issue.

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

Comment By: Jack Jansen (jackjansen)
Date: 2006-08-21 23:10

Message:
Logged In: YES 
user_id=45365

Ronald: just guesing that you know more about this than I do...

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

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

From noreply at sourceforge.net  Sun Oct  8 20:21:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 11:21:18 -0700
Subject: [ python-Bugs-1561243 ] mac installer profile patch vs. .bash_login
Message-ID: <E1GWdH4-0002cT-UE@sc8-sf-web3.sourceforge.net>

Bugs item #1561243, was opened at 2006-09-19 09:32
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: mac installer profile patch vs. .bash_login

Initial Comment:
The mac installer for 2.4.3 and 2.5 patches ~/.profile or ~/.bash_profile. 
If a .bash_login file exists and no .bash_profile exists the installer 
currently creates a .profile, which won't be used by bash.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 20:21

Message:
Logged In: YES 
user_id=580910

This is probably fixed in 52238, 52239 and 52240 (trunk, 2.5, 2.4), but needs 
more testing to make sure that we now test for all edge condiditions.

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

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

From noreply at sourceforge.net  Sun Oct  8 20:25:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 11:25:23 -0700
Subject: [ python-Bugs-1560114 ] Tutorial: incorrect info about package
	importing and mac
Message-ID: <E1GWdL1-0003MP-1r@sc8-sf-web6.sourceforge.net>

Bugs item #1560114, was opened at 2006-09-17 14:24
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560114&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: C L (cl_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial: incorrect info about package importing and mac

Initial Comment:
Section 6.4.1 of the Python tutorial says:
"Now what happens when the user writes from Sound.Effects import *? 
Ideally, one would hope that this somehow goes out to the filesystem, 
finds which submodules are present in the package, and imports them all. 
Unfortunately, this operation does not work very well on Mac and 
Windows platforms, where the filesystem does not always have accurate 
information about the case of a filename! On these platforms, there is no 
guaranteed way to know whether a file ECHO.PY should be imported as a 
module echo, Echo or ECHO."

This is incorrect. It's true that the (default *) Mac file system does not 
allow file names differing only in case in the same directory, and lets you 
access a file by any variation of case; but the file system always records 
and returns the file name with the exact capitalization that was given 
when the name was assigned. In other words, if you create a file called 
"MixedCase.py" you can access it as "mixedcase.py", "MiXeDcAsE.pY" etc., 
but if you list the contents of its parent directory the name will always be 
given as "MixedCase.py".

This has been true of all versions of the Mac OS going back to System 1.0. 
Therefore, none of that paragraph applies to any Mac system; on the 
contrary, the file system always has accurate information about the case 
of a file name. That section of the text should be changed to remove the 
reference to the Mac platform.

(*: recent Mac OS X systems also allow one to use the HFSX filesystem 
variant, which allows file names differing only in case and matches file 
names only when the case is exactly identical - ie, the fully case-sensitive 
Unix semantics. But again, this has no bearing on the ability to reliably 
obtain the exact case of the name of a file.)

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 20:25

Message:
Logged In: YES 
user_id=580910

+1 here. MacOS was case-preserving when I started using it (around OS8) and 
that hasn't changed. It also doesn't have the odd behaviour of windows where 
some versions of windows might convert short names to all uppercase.

Hence the Mac shouldn't be mentioned in this section.

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

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

From noreply at sourceforge.net  Sun Oct  8 20:34:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 11:34:23 -0700
Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9
Message-ID: <E1GWdTj-0007Ev-S0@sc8-sf-web1.sourceforge.net>

Bugs item #1542949, was opened at 2006-08-19 03:51
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Pending
Resolution: Fixed
Priority: 6
Submitted By: David Strozzi (dstrozzi)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: idle in python 2.5c1 freezes on macos 10.3.9

Initial Comment:
Hi,

I installed python 2.5b3 on a powerbook ppc laptop
running macos 10.3.9 a few days ago.  python and idle
worked.  Now I installed 2.5c1.  python works fine from
a terminal.  When I start idle, it loads, puts up its
menu bar, opens a shell window, displays usual startup
info, and gives me a prompt.  But, I can't type or get
a cursor. Whenever I move the mouse over the idle
window or menu bar, I get a spinning color wheel and
can't do anything.

I deleted the whole /library/python tree, reinstalled
2.5c1, and exactly the same thing happened.

Oh, and I rebooted :)

Not sure what is happening, or how to diagnose.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 20:34

Message:
Logged In: YES 
user_id=580910

I've just checked in a fix for this on all 3 active branches (trunk, 2.5 and 2.4).

BTW. The installer is supposed to install the files in Python.framework as 
owned by group admin, with mode 0664, admin users are supposed to be 
able to edit files and add new software without using sudo. That obviously 
didn't work as designed, the tree is owned by root:wheel on my 10.3.9 
testbox (the only one without a build-from-source install at the moment).

To fix this: open a terminal window and give the following command:
 
   sudo chgrp -R admin /Library/Framework/Python.framework

This will ask for a password, use your own password there. You have to be 
logged in with an admin account to do this.

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

Comment By: David Strozzi (dstrozzi)
Date: 2006-09-26 19:01

Message:
Logged In: YES 
user_id=1056922

Great, thanks for sorting this out!

I tried the edit you suggested in your first reply.  Alas,
I'm not root on my system - I am in the admin group, but I
don't have total complete powers.  The Python.Framework dir
in /Library/Frameworks has owner admin and group wheel.  I'm
not in the wheel group, so can't edit files.

I can wait for the patch, or maybe in the future the
installer could make the group admin instead of wheel?  This
may be too esoteric to my system's setup...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-24 20:46

Message:
Logged In: YES 
user_id=580910

It turns out to be a buglet in python2.5 after all. There is some code in 
distutils.sysconfig to strip out the -arch and -isysroot flags from the build flags 
when you ask for them through that way, but that doesn't fix all variables that 
need to be fixed.

I'll apply a patch in the morning.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-24 18:15

Message:
Logged In: YES 
user_id=580910

I'm seriously temped to call the problem you're having with numpy a bug in 
their system.

What happens is that the binary distribution for Python 2.5 (and 2.4.3 as well) 
is build as a universal binary on OSX 10.4. This is why you see '-arch ppc -
arch x86' in the compiler invocation. This works correctly on 10.4 but not on 
10.3.9, which is why distutils strips those arguments from the command-line 
on 10.3 systems.  That's all fine when you use the stock distutils, but numpy 
uses custom build commands and those don't work correctly with a universal 
build of python on 10.3.

The easiest way for you to get going again is open /Library/Frameworks/
Python.framework/Versions/2.5/lib/python2.5/config/Makefile in a text 
editor. Remove '-arch ppc -arch i386 -isysroot /Developer/SDKs/
MacOSX10.4u.sdk' from the definition of BASECFLAGS and LDFLAGS and then 
try to build numpy again


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

Comment By: David Strozzi (dstrozzi)
Date: 2006-09-23 00:35

Message:
Logged In: YES 
user_id=1056922

Hi,

Python 2.5 installs, and idle runs, perfectly on my 10.3.9
system!  Kudos to our noble MacOS builder!  Looks like the
problem vanished.

I'm going to risk bugging people here about my inability to
compile numpy 1.0* (* = betas and current release candidate
1) on the same 10.3.9 system.  The end of this post is a
dump of trying to install as per numpy directions.  One line
is very suspicious:

C compiler: gcc -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common
-dynamic -DNDEBUG -g -O3

-arch pcc -arch i386??  Smells bad.

10.4u.sdk??  I have sys 10.3.9;
/Developer/SDKs/MacOSX10.3.0.sdk exists on my system, but
not 10.4u.

Right after this, I get the error:
gcc: cannot specify -o with -c or -S and multiple compilations

gcc 3.3 is my 'main' gcc, although I finked 4.0 but haven't
replaced my 'main' gcc with it.

Anyway, thoughts are greatly appreciated, both by me and
presumably the numpy people (who haven't replied to any of
my bug postings :) )

********** The whole dump **************

> python setup.py install
Running from numpy source directory.
F2PY Version 2_3198
blas_opt_info:
  FOUND:
    extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
    define_macros = [('NO_ATLAS_INFO', 3)]
    extra_compile_args = ['-faltivec',
'-I/System/Library/Frameworks/vecLib.framework/Headers']

lapack_opt_info:
  FOUND:
    extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
    define_macros = [('NO_ATLAS_INFO', 3)]
    extra_compile_args = ['-faltivec']

running install
running build
running config_fc
running build_src
building py_modules sources
building extension "numpy.core.multiarray" sources
Generating build/src.macosx-10.3-fat-2.5/numpy/core/config.h
customize NAGFCompiler
customize AbsoftFCompiler
customize IbmFCompiler
Could not locate executable f95
customize GnuFCompiler
customize GnuFCompiler
customize GnuFCompiler using config
C compiler: gcc -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common
-dynamic -DNDEBUG -g -O3

compile options:
'-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-Inumpy/core/src -Inumpy/core/include
-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-c'
gcc: _configtest.c
gcc: cannot specify -o with -c or -S and multiple compilations
gcc: cannot specify -o with -c or -S and multiple compilations
failure.
removing: _configtest.c _configtest.o
numpy/core/setup.py:50: DeprecationWarning: raising a string
exception is deprecated
  raise "ERROR: Failed to test configuration"
Traceback (most recent call last):
  File "setup.py", line 89, in <module>
    setup_package()
  File "setup.py", line 82, in setup_package
    configuration=configuration )
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/core.py",
line 174, in setup
    return old_setup(**new_attr)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py",
line 151, in setup
    dist.run_commands()
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 974, in run_commands
    self.run_command(cmd)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/install.py",
line 16, in run
    r = old_install.run(self)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/install.py",
line 506, in run
    self.run_command('build')
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py",
line 333, in run_command
    self.distribution.run_command(command)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/build.py",
line 112, in run
    self.run_command(cmd_name)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py",
line 333, in run_command
    self.distribution.run_command(command)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py",
line 87, in run
    self.build_sources()
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py",
line 106, in build_sources
    self.build_extension_sources(ext)
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py",
line 212, in build_extension_sources
    sources = self.generate_sources(sources, ext)
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py",
line 270, in generate_sources
    source = func(extension, build_dir)
  File "numpy/core/setup.py", line 50, in generate_config_h
    raise "ERROR: Failed to test configuration"
ERROR: Failed to test configuration

strozzi2 at riata: ~/downloads/numpy-1.0rc1
> 

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-14 23:10

Message:
Logged In: YES 
user_id=580910

The scary bit is that the bug was "fixed" due to unclear differences between 
the build environment used for 2.5c1 and 2.5c2. 

I'll be building 2.5final as well, so expect this will stay fixed but I'm not 
entirely happy due to not knowing what caused the failure in the first place. It 
looks like 2.5c1 was build with a slighly different version of GCC (although 
both machines has Xcode 2.3 installed).

BTW. The issue still exists for 2.4.x, I hope to work on the 2.4 branch this 
weekend.

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

Comment By: David Strozzi (dstrozzi)
Date: 2006-09-14 23:03

Message:
Logged In: YES 
user_id=1056922

I just installed python 2.5 rc 2, and IDLE works!  On the
same 10.3.9 laptop which prompted me to post this bug.  I
guess the other who had problems should try rc2, and may
this bug had been laid to rest.

Thanks to whomever fixed it.

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

Comment By: diggableme (diggableme)
Date: 2006-09-09 19:18

Message:
Logged In: YES 
user_id=1594326

I am a new user that is experiencing the same exact problem.
 I have OSX.3.9 and everytime I start IDLE, it freezes and
the colorwheel somes up.  When I view the console output,
there are no errors or alert messages.

I have also tried uninstalling and re-installing from the
beginning with the same result.  I have been using the
instructions given at this site:
http://www.python.org/download/mac/
desp
I'm very interested to see if there is in fact a resolution
to this problem.  I'm at my wit's end.

-dig

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-08-28 18:59

Message:
Logged In: YES 
user_id=580910

I've created a new installer from the head of the release25-maint branch and 
that works correctly.

I'm keeping this issue open because I want to investigate why 2.5c1 doesn't 
work while the current head of the 2.5 branch does work.

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

Comment By: David Strozzi (dstrozzi)
Date: 2006-08-28 17:48

Message:
Logged In: YES 
user_id=1056922

Well, if there's anything I can do as a 10.3.9 user to test
this, let me know.  Too busy to delve into the python source
code though...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-08-28 17:22

Message:
Logged In: YES 
user_id=580910

I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, 
but then completely blocks (spinning cursor).

If I start IDLE from the commandline (/Applications/MacPython\ 2.5/
IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a 
valid command name. That requires further looking into, but is a red herring 
for this particular problem, removing the Tk-console hiding code in 
macosxSupport.py results in the same behaviour, without any further output 
on the console as well.

Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't 
help,  IDLE still hangs (Duh, that's because there's a /System/Library/
Frameworks/Tk.framework, which means a user install won't be used for 
IDLE).

The problem is also unrelated to my IDLE.app work, the same problem occurs 
when starting $prefix/lib/python2.5/idlelib/idle.py. 

According to gdb the IDLE process is handing in a semaphore call inside the 
Tcl mainloop. Time to get into serious debugging mode I guess :-(

BTW. IDLE does work correctly on a 10.4.7 system.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-08-28 15:59

Message:
Logged In: YES 
user_id=149084

Maybe priority should be higher?  Hopefully Ronald has 
time to look at this; I don't have access to a Mac.

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

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

From noreply at sourceforge.net  Sun Oct  8 22:53:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 13:53:13 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GWfe5-0003sA-Q3@sc8-sf-web1.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 17:19
Message generated for change (Comment added) made by daniboy22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

>Comment By: dani (daniboy22)
Date: 2006-10-08 20:53

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I no longer have problems with IDLE. I believe that probably
there still a bug on IDLE, but on the day that my problem
appeared, I did a lot of things and I am not fully able to
reproduce what happened. 

Anyway, with some luck, perhaps this error does not come up
again and/or will be solved indirectly later :-)

Tx,
Dani

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-07 17:52

Message:
Logged In: YES 
user_id=149084

I take it that the problem is gone now?  If it's real,
to have any hope of addressing it I need to be able
to reproduce it.  IDLE may be printing error messages
to stderr.  If you have more problems, start IDLE from
a command window so you can see the error messages:

cd to idlelib and run ..\..\python .\PyShell.py

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-04 23:58

Message:
Logged In: YES 
user_id=1604497

Well I think there is just a problem with my OS files or 
something anyway.  There are a couple other things (i.e. 
my "Recent Documents" folder) that do the same thing, even 
when I'm logged on as myself.  Thanks for the help 
though.  I need something to run and find/fix errors with 
my system, but not sure what the best program is.  If you 
know of any, could you let me know. :)  Thanks

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

Comment By: dani (daniboy22)
Date: 2006-10-04 14:38

Message:
Logged In: YES 
user_id=1604341

Usually I do not need to boot on safe mode to log in as
asministrator (I also work on a laptop)... The safe mode
reduces some of the Windows functionalities... Perhaps this
is the real reason for your problem.

Otherwise, I don't know what to tell you more... :-(

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-04 02:45

Message:
Logged In: YES 
user_id=1604497

The problem is that it is my laptop, so I am the 
administrator.  I booted up in safe mode so that I could 
log on as the administrator, and even then it wouldn't let 
me access any of my (username) documents, so I couldn't 
even get in to view that folder let alone change the 
name.  

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

Comment By: dani (daniboy22)
Date: 2006-10-03 13:33

Message:
Logged In: YES 
user_id=1604341

Well, I'm also not a specialist on the subject, but in my
case I don't have any problems in opening the folder. I just
had some problems to rename it (it didn't accepted a name
starting with a "."), but I resolve it (I rename it to "pinga").

Concerning your problem, my hint is that your account is not
an administrator one. Try to enter as an administrator and
make the necessary changes. Or else change the permissions
of your account to the "administrator" type (ask someone
that is already an administrator on that computer to do that).

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-02 22:15

Message:
Logged In: YES 
user_id=1604497

Thanks for that, I found it.  However, I guess I'm not as 
skilled with the computer as I thought...  It won't let me 
change the name, open the folder etc.  It says access is 
denied.  Know why it's doing that when I try to modify it?

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

Comment By: dani (daniboy22)
Date: 2006-10-02 14:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 14:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 16:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-01 02:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 21:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Mon Oct  9 01:37:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 16:37:14 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GWiCo-00049X-DI@sc8-sf-web2.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-08 18:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Flacy (markaflacy)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

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

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

From noreply at sourceforge.net  Mon Oct  9 01:54:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 16:54:35 -0700
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GWiTb-0001ZC-0i@sc8-sf-web6.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by scott_marks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Martin v. L?wis (loewis)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

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

>Comment By: applebucks (scott_marks)
Date: 2006-10-08 19:54

Message:
Logged In: YES 
user_id=120857

I didn't say Python is lame.  I use Python heavily,
apparently an uncommonly large subset of Python
functionality at that, and largely love it.  That's why the
failure of semantic transparency caused by something
apparently irrelevant (tracing, as opposed to some kind of
deliberate stack frame munging) is disturbing.  

Not to mention it makes my debugging tough. :)

More seriously, one of the users of the subsystem in which
this bug shows us just (on Friday) lost a few hours chasing
a real bug that should have been obvious but which was
masked by this error as manifest by a bdb-based debugger.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 12:54

Message:
Logged In: YES 
user_id=341410

I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:

..."just makes Python seem ... lame."

is insulting to those who have helped to develop Python over
the years.  In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).

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

Comment By: applebucks (scott_marks)
Date: 2006-10-03 22:32

Message:
Logged In: YES 
user_id=120857

"Cannot be fixed" sounds pretty final, and also a little
pessimistic.  From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does.  In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.

Not to mention that the workaround ("be sure to rename your
class factory function parameters so that they don't collide
with intended attributes of the created class") just makes
Python seem ... lame.

I hope for a more optimistic reply.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 02:49

Message:
Logged In: YES 
user_id=849994

I'm afraid that this cannot be fixed.

In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.

If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.

Martin, do you you have an additional opinion?

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

Comment By: applebucks (scott_marks)
Date: 2006-10-02 12:02

Message:
Logged In: YES 
user_id=120857

This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation.  The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.

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

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

From noreply at sourceforge.net  Mon Oct  9 03:11:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Oct 2006 18:11:40 -0700
Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without
	firewall problems
Message-ID: <E1GWjgC-0000C1-74@sc8-sf-web3.sourceforge.net>

Bugs item #1563630, was opened at 2006-09-22 13:19
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: dani (daniboy22)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE doesn't load - apparently without firewall problems

Initial Comment:
I've installed Python in Windows XP, SP2. When I ran
IDLE for the first times, it worked ok. But then I
redefined some shorcuts (history-previous,
history-next, and expand-word). This also worked ok,
but there was a problem I wasn't expecting: I changed
the history-previous to the short-cut <Ctrl> + P, and
when I use it for the first time it printed the content
of the window... I forgot that this shorcut was already
in use...

Then came the real problem. I went to redefine the
history-previous to another key set, but each time I
clicked for "oK" for the new keys, the shell wrote some
errors in red (-/+ 7/8 lines). I did that a few times
until I closed IDLE and tried to restarted it again.
Then it stop working.

The only thing it does now is to show the hourglass
logo in the mouse pointer for a few seconds and then it
does not do anything else.

I've installed Python in its default path
(C:\Python25), and tried to switch off all the
firewalls I remembered (Windows Firewall and disabled
McAfee Virus Scan). None of that worked. I tried
several times to reinstall the software, but that
didn't work either.

I even tried to install a previous version of Python
(v2.4.3), but it had exactly the same problem.

I haven't found any similar problem on the web.

Thanks,
Dani 

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-08 21:11

Message:
Logged In: YES 
user_id=149084

OK, thanks.  I'm closing this for now, but if you
manage to get something definitive, please reopen
the bug and post the error messages or describe a
sequence of events which would allow me to duplicate
it.



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

Comment By: dani (daniboy22)
Date: 2006-10-08 16:53

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I no longer have problems with IDLE. I believe that probably
there still a bug on IDLE, but on the day that my problem
appeared, I did a lot of things and I am not fully able to
reproduce what happened. 

Anyway, with some luck, perhaps this error does not come up
again and/or will be solved indirectly later :-)

Tx,
Dani

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-07 13:52

Message:
Logged In: YES 
user_id=149084

I take it that the problem is gone now?  If it's real,
to have any hope of addressing it I need to be able
to reproduce it.  IDLE may be printing error messages
to stderr.  If you have more problems, start IDLE from
a command window so you can see the error messages:

cd to idlelib and run ..\..\python .\PyShell.py

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-04 19:58

Message:
Logged In: YES 
user_id=1604497

Well I think there is just a problem with my OS files or 
something anyway.  There are a couple other things (i.e. 
my "Recent Documents" folder) that do the same thing, even 
when I'm logged on as myself.  Thanks for the help 
though.  I need something to run and find/fix errors with 
my system, but not sure what the best program is.  If you 
know of any, could you let me know. :)  Thanks

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

Comment By: dani (daniboy22)
Date: 2006-10-04 10:38

Message:
Logged In: YES 
user_id=1604341

Usually I do not need to boot on safe mode to log in as
asministrator (I also work on a laptop)... The safe mode
reduces some of the Windows functionalities... Perhaps this
is the real reason for your problem.

Otherwise, I don't know what to tell you more... :-(

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-03 22:45

Message:
Logged In: YES 
user_id=1604497

The problem is that it is my laptop, so I am the 
administrator.  I booted up in safe mode so that I could 
log on as the administrator, and even then it wouldn't let 
me access any of my (username) documents, so I couldn't 
even get in to view that folder let alone change the 
name.  

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

Comment By: dani (daniboy22)
Date: 2006-10-03 09:33

Message:
Logged In: YES 
user_id=1604341

Well, I'm also not a specialist on the subject, but in my
case I don't have any problems in opening the folder. I just
had some problems to rename it (it didn't accepted a name
starting with a "."), but I resolve it (I rename it to "pinga").

Concerning your problem, my hint is that your account is not
an administrator one. Try to enter as an administrator and
make the necessary changes. Or else change the permissions
of your account to the "administrator" type (ask someone
that is already an administrator on that computer to do that).

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-02 18:15

Message:
Logged In: YES 
user_id=1604497

Thanks for that, I found it.  However, I guess I'm not as 
skilled with the computer as I thought...  It won't let me 
change the name, open the folder etc.  It says access is 
denied.  Know why it's doing that when I try to modify it?

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

Comment By: dani (daniboy22)
Date: 2006-10-02 10:13

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: dani (daniboy22)
Date: 2006-10-02 10:12

Message:
Logged In: YES 
user_id=1604341

Dear kbk,

I tried your solution and everything seems to work fine. I
even recreated the problem (with the details that I still
remember), and everything is OK.

Many thanks!
Dani

P.S. For jordanramz: the .idlerc folder can be found in the
directory c:\Documents and Settings (assuming you installed
Windows on C:), and then selecting the folder corresponding
to your ID (say, "jordanramz").

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

Comment By: jordanramz (jordanramz)
Date: 2006-10-01 12:42

Message:
Logged In: YES 
user_id=1604497

What is the .idlerc customization folder?

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-09-30 22:38

Message:
Logged In: YES 
user_id=149084

Use the task manager to kill all Python processes.

Then set aside your .idlerc customization folder (i.e.
rename it).

Now IDLE should start.  Try to recreate the problem and
post any error messages you see here.

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

Comment By: jordanramz (jordanramz)
Date: 2006-09-22 17:15

Message:
Logged In: YES 
user_id=1604497

I am having the same problem.  When I first installed it, 
it ran okay.  Now everytime I go back to run it, the 
hourglass on my mouse shows up for a few seconds and then 
nothing.  At first I had v2.4.3 because that's what we're 
using in my class, but I tried v2.5(final) thinking it 
would help, but it didn't, so I reinstalled v2.4.3.   I 
noticed that with my task manager in view, when I click 
the IDLE program my processes jump up one number for a few 
seconds also, then goes back.  So apparently it's running 
but then ending before it loads up?  I tried messing with 
my firewall and stuff also, with no success, so I'm in the 
same boat as you.

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

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

From noreply at sourceforge.net  Mon Oct  9 15:59:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 06:59:05 -0700
Subject: [ python-Bugs-1508864 ] threading.Timer/timeouts break on change of
	win32 local time
Message-ID: <E1GWver-00039P-1Y@sc8-sf-web4.sourceforge.net>

Bugs item #1508864, was opened at 2006-06-19 19:53
Message generated for change (Comment added) made by jtate
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Warren (qopit)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Timer/timeouts break on change of win32 local time

Initial Comment:
THE ISSUE...
---
threading.py imports time.time as _time.

On win32 systems, time.time() periodically reads the
system time to figure out when to fire an Event.

System time can change while waiting for an Event!

eg:  If the system time is changed while a
threading.Timer is pending, the execution time is
affected by the time change.  eg: set a pending Timer
and then change the clock back an hour - this causes
your Timer to fire an hour later.  This is clearly not
desirable.


A FIX...
---
A fix for this is to use time.clock() on win32 systems
instead.  Once I found the problem, I currently just
fix it by overriding threading._time to be time.clock.
 Right now I do this in every file that uses
threading.Timer.


COMMENTS...
---
The penalty for this is that there will be a rollover
problem eventaully... when the 64-bit performance
counter rolls over in 30+ years of continuous pc
operation.  I'd much rather have this near impossible
event than the very likely system time change.

This is a general problem I find with the time module
and I often have to switch between time() and clock()
dependent on operating system, but I only work with
win32 and Linux.  The issue is that if you want a high
resolution and extended rollover counter, it is a
different call on each system.



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

Comment By: Joseph Tate (jtate)
Date: 2006-10-09 13:59

Message:
Logged In: YES 
user_id=55276

This is also currently a problem under Linux when the clock
is set back.

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

Comment By: Russell Warren (qopit)
Date: 2006-06-27 20:01

Message:
Logged In: YES 
user_id=1542586

No - just stating that clock() is definitely a better
solution for win32.

As you say, any system should just use a time-indpendent
uptime counter that is as high resolution as possible.  I
don't know how to get this on linux, but I do seem to recall
that, on linux, time() is higher resolution than clock() for
some reason.

If linux has no performance counter equivalent (isn't it a
hardware thing anyway?) I have no clue which is worse... low
resolution, or local time change issues.  The first is
limiting all the time, the second results in wacky and
sporadic errors that people might not expect.


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-06-27 15:04

Message:
Logged In: YES 
user_id=764593

Logically, these calls should always use clock, since they 
don't care about the actual time; they only want a baseline 
for computing elapsed time.

Are you saying that they should still use clock-time on 
linux anyway, because of resolution issues?


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

Comment By: Russell Warren (qopit)
Date: 2006-06-26 21:59

Message:
Logged In: YES 
user_id=1542586

This is an issue for anything that uses threading.py's _time
function.

This includes _Condition.wait(), which screws up both
Conditions and Events, which then screw up (for example) the
core Queue.Queue timeout implementation.

threading.Thread.join also uses the _time call, so it could
also get screwed by changes to the local time on Win32.



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

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

From noreply at sourceforge.net  Mon Oct  9 18:18:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 09:18:03 -0700
Subject: [ python-Bugs-1573854 ] sqlite3 documentation on rowcount is
	contradictory
Message-ID: <E1GWxpL-0004eu-Tf@sc8-sf-web5.sourceforge.net>

Bugs item #1573854, was opened at 2006-10-10 01:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573854&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Seo Sanghyeon (sanxiyn)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite3 documentation on rowcount is contradictory

Initial Comment:
http://docs.python.org/lib/sqlite3-Cursor-Objects.html
says:

----
For SELECT statements, rowcount is always None because
we cannot determine the number of rows a query produced
until all rows were fetched.

As required by the Python DB API Spec, the rowcount
attribute "is -1 in case no executeXX() has been
performed on the cursor or the rowcount of the last
operation is not determinable by the interface".
----

Clearly, both can't be true. My experiment showed that
rowcount is set to -1, not None. I suggest rewriting
this to something like:

----
As required by the Python DB API Spec, the rowcount
attribute "is -1 in case no executeXX() has been
performed on the cursor or the rowcount of the last
operation is not determinable by the interface".

This includes SELECT statements, because we cannot
determine the number of rows a query produced until all
rows are fetched.
----

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

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

From noreply at sourceforge.net  Mon Oct  9 19:13:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 10:13:46 -0700
Subject: [ python-Bugs-1545341 ] setup() keyword have to be list (doesn't work
	with tuple)
Message-ID: <E1GWyhG-0004ug-2t@sc8-sf-web1.sourceforge.net>

Bugs item #1545341, was opened at 2006-08-23 10:49
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: STINNER Victor (haypo)
Assigned to: A.M. Kuchling (akuchling)
Summary: setup() keyword have to be list (doesn't work with tuple)

Initial Comment:
Code:
====================== 8< =====================
from distutils.core import setup
setup(..., classifier=('Intended Audience :: 
Developers', 'Environment :: Console :: 
Curses'), ...)
====================== 8< =====================

The query: "./setup.py register" will create HTML 
request:
----------------GHSKFJDLGDS7543FJKLFHRE75642756743254
Content-Disposition: form-data; name="classifiers"

('Intended Audience :: Developers', 'Environment :: 
Console :: Curses')

Instead of a multipart part for each value.

====

The bug is stupid, see attached patch.

Haypo

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-09 13:13

Message:
Logged In: YES 
user_id=11375

Committed to 2.5-main in rev. 52243.

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

Comment By: STINNER Victor (haypo)
Date: 2006-10-06 12:12

Message:
Logged In: YES 
user_id=365388

Ok nice ;-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-06 09:20

Message:
Logged In: YES 
user_id=11375

Fix applied to trunk in rev. 52211; I'll backport to 2.5 and
2.4.  

The Distutils code is intended to be compatible with Python
2.1, so I've reworked the change to keep using type()
instead of isinstance().  Patch attached.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 19:16:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 10:16:08 -0700
Subject: [ python-Bugs-1545341 ] setup() keyword have to be list (doesn't work
	with tuple)
Message-ID: <E1GWyjY-0006Gi-Qc@sc8-sf-web4.sourceforge.net>

Bugs item #1545341, was opened at 2006-08-23 10:49
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: STINNER Victor (haypo)
Assigned to: A.M. Kuchling (akuchling)
Summary: setup() keyword have to be list (doesn't work with tuple)

Initial Comment:
Code:
====================== 8< =====================
from distutils.core import setup
setup(..., classifier=('Intended Audience :: 
Developers', 'Environment :: Console :: 
Curses'), ...)
====================== 8< =====================

The query: "./setup.py register" will create HTML 
request:
----------------GHSKFJDLGDS7543FJKLFHRE75642756743254
Content-Disposition: form-data; name="classifiers"

('Intended Audience :: Developers', 'Environment :: 
Console :: Curses')

Instead of a multipart part for each value.

====

The bug is stupid, see attached patch.

Haypo

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-09 13:16

Message:
Logged In: YES 
user_id=11375

Committed to 2.4-maint in rev. 52244.

Closing.  Thanks for the bug report!


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-09 13:13

Message:
Logged In: YES 
user_id=11375

Committed to 2.5-main in rev. 52243.

----------------------------------------------------------------------

Comment By: STINNER Victor (haypo)
Date: 2006-10-06 12:12

Message:
Logged In: YES 
user_id=365388

Ok nice ;-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-06 09:20

Message:
Logged In: YES 
user_id=11375

Fix applied to trunk in rev. 52211; I'll backport to 2.5 and
2.4.  

The Distutils code is intended to be compatible with Python
2.1, so I've reworked the change to keep using type()
instead of isinstance().  Patch attached.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 19:41:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 10:41:38 -0700
Subject: [ python-Bugs-1544102 ] ctypes unit test fails (test_macholib.py)
	under MacOS 10.4.7
Message-ID: <E1GWz8E-0004Rk-JJ@sc8-sf-web5.sourceforge.net>

Bugs item #1544102, was opened at 2006-08-21 12:59
Message generated for change (Comment added) made by reedobrien
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: M. J. Fromberger (njdibfm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: ctypes unit test fails (test_macholib.py) under MacOS 10.4.7

Initial Comment:
While building 2.5rc1 under MacOS 10.4.7, one of the ctypes module 
unit tests fails:

% ./python.exe -V
Python 2.5c1 (r25c1:51426, Aug 21 2006, 11:30:05) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin

% uname -a
Darwin chrysophylax 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 
15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power 
Macintosh powerpc

Output report:
===========================================
===========================
FAIL: test_find (ctypes.test.test_macholib.MachOTest)
------------------------------------------------------------
----------
Traceback (most recent call last):
  File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 
55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError

------------------------------------------------------------
----------
Ran 287 tests in 0.933s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_ctypes.py", line 12, in <module>
    test_main()
  File "Lib/test/test_ctypes.py", line 9, in test_main
    run_suite(unittest.TestSuite(suites))
  File "/usr/local/src/python2.5/Lib/test/test_support.py", line 426, in 
run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 
55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




----------------------------------------------------------------------

Comment By: reedobrien (reedobrien)
Date: 2006-10-09 12:41

Message:
Logged In: YES 
user_id=995094

As of 2006-10-9 I still get this error compiling on 
OS X 10.4.8
Python 2.5 (r25:51908, Oct  9 2006, 11:15:40) 

test_ctypes
test test_ctypes failed -- Traceback (most recent call last):
  File
"/Users/robrien/src/Python-2.5/Lib/ctypes/test/test_macholib.py",
line 55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 13:10

Message:
Logged In: YES 
user_id=580910

This is a rather annoying, but shallow, failure. Dlopen on osx is quite touchy 
about the flags you use to open a shared library.

Anyway, all tests pass on the trunk and 2.5 branch, I guess this was fixed before 
2.5 was released. I have had an e-mail exchange with Thomas Heller about a 
simular issue and he has checked in a fixed for that before 2.5 was released.\

I'm therefore closing this issue.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2006-08-21 16:10

Message:
Logged In: YES 
user_id=45365

Ronald: just guesing that you know more about this than I do...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 19:41:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 10:41:59 -0700
Subject: [ python-Bugs-1544102 ] ctypes unit test fails (test_macholib.py)
	under MacOS 10.4.7
Message-ID: <E1GWz8Z-0004S5-CW@sc8-sf-web5.sourceforge.net>

Bugs item #1544102, was opened at 2006-08-21 12:59
Message generated for change (Comment added) made by reedobrien
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: M. J. Fromberger (njdibfm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: ctypes unit test fails (test_macholib.py) under MacOS 10.4.7

Initial Comment:
While building 2.5rc1 under MacOS 10.4.7, one of the ctypes module 
unit tests fails:

% ./python.exe -V
Python 2.5c1 (r25c1:51426, Aug 21 2006, 11:30:05) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin

% uname -a
Darwin chrysophylax 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 
15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power 
Macintosh powerpc

Output report:
===========================================
===========================
FAIL: test_find (ctypes.test.test_macholib.MachOTest)
------------------------------------------------------------
----------
Traceback (most recent call last):
  File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 
55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError

------------------------------------------------------------
----------
Ran 287 tests in 0.933s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_ctypes.py", line 12, in <module>
    test_main()
  File "Lib/test/test_ctypes.py", line 9, in test_main
    run_suite(unittest.TestSuite(suites))
  File "/usr/local/src/python2.5/Lib/test/test_support.py", line 426, in 
run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 
55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




----------------------------------------------------------------------

Comment By: reedobrien (reedobrien)
Date: 2006-10-09 12:41

Message:
Logged In: YES 
user_id=995094

As of 2006-10-9 I still get this error compiling on 
OS X 10.4.8
Python 2.5 (r25:51908, Oct  9 2006, 11:15:40) 

test_ctypes
test test_ctypes failed -- Traceback (most recent call last):
  File
"/Users/robrien/src/Python-2.5/Lib/ctypes/test/test_macholib.py",
line 55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




----------------------------------------------------------------------

Comment By: reedobrien (reedobrien)
Date: 2006-10-09 12:41

Message:
Logged In: YES 
user_id=995094

As of 2006-10-9 I still get this error compiling on 
OS X 10.4.8
Python 2.5 (r25:51908, Oct  9 2006, 11:15:40) 

test_ctypes
test test_ctypes failed -- Traceback (most recent call last):
  File
"/Users/robrien/src/Python-2.5/Lib/ctypes/test/test_macholib.py",
line 55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 13:10

Message:
Logged In: YES 
user_id=580910

This is a rather annoying, but shallow, failure. Dlopen on osx is quite touchy 
about the flags you use to open a shared library.

Anyway, all tests pass on the trunk and 2.5 branch, I guess this was fixed before 
2.5 was released. I have had an e-mail exchange with Thomas Heller about a 
simular issue and he has checked in a fixed for that before 2.5 was released.\

I'm therefore closing this issue.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2006-08-21 16:10

Message:
Logged In: YES 
user_id=45365

Ronald: just guesing that you know more about this than I do...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 20:27:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 11:27:14 -0700
Subject: [ python-Bugs-1573928 ] if(status = ERROR_MORE_DATA)
Message-ID: <E1GWzqM-0000S1-K8@sc8-sf-web6.sourceforge.net>

Bugs item #1573928, was opened at 2006-10-09 18:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573928&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Helmut Grohne (gnarfk)
Assigned to: Nobody/Anonymous (nobody)
Summary: if(status = ERROR_MORE_DATA)

Initial Comment:
Go to PC/_msi.c around line 498 and search out for a
line like:
if(status = ERROR_MORE_DATA) {
This is a bug. It leaks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573928&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 20:34:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 11:34:31 -0700
Subject: [ python-Bugs-1573931 ] WSGI, cgi.FieldStorage incompatibility
Message-ID: <E1GWzxP-0005OA-2g@sc8-sf-web2.sourceforge.net>

Bugs item #1573931, was opened at 2006-10-09 18:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573931&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Kerrin (mkerrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: WSGI, cgi.FieldStorage incompatibility

Initial Comment:
The WSGI specification says in the section on "Input
and Error Streams":

  The optional "size" argument to readline() is not
supported, as it may be complex for server authors to
implement, and is not often used in practice.

  But the current implementation of cgi.FieldStorage in
the 2.4.4 branch and on Python 2.5 does call readline
with the size argument. It has started to do this in
response to the Python bug #1112549 - cgi.FieldStorage
memory usage can spike in line-oriented ops. See 
http://sourceforge.net/tracker/index.php?func=detail&aid=1112549&group_id=5470&atid=105470
 
  I am not 100% sure wheather this is a bug in the WSGI
application or cgi.FieldStorage class,

  Originally I thought it was cgi.FieldStorage that
needs to be changed, and hence tried to fix it by
wrapping the input stream so that the readline method
always uses the read method on the input stream (so has
to not to break the above mentioned bug). While this
seems to work for me it introduces a level of
complexity in the cgi.py file, and possible some other
bugs, that makes me think that adding the size argument
for readline into the WSGI specification isn't such bad
idea after all.

  I have attached my patch against cgi.FieldStorage if
any one thinks this is the best way of fixing this issue.

  This is an issue for Zope3 has Zope3 doesn't support
the size argument and neither does Twisted from which
Zope gets its input stream.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573931&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 20:57:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 11:57:31 -0700
Subject: [ python-Bugs-1573928 ] if(status = ERROR_MORE_DATA)
Message-ID: <E1GX0Jf-0002vI-Jq@sc8-sf-web3.sourceforge.net>

Bugs item #1573928, was opened at 2006-10-09 18:27
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573928&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Helmut Grohne (gnarfk)
Assigned to: Nobody/Anonymous (nobody)
Summary: if(status = ERROR_MORE_DATA)

Initial Comment:
Go to PC/_msi.c around line 498 and search out for a
line like:
if(status = ERROR_MORE_DATA) {
This is a bug. It leaks.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-09 18:57

Message:
Logged In: YES 
user_id=849994

Duplicate of #1572724. Thanks for reporting though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573928&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 22:16:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 13:16:36 -0700
Subject: [ python-Bugs-1517495 ] memory leak threading or socketserver module
Message-ID: <E1GX1YC-0002rc-PK@sc8-sf-web5.sourceforge.net>

Bugs item #1517495, was opened at 2006-07-05 08:47
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517495&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ids van der Molen (idsvandermolen)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak threading or socketserver module

Initial Comment:
a long running threaded server is not releasing memory,
but will keep lots of it for appearantly no reason,
causing memory exhaustion. This problem occurs with
python 2.4.2 (Suse 10.1 version) and 2.4.3 (customer
compiled on RedHat 8.0 and Suse 10.0). The problem does
_not_ occur with python 2.2.1 (RedHat 8.0 version).

The problem can be reproduced by running multiple
concurrent clients sending lots of data (25M)to a
threaded server. It looks like the garbage collector
does not always release memory used in threads, because
the ForkinMixIn and normal variants of the TCPServer do
not  show this problem (but it may be masked because of
seperate process memory space issues).
Testing:
To reproduce the probme run server code and create
multiple client connections by running multiple
instances of the client code, using the test run shell
script. The server will peak at about 550M, and remain
at lower but with every test run increasing amount of
memory (and therefore eventually using all available
memory).

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-09 16:16

Message:
Logged In: YES 
user_id=11375

Confirmed; the sample server does leak on Linux.

I couldn't figure out why, though.  I doubt it's an
interaction between threads and GC, unless there's a
refcounting bug in the threading module.  gc.garbage doesn't
contain anything, so it doesn't look like an __del__ cycle.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517495&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 22:29:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 13:29:44 -0700
Subject: [ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability
Message-ID: <E1GX1ku-0008Jn-OY@sc8-sf-web2.sourceforge.net>

Bugs item #1456209, was opened at 2006-03-22 10:47
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: dictobject.c:dictresize() vulnerability

Initial Comment:
We thought we squashed the last of the
modify-the-dict-from-a-custom-eq kind of bugs long ago. 
Too bad.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-10-09 16:29

Message:
Logged In: YES 
user_id=31435

I backported the parts of rev 46589 relevant to this bug to
the 2.4 maint branch, as rev 52256, for Python 2.4.4.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-06-01 11:54

Message:
Logged In: YES 
user_id=31435

Patch 1497053 was checked in as revision 46589 of the trunk
for Python 2.5, so closing this.  I doubt it's worth the
effort to backport to 2.4.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-06-01 09:20

Message:
Logged In: YES 
user_id=4771

Fixed by patch #1497053.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-03-22 11:32

Message:
Logged In: YES 
user_id=4771

The cause of the bug is that if oldtable == mp->ma_smalltable
then pure Python code can mangle with mp->ma_smalltable while
it is being walked on.  A simple fix would be to always make
a copy of the oldtable if it is mp->ma_smalltable (not only
if oldtable == newtable).

Attached a more efficient fix, which should also make dict
resizing somehow faster.  It requires yet another version
of the lookup algorithm, though.  It's a very simple version
that assumes that all items are different and the dict
contains no dummy entries.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470

From noreply at sourceforge.net  Mon Oct  9 22:45:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 13:45:40 -0700
Subject: [ python-Bugs-1565150 ] os.stat() subsecond file mode time is
	incorrect on Windows
Message-ID: <E1GX20K-0005mw-72@sc8-sf-web6.sourceforge.net>

Bugs item #1565150, was opened at 2006-09-25 17:08
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Glassford (glassfordm)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat() subsecond file mode time is incorrect on Windows

Initial Comment:
Either the new ability of os.stat() to report subsecond
file modification times, or the os.utime() function,
appears to have a bug on Windows. The following script
illustrates. The problem is that the decimal part of
the modification time reported by os.stat() is always
equal to the decimal part of what was passed to
os.utime() divided by ten (and rounded).

###Begin Script
import os

strPath = "c:/test.xxx"

#Create the file
f = open(strPath, 'w')
f.close()

#Set the file mod time
t1 = 1159195039.2
os.utime(strPath, (t1, t1))

#Get the file mod time
t2 = os.stat(strPath).st_mtime

print t1, t2

###Sample output
1159195039.2 1159195039.02

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-09 22:45

Message:
Logged In: YES 
user_id=21627

Thanks for the report. This is now fixed in r52257 and r52258.

----------------------------------------------------------------------

Comment By: Mike Glassford (glassfordm)
Date: 2006-09-25 17:10

Message:
Logged In: YES 
user_id=963931

Sorry, although it can be inferred from the report, I should
mention that this is with Python 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 04:20:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 9 Oct 2006 19:20:03 -0700
Subject: [ python-Bugs-1564039 ] 2.6 changes stomp on  2.5 docs
Message-ID: <200610100220.k9A2K3Gq016744@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1564039, was opened at 2006-09-23 05:54
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.6
>Status: Closed
Resolution: None
Priority: 5
Submitted By: ggpauly (ggpauly)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.6 changes stomp on  2.5 docs

Initial Comment:
Several links of the 2.5 changes index go to 2.6 changes

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-09 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-09-24 10:18

Message:
Logged In: YES 
user_id=21627

Several of these have been fixed a few days ago. Can you
spot any more? If so, please provide exact URL.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 04:55:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 19:55:53 -0700
Subject: [ python-Bugs-1574217 ] isinstance swallows exceptions
Message-ID: <E1GX7mb-0007Zh-3k@sc8-sf-web3.sourceforge.net>

Bugs item #1574217, was opened at 2006-10-09 21:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Harring (ferringb)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance swallows exceptions

Initial Comment:
Attached is a simple example; yes, a bit contrived, but
it's exactly what bit me in the ass for a week or two :)

nestled within abstract.c's recursive_isinstance, is
this lil nugget-

icls = PyObject_GetAttr(inst, __class__);
if (icls == NULL) {
  PyErr_Clear();
  retval = 0;
}
else {

No surrouding comments to indicate *why* it's
swallowing exceptions, but best explanation I've heard
was that it was attempting to swallow just
AttributeError... which would make sense.

So the question is, whats the purpose of it swallowing
exceptions there?  Bad form of AttributeError catching,
or some unstated reason?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 04:56:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 19:56:31 -0700
Subject: [ python-Bugs-1574217 ] isinstance swallows exceptions
Message-ID: <E1GX7nD-000826-3h@sc8-sf-web5.sourceforge.net>

Bugs item #1574217, was opened at 2006-10-09 21:55
Message generated for change (Comment added) made by ferringb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Harring (ferringb)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance swallows exceptions

Initial Comment:
Attached is a simple example; yes, a bit contrived, but
it's exactly what bit me in the ass for a week or two :)

nestled within abstract.c's recursive_isinstance, is
this lil nugget-

icls = PyObject_GetAttr(inst, __class__);
if (icls == NULL) {
  PyErr_Clear();
  retval = 0;
}
else {

No surrouding comments to indicate *why* it's
swallowing exceptions, but best explanation I've heard
was that it was attempting to swallow just
AttributeError... which would make sense.

So the question is, whats the purpose of it swallowing
exceptions there?  Bad form of AttributeError catching,
or some unstated reason?

----------------------------------------------------------------------

>Comment By: Brian Harring (ferringb)
Date: 2006-10-09 21:56

Message:
Logged In: YES 
user_id=874085

addition note; this is both 2.5 and 2.4, probably stretches
bit further back also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 08:14:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Oct 2006 23:14:03 -0700
Subject: [ python-Bugs-1544102 ] ctypes unit test fails (test_macholib.py)
	under MacOS 10.4.7
Message-ID: <E1GXAsN-00027p-9s@sc8-sf-web6.sourceforge.net>

Bugs item #1544102, was opened at 2006-08-21 19:59
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
>Status: Open
>Resolution: None
Priority: 5
Submitted By: M. J. Fromberger (njdibfm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: ctypes unit test fails (test_macholib.py) under MacOS 10.4.7

Initial Comment:
While building 2.5rc1 under MacOS 10.4.7, one of the ctypes module 
unit tests fails:

% ./python.exe -V
Python 2.5c1 (r25c1:51426, Aug 21 2006, 11:30:05) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin

% uname -a
Darwin chrysophylax 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 
15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power 
Macintosh powerpc

Output report:
===========================================
===========================
FAIL: test_find (ctypes.test.test_macholib.MachOTest)
------------------------------------------------------------
----------
Traceback (most recent call last):
  File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 
55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError

------------------------------------------------------------
----------
Ran 287 tests in 0.933s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_ctypes.py", line 12, in <module>
    test_main()
  File "Lib/test/test_ctypes.py", line 9, in test_main
    run_suite(unittest.TestSuite(suites))
  File "/usr/local/src/python2.5/Lib/test/test_support.py", line 426, in 
run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 
55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




----------------------------------------------------------------------

Comment By: reedobrien (reedobrien)
Date: 2006-10-09 19:41

Message:
Logged In: YES 
user_id=995094

As of 2006-10-9 I still get this error compiling on 
OS X 10.4.8
Python 2.5 (r25:51908, Oct  9 2006, 11:15:40) 

test_ctypes
test test_ctypes failed -- Traceback (most recent call last):
  File
"/Users/robrien/src/Python-2.5/Lib/ctypes/test/test_macholib.py",
line 55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




----------------------------------------------------------------------

Comment By: reedobrien (reedobrien)
Date: 2006-10-09 19:41

Message:
Logged In: YES 
user_id=995094

As of 2006-10-9 I still get this error compiling on 
OS X 10.4.8
Python 2.5 (r25:51908, Oct  9 2006, 11:15:40) 

test_ctypes
test test_ctypes failed -- Traceback (most recent call last):
  File
"/Users/robrien/src/Python-2.5/Lib/ctypes/test/test_macholib.py",
line 55, in test_find
    self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError




----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 20:10

Message:
Logged In: YES 
user_id=580910

This is a rather annoying, but shallow, failure. Dlopen on osx is quite touchy 
about the flags you use to open a shared library.

Anyway, all tests pass on the trunk and 2.5 branch, I guess this was fixed before 
2.5 was released. I have had an e-mail exchange with Thomas Heller about a 
simular issue and he has checked in a fixed for that before 2.5 was released.\

I'm therefore closing this issue.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2006-08-21 23:10

Message:
Logged In: YES 
user_id=45365

Ronald: just guesing that you know more about this than I do...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 09:45:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Oct 2006 00:45:09 -0700
Subject: [ python-Bugs-1574310 ] os.popen with os.close gives error message
Message-ID: <E1GXCIX-0006ZD-00@sc8-sf-web2.sourceforge.net>

Bugs item #1574310, was opened at 2006-10-10 09:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574310&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: dtrosset (dtrosset)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen with os.close gives error message

Initial Comment:
Given the following code:

  import os
  child_stdin = os.popen("cat -", "w")
  old_stdout = os.dup(1)
  os.close(child_stdin.fileno())
  print "foo"
  os.dup2(old_stdout, 1)
  os.close(old_stdout)


I got these different results depending on the version
of python I am using. 


$ python2.4 -V 
Python 2.4.4c0
$ python2.4 test.py 
foo
close failed: [Errno 9] Bad file descriptor

$ python2.3 -V 
Python 2.3.5
$ python2.3 test/new/test.py 
foo

My .02$ guess is that underlying file descriptor of
child_stdin being closed, when trying to delete this
object, it tries again to close it.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574310&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 12:04:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Oct 2006 03:04:56 -0700
Subject: [ python-Bugs-1573854 ] sqlite3 documentation on rowcount is
	contradictory
Message-ID: <E1GXETo-0006gR-PE@sc8-sf-web4.sourceforge.net>

Bugs item #1573854, was opened at 2006-10-09 18:18
Message generated for change (Comment added) made by ghaering
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573854&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
>Group: Python 2.5
Status: Open
Resolution: None
>Priority: 3
Submitted By: Seo Sanghyeon (sanxiyn)
>Assigned to: Gerhard H?ring (ghaering)
Summary: sqlite3 documentation on rowcount is contradictory

Initial Comment:
http://docs.python.org/lib/sqlite3-Cursor-Objects.html
says:

----
For SELECT statements, rowcount is always None because
we cannot determine the number of rows a query produced
until all rows were fetched.

As required by the Python DB API Spec, the rowcount
attribute "is -1 in case no executeXX() has been
performed on the cursor or the rowcount of the last
operation is not determinable by the interface".
----

Clearly, both can't be true. My experiment showed that
rowcount is set to -1, not None. I suggest rewriting
this to something like:

----
As required by the Python DB API Spec, the rowcount
attribute "is -1 in case no executeXX() has been
performed on the cursor or the rowcount of the last
operation is not determinable by the interface".

This includes SELECT statements, because we cannot
determine the number of rows a query produced until all
rows are fetched.
----

----------------------------------------------------------------------

>Comment By: Gerhard H?ring (ghaering)
Date: 2006-10-10 12:04

Message:
Logged In: YES 
user_id=163326

Thanks for the bug report. I will perform the suggested 
change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573854&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 17:11:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Oct 2006 08:11:36 -0700
Subject: [ python-Bugs-1574584 ] Error with callback function and as_parameter
	with NumPy ndp
Message-ID: <E1GXJGa-00040s-2z@sc8-sf-web5.sourceforge.net>

Bugs item #1574584, was opened at 2006-10-10 17:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with callback function and as_parameter with NumPy ndp

Initial Comment:
I posted to the ctypes-users mailing list about this
problem, but SourceForge failed to make that post and
its replies available in the ctypes-users archive, so
I'm repeating it here.

I'm using NumPy with ctypes. I would like to create a
callback function that calls into Python, allocates a
NumPy array and returns a suitable pointer to the C code.

NumPy has a function called ndpointer that allows one
to specify some details of NumPy arrays when dealing
with argtypes. This function also takes care of
extracting the array's data pointer.

Details here:

http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/ctypeslib.py
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/core/_internal.py

Creating a callback function as follows works:

stuff = []
import numpy
def allocator1():
    x = numpy.array([...], dtype='f4')
    stuff.append(x)
    return x.ctypes.data_as(POINTER(c_float))
CFUNCTYPE(POINTER(c_float))(allocator1)

However, if one adds ndpointer to the mix, an error occurs:

stuff = []
import numpy
def allocator2():
    x = numpy.array([...], dtype='f4')
    stuff.append(x)
    return x
CFUNCTYPE(numpy.ctypeslib.ndpointer('f4'))(allocator2)

The error is:

SystemError: NULL result without error in PyObject_Call

Thomas Heller has a patch for this issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 17:16:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Oct 2006 08:16:14 -0700
Subject: [ python-Bugs-1574588 ] ctypes: Pointer-to-pointer unchanged in
	callback
Message-ID: <E1GXJL4-0005wE-TV@sc8-sf-web1.sourceforge.net>

Bugs item #1574588, was opened at 2006-10-10 17:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574588&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes: Pointer-to-pointer unchanged in callback

Initial Comment:
This problem is from another post I made to
ctypes-users that didn't show up in the ctypes-users
archive.

C function:

extern CALLBACK_API void foo(void(*callback)(void**)) {
    void* p = 123;
    printf("foo calling callback\n");
    callback(&p);
    printf("callback returned in foo\n");
    printf("p = 0x%p\n", p);
}

I figured that while I try to find out why returning
c_void_p from a callback gives an error, I might as
well return the address via a pointer to a pointer.

In the Python code I have:

import sys
print sys.version
from ctypes import *
x_t = c_int*10
x = x_t()
def callback(ptr):
    print x
    print ptr
    ptr.contents = cast(addressof(x), c_void_p)
    print ptr.contents
#lib = cdll['libcallback.so']
lib = cdll['callback.dll']
lib.foo.argtypes = [CFUNCTYPE(None, POINTER(c_void_p))]
lib.foo(lib.foo.argtypes[0](callback))

Output when I running this script under Python 2.4.3
with ctypes 1.0.0 (I get identical results with Python
2.5 and ctypes 1.0.1):

2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
foo calling callback
<__main__.c_long_Array_10 object at 0x00963E90>
<ctypes.LP_c_void_p object at 0x00963EE0>
c_void_p(10048496)
callback returned in foo
p = 0x0000007B

For some reason, the value I assigned to ptr.contents
isn't present when we return to the C code.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574588&group_id=5470

From noreply at sourceforge.net  Tue Oct 10 17:18:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Oct 2006 08:18:17 -0700
Subject: [ python-Bugs-1574593 ] ctypes: Returning c_void_p from callback
	doesn't work
Message-ID: <E1GXJN3-0004Sr-A0@sc8-sf-web3.sourceforge.net>

Bugs item #1574593, was opened at 2006-10-10 17:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574593&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes: Returning c_void_p from callback doesn't work

Initial Comment:
C code:

extern CALLBACK_API void* foo(void*(*callback)()) {
    printf("foo calling callback\n");
    callback();
    printf("callback returned in foo\n");
}

callback.py contains:

import sys
print sys.version
from ctypes import *
def callback(*args):
    return c_void_p()
#lib = cdll['libcallback.so']
lib = cdll['callback.dll']
lib.foo.argtypes = [CFUNCTYPE(c_void_p)]
lib.foo(lib.foo.argtypes[0](callback))

With Python 2.4.3 and ctypes 1.0.0 + Thomas Heller's
patch for another issue (which doesn't seem to affect
this situation, but anyway) I get the following error:

2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
foo calling callback
Traceback (most recent call last):
  File "source/callbacks.c", line 216, in 'converting
callback result'
TypeError: cannot be converted to pointer
Exception  in None ignored
callback returned in foo

With Python 2.5 and ctypes 1.0.1 I get:

2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)]
foo calling callback
Traceback (most recent call last):
  File "\loewis\25\python\Modules\_ctypes\callbacks.c",
line 216, in
'converting callback result'
TypeError: cannot be converted to pointer
Exception  in <function callback at 0x009C3CF0> ignored
callback returned in foo

Returning a Python integer from callback() doesn't
cause an error to be raised.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574593&group_id=5470

From noreply at sourceforge.net  Wed Oct 11 03:46:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Oct 2006 18:46:25 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1GXTAv-0001Jd-V9@sc8-sf-web2.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 23:51
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-11 11:46

Message:
Logged In: YES 
user_id=29957

This is applied and will be in 2.3.3c1

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-12 03:21

Message:
Logged In: YES 
user_id=29957

Re-opening to remind myself to apply this to release24-maint
for the eventual 2.4.4 release.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-11 13:52

Message:
Logged In: YES 
user_id=29957

Applied. Patch will be in 2.5b2 (to be released shortly).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-11 12:53

Message:
Logged In: YES 
user_id=33168

Anthony checked this in to 2.5 as 50567.  I will backport at
least part of it later.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-10 15:47

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 09:57

Message:
Logged In: YES 
user_id=33168

I meant I don't think we *care* in this case (not can).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 09:55

Message:
Logged In: YES 
user_id=33168

I think you're right Martin.  Looking at what it means to
have a broken poll, I don't think we can in this instance. 
So I removed all refs to HAVE_BROKEN_POLL.  What do you
think of the new version?  

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-08 01:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-07 16:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 20:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-06-08 15:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-06-05 06:14

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-06-01 08:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-01 07:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-01 04:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-30 00:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-30 00:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-30 00:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 23:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Wed Oct 11 04:40:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Oct 2006 19:40:05 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1GXU0r-000188-4S@sc8-sf-web6.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 06:51
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-10 19:40

Message:
Logged In: YES 
user_id=33168

I assume 2.3.3c1 means 2.4.4c1.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-10 18:46

Message:
Logged In: YES 
user_id=29957

This is applied and will be in 2.3.3c1

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-11 10:21

Message:
Logged In: YES 
user_id=29957

Re-opening to remind myself to apply this to release24-maint
for the eventual 2.4.4 release.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-10 20:52

Message:
Logged In: YES 
user_id=29957

Applied. Patch will be in 2.5b2 (to be released shortly).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 19:53

Message:
Logged In: YES 
user_id=33168

Anthony checked this in to 2.5 as 50567.  I will backport at
least part of it later.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-09 22:47

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 16:57

Message:
Logged In: YES 
user_id=33168

I meant I don't think we *care* in this case (not can).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 16:55

Message:
Logged In: YES 
user_id=33168

I think you're right Martin.  Looking at what it means to
have a broken poll, I don't think we can in this instance. 
So I removed all refs to HAVE_BROKEN_POLL.  What do you
think of the new version?  

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-07-07 08:50

Message:
Logged In: YES 
user_id=21627

The __APPLE__ stuff looks wrong in file 184131. You would
have to use selectmodule.c:select_have_broken_poll at
run-time to be sure you can use poll(2) on OS X (you can use
it on 10.4, but can't on 10.3, IIRC).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-06 23:10

Message:
Logged In: YES 
user_id=33168

I've added a more complete patch (against 2.5, hopefully
applies to 2.4 too).  It cleans up some things and adds
support for SSL sockets too.  Can people please review/test
this?  I manually tested this with regular sockets and it
seemed to work.  All the tests pass, but this is somewhat
tricky.  I hate the duplicated code between socket and ssl
modules, but added to it.  It would be great to clean this
up for 2.6.

If you are forced to use select with a high socket, the
exception on connect is operation in progress rather than
can't select on socket.  I guess that's ok, it doesn't
actually change the existing behaviour.  That would have
been more involved and I'm not sure it's worth it.

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-06-09 03:31

Message:
Logged In: YES 
user_id=1488997

Ok, I'll attach a patch that uses poll when available
(HAVE_POLL is already being set by the configure stuff
appropriately).

It replaces one of the two uses of select() (specifically,
the internal_select() function) in socketmodule.c. The other
is win32-specific, so replacing it with poll() wouldn't make
sense.

greg: epoll/kevent don't make sense for replacing the use of
select/poll in this particular case - socketmodule.c always
selects/polls precisely one file descriptor.

I've tested this locally, and it fixes the problem
(linux/x86). I don't have a windows system to test it on,
but it shouldn't change behaviour in any way for windows.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-06-07 22:51

Message:
Logged In: YES 
user_id=413

eew yuck.  yes use poll at the very least.

we should also consider using epoll (linux) and kevent (bsd)
in the future as both of those scale better than O(n) unlike
select and poll.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-06-04 13:14

Message:
Logged In: YES 
user_id=21627

A patch to replace internal_select with poll(2) where
available is acceptable. The current version should be
conditionally kept. That Windows doesn't have poll(2) is no
problem: its select implementation supports arbitrarily
large FDs (just like poll).

Relaxing the IS_SELECTABLE usage to cases where select is
actually going to be called is optional: there shouldn't be
too many systems left without select where people still want
to open many file descriptors.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-31 15:27

Message:
Logged In: YES 
user_id=31435

akuchling:  No, poll() is not part of the Windows socket API.

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-31 14:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 11:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 07:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 07:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 06:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Wed Oct 11 05:52:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Oct 2006 20:52:09 -0700
Subject: [ python-Bugs-1575020 ] Request wave support > 16 bit samples
Message-ID: <E1GXV8b-00045p-J0@sc8-sf-web5.sourceforge.net>

Bugs item #1575020, was opened at 2006-10-11 11:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575020&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Murray Lang (murraylang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Request wave support > 16 bit samples

Initial Comment:
May I request that the wave library support audio
formats greater than 16 bit. I am hoping to use GNU
Radio (http://www.gnu.org/software/gnuradio/) Python
software with HPSDR (http://hpsdr.org/) hardware, but
the HPSDR audio is 24 bit. The extra dynamic range is
required for weak signal work. Many audio cards are now
coming on the market with 24 bit capability.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575020&group_id=5470

From noreply at sourceforge.net  Wed Oct 11 12:35:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Oct 2006 03:35:09 -0700
Subject: [ python-Bugs-1575169 ] isSequenceType returns True for dict
	subclasses (<> 2.3)
Message-ID: <E1GXbQb-0006RN-TQ@sc8-sf-web1.sourceforge.net>

Bugs item #1575169, was opened at 2006-10-11 12:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575169&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: isSequenceType returns True for dict subclasses (<> 2.3)

Initial Comment:
The following behavior is correct according to the 
documentation. However, it seems weird to me, and 
broke my code when going from 2.3 to 2.4:

Python  2.4.2:
>>> import operator
>>> class deriveddict(dict): pass
... 
>>> d =dict()
>>> dd = deriveddict()
>>> operator.isSequenceType(d)
False
>>> operator.isSequenceType(dd)
True


The last statement returns False in Python 2.3.4.






----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575169&group_id=5470

From noreply at sourceforge.net  Wed Oct 11 14:39:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Oct 2006 05:39:01 -0700
Subject: [ python-Feature Requests-1575020 ] Request wave support > 16 bit
	samples
Message-ID: <E1GXdMT-0005w0-2B@sc8-sf-web5.sourceforge.net>

Feature Requests item #1575020, was opened at 2006-10-11 03:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1575020&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Murray Lang (murraylang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Request wave support > 16 bit samples

Initial Comment:
May I request that the wave library support audio
formats greater than 16 bit. I am hoping to use GNU
Radio (http://www.gnu.org/software/gnuradio/) Python
software with HPSDR (http://hpsdr.org/) hardware, but
the HPSDR audio is 24 bit. The extra dynamic range is
required for weak signal work. Many audio cards are now
coming on the market with 24 bit capability.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-11 12:39

Message:
Logged In: YES 
user_id=849994

Turning into a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1575020&group_id=5470

From noreply at sourceforge.net  Wed Oct 11 16:44:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Oct 2006 07:44:45 -0700
Subject: [ python-Bugs-1575169 ] isSequenceType returns True for dict
	subclasses (<> 2.3)
Message-ID: <E1GXfK9-0005Fb-1V@sc8-sf-web3.sourceforge.net>

Bugs item #1575169, was opened at 2006-10-11 05:35
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575169&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Gfeller (gfe)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: isSequenceType returns True for dict subclasses (<> 2.3)

Initial Comment:
The following behavior is correct according to the 
documentation. However, it seems weird to me, and 
broke my code when going from 2.3 to 2.4:

Python  2.4.2:
>>> import operator
>>> class deriveddict(dict): pass
... 
>>> d =dict()
>>> dd = deriveddict()
>>> operator.isSequenceType(d)
False
>>> operator.isSequenceType(dd)
True


The last statement returns False in Python 2.3.4.






----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575169&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 07:58:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Oct 2006 22:58:50 -0700
Subject: [ python-Bugs-1574593 ] ctypes: Returning c_void_p from callback
	doesn\'t work
Message-ID: <E1GXtak-0005Rr-J8@sc8-sf-web4.sourceforge.net>

Bugs item #1574593, was opened at 2006-10-10 08:18
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574593&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
>Assigned to: Thomas Heller (theller)
>Summary: ctypes: Returning c_void_p from callback doesn\'t work

Initial Comment:
C code:

extern CALLBACK_API void* foo(void*(*callback)()) {
    printf("foo calling callback\n");
    callback();
    printf("callback returned in foo\n");
}

callback.py contains:

import sys
print sys.version
from ctypes import *
def callback(*args):
    return c_void_p()
#lib = cdll['libcallback.so']
lib = cdll['callback.dll']
lib.foo.argtypes = [CFUNCTYPE(c_void_p)]
lib.foo(lib.foo.argtypes[0](callback))

With Python 2.4.3 and ctypes 1.0.0 + Thomas Heller's
patch for another issue (which doesn't seem to affect
this situation, but anyway) I get the following error:

2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
foo calling callback
Traceback (most recent call last):
  File "source/callbacks.c", line 216, in 'converting
callback result'
TypeError: cannot be converted to pointer
Exception  in None ignored
callback returned in foo

With Python 2.5 and ctypes 1.0.1 I get:

2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32
bit (Intel)]
foo calling callback
Traceback (most recent call last):
  File "\loewis\25\python\Modules\_ctypes\callbacks.c",
line 216, in
'converting callback result'
TypeError: cannot be converted to pointer
Exception  in <function callback at 0x009C3CF0> ignored
callback returned in foo

Returning a Python integer from callback() doesn't
cause an error to be raised.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574593&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 07:58:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Oct 2006 22:58:50 -0700
Subject: [ python-Bugs-1574588 ] ctypes: Pointer-to-pointer unchanged in
	callback
Message-ID: <E1GXtak-0005Ru-KW@sc8-sf-web4.sourceforge.net>

Bugs item #1574588, was opened at 2006-10-10 08:16
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574588&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
>Assigned to: Thomas Heller (theller)
Summary: ctypes: Pointer-to-pointer unchanged in callback

Initial Comment:
This problem is from another post I made to
ctypes-users that didn't show up in the ctypes-users
archive.

C function:

extern CALLBACK_API void foo(void(*callback)(void**)) {
    void* p = 123;
    printf("foo calling callback\n");
    callback(&p);
    printf("callback returned in foo\n");
    printf("p = 0x%p\n", p);
}

I figured that while I try to find out why returning
c_void_p from a callback gives an error, I might as
well return the address via a pointer to a pointer.

In the Python code I have:

import sys
print sys.version
from ctypes import *
x_t = c_int*10
x = x_t()
def callback(ptr):
    print x
    print ptr
    ptr.contents = cast(addressof(x), c_void_p)
    print ptr.contents
#lib = cdll['libcallback.so']
lib = cdll['callback.dll']
lib.foo.argtypes = [CFUNCTYPE(None, POINTER(c_void_p))]
lib.foo(lib.foo.argtypes[0](callback))

Output when I running this script under Python 2.4.3
with ctypes 1.0.0 (I get identical results with Python
2.5 and ctypes 1.0.1):

2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
foo calling callback
<__main__.c_long_Array_10 object at 0x00963E90>
<ctypes.LP_c_void_p object at 0x00963EE0>
c_void_p(10048496)
callback returned in foo
p = 0x0000007B

For some reason, the value I assigned to ptr.contents
isn't present when we return to the C code.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574588&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 07:59:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Oct 2006 22:59:36 -0700
Subject: [ python-Bugs-1574584 ] Error with callback function and as_parameter
	with NumPy ndp
Message-ID: <E1GXtbU-0005Xq-C7@sc8-sf-web4.sourceforge.net>

Bugs item #1574584, was opened at 2006-10-10 08:11
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
>Assigned to: Thomas Heller (theller)
Summary: Error with callback function and as_parameter with NumPy ndp

Initial Comment:
I posted to the ctypes-users mailing list about this
problem, but SourceForge failed to make that post and
its replies available in the ctypes-users archive, so
I'm repeating it here.

I'm using NumPy with ctypes. I would like to create a
callback function that calls into Python, allocates a
NumPy array and returns a suitable pointer to the C code.

NumPy has a function called ndpointer that allows one
to specify some details of NumPy arrays when dealing
with argtypes. This function also takes care of
extracting the array's data pointer.

Details here:

http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/ctypeslib.py
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/core/_internal.py

Creating a callback function as follows works:

stuff = []
import numpy
def allocator1():
    x = numpy.array([...], dtype='f4')
    stuff.append(x)
    return x.ctypes.data_as(POINTER(c_float))
CFUNCTYPE(POINTER(c_float))(allocator1)

However, if one adds ndpointer to the mix, an error occurs:

stuff = []
import numpy
def allocator2():
    x = numpy.array([...], dtype='f4')
    stuff.append(x)
    return x
CFUNCTYPE(numpy.ctypeslib.ndpointer('f4'))(allocator2)

The error is:

SystemError: NULL result without error in PyObject_Call

Thomas Heller has a patch for this issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 09:22:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 00:22:01 -0700
Subject: [ python-Bugs-1575746 ] typo: section 2.1 -> property
Message-ID: <E1GXutF-0006ZI-Ow@sc8-sf-web2.sourceforge.net>

Bugs item #1575746, was opened at 2006-10-12 09:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575746&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine De Groote (grootea)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo: section 2.1 -> property

Initial Comment:
http://docs.python.org/lib/built-in-funcs.html

The property function paragraph (version 2.5) includes
the following snippet 

class C(object):
    def __init__(self): self.__x = None
    def getx(self): return self._x
    def setx(self, value): self._x = value
    def delx(self): del self._x
    x = property(getx, setx, delx, "I'm the 'x' property.")

On line 2, __x is initialized. Some think this should
be _x. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575746&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 09:38:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 00:38:29 -0700
Subject: [ python-Bugs-1575746 ] typo: section 2.1 -> property
Message-ID: <E1GXv9B-00075K-3m@sc8-sf-web4.sourceforge.net>

Bugs item #1575746, was opened at 2006-10-12 07:22
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575746&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Antoine De Groote (grootea)
>Assigned to: Georg Brandl (gbrandl)
Summary: typo: section 2.1 -> property

Initial Comment:
http://docs.python.org/lib/built-in-funcs.html

The property function paragraph (version 2.5) includes
the following snippet 

class C(object):
    def __init__(self): self.__x = None
    def getx(self): return self._x
    def setx(self, value): self._x = value
    def delx(self): del self._x
    x = property(getx, setx, delx, "I'm the 'x' property.")

On line 2, __x is initialized. Some think this should
be _x. 

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 07:38

Message:
Logged In: YES 
user_id=849994

Thanks for the report, fixed in rev. 52293, 52294 (2.5).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575746&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 09:57:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 00:57:38 -0700
Subject: [ python-Bugs-813342 ] -Qnew switch doesn't work
Message-ID: <E1GXvRi-0001c7-Q4@sc8-sf-web2.sourceforge.net>

Bugs item #813342, was opened at 2003-09-26 23:18
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Gregor Lingl (glingl)
>Assigned to: Georg Brandl (gbrandl)
Summary: -Qnew switch doesn't work

Initial Comment:
When starting IDLE 1.0 with Python's -Qnew option
new division ist *not* in action! (Whereas this worked
well with IDLE 0.8 and Python 2.2)

Exception: new division works, when additionally the -n
switch of IDLE is used (no subprocesses).





----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 07:57

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 52295, 52296 (2.5).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 06:25

Message:
Logged In: YES 
user_id=33168

This is still a problem in 2.5 (CVS).

----------------------------------------------------------------------

Comment By: Gregor Lingl (glingl)
Date: 2003-09-28 22:12

Message:
Logged In: YES 
user_id=505031

Sorry, adding turtle.py was an error (wrong bug-thread, see bug
812986)
Gregor

----------------------------------------------------------------------

Comment By: Gregor Lingl (glingl)
Date: 2003-09-28 22:05

Message:
Logged In: YES 
user_id=505031

Oh! Here is the file mentioned above,
Gregor


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 10:23:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 01:23:09 -0700
Subject: [ python-Bugs-1565919 ] sets missing from standard types list in ref
Message-ID: <E1GXvqP-0003Df-CL@sc8-sf-web4.sourceforge.net>

Bugs item #1565919, was opened at 2006-09-26 18:51
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565919&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Georg Brandl (gbrandl)
>Assigned to: Georg Brandl (gbrandl)
Summary: sets missing from standard types list in ref

Initial Comment:
Sets (and frozensets) are missing from
http://docs.python.org/ref/types.html.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 08:23

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 52297, 52298 (2.5).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565919&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 10:44:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 01:44:57 -0700
Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4
Message-ID: <E1GXwBV-0006AC-W4@sc8-sf-web2.sourceforge.net>

Bugs item #1086642, was opened at 2004-12-16 19:21
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 5
Submitted By: A. Stocker (akosprime)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile of _socket fails on 2.4

Initial Comment:
I'm attempting to install Python 2.4 on an SGI Origin
2400 running Irix 6.5.22.  I'm using gcc (3.3) to
compile, and I've tried using three different make
programs (make, smake, and gmake[3.80]) but get the
same error during compilation during the building of
_socket.  There was not a problem building 2.2.1 on
this machine before, we never built 2.3 so I do not
know if the same problem existed.  Here is the relevant
entry from the make:

building '_socket' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared
-fno-strict-aliasing -I.
-I/usr/local/src/Python-2.4/./Include -I/us
r/local/include -I/usr/local/src/Python-2.4/Include
-I/usr/local/src/Python-2.4 -c
/usr/local/src/Python-2.4/Modules/socke
tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o
In file included from
/usr/local/src/Python-2.4/Modules/socketmodule.c:280:
/usr/local/src/Python-2.4/Modules/addrinfo.h:145:1:
warning: "_SS_ALIGNSIZE" redefined
In file included from
/usr/local/src/Python-2.4/Modules/socketmodule.h:8,
                 from
/usr/local/src/Python-2.4/Modules/socketmodule.c:223:
/usr/include/sys/socket.h:246:1: warning: this is the
location of the previous definition
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `makeipaddr':
/usr/local/src/Python-2.4/Modules/socketmodule.c:853:
warning: implicit declaration of function `getnameinfo'
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: `NI_NUMERICHOST' undeclared (first use in this
function)
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: (Each undeclared identifier is reported only once
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: for each function it appears in.)
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `socket_gethostbyname_ex':
/usr/local/src/Python-2.4/Modules/socketmodule.c:2785:
warning: implicit declaration of function `gethostbyname_r'
/usr/local/src/Python-2.4/Modules/socketmodule.c:2785:
warning: assignment makes pointer from integer without
a cast
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `socket_gethostbyaddr':
/usr/local/src/Python-2.4/Modules/socketmodule.c:2880:
warning: implicit declaration of function `gethostbyaddr_r'
/usr/local/src/Python-2.4/Modules/socketmodule.c:2881:
warning: assignment makes pointer from integer without
a cast
building '_ssl' extension


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 08:44

Message:
Logged In: YES 
user_id=849994

Is anyone going to do something about this, without a
specific report? Anyway, lowering priority.

----------------------------------------------------------------------

Comment By: Andrew McNabb (amcnabb)
Date: 2006-09-19 21:42

Message:
Logged In: YES 
user_id=1234027

When I use the native IRIX cc to compile socketmodule.c in
Python 2.5, I get:

cc -OPT:Olimit=0 -DNDEBUG -O -I.
-I/auto/fsc/awm27/bzr/Python-2.5/./Include -I/fsc/awm27/i
nclude -I./Include -I. -I/usr/local/include
-I/auto/fsc/awm27/bzr/Python-2.5/Include -I/au
to/fsc/awm27/bzr/Python-2.5 -c
/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c -o bu
ild/temp.irix64-6.5-2.5/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.o
cc-1047 cc: WARNING File = /usr/include/sys/param.h, Line = 372
  Macro "MAX" (declared at line 77 of
         
"/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c") has an
          incompatible redefinition.

  #define MAX(a,b) (((a)>(b))?(a):(b))
          ^


When I commented out the macro definition in socketmodule.c,
I was able to get it to compile (with the IRIX compiler).

It seems to me that --without-gcc should be the default for
IRIX until the gcc problem gets fixed because ./configure is
currently automatically choosing gcc as the compiler when
both are available.  And I'm really not sure why the "#undef
MAX" didn't happen.

Anyway, I hope this is helpful for someone.

----------------------------------------------------------------------

Comment By: Andrew McNabb (amcnabb)
Date: 2006-09-19 21:26

Message:
Logged In: YES 
user_id=1234027

I'm having this same problem with Python 2.5.  I checked,
and "/usr/lib/libmpc.a" is present.  I've only tried with
gcc, and I'm getting the exact same errors as above.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2005-01-11 17:56

Message:
Logged In: YES 
user_id=71407

Before giving up I'd try to reset PATH before running configure 
in the Python directory. I had all kinds of trouble with the 
freeware tools on path. Here is what I use:

/usr/bin /usr/bsd /bin /usr/sbin /sbin /etc /usr/etc /usr/bin/X11

Python 2.4 really works under IRIX, incl. the socket module. I 
have it going on three different machines. On one machine 
the timestamp for libmpc.a is from 1998!


----------------------------------------------------------------------

Comment By: A. Stocker (akosprime)
Date: 2005-01-11 17:43

Message:
Logged In: YES 
user_id=1179755

Ralf,

Strange, I DO have that library:

ls -l /usr/lib/libmpc*
-r--r--r--    1 root     sys         1220 Mar 13  2001
/usr/lib/libmpc.a

It makes no sense to me that the SGI MIPS compilers can't
find a library that's in a default location.  Very peculiar.
 I guess I'm just going to have to give up on getting Python
2.4 working completely under Irix.  We need both network and
_locale to work in order for the various scripts we have in
place to work correctly and I can't get it to compile with gcc.

[*sigh*]

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2005-01-11 17:32

Message:
Logged In: YES 
user_id=71407

You are missing a system library:

/usr/lib/libmpc.a

I've never done anything special to install this library but it is 
available on all three IRIX systems that I have access to.

The library is not used to resolve any symbols. I guess you 
could just remove the -lmpc from the link line.


----------------------------------------------------------------------

Comment By: A. Stocker (akosprime)
Date: 2005-01-11 15:48

Message:
Logged In: YES 
user_id=1179755

Okay, I tried compiling using the Irix Mips compilers.  To
do this I did a ./configure --without-gcc.  However when
attempting to make it errored out.  Here is the last section
of the make output:

        ar cr libpython2.4.a Modules/config.o 
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.4.a Modules/threadmodule.o 
Modules/signalmodule.o  Modules/posixmodule.o 
Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o  Modules/zipimport.o 
Modules/symtablemodule.o  Modules/xxsubtype.o
        : libpython2.4.a
         c++   -o python \
                        Modules/python.o \
                        libpython2.4.a -lsocket -lnsl -ldl 
-lpthread -lmpc   -lm  
ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for
resolving any symbol.
ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for
resolving any symbol.
ld32: WARNING 84 : /usr/lib32/libdl.so is not used for
resolving any symbol.
ld32: FATAL   9  : I/O error (-lmpc): No such file or directory
collect2: ld returned 32 exit status
*** Error code 1 (bu21)

The patch is relatively the same as the hack I tried
earlier, and noted in a follow-up.  But as pointed out
test_socketserver doesn't work ("Use of the `network'
resource not enabled") and _locale doesn't work ("***
WARNING: renaming "_locale" since importing it failed:
1774654:./python: rld: Fatal Error: unresolvable symbol in
build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext")

I'm not sure what else to try in order to get this working.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-30 16:44

Message:
Logged In: YES 
user_id=71407

Some additional observations:

socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after 
applying this simple-minded patch (relative to Python 2.4):

--- socketmodule.c.orig 2004-11-07 06:24:25.000000000 -
0800
+++ socketmodule.c      2004-12-30 08:06:01.896160200 -
0800
@@ -280,6 +280,10 @@
 #  include "addrinfo.h"
 #endif
 
+#if defined(__sgi) && defined(__GNUC__) && !defined
(NI_NUMERICHOST)
+#  define NI_NUMERICHOST 0x00000002
+#endif
+
 #ifndef HAVE_INET_PTON
 int inet_pton(int af, const char *src, void *dst);
 const char *inet_ntop(int af, const void *src, char *dst, 
socklen_t size);


This test works OK:

./python Lib/test/test_socket.py

But this one doesn't:

./python Lib/test/test_socketserver.py


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-30 16:38

Message:
Logged In: YES 
user_id=71407

FWIW: socketmodule.c included in Python 2.3.4 also fails to 
compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's 
freeware distribution.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-30 15:28

Message:
Logged In: YES 
user_id=71407

Martin v. Loewis asked me to take a look (because of my 
involvement in http://python.org/sf/728330).

I never use gcc under IRIX. Python 2.4 works just fine with 
the native IRIX compilers.

Suggestion to A. Stocker: try to modify the ifdef's in 
socketmodule.c to do the right thing for gcc 3.3. I can test 
your patch on our machines to make sure compilation with the 
native compilers is still OK.


----------------------------------------------------------------------

Comment By: A. Stocker (akosprime)
Date: 2004-12-22 14:19

Message:
Logged In: YES 
user_id=1179755

All,

I decided to force the issue a bit.  Looking through
socketmodule.c I noticed that there was an SGI specific
check that basically disabled loading the addrinfo.h file,
which is where NI_NUMERICHOST is defined.  So I put the
#define statement from the addrinfo.h file directly in the
socketmodule.c file and the compilation with _socket worked.
 However this seems to be a clunky way to deal with the
situation.  Plus I don't know if there's anything else like
this biting me in the butt (for instance '_locale' doesn't
compile either.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 11:03:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 02:03:53 -0700
Subject: [ python-Bugs-1565468 ] Install on WinXP always goes to C:\
Message-ID: <E1GXwTp-0007KI-UN@sc8-sf-web4.sourceforge.net>

Bugs item #1565468, was opened at 2006-09-26 03:05
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Wayne Pierce (piercew)
>Assigned to: Martin v. L?wis (loewis)
Summary: Install on WinXP always goes to C:\

Initial Comment:
When I install Python on WinXP it always goes go C:\ 
even though I select C:\Python .  This happens when 
Python is installed for just me or for all users on a 
system.

The system is running WinXP SP 2 and the account 
installing has enough rights to install 
applications.  An install log has been attached.

----------------------------------------------------------------------

Comment By: Wayne Pierce (piercew)
Date: 2006-09-26 09:10

Message:
Logged In: YES 
user_id=4553

Since I cannot attach a file to a bug report I have placed 
the python.log file at 
http://shalofin.googlepages.com/python.log

----------------------------------------------------------------------

Comment By: Wayne Pierce (piercew)
Date: 2006-09-26 03:40

Message:
Logged In: YES 
user_id=4553

I am unable to attach a file.  Every time a file is 
attached I receive a 'page cannot be found' error message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565468&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 11:05:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 02:05:20 -0700
Subject: [ python-Feature Requests-1555501 ] Please include pliblist for all
	plattforms
Message-ID: <E1GXwVE-00052G-5a@sc8-sf-web6.sourceforge.net>

Feature Requests item #1555501, was opened at 2006-09-09 20:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1555501&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Guenther (guidog)
Assigned to: Nobody/Anonymous (nobody)
Summary: Please include pliblist for all plattforms

Initial Comment:
Hi,
plistlib which is currently under
./Lib/plat-mac/plistlib.py is usefull on other
platforms too (e.g. in apples calendar server which
runs on OS X and Linux). Could this be moved to Lib/
for 2.5 so that other platforms can benefit from it too?
Cheers,
 -- Guido

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 09:05

Message:
Logged In: YES 
user_id=849994

Currently, there is no documentation for plistlib. Would you
be willing to help writing one?

----------------------------------------------------------------------

Comment By: Guido Guenther (guidog)
Date: 2006-09-17 20:27

Message:
Logged In: YES 
user_id=696207

That's sad since it looks unproblematic. Please add it to
2.6 then.
Thanks a lot,
 -- Guido

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-17 19:27

Message:
Logged In: YES 
user_id=580910

this is too late for 2.5. Adding it to the general library could be done for 2.6.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1555501&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 11:06:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 02:06:10 -0700
Subject: [ python-Bugs-1565129 ] make plistlib.py available in every install
Message-ID: <E1GXwW2-0007bc-Ke@sc8-sf-web4.sourceforge.net>

Bugs item #1565129, was opened at 2006-09-25 14:28
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: make plistlib.py available in every install

Initial Comment:
[requested in http://bugs.debian.org/386738]

plistlib which is currently under
./Lib/plat-mac/plistlib.py is
usefull on other platforms too it's e.g. needed for
packaging calendar-server -- Apple's calendar server
The module could be packaged separately, but should
better be used from the standard library.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-09-25 15:42

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of bug #779460:
http://www.python.org/sf/779460

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 11:08:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 02:08:15 -0700
Subject: [ python-Feature Requests-1555501 ] Please include pliblist for all
	plattforms
Message-ID: <E1GXwY3-0003a5-GE@sc8-sf-web3.sourceforge.net>

Feature Requests item #1555501, was opened at 2006-09-09 22:07
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1555501&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Guenther (guidog)
Assigned to: Nobody/Anonymous (nobody)
Summary: Please include pliblist for all plattforms

Initial Comment:
Hi,
plistlib which is currently under
./Lib/plat-mac/plistlib.py is usefull on other
platforms too (e.g. in apples calendar server which
runs on OS X and Linux). Could this be moved to Lib/
for 2.5 so that other platforms can benefit from it too?
Cheers,
 -- Guido

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-12 11:08

Message:
Logged In: YES 
user_id=580910

As an aside: adding plistlib to the standard library seems to be a good idea. I've 
discussed this with Jack Jansen and Bob Ippolito and they agree.

The only thing that's missing at the moment is documentation.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:05

Message:
Logged In: YES 
user_id=849994

Currently, there is no documentation for plistlib. Would you
be willing to help writing one?

----------------------------------------------------------------------

Comment By: Guido Guenther (guidog)
Date: 2006-09-17 22:27

Message:
Logged In: YES 
user_id=696207

That's sad since it looks unproblematic. Please add it to
2.6 then.
Thanks a lot,
 -- Guido

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-17 21:27

Message:
Logged In: YES 
user_id=580910

this is too late for 2.5. Adding it to the general library could be done for 2.6.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1555501&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 11:21:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 02:21:08 -0700
Subject: [ python-Bugs-1550524 ] inspect module and class startlineno
Message-ID: <E1GXwkW-0006MS-1e@sc8-sf-web1.sourceforge.net>

Bugs item #1550524, was opened at 2006-09-01 13:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550524&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
>Assigned to: Georg Brandl (gbrandl)
Summary: inspect module and class startlineno

Initial Comment:
Inspect module fails to find the correct starting line
number of a class. ::

  import inspect

  def a_func():
      class AClass(object):
          pass

  class AClass(object):
      pass

  print inspect.findsource(AClass)[1]
  # the result should have been 7, but it is 4

After reading `inspect` module I realized that for
classes it does a
simple RE search to find their definition location. 
Apart from that I
think python does not seem to fully support classes
with the same name
in one module (nested classes that are defined in other
functions or
classes).  That is a `ClassType` only holds its module
and its name
and that is hardly enough for runtime analysis of objects.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 09:21

Message:
Logged In: YES 
user_id=849994

Added a better find heuristics in rev.  52299, 52300 (2.5).
(More can't be done)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550524&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 11:23:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 02:23:48 -0700
Subject: [ python-Bugs-1549574 ] Pdb parser bug
Message-ID: <E1GXwn6-0001Vh-Vf@sc8-sf-web2.sourceforge.net>

Bugs item #1549574, was opened at 2006-08-30 20:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pdb parser bug

Initial Comment:
>>> import pdb
>>> pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) p ";;"
*** SyntaxError: SyntaxError('EOL while scanning
single-quoted string', ('<string>', 1, 1, '"'))
*** SyntaxError: EOL while scanning single-quoted
string (<stdin>, line 1)


Still present in trunk:51513M

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 09:23

Message:
Logged In: YES 
user_id=849994

It's documented, and it can be worked around. So I'm closing
this as Won't Fix. If you want to have a more elaborate
splitting, please submit a feature request.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-09-04 21:42

Message:
Logged In: YES 
user_id=971153

For the record, this behaviour is explicitly documented in
pdb docs.

from:
http://www.python.org/doc/current/lib/debugger-commands.html

"""Multiple commands may be entered on a single line,
separated by ";;".... No intelligence is applied to
separating the commands; the input is split at the first
";;" pair, even if it is in the middle of a quoted string."""

So should this be considered a bug?  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 11:42:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 02:42:19 -0700
Subject: [ python-Bugs-1575803 ] Missing notice on environment setting
	LD_LIBRARY_PATH
Message-ID: <E1GXx51-0006tc-KW@sc8-sf-web3.sourceforge.net>

Bugs item #1575803, was opened at 2006-10-12 11:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575803&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Anastasios Hatzis (ahatzis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing notice on environment setting LD_LIBRARY_PATH

Initial Comment:
Probably it would be a good idea to provide Linux noobs
like me a short notice in the README that
LD_LIBRARY_PATH needs to be set. It was time-consuming
to find out what caused problems with my installation
although the build process went fine.

I don't know if this is really only necessary if Python
is built from source with the "--enable-shared" option.
If yes, a short notice in this paragraph would be fine:

<snip>
Building a shared libpython
---------------------------

Starting with Python 2.3, the majority of the
interpreter can be built
into a shared library, which can then be used by the
interpreter
executable, and by applications embedding Python. To
enable this feature,
configure with --enable-shared.

If you enable this feature, the same object files will
be used to create
a static library.  In particular, the static library
will contain object
files using position-independent code (PIC) on
platforms where PIC flags
are needed for the shared library.
</snip>

Otherwise, if the setting is necessary whether
"--enable-shared" is turned on or off, a good place
would be right after the "make install" explanations.

Again, this is a Linux rookie issue. But if I want to
install the most recent Python version I can't take any
ready-to-use RPM, so I have to build from sources and
will run into these problems the first time.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575803&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 11:47:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 02:47:34 -0700
Subject: [ python-Bugs-1548891 ] shlex (or perhaps cStringIO) and unicode
	strings
Message-ID: <E1GXxA6-0007Ni-CE@sc8-sf-web3.sourceforge.net>

Bugs item #1548891, was opened at 2006-08-29 21:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548891&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Erwin S. Andreasen (drylock)
>Assigned to: Georg Brandl (gbrandl)
Summary: shlex (or perhaps cStringIO) and unicode strings

Initial Comment:
Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) 
[GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on
linux2

(Also seen in 2.4)

shlex.split do not like unicode strings:

>>> shlex.split(u"foo")
['f\x00\x00\x00o\x00\x00\x00o\x00\x00\x00']

The shlex code IMO suggests that it should accept
unicode (as it checks for argument being an instance of
basestring).

Digging slightly into this, this seems to be a
difference between StringIO and cStringIO. While
cStringIO claims it accepts unicode as long as it
encode too ASCII it gives invalid results:

>>> sys.getdefaultencoding()
'ascii'


>>> cStringIO.StringIO(u'foo').getvalue()
'f\x00\x00\x00o\x00\x00\x00o\x00\x00\x00'

Perhaps cStringIO should .encode to ASCII encoding
before consuming the input, as I can't imagine anyone
cares about the above result (which I guess are the
UCS-2 or UCS-4 characters).



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 09:47

Message:
Logged In: YES 
user_id=849994

Thanks for your report, this is now fixed in rev. 52301,
52302 (2.5).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548891&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 12:49:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 03:49:47 -0700
Subject: [ python-Bugs-1551238 ] Build of 2.4.3 on fedora core 5 fails to find
	asm/msr.h
Message-ID: <E1GXy8J-0001Tw-Bh@sc8-sf-web2.sourceforge.net>

Bugs item #1551238, was opened at 2006-09-03 00:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551238&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George R. Goffe (grgoffe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build of 2.4.3 on fedora core 5 fails to find asm/msr.h

Initial Comment:
Howdy,

I just downloaded Python-2.4.3 and tried to build it
with the enclosed results. I then proceeded to check
out the latest from svn and that version DOES build.
This is just a fyi bug report unless you think otherwise.

Regards,

George...


gcc -pthread -c -fno-strict-aliasing -g -Wall
-Wstrict-prototypes -I. -I./Include -fPIC
-DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c
Python/ceval.c:50:21: error: asm/msr.h: No such file or
directory
Python/ceval.c: In function 'PyEval_EvalFrame':
Python/ceval.c:578: warning: implicit declaration of
function 'rdtscll'
make: *** [Python/ceval.o] Error 1


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 10:49

Message:
Logged In: YES 
user_id=849994

If it works in SVN, it will work in 2.4.4 and 2.5.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551238&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 12:51:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 03:51:00 -0700
Subject: [ python-Bugs-1560032 ] confusing error msg from random.randint
Message-ID: <E1GXy9U-0006uy-Cp@sc8-sf-web6.sourceforge.net>

Bugs item #1560032, was opened at 2006-09-17 06:22
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560032&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 3
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: confusing error msg from random.randint

Initial Comment:
See the following output.  The reason for the confusing
message is that random.randint is actually a bound
method to a Random instance inside the module, i.e.
someone got a little bit too clever.  It should be an
ordinary function that calls that instance method instead.

>>> import random
>>> random.randint(10000)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: randint() takes exactly 3 arguments (2 given)



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 10:51

Message:
Logged In: YES 
user_id=849994

Note that it is documented that the random functions are
actually bound methods.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560032&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 12:51:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 03:51:24 -0700
Subject: [ python-Bugs-1562092 ] IDLE: Dedent with Italian keyboard
Message-ID: <E1GXy9s-0001g9-DL@sc8-sf-web2.sourceforge.net>

Bugs item #1562092, was opened at 2006-09-20 11:01
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: neclepsio (neclepsio82)
>Assigned to: Kurt B. Kaiser (kbk)
>Summary: IDLE: Dedent with Italian keyboard

Initial Comment:
In IDLE, with an Italian keyboard, it's impossible to
dedent the text without using the menu, because the
shortcut Ctrl+] cannot be typed. In fact,  with an
Italian keybaord, the ] is typed with Ctrl+Alt++. While
indent can be achieved with Tab, so that's no problem,
dedent is only accesible from menu: I suggest you to
shortcut it as Shift+Tab too, like many other IDEs.

Thank you
Ignazio

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 13:15:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 04:15:10 -0700
Subject: [ python-Bugs-1546628 ] urlparse.urljoin odd behaviour
Message-ID: <E1GXyWs-00042q-GX@sc8-sf-web5.sourceforge.net>

Bugs item #1546628, was opened at 2006-08-25 13:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andres Riancho (andresriancho)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urljoin odd behaviour

Initial Comment:
Hi !

   I think i have found a bug on the urljoin function
of the urlparse
module. I'm using Python 2.4.3 (#2, Apr 27 2006,
14:43:58), [GCC 4.0.3
(Ubuntu 4.0.3-1ubuntu5)] on linux2 . Here is a demo of
the bug :

>>> import urlparse
>>>urlparse.urljoin('http://www.f00.com/','//a')
'http://a'
>>>
urlparse.urljoin('http://www.f00.com/','https://0000/somethingIsWrong')
'https://0000/somethingIsWrong'
>>>
urlparse.urljoin('http://www.f00.com/','https://0000/somethingIsWrong')
'https://0000/somethingIsWrong'
>>>
urlparse.urljoin('http://www.f00.com/','file:///etc/passwd')
'file:///etc/passwd'


   The result for the first call to urljoin should be
either
'http://www.f00.com/a' or 'http://www.f00.com//a'. The
result to the
second and third call to urljoin should be
'http://www.f00.com/', or maybe an
exception ?

   Please correct me if i'm wrong and this is some kind
of feature or
the bug was already reported. This bug can result in a
security vuln,
take this code as an example:

// viewImage.py //
import htmlTools                                      
    # Some fake
module, just for the example
import urlparse                                       
     # module
with bug.

htmlTools.startHtml()                                 
  # print <html>
params = htmlTools.getParams()                # get the
query string
parameters
htmlTools.printToHtml( '<img src=' + urlparse.urljoin(
'http://myWebsite/' , params['image'] ) + '>' )
htmlTools.endHtml()                                   
 # print </html>
// viewImage.py //

   The code should generate an html that shows an image
from the site
http://myWebsite/, but with the urljoin bug, the image
source can be
manipulated and result in a completely different html.

Cheers,

Andres Riancho

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:15

Message:
Logged In: YES 
user_id=849994

The behavior is okay, but the docs didn't say that. I added
a note in rev. 52303, 52304 (2.5).

----------------------------------------------------------------------

Comment By: Andrew  Jones (the_j10)
Date: 2006-08-29 11:29

Message:
Logged In: YES 
user_id=332575

The second argument in the urljoin method can be either an 
absolute url or a relative url as specified by rfc1808. So
your 1st example: '//a' gives a relative position w.r.t the
base resulting in: 'http://a'. This is similar to how `cd
/boot` takes you to a path relative to the filesystem's root
'/'. 

In the rest of your examples you have the scheme name
'https'in the url as the 2nd argument. urljoin follows the
rfc1808 and accepts the second argument if it has a scheme
name as the absolute url and returns it.

This behavior is not very intuitive. Perhaps the urlparse 
could be extended to have a urlappend method, which has the 
behavior you expected. Hmmm...

-- Andrew

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 13:15:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 04:15:47 -0700
Subject: [ python-Bugs-1563243 ] python_d python
Message-ID: <E1GXyXT-0004Lj-5F@sc8-sf-web4.sourceforge.net>

Bugs item #1563243, was opened at 2006-09-22 01:20
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Grzegorz Makarewicz (makaron)
Assigned to: Nobody/Anonymous (nobody)
Summary: python_d python

Initial Comment:
I'v added _d to python (python_d.exe) while performing
standard tests ... it dies after testInfinitRecursion
without any message - just dissapears :(


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:15

Message:
Logged In: YES 
user_id=849994

"I'v added _d to python" is not clear to me.
Can you give more information?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 13:28:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 04:28:20 -0700
Subject: [ python-Bugs-1545497 ] inconsistent treatment of NULs in int()
Message-ID: <E1GXyjc-0002Mg-Cb@sc8-sf-web6.sourceforge.net>

Bugs item #1545497, was opened at 2006-08-23 19:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545497&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Georg Brandl (gbrandl)
Summary: inconsistent treatment of NULs in int()

Initial Comment:
In int_new (Objects/intobject.c), embedded NUL chars
are handled differently.

We should check that the entire string is converted
like PyNumber_Int().  int('5\0') raises an exception. 
int('5\0', 10) returns 5.

>>> int('5\0', 10)
5
>>> int('5\0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: null byte in argument for int()

The difference is the explicit vs implicit base.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:28

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 52305, 52306 (2.5).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545497&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 13:41:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 04:41:28 -0700
Subject: [ python-Bugs-1556261 ] Move fpectl elsewhere in library reference
Message-ID: <E1GXywK-00024R-Su@sc8-sf-web3.sourceforge.net>

Bugs item #1556261, was opened at 2006-09-11 10:47
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556261&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
>Assigned to: Georg Brandl (gbrandl)
Summary: Move fpectl elsewhere in library reference

Initial Comment:
The fpectl module is not installed by default, but it
still has a prominent place in the library reference. I
think it should be moved to Optional Operating System
Services and a note added at the top that it is not
installed by default.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:41

Message:
Logged In: YES 
user_id=849994

Added a note in rev. 52307, 52308 (2.5).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556261&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 13:47:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 04:47:13 -0700
Subject: [ python-Bugs-1560114 ] Tutorial: incorrect info about package
	importing and mac
Message-ID: <E1GXz1t-0007Ar-0D@sc8-sf-web2.sourceforge.net>

Bugs item #1560114, was opened at 2006-09-17 12:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560114&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: C L (cl_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial: incorrect info about package importing and mac

Initial Comment:
Section 6.4.1 of the Python tutorial says:
"Now what happens when the user writes from Sound.Effects import *? 
Ideally, one would hope that this somehow goes out to the filesystem, 
finds which submodules are present in the package, and imports them all. 
Unfortunately, this operation does not work very well on Mac and 
Windows platforms, where the filesystem does not always have accurate 
information about the case of a filename! On these platforms, there is no 
guaranteed way to know whether a file ECHO.PY should be imported as a 
module echo, Echo or ECHO."

This is incorrect. It's true that the (default *) Mac file system does not 
allow file names differing only in case in the same directory, and lets you 
access a file by any variation of case; but the file system always records 
and returns the file name with the exact capitalization that was given 
when the name was assigned. In other words, if you create a file called 
"MixedCase.py" you can access it as "mixedcase.py", "MiXeDcAsE.pY" etc., 
but if you list the contents of its parent directory the name will always be 
given as "MixedCase.py".

This has been true of all versions of the Mac OS going back to System 1.0. 
Therefore, none of that paragraph applies to any Mac system; on the 
contrary, the file system always has accurate information about the case 
of a file name. That section of the text should be changed to remove the 
reference to the Mac platform.

(*: recent Mac OS X systems also allow one to use the HFSX filesystem 
variant, which allows file names differing only in case and matches file 
names only when the case is exactly identical - ie, the fully case-sensitive 
Unix semantics. But again, this has no bearing on the ability to reliably 
obtain the exact case of the name of a file.)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:47

Message:
Logged In: YES 
user_id=849994

Removed "Mac and" in rev. 52309, 52310 (2.5).

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 18:25

Message:
Logged In: YES 
user_id=580910

+1 here. MacOS was case-preserving when I started using it (around OS8) and 
that hasn't changed. It also doesn't have the odd behaviour of windows where 
some versions of windows might convert short names to all uppercase.

Hence the Mac shouldn't be mentioned in this section.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560114&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 13:49:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 04:49:25 -0700
Subject: [ python-Bugs-1544295 ] Fix Lib/test/test___all__.py
Message-ID: <E1GXz41-0007i1-H2@sc8-sf-web4.sourceforge.net>

Bugs item #1544295, was opened at 2006-08-22 00:12
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix Lib/test/test___all__.py

Initial Comment:
There's a comment saying:
             # In case _socket fails to build, make
this test fail more gracefully             
             # than an AttributeError somewhere deep in
CGIHTTPServer.

The proposed fix is attached. Applies to revision 51453.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:49

Message:
Logged In: YES 
user_id=849994

The existing code's comment is not a To-Do. It states that
the test will fail clearly at the import of _socket instead
of somewhere in CGIHTTPServer. (closing)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-06 17:38

Message:
Logged In: YES 
user_id=11375

Please explain more clearly what the problem is.  Does the
existing code not work?  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:08:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:08:10 -0700
Subject: [ python-Bugs-1545696 ] structmember T_LONG won't accept a python long
Message-ID: <E1GXzMA-0006CW-IG@sc8-sf-web6.sourceforge.net>

Bugs item #1545696, was opened at 2006-08-24 05:07
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: structmember T_LONG won't accept a python long

Initial Comment:
An attribute defined as T_LONG throws a vague error
when set to a python long, even when the value is 
within the range of a LONG.

TypeError: bad argument type for built-in operation


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-08-30 05:06

Message:
Logged In: YES 
user_id=771074

Submitted patch 1549049.

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-08-28 02:23

Message:
Logged In: YES 
user_id=771074

In the process of creating a patch for this, I came across 
some more 'ugh'-liness.  T_UINT's are returned via 
PyInt_FromLong, so you actually get back a negative value 
for large numbers.  Changing it to use 
PyLong_FromUnsignedLong will break backward compatibility, 
but this is so wrong I can't possibly see keeping it.  Your 
call. (plus it makes it impossible to test T_UINT with 
values larger than INT_MAX)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-25 00:52

Message:
Logged In: YES 
user_id=33168

Ugh.  This code is lax in checking/conversion.  Do you think
you could provide a patch?

All of the int cases should call PyInt_AsLong() if this call
fails (returns -1), then that should be returned from
PyMember_SetOne.  If it succeeds, there should be a range
check that ensures the value is valid.  If that fails a
warning should be produced.  We need to issue a warning
rather than an error for backwards compatability (at least
for 2.6).

The float/double cases can be simplified some by calling
PyFloat_AsDouble and doing similar checks as in the int cases.

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-08-24 19:56

Message:
Logged In: YES 
user_id=771074

The DEVMODE object from pywintypes has attributes defined 
as T_LONG via the structmember API.

>>> import pywintypes
>>> dm=pywintypes.DEVMODEType()
>>> dm.Position_x=3
>>> dm.Position_x
3
>>> dm.Position_x=long(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation
>>>

Here's the relevant code from structmember.c
that throws the error:
	case T_LONG:
		if (!PyInt_Check(v)) {
			PyErr_BadArgument();
			return -1;
		}
		*(long*)addr = PyInt_AsLong(v);
		break;


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 18:30

Message:
Logged In: YES 
user_id=33168

Can you provide example code that demonstrates what you mean?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:10:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:10:33 -0700
Subject: [ python-Bugs-1555842 ] email package and Unicode strings handling
Message-ID: <E1GXzOT-0004vo-2W@sc8-sf-web3.sourceforge.net>

Bugs item #1555842, was opened at 2006-09-10 16:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555842&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Manlio Perillo (manlioperillo)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email package and Unicode strings handling

Initial Comment:
The support for Unicode strings in the email package
(notably MIMEText and Header class) is not uniform.

The behaviour with Unicode strings in Header is
documented but the interface is not good.

This code works, but it should not:

>>> h = Header.Header(u"?????", charset="us-ascii")
>>> m = Message.Message()
>>> m["Subject"] = h
>>> print m.as_string()


Allowing this to work can cause confusion, I'm saying
that the charset is us-ascii, not utf-8.

With MIMEText I obtain:

m = MIMEText.MIMEText(u"?????", _charset="us-ascii")
>>> print m.as_string()

[ exception ]


I think that the correct behaviour (for all functions
accepting strings) is:

- Do not accept plain str strings (8-bit).
  Accept only if they are plain ascii (7-bit).
- The charset specified should not be considered an 
  hint, but the charset I want to be used.



Regards  Manlio Perillo

----------------------------------------------------------------------

Comment By: Manlio Perillo (manlioperillo)
Date: 2006-09-10 17:35

Message:
Logged In: YES 
user_id=1054957

The last example is not right.
Here is the correct one:

 >>> m = MIMEText.MIMEText(u"?????", _charset="utf-8")
 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python2.4\lib\email\MIMEText.py", line 28, in
__init__
    self.set_payload(_text, _charset)
  File "C:\Python2.4\lib\email\Message.py", line 218, in
set_payload
    self.set_charset(charset)
  File "C:\Python2.4\lib\email\Message.py", line 260, in
set_charset
    self._payload = charset.body_encode(self._payload)
  File "C:\Python2.4\lib\email\Charset.py", line 366, in
body_encode
    return email.base64MIME.body_encode(s)
  File "C:\Python2.4\lib\email\base64MIME.py", line 136, in
encode
    enc = b2a_base64(s[i:i + max_unencoded])
UnicodeEncodeError: 'ascii' codec can't encode characters in
position 0-2: ordinal not in range(128)


So it seems that email.Message does not handle Unicode strings.

The code works if I set the charset to latin-1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555842&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:15:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:15:31 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GXzTH-0001T3-QB@sc8-sf-web2.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-08 23:37
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Flacy (markaflacy)
>Assigned to: Bob Ippolito (etrepum)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:15:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:15:47 -0700
Subject: [ python-Bugs-1571841 ] email module does not complay with RFC 2046:
	CRLF issue
Message-ID: <E1GXzTX-0001WO-L0@sc8-sf-web5.sourceforge.net>

Bugs item #1571841, was opened at 2006-10-06 01:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571841&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andy Leszczynski (andrzejl)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email module does not complay with RFC 2046: CRLF issue

Initial Comment:
According to rfc2046, line breaks in MIME are CRLF.
However python just
uses LF like in the following example:

from email.MIMEMultipart import MIMEMultipart
from email.MIMEText import MIMEText

msg = MIMEMultipart()
msg['Subject'] = 'Our family reunion'
msg['From'] = '... at a.b'
msg['To'] = '... at x.y'
msg.epilogue = ''

msg.attach(MIMEText('aaaaaaaaaaaaaaaaaaaaaaaa'))

print `msg.as_string()`

gives:
'Content-Type: multipart/mixed;
boundary="===============1018679223=="\nMIME-Version:
1.0\nSubject: Our
family reunion\nFrom: a... at a.b\nTo:
c... at x.y\n\n--===============1018679223==\nContent-Type:
text/plain;
charset="us-ascii"\nMIME-Version:
1.0\nContent-Transfer-Encoding:
7bit\n\naaaaaaaaaaaaaaaaaaaaaaaa\n--===============1018679223==--\n'


Found in version 2.3 and 2.4 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571841&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:15:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:15:59 -0700
Subject: [ python-Bugs-1572084 ] .eml attachments in email
Message-ID: <E1GXzTj-0006vB-BY@sc8-sf-web6.sourceforge.net>

Bugs item #1572084, was opened at 2006-10-06 12:23
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: rainwolf8472 (rainwolf8472)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: .eml attachments in email

Initial Comment:
I think there's a bug somewhere in the email package. 
I wanted to write a 
script to send emails with certain attachments using
libgmail, and found 
this one, http://pramode.net/articles/lfy/fuse/4.txt ,
it works fine with 
most files, but it fails with .eml files, and what i
can't understand is 
that if I change the extension of those .eml files to
.txt, the script works 
fine.  However, when trying to mail a simple textfile
containing "hello", en 
changing the extension to .eml before sending, it fails
again. it doesn't 
fail when I don't change the extension to .eml.
Any help please? I pasted the output I get (over and
over again) in the attached textfile.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:29:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:29:38 -0700
Subject: [ python-Bugs-1049615 ] smeared title when installing
Message-ID: <E1GXzgw-0008I7-NY@sc8-sf-web6.sourceforge.net>

Bugs item #1049615, was opened at 2004-10-18 22:09
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1049615&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: smeared title when installing

Initial Comment:
Python 2.4b1 on Windows XP.  1280x800.

The "python: for windows" heading looks smeared.

Other graphical elements also look somewhat 
smeared, but it isn't as much of a problem when it 
isn't text to begin with.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 12:29

Message:
Logged In: YES 
user_id=849994

The PC build now has entirely different icons, using the new
Python.org style. Closing this.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-10-20 06:35

Message:
Logged In: YES 
user_id=21627

Scratch the remark on PCbuild/installer.bmp. I somehow
thought that 1.2.18.2 has a different resolution than the
HEAD version, which it doesn't. I don't understand the
phrase "highest-level source". If you are asking whether
this is the primary source: for us, it is. Erik van Blokland
has some mechanism to generate that, but we don't.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-10-20 06:32

Message:
Logged In: YES 
user_id=21627

We would need to ask the original author of that picture. I
have not been able to contact him; please try yourself.

Using PCbuild/installer.bmp might indeed be an option. I
could try to arrange the dialogs so that it won't need scaling.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-10-20 00:23

Message:
Logged In: YES 
user_id=764593

Would it be possible to recreate the original picture (or at 
least parts of it) at the full size, instead of stretching?  If the 
picture parts have to be stretched, that isn't such a 
problem, but it is better if the button frames aren't 
stretched -- and particularly the text.

Even just replacing the "windows: python" with blank space 
and text (or redoing that one portion at full size -- maybe 
not aliased?) would help.

Is this the highest-level source?  If so, what size would you 
like it stretched to, and I'll see if I can help.
http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/
python/dist/src/PCbuild/installer.bmp?rev=1.2.18.2

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-10-19 19:30

Message:
Logged In: YES 
user_id=21627

I don't know what to do about this. Any suggestion
appreciated; without suggestions, this likely is what 2.4
will look like.

----------------------------------------------------------------------

Comment By: Mike Brauwerman (brauwerman)
Date: 2004-10-18 23:09

Message:
Logged In: YES 
user_id=71983

The "smearing" is the effect of a small bitmap picture, with
aliased text, blown up (stretched) to fit into a large
space. The graphic has fat pixels, which look a little
funny, but they look better if you squint :-)



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-10-18 22:16

Message:
Logged In: YES 
user_id=764593

I used a .bmp to avoid additional info loss.  Zipped file is 
only 20K, but unzips to over a meg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1049615&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:33:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:33:19 -0700
Subject: [ python-Bugs-1283491 ] nit for builtin sum doc
Message-ID: <E1GXzkV-0008Ie-Ow@sc8-sf-web1.sourceforge.net>

Bugs item #1283491, was opened at 2005-09-07 00:18
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: daishi harada (daishiharada)
>Assigned to: Georg Brandl (gbrandl)
Summary: nit for builtin sum doc

Initial Comment:
the docstring signature for sum in bltinmodule.c
should be changed from:
    sum(sequence, start=0)
to:
    sum(sequence[, start])
to reflect the current implementation in builtin_sum.

(or else the implementation should be changed
to accept kwargs.)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 12:33

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 52315.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-14 20:24

Message:
Logged In: YES 
user_id=1188172

If we change the function signature in the docstring, we
must include the "defaults to 0" somewhere.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-08 02:37

Message:
Logged In: YES 
user_id=80475

"""
>>> sum([x] for x in xrange(10), start=[])
  File "<stdin>", line 1
SyntaxError: invalid syntax

# The problem above is orthogonal to the issue in this bug,
# but I wonder if at some point we'll be able to write such?
"""

FYI, the answer is no.  The requirement for parenthesis
cannot change.  To see why, parse this:  f(g(t) for t in a,
b).    

----------------------------------------------------------------------

Comment By: daishi harada (daishiharada)
Date: 2005-09-07 19:02

Message:
Logged In: YES 
user_id=493197

This is relatively minor so I don't mean
to push particularly hard, but I'd like to
at least show how the docstring made
me stray:

>>> sum([x] for x in xrange(10))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'int' and 'list'
>>> help(sum)
Help on built-in function sum in module __builtin__:

sum(...)
    sum(sequence, start=0) -> value
    
    Returns the sum of a sequence of numbers (NOT strings) plus the value
    of parameter 'start'.  When the sequence is empty, returns start.

>>> sum([x] for x in xrange(10), start=[])
  File "<stdin>", line 1
SyntaxError: invalid syntax

# The problem above is orthogonal to the issue in this bug,
# but I wonder if at some point we'll be able to write such?

>>> sum(([x] for x in xrange(10)), start=[])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: sum() takes no keyword arguments

# examine lib docs, which give the signature:
#   sum(	sequence[, start])

>>> sum(([x] for x in xrange(10)), [])
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> 

# examine bltinmodule.c to confirm that
# sum doesn't accept kwargs.

----------------------------------------------------------------------

Comment By: daishi harada (daishiharada)
Date: 2005-09-07 19:02

Message:
Logged In: YES 
user_id=493197

This is relatively minor so I don't mean
to push particularly hard, but I'd like to
at least show how the docstring made
me stray:

>>> sum([x] for x in xrange(10))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'int' and 'list'
>>> help(sum)
Help on built-in function sum in module __builtin__:

sum(...)
    sum(sequence, start=0) -> value
    
    Returns the sum of a sequence of numbers (NOT strings) plus the value
    of parameter 'start'.  When the sequence is empty, returns start.

>>> sum([x] for x in xrange(10), start=[])
  File "<stdin>", line 1
SyntaxError: invalid syntax

# The problem above is orthogonal to the issue in this bug,
# but I wonder if at some point we'll be able to write such?

>>> sum(([x] for x in xrange(10)), start=[])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: sum() takes no keyword arguments

# examine lib docs, which give the signature:
#   sum(	sequence[, start])

>>> sum(([x] for x in xrange(10)), [])
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> 

# examine bltinmodule.c to confirm that
# sum doesn't accept kwargs.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-07 03:11

Message:
Logged In: YES 
user_id=80475

While the proposed change is technically correct, I find the
original to be more informative.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:40:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:40:20 -0700
Subject: [ python-Feature Requests-1043446 ] Interpreter should be
	interruptable everywhere
Message-ID: <E1GXzrI-0003te-9f@sc8-sf-web2.sourceforge.net>

Feature Requests item #1043446, was opened at 2004-10-09 04:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043446&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Interpreter Core
>Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jp Calderone (kuran)
Assigned to: Raymond Hettinger (rhettinger)
>Summary: Interpreter should be interruptable everywhere

Initial Comment:
import itertools
list(itertools.repeat('x'))

^C will not interrupt this.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 12:40

Message:
Logged In: YES 
user_id=849994

Turning into a feature request.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:15

Message:
Logged In: YES 
user_id=1188172

What to do here?

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-10-15 22:25

Message:
Logged In: YES 
user_id=593130

Killing the interpreter will, of course, interrupt anything ;-).

The ability to ask the interpreter, via an alternate non-code 
communication channel, to stop doing what one just 
requested via the normal code input channel,  is an 
implementation-specific metafeature independent of the 
language definition.  So I see this as a CPython feature-
expansion request rather than a bug report.

If the CPython interpreter documentation promises that ^C 
or whatever will always grab the interpreter's attention, then 
that overpromise is a bug that should be modified.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-10 08:06

Message:
Logged In: YES 
user_id=80475

FWIW, there are many variations of this theme using almost
anything accepting an iterable input (dict.fromkeys, tuple,
set, etc) paired with any long running or infinite iterator
(itertools.count, xrange(sys.maxint), etc).  Even the
tp_print slot can get caught up in emitting oversized output
in a way that is uninterruptable.

I don't see a clean way of teaching all of these functions
to periodically check for signals, and either handle them,
raise an exception or continue.   Fixing this could muck-up
and complicate a bunch of otherwise clean code.  

Still, it would be nice if everything were interruptable. 
I'm just not sure it's worth it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043446&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:40:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:40:36 -0700
Subject: [ python-Feature Requests-231540 ] threads and profiler don't work
	together
Message-ID: <E1GXzrY-0007qx-Vw@sc8-sf-web3.sourceforge.net>

Feature Requests item #231540, was opened at 2001-02-08 15:53
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=231540&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Threads
>Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Dave Brueck (dbrueck)
>Assigned to: Nobody/Anonymous (nobody)
Summary: threads and profiler don't work together

Initial Comment:
When a new thread is created, it doesn't inherit from the parent thread the trace and profile functions (sys_tracefunc and sys_profilefunc in PyThreadState), so multithreaded programs can't easily be profiled. 

This may be by design for safety/complexity sake, but the profiler module should still find some way to function correctly. A temporary (and performance-killing) workaround is to modify the standard profiler to hook into threads to start a new profiler for each new thread, and then merge the stats from a child thread into the parent's when the child thread ends.

Here is sample code that exhibits the problem. Stats are printed only for the main thread because the child thread has no profiling function and therefore collects no stats:

import threading, profile, time

def yo():
    for j in range(5):
        print j,

def go():
    threading.Thread(target=yo).start()
    time.sleep(1)

profile.run('go()')


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 12:40

Message:
Logged In: YES 
user_id=849994

Turning into a feature request.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-10 05:31

Message:
Logged In: YES 
user_id=31435

Reassigned to Fred, our current profiler expert.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 23:57

Message:
Assigned to me but reduced the priority.  I'll take a look at it, but have to suspect it will get reclassified as a Feature Request and moved into PEP 42.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=231540&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:42:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:42:47 -0700
Subject: [ python-Bugs-586700 ] site-packages &amp; build-dir python
Message-ID: <E1GXztf-0004BF-IQ@sc8-sf-web5.sourceforge.net>

Bugs item #586700, was opened at 2002-07-25 20:36
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586700&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: site-packages &amp; build-dir python

Initial Comment:
A Python interpreter running from the build directory
rather than the installation directory should not use
the site-packages or site-python directories.  This is
more important for a debug-build Python than for a
release build.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 12:42

Message:
Logged In: YES 
user_id=849994

As far as I can see, sys.path for ./python in the build-dir
does not include any site-packages entry.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586700&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 14:48:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 05:48:15 -0700
Subject: [ python-Bugs-1534014 ] __name__ doesn't show up in dir() of class
Message-ID: <E1GXzyx-0001N7-5Z@sc8-sf-web1.sourceforge.net>

Bugs item #1534014, was opened at 2006-08-03 17:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534014&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Type/class unification
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 4
Submitted By: Tim Chase (gumnos)
Assigned to: Nobody/Anonymous (nobody)
Summary: __name__ doesn't show up in dir() of class

Initial Comment:
The __name__ attribute doesn't appear in the dir() of a
class, yet is an available attribute.

The below reproduces the problem:

>>> class Foo(object):
	pass
>>> dir(Foo)
['__class__', '__delattr__', '__dict__', '__doc__',
'__getattribute__', '__hash__', '__init__',
'__module__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__str__', '__weakref__']
>>> Foo.__name__
'Foo'

Note that this is different from the attribute
appearing in an *instance* of the class, as in

>>> x = Foo()
>>> '__name__' in dir(x)




----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 12:48

Message:
Logged In: YES 
user_id=849994

Duplicate of #945861.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534014&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 15:01:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 06:01:35 -0700
Subject: [ python-Bugs-1517663 ] Interpreter crash: filter() +
	gc.get_referrers()
Message-ID: <E1GY0Br-0002h1-5v@sc8-sf-web1.sourceforge.net>

Bugs item #1517663, was opened at 2006-07-05 17:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517663&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interpreter crash: filter() + gc.get_referrers()

Initial Comment:
Similar to the bug in tuple() shown in the current
(r47245) version of Lib/test/crashers/gc_inspection.py,
filter() can be exploited in similar ways.

Rather than the tricky generator used to exploit
tuple(), the attached test case uses a subclass of
tuple with a malicious __getitem__ method. The pattern
being exploited is the same, however: a built-in
function pre-allocates a tuple, then fills it using
calls to user-defined code.

gc_inspection.py.diff also expands the infrastructure
in gc_inspection.py, allowing multiple test functions
to run that could crash the interpreter.

The second patch, fix_filter_crash.patch, is against
Python/bltinmodule.c and adds
_PyObject_GC_TRACK/UNTRACK macros around the call to
the type's sq_item slot in filtertuple().

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 13:01

Message:
Logged In: YES 
user_id=849994

I will not disagree with Raymond :)

Furthermore, with your patch to gc_inspection.py, it doesn't
even crash anymore (without the other patch applied).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 18:01

Message:
Logged In: YES 
user_id=80475

FWIW, I think these safe-cracking style efforts at 
creating crashers is a waste of time.  Please focus your 
efforts on fixing real bugs that matter, not in creating 
strange self-referential twists designed to poke holes in 
specific implementation details.  There is no end to the 
kind of things like this that can be found and "fixing" 
them involves either making the code more convoluted or 
making the code slower but it won't make life better for 
most users.  Also, I'm concerned that these "fixes" would 
need to be reviewed with extreme care, lest we introduce 
some new, real bug that DOES impact people's lives.  If 
there were a real problem with filter(), we would have 
known it long ago.

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 17:54

Message:
Logged In: YES 
user_id=1344176

An alternative fix for this would be not to invoke
filter{tuple,string,unicode} on instances of subclasses of
tuple, str and unicode.

This would fix this bug because you have to be using a
subclass of one of these types to exploit the preallocation.

As a side-effect, this would also resolve the issue I raised
in bug #1517509 concerning filter()'s treatment of these
subtypes re: the iterator protocol.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517663&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 15:08:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 06:08:30 -0700
Subject: [ python-Bugs-1560179 ] Better/faster implementation of
	os.path.basename/dirname
Message-ID: <E1GY0IY-0006dY-Q6@sc8-sf-web2.sourceforge.net>

Bugs item #1560179, was opened at 2006-09-17 14:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.basename/dirname

Initial Comment:
hi,

basename/dirname could do better (especially on long 
pathnames)

def basename(p):
    return split(p)[1]

def dirname(p):
    return split(p)[0]

both construct base and dirname and discard the unused 
one.

what about that?

def basename(p):
    i = p.rfind('/') + 1
    return p[i:]

def dirname(p):
    i = p.rfind('/') + 1
    return p[:i]

greets,
michael

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 13:08

Message:
Logged In: YES 
user_id=849994

Committed in rev. 52316.

----------------------------------------------------------------------

Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 12:42

Message:
Logged In: YES 
user_id=1600082

posixpath with this patch passes all test from 
test_posixpath cleanly.

benchmark:
basename( 310 ) means basename called with a 310 chars long 
path

sum = 0.0435626506805 min = 4.19616699219e-05 
posixpath.basename( 310 )
sum = 0.152147769928 min = 0.00014591217041 
posixpath_orig.basename( 310 )

sum = 0.0436658859253 min = 4.07695770264e-05 
posixpath.basename( 106 )
sum = 0.117312431335 min = 0.000112771987915 
posixpath_orig.basename( 106 )

sum = 0.0426909923553 min = 4.07695770264e-05 
posixpath.basename( 21 )
sum = 0.113305330276 min = 0.000110864639282 
posixpath_orig.basename( 21 )

sum = 0.12392115593 min = 0.000121831893921 
posixpath.dirname( 310 )
sum = 0.152860403061 min = 0.00014591217041 
posixpath_orig.dirname( 310 )

sum = 0.0942873954773 min = 9.08374786377e-05 
posixpath.dirname( 106 )
sum = 0.114937067032 min = 0.000111818313599 
posixpath_orig.dirname( 106 )

sum = 0.0918889045715 min = 8.79764556885e-05 
posixpath.dirname( 21 )
sum = 0.114675760269 min = 0.000109910964966 
posixpath_orig.dirname( 21 )

greets

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 16:25:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 07:25:17 -0700
Subject: [ python-Bugs-1575945 ] from_param and _as_parameter_ truncating
	64-bit value
Message-ID: <E1GY1Ur-0005kA-3v@sc8-sf-web2.sourceforge.net>

Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Nobody/Anonymous (nobody)
Summary: from_param and _as_parameter_ truncating 64-bit value

Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.

SConstruct to build library:

env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])

C code:

#include <stdio.h>
void nnz(double *ary) {
    printf("ary = %p\n", (void*)ary);
}

Python code:

import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype  = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)

Output on 32-bit system:

data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8

Output on 64-bit system:

data_as c_void_p(46912559644688)
array interface 0x2aaaae740010
ary = 0x2aaaae740010
ary = 0xae740010
_as_parameter 0x2aaaae740010

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 17:37:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 08:37:27 -0700
Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4
Message-ID: <E1GY2ch-0007R1-Fk@sc8-sf-web6.sourceforge.net>

Bugs item #1086642, was opened at 2004-12-16 12:21
Message generated for change (Comment added) made by amcnabb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Stocker (akosprime)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile of _socket fails on 2.4

Initial Comment:
I'm attempting to install Python 2.4 on an SGI Origin
2400 running Irix 6.5.22.  I'm using gcc (3.3) to
compile, and I've tried using three different make
programs (make, smake, and gmake[3.80]) but get the
same error during compilation during the building of
_socket.  There was not a problem building 2.2.1 on
this machine before, we never built 2.3 so I do not
know if the same problem existed.  Here is the relevant
entry from the make:

building '_socket' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared
-fno-strict-aliasing -I.
-I/usr/local/src/Python-2.4/./Include -I/us
r/local/include -I/usr/local/src/Python-2.4/Include
-I/usr/local/src/Python-2.4 -c
/usr/local/src/Python-2.4/Modules/socke
tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o
In file included from
/usr/local/src/Python-2.4/Modules/socketmodule.c:280:
/usr/local/src/Python-2.4/Modules/addrinfo.h:145:1:
warning: "_SS_ALIGNSIZE" redefined
In file included from
/usr/local/src/Python-2.4/Modules/socketmodule.h:8,
                 from
/usr/local/src/Python-2.4/Modules/socketmodule.c:223:
/usr/include/sys/socket.h:246:1: warning: this is the
location of the previous definition
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `makeipaddr':
/usr/local/src/Python-2.4/Modules/socketmodule.c:853:
warning: implicit declaration of function `getnameinfo'
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: `NI_NUMERICHOST' undeclared (first use in this
function)
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: (Each undeclared identifier is reported only once
/usr/local/src/Python-2.4/Modules/socketmodule.c:854:
error: for each function it appears in.)
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `socket_gethostbyname_ex':
/usr/local/src/Python-2.4/Modules/socketmodule.c:2785:
warning: implicit declaration of function `gethostbyname_r'
/usr/local/src/Python-2.4/Modules/socketmodule.c:2785:
warning: assignment makes pointer from integer without
a cast
/usr/local/src/Python-2.4/Modules/socketmodule.c: In
function `socket_gethostbyaddr':
/usr/local/src/Python-2.4/Modules/socketmodule.c:2880:
warning: implicit declaration of function `gethostbyaddr_r'
/usr/local/src/Python-2.4/Modules/socketmodule.c:2881:
warning: assignment makes pointer from integer without
a cast
building '_ssl' extension


----------------------------------------------------------------------

Comment By: Andrew McNabb (amcnabb)
Date: 2006-10-12 09:37

Message:
Logged In: YES 
user_id=1234027

There IS a specific report.  It won't compile with gcc. 
Either  it needs to be acknowledged that gcc doesn't work
and only allow the IRIX compiler, or else it needs to be
fixed.  There's tons of detail in the many reports in this
thread.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 02:44

Message:
Logged In: YES 
user_id=849994

Is anyone going to do something about this, without a
specific report? Anyway, lowering priority.

----------------------------------------------------------------------

Comment By: Andrew McNabb (amcnabb)
Date: 2006-09-19 15:42

Message:
Logged In: YES 
user_id=1234027

When I use the native IRIX cc to compile socketmodule.c in
Python 2.5, I get:

cc -OPT:Olimit=0 -DNDEBUG -O -I.
-I/auto/fsc/awm27/bzr/Python-2.5/./Include -I/fsc/awm27/i
nclude -I./Include -I. -I/usr/local/include
-I/auto/fsc/awm27/bzr/Python-2.5/Include -I/au
to/fsc/awm27/bzr/Python-2.5 -c
/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c -o bu
ild/temp.irix64-6.5-2.5/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.o
cc-1047 cc: WARNING File = /usr/include/sys/param.h, Line = 372
  Macro "MAX" (declared at line 77 of
         
"/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c") has an
          incompatible redefinition.

  #define MAX(a,b) (((a)>(b))?(a):(b))
          ^


When I commented out the macro definition in socketmodule.c,
I was able to get it to compile (with the IRIX compiler).

It seems to me that --without-gcc should be the default for
IRIX until the gcc problem gets fixed because ./configure is
currently automatically choosing gcc as the compiler when
both are available.  And I'm really not sure why the "#undef
MAX" didn't happen.

Anyway, I hope this is helpful for someone.

----------------------------------------------------------------------

Comment By: Andrew McNabb (amcnabb)
Date: 2006-09-19 15:26

Message:
Logged In: YES 
user_id=1234027

I'm having this same problem with Python 2.5.  I checked,
and "/usr/lib/libmpc.a" is present.  I've only tried with
gcc, and I'm getting the exact same errors as above.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2005-01-11 10:56

Message:
Logged In: YES 
user_id=71407

Before giving up I'd try to reset PATH before running configure 
in the Python directory. I had all kinds of trouble with the 
freeware tools on path. Here is what I use:

/usr/bin /usr/bsd /bin /usr/sbin /sbin /etc /usr/etc /usr/bin/X11

Python 2.4 really works under IRIX, incl. the socket module. I 
have it going on three different machines. On one machine 
the timestamp for libmpc.a is from 1998!


----------------------------------------------------------------------

Comment By: A. Stocker (akosprime)
Date: 2005-01-11 10:43

Message:
Logged In: YES 
user_id=1179755

Ralf,

Strange, I DO have that library:

ls -l /usr/lib/libmpc*
-r--r--r--    1 root     sys         1220 Mar 13  2001
/usr/lib/libmpc.a

It makes no sense to me that the SGI MIPS compilers can't
find a library that's in a default location.  Very peculiar.
 I guess I'm just going to have to give up on getting Python
2.4 working completely under Irix.  We need both network and
_locale to work in order for the various scripts we have in
place to work correctly and I can't get it to compile with gcc.

[*sigh*]

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2005-01-11 10:32

Message:
Logged In: YES 
user_id=71407

You are missing a system library:

/usr/lib/libmpc.a

I've never done anything special to install this library but it is 
available on all three IRIX systems that I have access to.

The library is not used to resolve any symbols. I guess you 
could just remove the -lmpc from the link line.


----------------------------------------------------------------------

Comment By: A. Stocker (akosprime)
Date: 2005-01-11 08:48

Message:
Logged In: YES 
user_id=1179755

Okay, I tried compiling using the Irix Mips compilers.  To
do this I did a ./configure --without-gcc.  However when
attempting to make it errored out.  Here is the last section
of the make output:

        ar cr libpython2.4.a Modules/config.o 
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.4.a Modules/threadmodule.o 
Modules/signalmodule.o  Modules/posixmodule.o 
Modules/errnomodule.o  Modules/_sre.o 
Modules/_codecsmodule.o  Modules/zipimport.o 
Modules/symtablemodule.o  Modules/xxsubtype.o
        : libpython2.4.a
         c++   -o python \
                        Modules/python.o \
                        libpython2.4.a -lsocket -lnsl -ldl 
-lpthread -lmpc   -lm  
ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for
resolving any symbol.
ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for
resolving any symbol.
ld32: WARNING 84 : /usr/lib32/libdl.so is not used for
resolving any symbol.
ld32: FATAL   9  : I/O error (-lmpc): No such file or directory
collect2: ld returned 32 exit status
*** Error code 1 (bu21)

The patch is relatively the same as the hack I tried
earlier, and noted in a follow-up.  But as pointed out
test_socketserver doesn't work ("Use of the `network'
resource not enabled") and _locale doesn't work ("***
WARNING: renaming "_locale" since importing it failed:
1774654:./python: rld: Fatal Error: unresolvable symbol in
build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext")

I'm not sure what else to try in order to get this working.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-30 09:44

Message:
Logged In: YES 
user_id=71407

Some additional observations:

socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after 
applying this simple-minded patch (relative to Python 2.4):

--- socketmodule.c.orig 2004-11-07 06:24:25.000000000 -
0800
+++ socketmodule.c      2004-12-30 08:06:01.896160200 -
0800
@@ -280,6 +280,10 @@
 #  include "addrinfo.h"
 #endif
 
+#if defined(__sgi) && defined(__GNUC__) && !defined
(NI_NUMERICHOST)
+#  define NI_NUMERICHOST 0x00000002
+#endif
+
 #ifndef HAVE_INET_PTON
 int inet_pton(int af, const char *src, void *dst);
 const char *inet_ntop(int af, const void *src, char *dst, 
socklen_t size);


This test works OK:

./python Lib/test/test_socket.py

But this one doesn't:

./python Lib/test/test_socketserver.py


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-30 09:38

Message:
Logged In: YES 
user_id=71407

FWIW: socketmodule.c included in Python 2.3.4 also fails to 
compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's 
freeware distribution.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-12-30 08:28

Message:
Logged In: YES 
user_id=71407

Martin v. Loewis asked me to take a look (because of my 
involvement in http://python.org/sf/728330).

I never use gcc under IRIX. Python 2.4 works just fine with 
the native IRIX compilers.

Suggestion to A. Stocker: try to modify the ifdef's in 
socketmodule.c to do the right thing for gcc 3.3. I can test 
your patch on our machines to make sure compilation with the 
native compilers is still OK.


----------------------------------------------------------------------

Comment By: A. Stocker (akosprime)
Date: 2004-12-22 07:19

Message:
Logged In: YES 
user_id=1179755

All,

I decided to force the issue a bit.  Looking through
socketmodule.c I noticed that there was an SGI specific
check that basically disabled loading the addrinfo.h file,
which is where NI_NUMERICHOST is defined.  So I put the
#define statement from the addrinfo.h file directly in the
socketmodule.c file and the compilation with _socket worked.
 However this seems to be a clunky way to deal with the
situation.  Plus I don't know if there's anything else like
this biting me in the butt (for instance '_locale' doesn't
compile either.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 17:52:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 08:52:37 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GY2rN-0005PN-HJ@sc8-sf-web6.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-09 01:37
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Flacy (markaflacy)
Assigned to: Bob Ippolito (etrepum)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 17:52

Message:
Logged In: YES 
user_id=1326842

WeakValueDictionary would be useless here; the cache is
the only thing that holds references to Struct objects.
Replacing the _cache.clear() call with _cache.popitem()
seems like a better solution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 18:56:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 09:56:25 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GY3r7-0001ve-Nu@sc8-sf-web2.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-08 19:37
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mark Flacy (markaflacy)
Assigned to: Bob Ippolito (etrepum)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 12:56

Message:
Logged In: YES 
user_id=139309

Weakrefs would slow it down.. probably to the point where
the cache wouldn't be an improvement at all.

The re module does the same thing with the regular
expression cache. This isn't a bug until someone presents a
patch that proves another strategy is better for performance.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 11:52

Message:
Logged In: YES 
user_id=1326842

WeakValueDictionary would be useless here; the cache is
the only thing that holds references to Struct objects.
Replacing the _cache.clear() call with _cache.popitem()
seems like a better solution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 19:36:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 10:36:09 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GY4TZ-0003uR-P9@sc8-sf-web5.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-09 01:37
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Flacy (markaflacy)
Assigned to: Bob Ippolito (etrepum)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 19:36

Message:
Logged In: YES 
user_id=1326842

I was thinking abot something like this:

Index: Lib/struct.py
===================================================================
--- Lib/struct.py	(revision 52316)
+++ Lib/struct.py	(working copy)
@@ -35,7 +35,7 @@
 def _compile(fmt):
     # Internal: compile struct pattern
     if len(_cache) >= _MAXCACHE:
-        _cache.clear()
+        _cache.popitem()
     s = Struct(fmt)
     _cache[fmt] = s
     return s

(sorry, I don't have the rights to attach a file)


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 18:56

Message:
Logged In: YES 
user_id=139309

Weakrefs would slow it down.. probably to the point where
the cache wouldn't be an improvement at all.

The re module does the same thing with the regular
expression cache. This isn't a bug until someone presents a
patch that proves another strategy is better for performance.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 17:52

Message:
Logged In: YES 
user_id=1326842

WeakValueDictionary would be useless here; the cache is
the only thing that holds references to Struct objects.
Replacing the _cache.clear() call with _cache.popitem()
seems like a better solution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 19:54:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 10:54:58 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GY4lm-0005Cu-QX@sc8-sf-web4.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-08 19:37
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Flacy (markaflacy)
Assigned to: Bob Ippolito (etrepum)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 13:54

Message:
Logged In: YES 
user_id=139309

Yes, that code is different. You haven't shown that it's
better though. Using popitem probably doesn't have very good
cache effects.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 13:36

Message:
Logged In: YES 
user_id=1326842

I was thinking abot something like this:

Index: Lib/struct.py
===================================================================
--- Lib/struct.py	(revision 52316)
+++ Lib/struct.py	(working copy)
@@ -35,7 +35,7 @@
 def _compile(fmt):
     # Internal: compile struct pattern
     if len(_cache) >= _MAXCACHE:
-        _cache.clear()
+        _cache.popitem()
     s = Struct(fmt)
     _cache[fmt] = s
     return s

(sorry, I don't have the rights to attach a file)


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 12:56

Message:
Logged In: YES 
user_id=139309

Weakrefs would slow it down.. probably to the point where
the cache wouldn't be an improvement at all.

The re module does the same thing with the regular
expression cache. This isn't a bug until someone presents a
patch that proves another strategy is better for performance.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 11:52

Message:
Logged In: YES 
user_id=1326842

WeakValueDictionary would be useless here; the cache is
the only thing that holds references to Struct objects.
Replacing the _cache.clear() call with _cache.popitem()
seems like a better solution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 22:12:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 13:12:25 -0700
Subject: [ python-Bugs-1576174 ] str(WindowsError) wrong
Message-ID: <E1GY6un-0004Mt-3k@sc8-sf-web6.sourceforge.net>

Bugs item #1576174, was opened at 2006-10-12 22:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: str(WindowsError) wrong

Initial Comment:
str(WindowsError(1001, 'a message') in Python 2.5 gives
'[Error 22] a message'.

The attached patch with test fixes this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 22:13:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 13:13:56 -0700
Subject: [ python-Bugs-1576174 ] str(WindowsError) wrong
Message-ID: <E1GY6wG-0008VP-FR@sc8-sf-web2.sourceforge.net>

Bugs item #1576174, was opened at 2006-10-12 22:12
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: str(WindowsError) wrong

Initial Comment:
str(WindowsError(1001, 'a message') in Python 2.5 gives
'[Error 22] a message'.

The attached patch with test fixes this.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-12 22:13

Message:
Logged In: YES 
user_id=11105

See also:
http://mail.python.org/pipermail/python-dev/2006-September/068869.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 23:19:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 14:19:22 -0700
Subject: [ python-Bugs-1576208 ] ConfigParser: whitespace leading comment lines
Message-ID: <E1GY7xa-0007FQ-FN@sc8-sf-web4.sourceforge.net>

Bugs item #1576208, was opened at 2006-10-12 16:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576208&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: gregwillden (gregwillden)
Assigned to: Nobody/Anonymous (nobody)
Summary: ConfigParser: whitespace leading comment lines

Initial Comment:
I'd like to propose the following change to
ConfigParser.py.
This change will enable multiline comments as follows:

[section]
item=value   ;first of multiline comment
            ;second of multiline comment

Right now the behaviour is

In [19]: cfg.get('section','item')
Out[19]: 'value\n;second of multiline comment'

It's a one-line change.
RawConfigParser._read lines 434-437
            # comment or blank line?
-            if line.strip() == '' or line[0] in '#;':
+            if line.strip() == '' or line.strip()[0]
in '#;':
                continue


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576208&group_id=5470

From noreply at sourceforge.net  Thu Oct 12 23:53:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 14:53:43 -0700
Subject: [ python-Bugs-1576174 ] str(WindowsError) wrong
Message-ID: <E1GY8Up-0006oj-3I@sc8-sf-web5.sourceforge.net>

Bugs item #1576174, was opened at 2006-10-12 22:12
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: str(WindowsError) wrong

Initial Comment:
str(WindowsError(1001, 'a message') in Python 2.5 gives
'[Error 22] a message'.

The attached patch with test fixes this.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 23:53

Message:
Logged In: YES 
user_id=1326842

The part of the patch that changes EnvironmentError_str
should be removed (EnvironmentError doesn't have a winerror
member, the change causes compilation errors).  Otherwise
the patch looks fine.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-12 22:13

Message:
Logged In: YES 
user_id=11105

See also:
http://mail.python.org/pipermail/python-dev/2006-September/068869.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 00:24:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 15:24:20 -0700
Subject: [ python-Bugs-1576241 ] functools.wraps fails on builtins
Message-ID: <E1GY8yS-0000TT-6x@sc8-sf-web6.sourceforge.net>

Bugs item #1576241, was opened at 2006-10-12 22:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: kajiuma (kajiuma)
Assigned to: Nobody/Anonymous (nobody)
Summary: functools.wraps fails on builtins

Initial Comment:
functools.wraps assumes that the wrapped function 
has a __dict__ attribute, which is not true for 
builtins.

The attached patch provides an empty dictionaries 
for functions that do not have the required 
attributes. This will cause programs expecting an 
AttributeError (if there are any) to fail.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 00:33:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 15:33:50 -0700
Subject: [ python-Bugs-1576241 ] functools.wraps fails on builtins
Message-ID: <E1GY97e-0005Qs-BJ@sc8-sf-web2.sourceforge.net>

Bugs item #1576241, was opened at 2006-10-12 22:24
Message generated for change (Comment added) made by kajiuma
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: kajiuma (kajiuma)
Assigned to: Nobody/Anonymous (nobody)
Summary: functools.wraps fails on builtins

Initial Comment:
functools.wraps assumes that the wrapped function 
has a __dict__ attribute, which is not true for 
builtins.

The attached patch provides an empty dictionaries 
for functions that do not have the required 
attributes. This will cause programs expecting an 
AttributeError (if there are any) to fail.


----------------------------------------------------------------------

>Comment By: kajiuma (kajiuma)
Date: 2006-10-12 22:33

Message:
Logged In: YES 
user_id=1619773

Looks like lynx cannot send files.
The patch changed: getattr(wrapped, attr)
to: getattr(wrapped, attr, {})
At then end of line 35 of Lib/functools.py


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 04:36:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 19:36:56 -0700
Subject: [ python-Bugs-1576348 ] Example typo in section 4 of 'Installing
	Python Modules'
Message-ID: <E1GYCuu-0006do-7R@sc8-sf-web1.sourceforge.net>

Bugs item #1576348, was opened at 2006-10-13 02:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576348&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: ytrewq1 (ytrewq1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Example typo in section 4 of 'Installing Python Modules'

Initial Comment:
On 2006-10-13, in the docs.python.org version of '4
Custom Installation' of 'Installing Python Modules' (
http://docs.python.org/inst/search-path.html) I see:

python setup.py --install-base=/tmp

It seems to me that that may be missing the mention of
a command -- presumably 'install'.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576348&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 04:57:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 19:57:00 -0700
Subject: [ python-Bugs-1544339 ] _ctypes fails to build on Solaris x86 32-bit
	(Sun compiler)
Message-ID: <E1GYDEK-0001h5-Qv@sc8-sf-web6.sourceforge.net>

Bugs item #1544339, was opened at 2006-08-21 21:28
Message generated for change (Comment added) made by casevh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Case Van Horsen (casevh)
Assigned to: Thomas Heller (theller)
Summary: _ctypes fails to build on Solaris x86 32-bit (Sun compiler)

Initial Comment:
The _ctypes modules fails to compile on Solaris 10 x86
32-bit using the Sun Studio 11 compiler. _ctypes does
compile successfully using gcc. The error messages are
attached. If needed, I can provide access to the machine.


----------------------------------------------------------------------

>Comment By: Case Van Horsen (casevh)
Date: 2006-10-12 19:57

Message:
Logged In: YES 
user_id=1212585

I have tracked down two issues. First Sun's cc compiler does
defines __386 instead of __386__. This causes problems in
ffitarget.h 

Second, Sun's cc compiler fails on the following line in ffi.h:
} ffi_closure __attribute__((aligned (8)));

This is a problem in Sun's cc compiler. It is fixed in the
Sun Studio Express August 2006 release. I don't think there
is a patch for the "official" Sun Studio 11 compiler.

With these two changes, ctypes does compile but "make test"
still fails. I am still researching the "make test" failure.
test_crypt
test_csv
test_ctypes
sh: objdump: not found
*** Signal 11 - core dumped
make: Fatal error: Command failed for target `test'
bash-3.00$





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 07:17:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Oct 2006 22:17:21 -0700
Subject: [ python-Bugs-1576394 ] enable-shared .dso location
Message-ID: <E1GYFQ9-0007tG-Qf@sc8-sf-web5.sourceforge.net>

Bugs item #1576394, was opened at 2006-10-12 22:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: enable-shared .dso location

Initial Comment:
When building on AMD64/FC5 with --enable-shared,
libpython.so is placed in /usr/lib.  Unfortunately,
/usr/lib is not in the shared object search path by
default--/usr/lib64 is used.

I believe that this is a fairly standard linux
configuration for 64bit machines.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 10:40:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Oct 2006 01:40:35 -0700
Subject: [ python-Bugs-1576443 ] cStringIO misbehaving with unicode
Message-ID: <E1GYIap-0001kW-Ko@sc8-sf-web4.sourceforge.net>

Bugs item #1576443, was opened at 2006-10-13 01:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576443&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: cStringIO misbehaving with unicode

Initial Comment:
The bug is the following:

StringIO.StringIO(u'abc').getvalue() !=
cStringIO.StringIO(u'abc').getvalue()

It all started with the following code:

# client.py
 
import cPickle as cp
import xmlrpclib as x
p=x.ServerProxy('http://localhost:8082')
msg=u'abc'
print msg
print len(msg)
p.foo(x.Binary(msg))
 
# client output
 
abc
3
 
# server.py
 
from twisted.web import server, xmlrpc
 
class WikiXmlRpc(xmlrpc.XMLRPC):
    def xmlrpc_foo(self, x):
        print x.data
        print len(x.data)
        return 0
 
if __name__ == "__main__":
    import sys
    from twisted.internet import reactor
    siteRoot = WikiXmlRpc()
    reactor.listenTCP(8082, server.Site(siteRoot))
    reactor.run( )
 
# server output
 
abc
12

I wanted both hosts to agree on the length, so I
started digging to find out what was up. Some time
later....

<alus> zeeeee: you found a bug in xmlrpclib
<alus> zeeeee: it's using cStringIO in a place where it
can't
<alus> odd. cStringIO does not react to unicode in a
sane way
<alus> cStringIO.StringIO(u'abc').getvalue()
<alus> #=> 'a\x00b\x00c\x00'
...
<alus> zeeeee: the heart of the matter is that
StringIO.StringIO(u'abc').getvalue() !=
cStringIO.StringIO(u'abc').getvalue()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576443&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 16:46:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Oct 2006 07:46:35 -0700
Subject: [ python-Bugs-1576598 ] ftplib doesn't follow standard
Message-ID: <E1GYOJ1-0007Ds-F8@sc8-sf-web2.sourceforge.net>

Bugs item #1576598, was opened at 2006-10-13 18:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576598&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Denis S. Otkidach (ods)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib doesn't follow standard

Initial Comment:
According to RFC 959 communication for the exchange of
commands and replies must follow telnet protocol, but
ftplib doesn't. This causes "550 No such file or
directory" replies when path contains '\xFF' character
(which is quite widely used in some languages).

The bug applies to all versions of Python.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576598&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 17:54:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Oct 2006 08:54:09 -0700
Subject: [ python-Bugs-1124861 ] GetStdHandle in interactive GUI
Message-ID: <E1GYPMP-00005E-Jw@sc8-sf-web1.sourceforge.net>

Bugs item #1124861, was opened at 2005-02-17 11:23
Message generated for change (Comment added) made by codecraig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: davids (davidschein)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetStdHandle in interactive GUI

Initial Comment:
Using the suprocess module from with IDLE or PyWindows,
it appears that calls GetStdHandle (STD_<???>_HANDLE)
returns None, which causes an error.  (All appears fine
on Linux, the standard Python command-line, and ipython.)

For example:
>>> import subprocess
>>> p = subprocess.Popen("dir", stdout=subprocess.PIPE)

Traceback (most recent call last):
  File "<pyshell#49>", line 1, in -toplevel-
    p = subprocess.Popen("dir", stdout=subprocess.PIPE)
  File "C:\Python24\lib\subprocess.py", line 545, in
__init__
    (p2cread, p2cwrite,
  File "C:\Python24\lib\subprocess.py", line 605, in
_get_handles
    p2cread = self._make_inheritable(p2cread)
  File "C:\Python24\lib\subprocess.py", line 646, in
_make_inheritable
    DUPLICATE_SAME_ACCESS)
TypeError: an integer is required

The error originates in the mswindows implementation of
_get_handles.  You need to set one of stdin, stdout, or
strerr because the first line in the method is:
if stdin == None and stdout == None and stderr == None:
...return (None, None, None, None, None, None)

I added "if not handle: return GetCurrentProcess()" to
_make_inheritable() as below and it worked.  Of course,
I really do not know what is going on, so I am letting
go now...

def _make_inheritable(self, handle):
..."""Return a duplicate of handle, which is inheritable"""
...if not handle: return GetCurrentProcess()
...return DuplicateHandle(GetCurrentProcess(), handle,
....................................GetCurrentProcess(),
0, 1,
....................................DUPLICATE_SAME_ACCESS)


----------------------------------------------------------------------

Comment By: craig (codecraig)
Date: 2006-10-13 11:54

Message:
Logged In: YES 
user_id=1258995

On windows, this seems to work

from subprocess import *
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)

....in some cases (depending on what command you are
executing, a command prompt window may appear).  Do not show
a window use this...

import win32con
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE,
creationflags=win32con.CREATE_NO_WINDOW)

...google for Microsoft Process Creation Flags for more info

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-09-26 10:53

Message:
Logged In: YES 
user_id=945502

This issue was discussed on comp.lang.python[1] and Roger
Upole suggested:

"""
Basically, gui apps like VS don't have a console, so
GetStdHandle returns 0.   _subprocess.GetStdHandle
returns None if the handle is 0, which gives the original
error.  Pywin32 just returns the 0, so the process gets
one step further but still hits the above error.

Subprocess.py should probably check the
result of GetStdHandle for None (or 0)
and throw a readable error that says something like
"No standard handle available, you must specify one"
"""

[1]http://mail.python.org/pipermail/python-list/2005-September/300744.html

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-08-13 16:37

Message:
Logged In: YES 
user_id=945502

I ran into a similar problem in Ellogon (www.ellogon.org)
which interfaces with Python through tclpython
(http://jfontain.free.fr/tclpython.htm).

My current workaround is to always set all of stdin, stdout,
and stderr to subprocess.PIPE.  I never use the stderr pipe,
but at least this keeps the broken GetStdHandle calls from
happening.

Looking at the code, I kinda think the fix should be::

    if handle is None:
        return handle
    return DuplicateHandle(GetCurrentProcess(), ...

where if handle is None, it stays None.  But I'm also
probably in over my head here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 18:00:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Oct 2006 09:00:54 -0700
Subject: [ python-Bugs-1576657 ] dict keyerror formatting and tuples
Message-ID: <E1GYPSw-0000jO-2I@sc8-sf-web1.sourceforge.net>

Bugs item #1576657, was opened at 2006-10-13 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=105470&aid=1576657&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict keyerror formatting and tuples

Initial Comment:
Probably just a minor glitch, but one which caused me
half an hour to track down:

>>> d = {1:'x'}
>>> v = (1,)
>>> d[v]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 1

Note the formatting of the error message. It reads '1',
not '(1,)' as you would expect.

The example is constructed. In the code I was
debugging, I didn't know that v was a tuple and thought
it was the integer 1 - so the KeyError itself was
somewhat puzzling.

Only after printing the key I found that the lookup
failed due to a type error.

This happens in Python 2.4 and 2.5.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576657&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 20:17:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Oct 2006 11:17:05 -0700
Subject: [ python-Bugs-1576174 ] str(WindowsError) wrong
Message-ID: <E1GYRaj-0000AW-Tf@sc8-sf-web5.sourceforge.net>

Bugs item #1576174, was opened at 2006-10-12 22:12
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: str(WindowsError) wrong

Initial Comment:
str(WindowsError(1001, 'a message') in Python 2.5 gives
'[Error 22] a message'.

The attached patch with test fixes this.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-13 20:17

Message:
Logged In: YES 
user_id=11105

My bad.  I didn't test on Linux.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 23:53

Message:
Logged In: YES 
user_id=1326842

The part of the patch that changes EnvironmentError_str
should be removed (EnvironmentError doesn't have a winerror
member, the change causes compilation errors).  Otherwise
the patch looks fine.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-12 22:13

Message:
Logged In: YES 
user_id=11105

See also:
http://mail.python.org/pipermail/python-dev/2006-September/068869.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 20:17:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Oct 2006 11:17:52 -0700
Subject: [ python-Bugs-1576174 ] str(WindowsError) wrong
Message-ID: <E1GYRbU-0000Dn-Rr@sc8-sf-web5.sourceforge.net>

Bugs item #1576174, was opened at 2006-10-12 22:12
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: str(WindowsError) wrong

Initial Comment:
str(WindowsError(1001, 'a message') in Python 2.5 gives
'[Error 22] a message'.

The attached patch with test fixes this.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-13 20:17

Message:
Logged In: YES 
user_id=11105

Uploaded a new patch which I actually tested under Linux also.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-13 20:17

Message:
Logged In: YES 
user_id=11105

My bad.  I didn't test on Linux.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 23:53

Message:
Logged In: YES 
user_id=1326842

The part of the patch that changes EnvironmentError_str
should be removed (EnvironmentError doesn't have a winerror
member, the change causes compilation errors).  Otherwise
the patch looks fine.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-12 22:13

Message:
Logged In: YES 
user_id=11105

See also:
http://mail.python.org/pipermail/python-dev/2006-September/068869.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 21:24:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Oct 2006 12:24:46 -0700
Subject: [ python-Bugs-1576443 ] cStringIO misbehaving with unicode
Message-ID: <E1GYSeE-0004Ym-OE@sc8-sf-web1.sourceforge.net>

Bugs item #1576443, was opened at 2006-10-13 08:40
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576443&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: cStringIO misbehaving with unicode

Initial Comment:
The bug is the following:

StringIO.StringIO(u'abc').getvalue() !=
cStringIO.StringIO(u'abc').getvalue()

It all started with the following code:

# client.py
 
import cPickle as cp
import xmlrpclib as x
p=x.ServerProxy('http://localhost:8082')
msg=u'abc'
print msg
print len(msg)
p.foo(x.Binary(msg))
 
# client output
 
abc
3
 
# server.py
 
from twisted.web import server, xmlrpc
 
class WikiXmlRpc(xmlrpc.XMLRPC):
    def xmlrpc_foo(self, x):
        print x.data
        print len(x.data)
        return 0
 
if __name__ == "__main__":
    import sys
    from twisted.internet import reactor
    siteRoot = WikiXmlRpc()
    reactor.listenTCP(8082, server.Site(siteRoot))
    reactor.run( )
 
# server output
 
abc
12

I wanted both hosts to agree on the length, so I
started digging to find out what was up. Some time
later....

<alus> zeeeee: you found a bug in xmlrpclib
<alus> zeeeee: it's using cStringIO in a place where it
can't
<alus> odd. cStringIO does not react to unicode in a
sane way
<alus> cStringIO.StringIO(u'abc').getvalue()
<alus> #=> 'a\x00b\x00c\x00'
...
<alus> zeeeee: the heart of the matter is that
StringIO.StringIO(u'abc').getvalue() !=
cStringIO.StringIO(u'abc').getvalue()

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-13 19:24

Message:
Logged In: YES 
user_id=849994

This was fixed with bug #1548891 a short while ago.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576443&group_id=5470

From noreply at sourceforge.net  Fri Oct 13 23:06:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Oct 2006 14:06:49 -0700
Subject: [ python-Bugs-1576861 ] potential buffer overflow in complexobject.c
Message-ID: <E1GYUEz-0007uP-3c@sc8-sf-web6.sourceforge.net>

Bugs item #1576861, was opened at 2006-10-13 22:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576861&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jochen Voss (jvoss2)
Assigned to: Nobody/Anonymous (nobody)
Summary: potential buffer overflow in complexobject.c

Initial Comment:
python version 2.4.3

Hello,

recently I came across the following bit of code in the
source file Objects/complexobject.c:

static void
complex_to_buf(char *buf, int bufsz, PyComplexObject
*v, int precision)
{
        char format[32];
        if (v->cval.real == 0.) {
                PyOS_snprintf(format, 32, "%%.%ig",
precision);
                PyOS_ascii_formatd(buf, bufsz, format,
v->cval.imag);
                strncat(buf, "j", bufsz);

The strncat statement in the last line is potentially
unsafe: the size argument of strncat determines how
many characters are to be added maxmimally and not how
large the buffer is in total.  Also there needs to be
space for an additional '\0' byte.

This seems currently not exploitable, because the
function 'complex_to_buf' is always called with a large
enough buffer, but it should be fixed any way (for
example to make sure that nobody copies this code for
use in another context).

I hope this helps,
Jochen


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576861&group_id=5470

From noreply at sourceforge.net  Sat Oct 14 09:16:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 00:16:23 -0700
Subject: [ python-Bugs-1576657 ] dict keyerror formatting and tuples
Message-ID: <E1GYdkt-0006pE-W3@sc8-sf-web5.sourceforge.net>

Bugs item #1576657, was opened at 2006-10-13 16:00
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576657&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict keyerror formatting and tuples

Initial Comment:
Probably just a minor glitch, but one which caused me
half an hour to track down:

>>> d = {1:'x'}
>>> v = (1,)
>>> d[v]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 1

Note the formatting of the error message. It reads '1',
not '(1,)' as you would expect.

The example is constructed. In the code I was
debugging, I didn't know that v was a tuple and thought
it was the integer 1 - so the KeyError itself was
somewhat puzzling.

Only after printing the key I found that the lookup
failed due to a type error.

This happens in Python 2.4 and 2.5.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-14 07:16

Message:
Logged In: YES 
user_id=849994

This is because a tuple as exception "argument" is
automatically unpacked as the arguments on NormalizeException.

Attaching patch that wraps all KeyErrors from dictionaries
in a tuple. (There may be other objects and exceptions where
this must be handled)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576657&group_id=5470

From noreply at sourceforge.net  Sat Oct 14 22:06:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 13:06:16 -0700
Subject: [ python-Bugs-1576394 ] enable-shared .dso location
Message-ID: <E1GYplw-0000Ps-EW@sc8-sf-web6.sourceforge.net>

Bugs item #1576394, was opened at 2006-10-13 07:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: enable-shared .dso location

Initial Comment:
When building on AMD64/FC5 with --enable-shared,
libpython.so is placed in /usr/lib.  Unfortunately,
/usr/lib is not in the shared object search path by
default--/usr/lib64 is used.

I believe that this is a fairly standard linux
configuration for 64bit machines.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:06

Message:
Logged In: YES 
user_id=21627

You should configure Python with --libdir=/usr/lib64, then,
right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470

From noreply at sourceforge.net  Sat Oct 14 22:07:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 13:07:20 -0700
Subject: [ python-Bugs-1575945 ] from_param and _as_parameter_ truncating
	64-bit value
Message-ID: <E1GYpmy-0000W3-98@sc8-sf-web6.sourceforge.net>

Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
>Assigned to: Thomas Heller (theller)
Summary: from_param and _as_parameter_ truncating 64-bit value

Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.

SConstruct to build library:

env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])

C code:

#include <stdio.h>
void nnz(double *ary) {
    printf("ary = %p\n", (void*)ary);
}

Python code:

import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype  = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)

Output on 32-bit system:

data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8

Output on 64-bit system:

data_as c_void_p(46912559644688)
array interface 0x2aaaae740010
ary = 0x2aaaae740010
ary = 0xae740010
_as_parameter 0x2aaaae740010

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:07

Message:
Logged In: YES 
user_id=21627

Thomas, can you take a look? If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

From noreply at sourceforge.net  Sat Oct 14 22:13:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 13:13:31 -0700
Subject: [ python-Bugs-1575803 ] Missing notice on environment setting
	LD_LIBRARY_PATH
Message-ID: <E1GYpsx-0005vF-Pq@sc8-sf-web1.sourceforge.net>

Bugs item #1575803, was opened at 2006-10-12 11:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575803&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Anastasios Hatzis (ahatzis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing notice on environment setting LD_LIBRARY_PATH

Initial Comment:
Probably it would be a good idea to provide Linux noobs
like me a short notice in the README that
LD_LIBRARY_PATH needs to be set. It was time-consuming
to find out what caused problems with my installation
although the build process went fine.

I don't know if this is really only necessary if Python
is built from source with the "--enable-shared" option.
If yes, a short notice in this paragraph would be fine:

<snip>
Building a shared libpython
---------------------------

Starting with Python 2.3, the majority of the
interpreter can be built
into a shared library, which can then be used by the
interpreter
executable, and by applications embedding Python. To
enable this feature,
configure with --enable-shared.

If you enable this feature, the same object files will
be used to create
a static library.  In particular, the static library
will contain object
files using position-independent code (PIC) on
platforms where PIC flags
are needed for the shared library.
</snip>

Otherwise, if the setting is necessary whether
"--enable-shared" is turned on or off, a good place
would be right after the "make install" explanations.

Again, this is a Linux rookie issue. But if I want to
install the most recent Python version I can't take any
ready-to-use RPM, so I have to build from sources and
will run into these problems the first time.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:13

Message:
Logged In: YES 
user_id=21627

Yes, setting LD_LIBRARY_PATH may be necessary only when
compiling with --enable-shared. However, it is not mandatory
in this case:
1. if you put the target directory into /etc/ld.so.conf, and
run ldconfig, setting LD_LIBRARY_PATH is not necessary.
2. if you set LD_RUN_PATH during compilation, setting
LD_LIBRARY_PATH is not necessary during run-time.

All of this "standard" Unix know-how; it is better explained
in a Linux book than in the Python README.

Indeed, setting LD_LIBRARY_PATH is bad practice, so the
README should not recommend it.

My recommendation is to not build with --enable-shared at
all. I doubt it has any advantages in your case, but has
disadvantages (as you found).

Closing this as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575803&group_id=5470

From noreply at sourceforge.net  Sat Oct 14 22:17:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 13:17:26 -0700
Subject: [ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows
Message-ID: <E1GYpwk-0006J7-5V@sc8-sf-web1.sourceforge.net>

Bugs item #1568240, was opened at 2006-09-30 11:19
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Christos Georgiou (tzot)
>Assigned to: Martin v. L?wis (loewis)
Summary: Tix is not included in 2.5 for Windows

Initial Comment:
(I hope "Build" is more precise than "Extension
Modules" and "Tkinter" for this specific bug.)

At least the following files are missing from 2.5 for
Windows:

DLLs\tix8184.dll
tcl\tix8184.lib
tcl\tix8.1\*

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470

From noreply at sourceforge.net  Sat Oct 14 22:17:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 13:17:55 -0700
Subject: [ python-Bugs-1567666 ] GetFileAttributesExA and Win95
Message-ID: <E1GYpxD-0007Un-MK@sc8-sf-web5.sourceforge.net>

Bugs item #1567666, was opened at 2006-09-29 14:12
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: giomach (giomach)
>Assigned to: Martin v. L?wis (loewis)
Summary: GetFileAttributesExA and Win95

Initial Comment:
When Python 2.5 is run under Win95 (Windows 
4.00.950B), it immediately fails with "The 
PYTHON25.DLL file is linked to missing export 
KERNEL32.DLL.GetFileAttributesExA".

Python 2.4.3 is fine.

Ciar?n ? Duibh?n.

My e-mail: ciaran at oduibhin.freeserve.co.uk


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470

From noreply at sourceforge.net  Sat Oct 14 22:19:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 13:19:50 -0700
Subject: [ python-Bugs-1565509 ] Repair or Change installation error
Message-ID: <E1GYpz4-0000E2-1V@sc8-sf-web4.sourceforge.net>

Bugs item #1565509, was opened at 2006-09-26 07:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565509&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Hazel (ghazel)
>Assigned to: Martin v. L?wis (loewis)
Summary: Repair or Change installation error

Initial Comment:
When I re-run the Python 2.5 final installer and 
choose either Repair or Change options, it makes it to 
the "Publish product information" step then says:

"A network error occurred while attempting to read 
from the file:

C:\Documents and Settings\username\Desktop\python-2.5
[1].msi"

The thing is, I saved the file as python-2.5.msi and 
the file it mentions does not exist. If I copy python-
2.5.msi to python-2.5[1].msi, then run python-2.5.msi, 
the installation works!

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:19

Message:
Logged In: YES 
user_id=21627

Can you please run the installer with "msiexec /i <filename>
/l*v python.log", and attach a compressed version of
python.log to this report?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565509&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 00:36:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 15:36:01 -0700
Subject: [ python-Bugs-1576394 ] enable-shared .dso location
Message-ID: <E1GYs6r-0005gV-6M@sc8-sf-web4.sourceforge.net>

Bugs item #1576394, was opened at 2006-10-12 22:17
Message generated for change (Comment added) made by mklaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: enable-shared .dso location

Initial Comment:
When building on AMD64/FC5 with --enable-shared,
libpython.so is placed in /usr/lib.  Unfortunately,
/usr/lib is not in the shared object search path by
default--/usr/lib64 is used.

I believe that this is a fairly standard linux
configuration for 64bit machines.

----------------------------------------------------------------------

>Comment By: Mike Klaas (mklaas)
Date: 2006-10-14 15:36

Message:
Logged In: YES 
user_id=1611720

Point.  It is probably unrealistic for the python build to
figure this out automatically.  Thanks.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 13:06

Message:
Logged In: YES 
user_id=21627

You should configure Python with --libdir=/usr/lib64, then,
right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 00:38:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 15:38:56 -0700
Subject: [ python-Feature Requests-1509798 ] replace
	dist/src/Tools/scripts/which.py with tmick's which
Message-ID: <E1GYs9g-00045q-9W@sc8-sf-web2.sourceforge.net>

Feature Requests item #1509798, was opened at 2006-06-21 10:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: wrstl prmpft (wrstlprmpft)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace dist/src/Tools/scripts/which.py with tmick's which

Initial Comment:
see http://starship.python.net/~tmick/#which

The author agrees with me in his README.

Even better: include which as a module in the standard 
library so it can be used programmatically and as::

  python -m which ...

or maybe::

  python -m os.which ...

cheers


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 00:38

Message:
Logged In: YES 
user_id=21627

The URL is now bad... Do you have a current location of the
file?

In any case, we cannot really replace it unless Trent
actively contributes it. So you have to pursudate Trent to
contribute it first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 04:20:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 19:20:05 -0700
Subject: [ python-Bugs-1566719 ] site-packages isn't created before
	install_egg_info
Message-ID: <200610150220.k9F2K5tx008706@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1566719, was opened at 2006-09-27 17:34
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Closed
Resolution: None
Priority: 5
Submitted By: James Oakley (jfunk)
Assigned to: Nobody/Anonymous (nobody)
Summary: site-packages isn't created before install_egg_info

Initial Comment:
install_egg_info is called without creating the site-packages 
directory when only a script is specified. This can break 
RPM builds since the site-packages directory isn't present 
beforehand.

Here's an setup.py that causes this problem::

from distutils.core import setup
setup(name='dot2tex',
      version='1.0.1',
      description = 'A Graphviz to LaTeX converter',
      author = 'Kjell Magne Fauske',
      author_email = 'kjellmf at gmail.com',
      url = "http://www.fauskes.net/code/dot2tex/",
      download_url 
= "http://www.fauskes.net/code/dot2tex/download/",
      scripts=['dot2tex/dot2tex.py']
      )

Here's the build output::

+ python setup.py 
install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES
running install
running build
running build_scripts
running install_scripts
creating /var/tmp/dot2tex-buildroot
creating /var/tmp/dot2tex-buildroot/usr
creating /var/tmp/dot2tex-buildroot/usr/bin
copying 
build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin
changing mode 
of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755
running install_egg_info
Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info
error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: 
No such file or directory


----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-14 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-09-27 20:26

Message:
Logged In: YES 
user_id=21627

How can there not be a site-packages directory? It is
created with the installation of Python itself, so it is
always there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 07:47:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Oct 2006 22:47:58 -0700
Subject: [ python-Bugs-1576394 ] enable-shared .dso location
Message-ID: <E1GYyqs-0008Gh-5B@sc8-sf-web6.sourceforge.net>

Bugs item #1576394, was opened at 2006-10-13 07:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: enable-shared .dso location

Initial Comment:
When building on AMD64/FC5 with --enable-shared,
libpython.so is placed in /usr/lib.  Unfortunately,
/usr/lib is not in the shared object search path by
default--/usr/lib64 is used.

I believe that this is a fairly standard linux
configuration for 64bit machines.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 07:47

Message:
Logged In: YES 
user_id=21627

Ok, closing as "won't fix". It would be possible to
hard-code this into configure, but I'm unsure whether that
would be the right thing to do.

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-15 00:36

Message:
Logged In: YES 
user_id=1611720

Point.  It is probably unrealistic for the python build to
figure this out automatically.  Thanks.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:06

Message:
Logged In: YES 
user_id=21627

You should configure Python with --libdir=/usr/lib64, then,
right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 12:07:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Oct 2006 03:07:40 -0700
Subject: [ python-Bugs-1567666 ] GetFileAttributesExA and Win95
Message-ID: <E1GZ2uC-0008Pa-RW@sc8-sf-web5.sourceforge.net>

Bugs item #1567666, was opened at 2006-09-29 14:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 7
Submitted By: giomach (giomach)
Assigned to: Martin v. L?wis (loewis)
Summary: GetFileAttributesExA and Win95

Initial Comment:
When Python 2.5 is run under Win95 (Windows 
4.00.950B), it immediately fails with "The 
PYTHON25.DLL file is linked to missing export 
KERNEL32.DLL.GetFileAttributesExA".

Python 2.4.3 is fine.

Ciar?n ? Duibh?n.

My e-mail: ciaran at oduibhin.freeserve.co.uk


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 12:07

Message:
Logged In: YES 
user_id=21627

This should now be fixed in r52339 and r52340. I can't test
it on Win95, though, so I created an inofficial, incomplete
installer on 

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13436.msi

Please try it out and report here whether it works.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 15:31:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Oct 2006 06:31:10 -0700
Subject: [ python-Feature Requests-1509798 ] replace
	dist/src/Tools/scripts/which.py with tmick's which
Message-ID: <E1GZ658-0002ja-Lf@sc8-sf-web3.sourceforge.net>

Feature Requests item #1509798, was opened at 2006-06-21 10:47
Message generated for change (Comment added) made by wrstlprmpft
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: wrstl prmpft (wrstlprmpft)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace dist/src/Tools/scripts/which.py with tmick's which

Initial Comment:
see http://starship.python.net/~tmick/#which

The author agrees with me in his README.

Even better: include which as a module in the standard 
library so it can be used programmatically and as::

  python -m which ...

or maybe::

  python -m os.which ...

cheers


----------------------------------------------------------------------

>Comment By: wrstl prmpft (wrstlprmpft)
Date: 2006-10-15 15:31

Message:
Logged In: YES 
user_id=801589

Current location: http://trentm.com/projects/which/

About getting Trent to actively contribute, I'll cite the 
linked page:

  "I also would be happy to have this be a replacement for 
the which.py in the Python CVS tree at dist/src/Tools/
scripts/which.py which is Unix-specific and not usable as a 
module; and perhaps for inclusion in the stdlib."

So I do not think this will be a problem.
(No way of cc:ing someone for sf.net replies? I will try 
contacting him directly, cc:ing you.)

cheers

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 00:38

Message:
Logged In: YES 
user_id=21627

The URL is now bad... Do you have a current location of the
file?

In any case, we cannot really replace it unless Trent
actively contributes it. So you have to pursudate Trent to
contribute it first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 15:46:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Oct 2006 06:46:13 -0700
Subject: [ python-Feature Requests-1509798 ] replace
	dist/src/Tools/scripts/which.py with tmick's which
Message-ID: <E1GZ6Jh-0004CU-K7@sc8-sf-web3.sourceforge.net>

Feature Requests item #1509798, was opened at 2006-06-21 10:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: wrstl prmpft (wrstlprmpft)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace dist/src/Tools/scripts/which.py with tmick's which

Initial Comment:
see http://starship.python.net/~tmick/#which

The author agrees with me in his README.

Even better: include which as a module in the standard 
library so it can be used programmatically and as::

  python -m which ...

or maybe::

  python -m os.which ...

cheers


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 15:46

Message:
Logged In: YES 
user_id=21627

Can you please work with Trent on contributing it? Determine
whether it should be targeted for the standard library or
for Tools/scripts; if for the standard library, somebody
needs to provide documentation and test cases also (and
there should be an API review by potential users).

----------------------------------------------------------------------

Comment By: wrstl prmpft (wrstlprmpft)
Date: 2006-10-15 15:31

Message:
Logged In: YES 
user_id=801589

Current location: http://trentm.com/projects/which/

About getting Trent to actively contribute, I'll cite the 
linked page:

  "I also would be happy to have this be a replacement for 
the which.py in the Python CVS tree at dist/src/Tools/
scripts/which.py which is Unix-specific and not usable as a 
module; and perhaps for inclusion in the stdlib."

So I do not think this will be a problem.
(No way of cc:ing someone for sf.net replies? I will try 
contacting him directly, cc:ing you.)

cheers

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 00:38

Message:
Logged In: YES 
user_id=21627

The URL is now bad... Do you have a current location of the
file?

In any case, we cannot really replace it unless Trent
actively contributes it. So you have to pursudate Trent to
contribute it first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 19:38:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Oct 2006 10:38:42 -0700
Subject: [ python-Bugs-1562092 ] IDLE: Dedent with Italian keyboard
Message-ID: <E1GZ9wg-0000pa-1J@sc8-sf-web6.sourceforge.net>

Bugs item #1562092, was opened at 2006-09-20 07:01
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: neclepsio (neclepsio82)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE: Dedent with Italian keyboard

Initial Comment:
In IDLE, with an Italian keyboard, it's impossible to
dedent the text without using the menu, because the
shortcut Ctrl+] cannot be typed. In fact,  with an
Italian keybaord, the ] is typed with Ctrl+Alt++. While
indent can be achieved with Tab, so that's no problem,
dedent is only accesible from menu: I suggest you to
shortcut it as Shift+Tab too, like many other IDEs.

Thank you
Ignazio

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-10-15 13:38

Message:
Logged In: YES 
user_id=149084

While I agree with your suggestion about Shift+Tab,
in the meantime is it possible for you to create
a custom key assignment in Options / Configure IDLE
and use the Keys tab to re-assign the dedent?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 20:46:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Oct 2006 11:46:50 -0700
Subject: [ python-Bugs-1567666 ] GetFileAttributesExA and Win95
Message-ID: <E1GZB0c-0007Tz-1P@sc8-sf-web6.sourceforge.net>

Bugs item #1567666, was opened at 2006-09-29 12:12
Message generated for change (Comment added) made by giomach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Open
Resolution: Fixed
Priority: 7
Submitted By: giomach (giomach)
Assigned to: Martin v. L?wis (loewis)
Summary: GetFileAttributesExA and Win95

Initial Comment:
When Python 2.5 is run under Win95 (Windows 
4.00.950B), it immediately fails with "The 
PYTHON25.DLL file is linked to missing export 
KERNEL32.DLL.GetFileAttributesExA".

Python 2.4.3 is fine.

Ciar?n ? Duibh?n.

My e-mail: ciaran at oduibhin.freeserve.co.uk


----------------------------------------------------------------------

>Comment By: giomach (giomach)
Date: 2006-10-15 18:46

Message:
Logged In: YES 
user_id=1116705

Thanks, this new installer seems to work under Win95.
Vielen Dank,
Ciar?n ? Duibh?n.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 10:07

Message:
Logged In: YES 
user_id=21627

This should now be fixed in r52339 and r52340. I can't test
it on Win95, though, so I created an inofficial, incomplete
installer on 

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13436.msi

Please try it out and report here whether it works.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470

From noreply at sourceforge.net  Sun Oct 15 22:09:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Oct 2006 13:09:47 -0700
Subject: [ python-Bugs-1567666 ] GetFileAttributesExA and Win95
Message-ID: <E1GZCIt-0002pg-Bi@sc8-sf-web4.sourceforge.net>

Bugs item #1567666, was opened at 2006-09-29 14:12
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: giomach (giomach)
Assigned to: Martin v. L?wis (loewis)
Summary: GetFileAttributesExA and Win95

Initial Comment:
When Python 2.5 is run under Win95 (Windows 
4.00.950B), it immediately fails with "The 
PYTHON25.DLL file is linked to missing export 
KERNEL32.DLL.GetFileAttributesExA".

Python 2.4.3 is fine.

Ciar?n ? Duibh?n.

My e-mail: ciaran at oduibhin.freeserve.co.uk


----------------------------------------------------------------------

Comment By: giomach (giomach)
Date: 2006-10-15 20:46

Message:
Logged In: YES 
user_id=1116705

Thanks, this new installer seems to work under Win95.
Vielen Dank,
Ciar?n ? Duibh?n.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 12:07

Message:
Logged In: YES 
user_id=21627

This should now be fixed in r52339 and r52340. I can't test
it on Win95, though, so I created an inofficial, incomplete
installer on 

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13436.msi

Please try it out and report here whether it works.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470

From noreply at sourceforge.net  Mon Oct 16 17:05:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 08:05:33 -0700
Subject: [ python-Bugs-1575945 ] from_param and _as_parameter_ truncating
	64-bit value
Message-ID: <E1GZU21-0001O4-If@sc8-sf-web5.sourceforge.net>

Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: from_param and _as_parameter_ truncating 64-bit value

Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.

SConstruct to build library:

env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])

C code:

#include <stdio.h>
void nnz(double *ary) {
    printf("ary = %p\n", (void*)ary);
}

Python code:

import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype  = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)

Output on 32-bit system:

data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8

Output on 64-bit system:

data_as c_void_p(46912559644688)
array interface 0x2aaaae740010
ary = 0x2aaaae740010
ary = 0xae740010
_as_parameter 0x2aaaae740010

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-16 17:05

Message:
Logged In: YES 
user_id=11105

This is not a ctypes bug.

It seems that A.ctypes._as_parameter_ is a Python integer. 
These are passed as 'C int' type to foreign function calls.
(The C int type typically has 32 bits on 64-bit platforms,
while a pointer has 64 bit.)

To pass a pointer, A.ctypes._as_parameter_ should be a
ctypes c_void_p instance, not a Python integer.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:07

Message:
Logged In: YES 
user_id=21627

Thomas, can you take a look? If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

From noreply at sourceforge.net  Mon Oct 16 17:21:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 08:21:15 -0700
Subject: [ python-Feature Requests-1578269 ] Add os.link() and os.symlink()
	support for Windows
Message-ID: <E1GZUHD-00042d-NN@sc8-sf-web3.sourceforge.net>

Feature Requests item #1578269, was opened at 2006-10-16 17:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add os.link() and os.symlink() support for Windows

Initial Comment:
NTFS version 5.0 and up has all the needed APIs for
creating hard links and symlinks (junctions), so it
should be possible to add support for both hard links
and symlinks to the posixmodule.

Here are a few references:

http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
(see list of links at the end of the page)

http://www.codeproject.com/w2k/junctionpoints.asp
(junction points only, but includes analysis and source
code)

Note: NTFS 5.0 is supported in Win 2k, XP, 2003 and later.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470

From noreply at sourceforge.net  Mon Oct 16 18:18:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 09:18:17 -0700
Subject: [ python-Bugs-1575945 ] from_param and _as_parameter_ truncating
	64-bit value
Message-ID: <E1GZVAP-0001KX-8P@sc8-sf-web3.sourceforge.net>

Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Comment added) made by albertstrasheim
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: from_param and _as_parameter_ truncating 64-bit value

Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.

SConstruct to build library:

env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])

C code:

#include <stdio.h>
void nnz(double *ary) {
    printf("ary = %p\n", (void*)ary);
}

Python code:

import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype  = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)

Output on 32-bit system:

data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8

Output on 64-bit system:

data_as c_void_p(46912559644688)
array interface 0x2aaaae740010
ary = 0x2aaaae740010
ary = 0xae740010
_as_parameter 0x2aaaae740010

----------------------------------------------------------------------

>Comment By: Albert Strasheim (albertstrasheim)
Date: 2006-10-16 18:18

Message:
Logged In: YES 
user_id=945096

Changing NumPy's _as_parameter_ to return the pointer as a
c_void_p causes ctypes to raise the following erorr:

ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-16 17:05

Message:
Logged In: YES 
user_id=11105

This is not a ctypes bug.

It seems that A.ctypes._as_parameter_ is a Python integer. 
These are passed as 'C int' type to foreign function calls.
(The C int type typically has 32 bits on 64-bit platforms,
while a pointer has 64 bit.)

To pass a pointer, A.ctypes._as_parameter_ should be a
ctypes c_void_p instance, not a Python integer.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:07

Message:
Logged In: YES 
user_id=21627

Thomas, can you take a look? If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

From noreply at sourceforge.net  Mon Oct 16 18:37:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 09:37:09 -0700
Subject: [ python-Feature Requests-1509798 ] replace
	dist/src/Tools/scripts/which.py with tmick's which
Message-ID: <E1GZVSf-0004q0-4Z@sc8-sf-web2.sourceforge.net>

Feature Requests item #1509798, was opened at 2006-06-21 08:47
Message generated for change (Comment added) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: wrstl prmpft (wrstlprmpft)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace dist/src/Tools/scripts/which.py with tmick's which

Initial Comment:
see http://starship.python.net/~tmick/#which

The author agrees with me in his README.

Even better: include which as a module in the standard 
library so it can be used programmatically and as::

  python -m which ...

or maybe::

  python -m os.which ...

cheers


----------------------------------------------------------------------

>Comment By: Trent Mick (tmick)
Date: 2006-10-16 16:37

Message:
Logged In: YES 
user_id=34892

I'm happy to contribute this to the Python core. There are
some TODOs here that I think should be worked through:

http://trentm.com/projects/which/TODO.txt

I'll see if wrstlprmpft and I can get through those. Help
and opinions from others very welcome.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-15 13:46

Message:
Logged In: YES 
user_id=21627

Can you please work with Trent on contributing it? Determine
whether it should be targeted for the standard library or
for Tools/scripts; if for the standard library, somebody
needs to provide documentation and test cases also (and
there should be an API review by potential users).

----------------------------------------------------------------------

Comment By: wrstl prmpft (wrstlprmpft)
Date: 2006-10-15 13:31

Message:
Logged In: YES 
user_id=801589

Current location: http://trentm.com/projects/which/

About getting Trent to actively contribute, I'll cite the 
linked page:

  "I also would be happy to have this be a replacement for 
the which.py in the Python CVS tree at dist/src/Tools/
scripts/which.py which is Unix-specific and not usable as a 
module; and perhaps for inclusion in the stdlib."

So I do not think this will be a problem.
(No way of cc:ing someone for sf.net replies? I will try 
contacting him directly, cc:ing you.)

cheers

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:38

Message:
Logged In: YES 
user_id=21627

The URL is now bad... Do you have a current location of the
file?

In any case, we cannot really replace it unless Trent
actively contributes it. So you have to pursudate Trent to
contribute it first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470

From noreply at sourceforge.net  Mon Oct 16 23:27:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 14:27:58 -0700
Subject: [ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Message-ID: <E1GZa06-0001Gu-Tk@sc8-sf-web2.sourceforge.net>

Bugs item #1578513, was opened at 2006-10-16 17:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: smithj (smithj_rpath)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4c1 will not build when cross compiling

Initial Comment:
When trying to build 2.4.4c1 with cross-compiling, I
get the following 
error.

checking for /dev/ptmx... configure: error: cannot
check for file 
existence when cross compiling

./config.log:configure:20566: checking for /dev/ptmx
./config.log:configure:20572: error: cannot check for
file existence 
when cross compiling

This does not occur with 2.4.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 00:12:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 15:12:42 -0700
Subject: [ python-Feature Requests-1572968 ] release GIL while doing I/O
	operations in the mmap module
Message-ID: <E1GZahO-00028v-1V@sc8-sf-web5.sourceforge.net>

Feature Requests item #1572968, was opened at 2006-10-07 17:26
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572968&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: release GIL while doing I/O operations in the mmap module

Initial Comment:
There is a few system I/O calls in the mmap module that
can take some time. Would be be possible to put
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS around
these to release the GIL and allow other Python threads
to do their work?

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-16 15:12

Message:
Logged In: YES 
user_id=341410

Can you come up with the listing of code blocks where it
would make sense to allow threads, or even provide a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572968&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 00:23:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 15:23:42 -0700
Subject: [ python-Bugs-1560179 ] Better/faster implementation of
	os.path.basename/dirname
Message-ID: <E1GZas2-0003DX-93@sc8-sf-web5.sourceforge.net>

Bugs item #1560179, was opened at 2006-09-17 07:55
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.basename/dirname

Initial Comment:
hi,

basename/dirname could do better (especially on long 
pathnames)

def basename(p):
    return split(p)[1]

def dirname(p):
    return split(p)[0]

both construct base and dirname and discard the unused 
one.

what about that?

def basename(p):
    i = p.rfind('/') + 1
    return p[i:]

def dirname(p):
    i = p.rfind('/') + 1
    return p[:i]

greets,
michael

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-16 15:23

Message:
Logged In: YES 
user_id=341410

I note that in the current SVN, dirname uses a test of "if
head and head != '/'*len(head):" to check for the path being
all /, could be replaced by "if head and head.count('/') !=
len(head):", but it probably isn't terribly important.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 06:08

Message:
Logged In: YES 
user_id=849994

Committed in rev. 52316.

----------------------------------------------------------------------

Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 05:42

Message:
Logged In: YES 
user_id=1600082

posixpath with this patch passes all test from 
test_posixpath cleanly.

benchmark:
basename( 310 ) means basename called with a 310 chars long 
path

sum = 0.0435626506805 min = 4.19616699219e-05 
posixpath.basename( 310 )
sum = 0.152147769928 min = 0.00014591217041 
posixpath_orig.basename( 310 )

sum = 0.0436658859253 min = 4.07695770264e-05 
posixpath.basename( 106 )
sum = 0.117312431335 min = 0.000112771987915 
posixpath_orig.basename( 106 )

sum = 0.0426909923553 min = 4.07695770264e-05 
posixpath.basename( 21 )
sum = 0.113305330276 min = 0.000110864639282 
posixpath_orig.basename( 21 )

sum = 0.12392115593 min = 0.000121831893921 
posixpath.dirname( 310 )
sum = 0.152860403061 min = 0.00014591217041 
posixpath_orig.dirname( 310 )

sum = 0.0942873954773 min = 9.08374786377e-05 
posixpath.dirname( 106 )
sum = 0.114937067032 min = 0.000111818313599 
posixpath_orig.dirname( 106 )

sum = 0.0918889045715 min = 8.79764556885e-05 
posixpath.dirname( 21 )
sum = 0.114675760269 min = 0.000109910964966 
posixpath_orig.dirname( 21 )

greets

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 00:27:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 15:27:11 -0700
Subject: [ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Message-ID: <E1GZavP-0000Hz-Qj@sc8-sf-web6.sourceforge.net>

Bugs item #1578513, was opened at 2006-10-16 16:27
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: smithj (smithj_rpath)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: 2.4.4c1 will not build when cross compiling

Initial Comment:
When trying to build 2.4.4c1 with cross-compiling, I
get the following 
error.

checking for /dev/ptmx... configure: error: cannot
check for file 
existence when cross compiling

./config.log:configure:20566: checking for /dev/ptmx
./config.log:configure:20572: error: cannot check for
file existence 
when cross compiling

This does not occur with 2.4.3.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-10-16 17:27

Message:
Logged In: YES 
user_id=44345

Boosting this and at least provisionally assigning to Anthony since it's related to 
a change between 2.4.3 and 2.4.4c1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 00:41:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 15:41:05 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GZb8r-0006NV-5y@sc8-sf-web4.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-08 16:37
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Flacy (markaflacy)
Assigned to: Bob Ippolito (etrepum)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-16 15:41

Message:
Logged In: YES 
user_id=341410

Add a deque and a bit of logic, and one would get a fifo
implementation of the cache.

from collections import deque
_toss = deque()

def _compile(fmt):
    # Internal: compile struct pattern
    if len(_cache) >= _MAXCACHE:
        del _cache[_toss.popleft()]
    s = Struct(fmt)
    _cache[fmt] = s
    _toss.append(fmt)
    return s

Race conditions from multiple threads could result in
#threads-1 more entries in the cache than _MAXCACHE, but
this could be trimmed in later calls by replacing 'if' with
'while'.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 10:54

Message:
Logged In: YES 
user_id=139309

Yes, that code is different. You haven't shown that it's
better though. Using popitem probably doesn't have very good
cache effects.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 10:36

Message:
Logged In: YES 
user_id=1326842

I was thinking abot something like this:

Index: Lib/struct.py
===================================================================
--- Lib/struct.py	(revision 52316)
+++ Lib/struct.py	(working copy)
@@ -35,7 +35,7 @@
 def _compile(fmt):
     # Internal: compile struct pattern
     if len(_cache) >= _MAXCACHE:
-        _cache.clear()
+        _cache.popitem()
     s = Struct(fmt)
     _cache[fmt] = s
     return s

(sorry, I don't have the rights to attach a file)


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 09:56

Message:
Logged In: YES 
user_id=139309

Weakrefs would slow it down.. probably to the point where
the cache wouldn't be an improvement at all.

The re module does the same thing with the regular
expression cache. This isn't a bug until someone presents a
patch that proves another strategy is better for performance.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 08:52

Message:
Logged In: YES 
user_id=1326842

WeakValueDictionary would be useless here; the cache is
the only thing that holds references to Struct objects.
Replacing the _cache.clear() call with _cache.popitem()
seems like a better solution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 01:57:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 16:57:09 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GZcKT-00050J-Oq@sc8-sf-web3.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-08 19:37
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Flacy (markaflacy)
Assigned to: Bob Ippolito (etrepum)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-10-16 19:57

Message:
Logged In: YES 
user_id=139309

The flush strategy is a silly thing to rattle on about.

The idea is just to pick a cache size that's big enough that
any sane application will never have to flush it. The
current cache size is plenty big enough for anything I threw
at it. If there's an application out there that needs a
bigger cache I'd like to see it, and then perhaps we could
adjust the size in some minor release to accommodate it.

A FIFO is probably a bad strategy because there are a lot of
common structs that are used a lot (the ones with just a few
characters).

If there was an obviously better solution here, surely it
would have already been proposed or implemented for the re
module.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-16 18:41

Message:
Logged In: YES 
user_id=341410

Add a deque and a bit of logic, and one would get a fifo
implementation of the cache.

from collections import deque
_toss = deque()

def _compile(fmt):
    # Internal: compile struct pattern
    if len(_cache) >= _MAXCACHE:
        del _cache[_toss.popleft()]
    s = Struct(fmt)
    _cache[fmt] = s
    _toss.append(fmt)
    return s

Race conditions from multiple threads could result in
#threads-1 more entries in the cache than _MAXCACHE, but
this could be trimmed in later calls by replacing 'if' with
'while'.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 13:54

Message:
Logged In: YES 
user_id=139309

Yes, that code is different. You haven't shown that it's
better though. Using popitem probably doesn't have very good
cache effects.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 13:36

Message:
Logged In: YES 
user_id=1326842

I was thinking abot something like this:

Index: Lib/struct.py
===================================================================
--- Lib/struct.py	(revision 52316)
+++ Lib/struct.py	(working copy)
@@ -35,7 +35,7 @@
 def _compile(fmt):
     # Internal: compile struct pattern
     if len(_cache) >= _MAXCACHE:
-        _cache.clear()
+        _cache.popitem()
     s = Struct(fmt)
     _cache[fmt] = s
     return s

(sorry, I don't have the rights to attach a file)


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 12:56

Message:
Logged In: YES 
user_id=139309

Weakrefs would slow it down.. probably to the point where
the cache wouldn't be an improvement at all.

The re module does the same thing with the regular
expression cache. This isn't a bug until someone presents a
patch that proves another strategy is better for performance.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 11:52

Message:
Logged In: YES 
user_id=1326842

WeakValueDictionary would be useless here; the cache is
the only thing that holds references to Struct objects.
Replacing the _cache.clear() call with _cache.popitem()
seems like a better solution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 02:08:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 17:08:15 -0700
Subject: [ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Message-ID: <E1GZcVD-0004zq-7I@sc8-sf-web5.sourceforge.net>

Bugs item #1573394, was opened at 2006-10-08 16:37
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Flacy (markaflacy)
Assigned to: Bob Ippolito (etrepum)
Summary: struct module doesn't use weakref for cache

Initial Comment:
At the moment, when you attempt to add your 101st
different Struct object to the cache, all the other 100
entries are tossed into the garbage.  That seems a
trifle odd.

The Struct cache would appear to be a perfect use for a
weakref dictionary.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-16 17:08

Message:
Logged In: YES 
user_id=341410

I agree, just pointing out that there exists a cache
replacement strategy.  Also, there is an LRU implementation
in the Python cookbook, but unless it is rewritten in C (a
serious overkill for the 2? uses in the stdlib), it would
necessitate a lock, which would be a waste.  But we've
talked enough, and I probably shouldn't have bothered
posting *this* message.  I'll let the thread die this time,
really!

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-16 16:57

Message:
Logged In: YES 
user_id=139309

The flush strategy is a silly thing to rattle on about.

The idea is just to pick a cache size that's big enough that
any sane application will never have to flush it. The
current cache size is plenty big enough for anything I threw
at it. If there's an application out there that needs a
bigger cache I'd like to see it, and then perhaps we could
adjust the size in some minor release to accommodate it.

A FIFO is probably a bad strategy because there are a lot of
common structs that are used a lot (the ones with just a few
characters).

If there was an obviously better solution here, surely it
would have already been proposed or implemented for the re
module.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-16 15:41

Message:
Logged In: YES 
user_id=341410

Add a deque and a bit of logic, and one would get a fifo
implementation of the cache.

from collections import deque
_toss = deque()

def _compile(fmt):
    # Internal: compile struct pattern
    if len(_cache) >= _MAXCACHE:
        del _cache[_toss.popleft()]
    s = Struct(fmt)
    _cache[fmt] = s
    _toss.append(fmt)
    return s

Race conditions from multiple threads could result in
#threads-1 more entries in the cache than _MAXCACHE, but
this could be trimmed in later calls by replacing 'if' with
'while'.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 10:54

Message:
Logged In: YES 
user_id=139309

Yes, that code is different. You haven't shown that it's
better though. Using popitem probably doesn't have very good
cache effects.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 10:36

Message:
Logged In: YES 
user_id=1326842

I was thinking abot something like this:

Index: Lib/struct.py
===================================================================
--- Lib/struct.py	(revision 52316)
+++ Lib/struct.py	(working copy)
@@ -35,7 +35,7 @@
 def _compile(fmt):
     # Internal: compile struct pattern
     if len(_cache) >= _MAXCACHE:
-        _cache.clear()
+        _cache.popitem()
     s = Struct(fmt)
     _cache[fmt] = s
     return s

(sorry, I don't have the rights to attach a file)


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-10-12 09:56

Message:
Logged In: YES 
user_id=139309

Weakrefs would slow it down.. probably to the point where
the cache wouldn't be an improvement at all.

The re module does the same thing with the regular
expression cache. This isn't a bug until someone presents a
patch that proves another strategy is better for performance.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 08:52

Message:
Logged In: YES 
user_id=1326842

WeakValueDictionary would be useless here; the cache is
the only thing that holds references to Struct objects.
Replacing the _cache.clear() call with _cache.popitem()
seems like a better solution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 07:32:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Oct 2006 22:32:12 -0700
Subject: [ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump
Message-ID: <E1GZhYi-0006Km-Pa@sc8-sf-web4.sourceforge.net>

Bugs item #1558223, was opened at 2006-09-14 00:05
Message generated for change (Comment added) made by thurnerrupert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: 3rd Party
Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: ThurnerRupert (thurnerrupert)
Assigned to: Nobody/Anonymous (nobody)
Summary: apache2 - mod_python - python2.4 core dump

Initial Comment:
$ gdb bin/httpd
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) core core
Core was generated by `/usr/local/bin/httpd -k restart'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libssl.so.0.9.8...done.
Loaded symbols for /usr/local/lib/libssl.so.0.9.8
<... deleted the whole loaded libraries>

#0  0xfebb3218 in strlen () from /usr/lib/libc.so.1

(gdb) bt

#0  0xfebb3218 in strlen () from /usr/lib/libc.so.1
#1  0xfda6ac4c in PyString_FromString (
    str=0xfef65ec0 "unexpected parser state - please
send a bug report")
    at Objects/stringobject.c:106
#2  0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0,
    name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE",
value=0x0)
    at Python/modsupport.c:589
#3  0xfe57cec4 in initpyexpat ()
    at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973

this happens when running moinmoin 1.5.4, and doing a
gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8,
compile with gcc-3.4.6.



----------------------------------------------------------------------

>Comment By: ThurnerRupert (thurnerrupert)
Date: 2006-10-17 07:32

Message:
Logged In: YES 
user_id=1597584

thanks a lot, zseil!

with python-2.5 it works, so marking as duplicate of
http://www.python.org/sf/1295808.



----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-04 00:47

Message:
Logged In: YES 
user_id=1326842

This looks like another problem with pyexpat getting
the export symbols from an older expat version.  See:
http://www.python.org/sf/1295808 and
http://www.python.org/sf/1075984
for details.


----------------------------------------------------------------------

Comment By: ThurnerRupert (thurnerrupert)
Date: 2006-10-03 23:54

Message:
Logged In: YES 
user_id=1597584

ok ... i will.

we noticed similar errors when running:
 * edgewall trac 0.11-dev (which uses edgewall ghenshi)
 * xml-rpc plugin for edgewall trac

also, i filed the bug report after changing to newest 
mod_python. the old mod_python with apache 2.0.54 did not 
give a core, just segfaulted.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-14 05:34

Message:
Logged In: YES 
user_id=33168

Please file this bug report with mod_python.  That's
typically the cause and it will likely be very hard for any
Python developer to create this setup and much less try to
reproduce the error.

If you can provoke the same error without mod_python or
other third party C extensions, please file a bug report
with the minimal test case to reproduce.

If you need a work-around, I would suggest changing to a
different version of mod_python.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 14:50:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 05:50:38 -0700
Subject: [ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Message-ID: <E1GZoP0-0001Xw-Q2@sc8-sf-web2.sourceforge.net>

Bugs item #1578513, was opened at 2006-10-17 07:27
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: smithj (smithj_rpath)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: 2.4.4c1 will not build when cross compiling

Initial Comment:
When trying to build 2.4.4c1 with cross-compiling, I
get the following 
error.

checking for /dev/ptmx... configure: error: cannot
check for file 
existence when cross compiling

./config.log:configure:20566: checking for /dev/ptmx
./config.log:configure:20572: error: cannot check for
file existence 
when cross compiling

This does not occur with 2.4.3.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 22:50

Message:
Logged In: YES 
user_id=29957

Goody - autoconf debugging, my absolute favourite!

r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon,
31 Jul 2006) | 3 lines

Drop usage of test -e in configure as it is not portable.
Fixes #1439538



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-10-17 08:27

Message:
Logged In: YES 
user_id=44345

Boosting this and at least provisionally assigning to Anthony since it's related to 
a change between 2.4.3 and 2.4.4c1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 15:21:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 06:21:34 -0700
Subject: [ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Message-ID: <E1GZosw-0004Z6-74@sc8-sf-web2.sourceforge.net>

Bugs item #1578513, was opened at 2006-10-17 07:27
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 9
Submitted By: smithj (smithj_rpath)
>Assigned to: Martin v. L?wis (loewis)
Summary: 2.4.4c1 will not build when cross compiling

Initial Comment:
When trying to build 2.4.4c1 with cross-compiling, I
get the following 
error.

checking for /dev/ptmx... configure: error: cannot
check for file 
existence when cross compiling

./config.log:configure:20566: checking for /dev/ptmx
./config.log:configure:20572: error: cannot check for
file existence 
when cross compiling

This does not occur with 2.4.3.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 23:21

Message:
Logged In: YES 
user_id=29957

Ok, this revision is definitely the problem - it switched
from using our own test to autoconf's AC_CHECK_FILE. This
breaks things. Yay. :-/

Looking closer - we used to use our own test -e check.
autoconf uses test -r. The attached patch reverses that fix,
and changes back to our own test, using test -r instead.

Can you please test this? Martin, can you check this out? I
had to hand-edit the patch, because autoconf on this box
spat out a vast number of extra pointless changes. 


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 22:50

Message:
Logged In: YES 
user_id=29957

Goody - autoconf debugging, my absolute favourite!

r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon,
31 Jul 2006) | 3 lines

Drop usage of test -e in configure as it is not portable.
Fixes #1439538



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-10-17 08:27

Message:
Logged In: YES 
user_id=44345

Boosting this and at least provisionally assigning to Anthony since it's related to 
a change between 2.4.3 and 2.4.4c1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 16:38:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 07:38:48 -0700
Subject: [ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Message-ID: <E1GZq5g-0000Sv-UZ@sc8-sf-web3.sourceforge.net>

Bugs item #1578513, was opened at 2006-10-16 17:27
Message generated for change (Comment added) made by smithj_rpath
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 9
Submitted By: smithj (smithj_rpath)
Assigned to: Martin v. L?wis (loewis)
Summary: 2.4.4c1 will not build when cross compiling

Initial Comment:
When trying to build 2.4.4c1 with cross-compiling, I
get the following 
error.

checking for /dev/ptmx... configure: error: cannot
check for file 
existence when cross compiling

./config.log:configure:20566: checking for /dev/ptmx
./config.log:configure:20572: error: cannot check for
file existence 
when cross compiling

This does not occur with 2.4.3.

----------------------------------------------------------------------

>Comment By: smithj (smithj_rpath)
Date: 2006-10-17 10:38

Message:
Logged In: YES 
user_id=1622486

Yes, that patch does fix the issue. Thank you.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 09:21

Message:
Logged In: YES 
user_id=29957

Ok, this revision is definitely the problem - it switched
from using our own test to autoconf's AC_CHECK_FILE. This
breaks things. Yay. :-/

Looking closer - we used to use our own test -e check.
autoconf uses test -r. The attached patch reverses that fix,
and changes back to our own test, using test -r instead.

Can you please test this? Martin, can you check this out? I
had to hand-edit the patch, because autoconf on this box
spat out a vast number of extra pointless changes. 


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 08:50

Message:
Logged In: YES 
user_id=29957

Goody - autoconf debugging, my absolute favourite!

r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon,
31 Jul 2006) | 3 lines

Drop usage of test -e in configure as it is not portable.
Fixes #1439538



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-10-16 18:27

Message:
Logged In: YES 
user_id=44345

Boosting this and at least provisionally assigning to Anthony since it's related to 
a change between 2.4.3 and 2.4.4c1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 17:03:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 08:03:55 -0700
Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not
	work
Message-ID: <E1GZqTz-0007xx-Hh@sc8-sf-web1.sourceforge.net>

Bugs item #1579029, was opened at 2006-10-17 17:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: ThurnerRupert (thurnerrupert)
Assigned to: Martin v. L?wis (loewis)
Summary: --disable-sunaudiodev --disable-tk does not work

Initial Comment:
trying to disable sunaudiodev and tk does not really 
work in solaris.

./configure --prefix=/usr/local/Python-2.5 --enable-
shared --disable-sunaudiodev --disable-tk

building 'sunaudiodev' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I/usr/local/Python-
2.5/./Include -I/cs/ecms/2.0.0/include -I./Include -
I. -I/usr/local/include -I/usr/local/Python-
2.5/Include -I/usr/local/Python-2.5 -
c /usr/local/Python-2.5/Modules/sunaudiodev.c -o 
build/temp.solaris-2.8-sun4u-2.5/usr/local/Python-
2.5/Modules/sunaudiodev.o
/usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: 
sun/audioio.h: No such file or directory

building '_tkinter' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -DWITH_APPINIT=1 -
I/usr/openwin/include -I. -I/usr/local/Python-
2.5/./Include -I/cs/ecms/2.0.0/include -I./Include -
I. -I/usr/local/include -I/usr/local/Python-
2.5/Include -I/usr/local/Python-2.5 -
c /usr/local/Python-2.5/Modules/_tkinter.c -o 
build/temp.solaris-2.8-sun4u-2.5/usr/local/Python-
2.5/Modules/_tkinter.o
In file included from /usr/local/Python-
2.5/Modules/_tkinter.c:67:
/usr/local/include/tk.h:96:23: X11/Xlib.h: No such 
file or directory
In file included from /usr/local/Python-
2.5/Modules/_tkinter.c:67:
/usr/local/include/tk.h:572: error: syntax error 
before "Window"
/usr/local/include/tk.h:572: error: `Window' declared 
as function returning a function
/usr/local/include/tk.h:575: error: syntax error 
before "XEvent"
/usr/local/include/tk.h:584: error: syntax error 
before "Tk_ClassCreateProc"
/usr/local/include/tk.h:592: error: syntax error 
before '}' token
/usr/local/include/tk.h:678: error: syntax error 
before "Bool"

is it possible to correct this or state clearly in 
the configure options how to disable it correctly?

we also checked the Modules/Setup and both seems 
commented.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 17:37:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 08:37:56 -0700
Subject: [ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Message-ID: <E1GZr0u-00061e-2B@sc8-sf-web5.sourceforge.net>

Bugs item #1578513, was opened at 2006-10-16 23:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 9
Submitted By: smithj (smithj_rpath)
Assigned to: Martin v. L?wis (loewis)
Summary: 2.4.4c1 will not build when cross compiling

Initial Comment:
When trying to build 2.4.4c1 with cross-compiling, I
get the following 
error.

checking for /dev/ptmx... configure: error: cannot
check for file 
existence when cross compiling

./config.log:configure:20566: checking for /dev/ptmx
./config.log:configure:20572: error: cannot check for
file existence 
when cross compiling

This does not occur with 2.4.3.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-17 17:37

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. Of course, the check result is
still bogus for cross-compilation (so it doesn't, and really
can't, "work"), as we cannot know whether /dev/something
exists on the target machine.

As for regenerating configure: it should work fine if you
install a stock autoconf 2.59 (I typically have one in
~/ac259). If you happen to use a Debian-or-Redhat-modified
one, regeneration will often include unrelated changes.

As there really isn't a better way to deal with it, this
should then also be forward-ported to 2.5 and 2.6.

----------------------------------------------------------------------

Comment By: smithj (smithj_rpath)
Date: 2006-10-17 16:38

Message:
Logged In: YES 
user_id=1622486

Yes, that patch does fix the issue. Thank you.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 15:21

Message:
Logged In: YES 
user_id=29957

Ok, this revision is definitely the problem - it switched
from using our own test to autoconf's AC_CHECK_FILE. This
breaks things. Yay. :-/

Looking closer - we used to use our own test -e check.
autoconf uses test -r. The attached patch reverses that fix,
and changes back to our own test, using test -r instead.

Can you please test this? Martin, can you check this out? I
had to hand-edit the patch, because autoconf on this box
spat out a vast number of extra pointless changes. 


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 14:50

Message:
Logged In: YES 
user_id=29957

Goody - autoconf debugging, my absolute favourite!

r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon,
31 Jul 2006) | 3 lines

Drop usage of test -e in configure as it is not portable.
Fixes #1439538



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-10-17 00:27

Message:
Logged In: YES 
user_id=44345

Boosting this and at least provisionally assigning to Anthony since it's related to 
a change between 2.4.3 and 2.4.4c1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 17:43:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 08:43:44 -0700
Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not
	work
Message-ID: <E1GZr6W-0003fH-M4@sc8-sf-web4.sourceforge.net>

Bugs item #1579029, was opened at 2006-10-17 17:03
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: ThurnerRupert (thurnerrupert)
Assigned to: Martin v. L?wis (loewis)
Summary: --disable-sunaudiodev --disable-tk does not work

Initial Comment:
trying to disable sunaudiodev and tk does not really 
work in solaris.

./configure --prefix=/usr/local/Python-2.5 --enable-
shared --disable-sunaudiodev --disable-tk

building 'sunaudiodev' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I/usr/local/Python-
2.5/./Include -I/cs/ecms/2.0.0/include -I./Include -
I. -I/usr/local/include -I/usr/local/Python-
2.5/Include -I/usr/local/Python-2.5 -
c /usr/local/Python-2.5/Modules/sunaudiodev.c -o 
build/temp.solaris-2.8-sun4u-2.5/usr/local/Python-
2.5/Modules/sunaudiodev.o
/usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: 
sun/audioio.h: No such file or directory

building '_tkinter' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -DWITH_APPINIT=1 -
I/usr/openwin/include -I. -I/usr/local/Python-
2.5/./Include -I/cs/ecms/2.0.0/include -I./Include -
I. -I/usr/local/include -I/usr/local/Python-
2.5/Include -I/usr/local/Python-2.5 -
c /usr/local/Python-2.5/Modules/_tkinter.c -o 
build/temp.solaris-2.8-sun4u-2.5/usr/local/Python-
2.5/Modules/_tkinter.o
In file included from /usr/local/Python-
2.5/Modules/_tkinter.c:67:
/usr/local/include/tk.h:96:23: X11/Xlib.h: No such 
file or directory
In file included from /usr/local/Python-
2.5/Modules/_tkinter.c:67:
/usr/local/include/tk.h:572: error: syntax error 
before "Window"
/usr/local/include/tk.h:572: error: `Window' declared 
as function returning a function
/usr/local/include/tk.h:575: error: syntax error 
before "XEvent"
/usr/local/include/tk.h:584: error: syntax error 
before "Tk_ClassCreateProc"
/usr/local/include/tk.h:592: error: syntax error 
before '}' token
/usr/local/include/tk.h:678: error: syntax error 
before "Bool"

is it possible to correct this or state clearly in 
the configure options how to disable it correctly?

we also checked the Modules/Setup and both seems 
commented.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-17 17:43

Message:
Logged In: YES 
user_id=21627

I fail to see a bug here. What makes you think
--disable-sunaudiodev --disable-tk exist? ./configure --help
does not claim they do.

In fact, it is not possible to disable modules. Why do you
want that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 17:47:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 08:47:40 -0700
Subject: [ python-Feature Requests-1578269 ] Add os.link() and os.symlink()
	support for Windows
Message-ID: <E1GZrAK-000442-43@sc8-sf-web4.sourceforge.net>

Feature Requests item #1578269, was opened at 2006-10-16 17:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add os.link() and os.symlink() support for Windows

Initial Comment:
NTFS version 5.0 and up has all the needed APIs for
creating hard links and symlinks (junctions), so it
should be possible to add support for both hard links
and symlinks to the posixmodule.

Here are a few references:

http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
(see list of links at the end of the page)

http://www.codeproject.com/w2k/junctionpoints.asp
(junction points only, but includes analysis and source
code)

Note: NTFS 5.0 is supported in Win 2k, XP, 2003 and later.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-17 17:47

Message:
Logged In: YES 
user_id=21627

We shouldn't expose junctions as symlinks. Instead, Vista
will get real symlinks, so we should use that:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 18:11:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 09:11:48 -0700
Subject: [ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Message-ID: <E1GZrXg-000105-17@sc8-sf-web5.sourceforge.net>

Bugs item #1578513, was opened at 2006-10-17 07:27
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
>Group: Python 2.5
Status: Open
Resolution: None
>Priority: 5
Submitted By: smithj (smithj_rpath)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: 2.4.4c1 will not build when cross compiling

Initial Comment:
When trying to build 2.4.4c1 with cross-compiling, I
get the following 
error.

checking for /dev/ptmx... configure: error: cannot
check for file 
existence when cross compiling

./config.log:configure:20566: checking for /dev/ptmx
./config.log:configure:20572: error: cannot check for
file existence 
when cross compiling

This does not occur with 2.4.3.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-18 02:11

Message:
Logged In: YES 
user_id=29957

Yeah, this is the ubuntu version of autoconf, oh well. I
don't have time right now to mess around with installing a
new autoconf (it's late, and I have a release in the morning). 

Checked into release24-maint as r52358, will be part of
2.4.4 (and 2.5.1 and 2.6 when I forward-port it). Leaving
open as a reminder.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 01:37

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. Of course, the check result is
still bogus for cross-compilation (so it doesn't, and really
can't, "work"), as we cannot know whether /dev/something
exists on the target machine.

As for regenerating configure: it should work fine if you
install a stock autoconf 2.59 (I typically have one in
~/ac259). If you happen to use a Debian-or-Redhat-modified
one, regeneration will often include unrelated changes.

As there really isn't a better way to deal with it, this
should then also be forward-ported to 2.5 and 2.6.

----------------------------------------------------------------------

Comment By: smithj (smithj_rpath)
Date: 2006-10-18 00:38

Message:
Logged In: YES 
user_id=1622486

Yes, that patch does fix the issue. Thank you.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 23:21

Message:
Logged In: YES 
user_id=29957

Ok, this revision is definitely the problem - it switched
from using our own test to autoconf's AC_CHECK_FILE. This
breaks things. Yay. :-/

Looking closer - we used to use our own test -e check.
autoconf uses test -r. The attached patch reverses that fix,
and changes back to our own test, using test -r instead.

Can you please test this? Martin, can you check this out? I
had to hand-edit the patch, because autoconf on this box
spat out a vast number of extra pointless changes. 


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 22:50

Message:
Logged In: YES 
user_id=29957

Goody - autoconf debugging, my absolute favourite!

r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon,
31 Jul 2006) | 3 lines

Drop usage of test -e in configure as it is not portable.
Fixes #1439538



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-10-17 08:27

Message:
Logged In: YES 
user_id=44345

Boosting this and at least provisionally assigning to Anthony since it's related to 
a change between 2.4.3 and 2.4.4c1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 19:48:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 10:48:06 -0700
Subject: [ python-Bugs-1575945 ] from_param and _as_parameter_ truncating
	64-bit value
Message-ID: <E1GZt2s-0007d3-Dl@sc8-sf-web1.sourceforge.net>

Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: from_param and _as_parameter_ truncating 64-bit value

Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.

SConstruct to build library:

env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])

C code:

#include <stdio.h>
void nnz(double *ary) {
    printf("ary = %p\n", (void*)ary);
}

Python code:

import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype  = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)

Output on 32-bit system:

data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8

Output on 64-bit system:

data_as c_void_p(46912559644688)
array interface 0x2aaaae740010
ary = 0x2aaaae740010
ary = 0xae740010
_as_parameter 0x2aaaae740010

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-17 19:48

Message:
Logged In: YES 
user_id=11105

I replaced in numpy/core/_internal.py, version 1.0rc2, the
get_as_parameter method with this code:

    def get_as_parameter(self):
        ##return self._data
        return self._ctypes.c_void_p(self._data)

and here is the script and the output on a 64-bit Linux
system, with Python 2.5:

theller at tubu:~/devel/release25-maint$ cat param.py
import numpy
from numpy.ctypeslib import ndpointer
from ctypes import *
import _ctypes_test

A = numpy.eye(1280)

print A.__array_interface__['data'],
hex(A.__array_interface__['data'][0])

func = CDLL(_ctypes_test.__file__)._testfunc_p_p
func.restype = c_void_p
func.argtypes = [ndpointer(dtype=numpy.float64)]

print hex(func(A))
theller at tubu:~/devel/release25-maint$ ./python param.py
(46912527945744, False) 0x2aaaac905010
0x2aaaac905010
theller at tubu:~/devel/release25-maint$


As you can see the 64-bit pointer is passed through the
function.  _testfunc_p_p in _ctypes_test.so is simply

char * _testfunc_p_p (void *s)
{
    return (char *)s;
}


----------------------------------------------------------------------

Comment By: Albert Strasheim (albertstrasheim)
Date: 2006-10-16 18:18

Message:
Logged In: YES 
user_id=945096

Changing NumPy's _as_parameter_ to return the pointer as a
c_void_p causes ctypes to raise the following erorr:

ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-16 17:05

Message:
Logged In: YES 
user_id=11105

This is not a ctypes bug.

It seems that A.ctypes._as_parameter_ is a Python integer. 
These are passed as 'C int' type to foreign function calls.
(The C int type typically has 32 bits on 64-bit platforms,
while a pointer has 64 bit.)

To pass a pointer, A.ctypes._as_parameter_ should be a
ctypes c_void_p instance, not a Python integer.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:07

Message:
Logged In: YES 
user_id=21627

Thomas, can you take a look? If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 21:00:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 12:00:09 -0700
Subject: [ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Message-ID: <E1GZuAb-0004Et-Kj@sc8-sf-web2.sourceforge.net>

Bugs item #1578513, was opened at 2006-10-16 23:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: smithj (smithj_rpath)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: 2.4.4c1 will not build when cross compiling

Initial Comment:
When trying to build 2.4.4c1 with cross-compiling, I
get the following 
error.

checking for /dev/ptmx... configure: error: cannot
check for file 
existence when cross compiling

./config.log:configure:20566: checking for /dev/ptmx
./config.log:configure:20572: error: cannot check for
file existence 
when cross compiling

This does not occur with 2.4.3.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-17 21:00

Message:
Logged In: YES 
user_id=21627

Committed into 2.5 as 52362, and the trunk as 52363.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 18:11

Message:
Logged In: YES 
user_id=29957

Yeah, this is the ubuntu version of autoconf, oh well. I
don't have time right now to mess around with installing a
new autoconf (it's late, and I have a release in the morning). 

Checked into release24-maint as r52358, will be part of
2.4.4 (and 2.5.1 and 2.6 when I forward-port it). Leaving
open as a reminder.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-17 17:37

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. Of course, the check result is
still bogus for cross-compilation (so it doesn't, and really
can't, "work"), as we cannot know whether /dev/something
exists on the target machine.

As for regenerating configure: it should work fine if you
install a stock autoconf 2.59 (I typically have one in
~/ac259). If you happen to use a Debian-or-Redhat-modified
one, regeneration will often include unrelated changes.

As there really isn't a better way to deal with it, this
should then also be forward-ported to 2.5 and 2.6.

----------------------------------------------------------------------

Comment By: smithj (smithj_rpath)
Date: 2006-10-17 16:38

Message:
Logged In: YES 
user_id=1622486

Yes, that patch does fix the issue. Thank you.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 15:21

Message:
Logged In: YES 
user_id=29957

Ok, this revision is definitely the problem - it switched
from using our own test to autoconf's AC_CHECK_FILE. This
breaks things. Yay. :-/

Looking closer - we used to use our own test -e check.
autoconf uses test -r. The attached patch reverses that fix,
and changes back to our own test, using test -r instead.

Can you please test this? Martin, can you check this out? I
had to hand-edit the patch, because autoconf on this box
spat out a vast number of extra pointless changes. 


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-10-17 14:50

Message:
Logged In: YES 
user_id=29957

Goody - autoconf debugging, my absolute favourite!

r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon,
31 Jul 2006) | 3 lines

Drop usage of test -e in configure as it is not portable.
Fixes #1439538



----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-10-17 00:27

Message:
Logged In: YES 
user_id=44345

Boosting this and at least provisionally assigning to Anthony since it's related to 
a change between 2.4.3 and 2.4.4c1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 21:47:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 12:47:58 -0700
Subject: [ python-Bugs-1574584 ] Error with callback function and as_parameter
	with NumPy ndp
Message-ID: <E1GZuus-0007jb-P5@sc8-sf-web5.sourceforge.net>

Bugs item #1574584, was opened at 2006-10-10 17:11
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: Error with callback function and as_parameter with NumPy ndp

Initial Comment:
I posted to the ctypes-users mailing list about this
problem, but SourceForge failed to make that post and
its replies available in the ctypes-users archive, so
I'm repeating it here.

I'm using NumPy with ctypes. I would like to create a
callback function that calls into Python, allocates a
NumPy array and returns a suitable pointer to the C code.

NumPy has a function called ndpointer that allows one
to specify some details of NumPy arrays when dealing
with argtypes. This function also takes care of
extracting the array's data pointer.

Details here:

http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/ctypeslib.py
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/core/_internal.py

Creating a callback function as follows works:

stuff = []
import numpy
def allocator1():
    x = numpy.array([...], dtype='f4')
    stuff.append(x)
    return x.ctypes.data_as(POINTER(c_float))
CFUNCTYPE(POINTER(c_float))(allocator1)

However, if one adds ndpointer to the mix, an error occurs:

stuff = []
import numpy
def allocator2():
    x = numpy.array([...], dtype='f4')
    stuff.append(x)
    return x
CFUNCTYPE(numpy.ctypeslib.ndpointer('f4'))(allocator2)

The error is:

SystemError: NULL result without error in PyObject_Call

Thomas Heller has a patch for this issue.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-17 21:47

Message:
Logged In: YES 
user_id=11105

At least the 'SystemError: NULL result without error in
PyObject_Call' is fixed now in SVN revision 52367
(release25-maint), and revision 52365 (trunk).

You will now get a 'TypeError: unsupported result type for
callback function'.

That's all I can do for Python 2.5, anyway.

I suggest that possible workarounds should be discussed on
the ctypes-users list.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&group_id=5470

From noreply at sourceforge.net  Tue Oct 17 21:57:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 12:57:25 -0700
Subject: [ python-Bugs-723205 ] PyThreadState_Clear() docs incorrect
Message-ID: <E1GZv41-0000Gb-FV@sc8-sf-web5.sourceforge.net>

Bugs item #723205, was opened at 2003-04-17 18:12
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyThreadState_Clear() docs incorrect

Initial Comment:
The docs state that the GIL must be held while
PyThreadStare_Clear() is called. This seems incorrect,
at least in Python 2.2 the thread state must not be
NULL under certain conditions.

See:
http://mail.python.org/pipermail/python-dev/2003-April/034574.html


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-17 21:57

Message:
Logged In: YES 
user_id=11105

I retract this request.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 20:36

Message:
Logged In: YES 
user_id=11105

Sorry, that's because I'm still confused about thread
states, and I think the experts ;-) should sort this out.

No, I'm not claiming that the GIL does not need to be held,
I'm claiming that this is not sufficient: *in addition* the
current threadstate must not be NULL.

To quote from the mentioned posts:

I was doing this:

pts = PyThreadState_Swap(NULL);
PyThreadState_Clear(pts);
PyThreadState_Delete(pts);
PyEval_ReleaseLock();

and got a crash in PyThreadState_Clear(). If I understand
the current docs correctly, this should be allowed, so (my
conclusion) the docs are wrong.

I had to change the code in this way to avoid the crashes:

pts = PyThreadState_Get();
PyThreadState_Clear(pts);
pts = PyThreadState_Swap(NULL);
PyThreadState_Delete(pts);
PyEval_ReleaseLock();

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-17 20:10

Message:
Logged In: YES 
user_id=31435

That was a confusing thread, and this is a confusing bug 
report &lt;wink&gt;.

Are you claiming that the GIL does not need to be held?  If 
not (and it doesn't seem that you were in the thread), it's 
unclear why you mention the GIL.

Best would be if you attached a patch incorporating what you 
think the resolution of that thread was.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 03:40:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 18:40:12 -0700
Subject: [ python-Bugs-1575945 ] from_param and _as_parameter_ truncating
	64-bit value
Message-ID: <E1Ga0Pk-000297-Vx@sc8-sf-web2.sourceforge.net>

Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Comment added) made by sjvdw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: from_param and _as_parameter_ truncating 64-bit value

Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.

SConstruct to build library:

env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])

C code:

#include <stdio.h>
void nnz(double *ary) {
    printf("ary = %p\n", (void*)ary);
}

Python code:

import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype  = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)

Output on 32-bit system:

data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8

Output on 64-bit system:

data_as c_void_p(46912559644688)
array interface 0x2aaaae740010
ary = 0x2aaaae740010
ary = 0xae740010
_as_parameter 0x2aaaae740010

----------------------------------------------------------------------

Comment By: Stefan van der Walt (sjvdw)
Date: 2006-10-18 03:40

Message:
Logged In: YES 
user_id=1104792

On both 32 and 64-bit systems, running param.py under python
2.4 with ctypes 1.0.0 and numpy from SVN (with patch
applied) I see:

$ python param.py 
(-1264099320, False)
Traceback (most recent call last):
  File "param.py", line 16, in ?
    print hex(func(A))
ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1



----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-17 19:48

Message:
Logged In: YES 
user_id=11105

I replaced in numpy/core/_internal.py, version 1.0rc2, the
get_as_parameter method with this code:

    def get_as_parameter(self):
        ##return self._data
        return self._ctypes.c_void_p(self._data)

and here is the script and the output on a 64-bit Linux
system, with Python 2.5:

theller at tubu:~/devel/release25-maint$ cat param.py
import numpy
from numpy.ctypeslib import ndpointer
from ctypes import *
import _ctypes_test

A = numpy.eye(1280)

print A.__array_interface__['data'],
hex(A.__array_interface__['data'][0])

func = CDLL(_ctypes_test.__file__)._testfunc_p_p
func.restype = c_void_p
func.argtypes = [ndpointer(dtype=numpy.float64)]

print hex(func(A))
theller at tubu:~/devel/release25-maint$ ./python param.py
(46912527945744, False) 0x2aaaac905010
0x2aaaac905010
theller at tubu:~/devel/release25-maint$


As you can see the 64-bit pointer is passed through the
function.  _testfunc_p_p in _ctypes_test.so is simply

char * _testfunc_p_p (void *s)
{
    return (char *)s;
}


----------------------------------------------------------------------

Comment By: Albert Strasheim (albertstrasheim)
Date: 2006-10-16 18:18

Message:
Logged In: YES 
user_id=945096

Changing NumPy's _as_parameter_ to return the pointer as a
c_void_p causes ctypes to raise the following erorr:

ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-16 17:05

Message:
Logged In: YES 
user_id=11105

This is not a ctypes bug.

It seems that A.ctypes._as_parameter_ is a Python integer. 
These are passed as 'C int' type to foreign function calls.
(The C int type typically has 32 bits on 64-bit platforms,
while a pointer has 64 bit.)

To pass a pointer, A.ctypes._as_parameter_ should be a
ctypes c_void_p instance, not a Python integer.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:07

Message:
Logged In: YES 
user_id=21627

Thomas, can you take a look? If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 04:23:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 19:23:29 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1Ga15d-0000L7-D4@sc8-sf-web1.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 19:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 04:23:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 19:23:46 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1Ga15u-0000LP-9T@sc8-sf-web1.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 19:23
Message generated for change (Comment added) made by mklaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 19:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 07:23:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Oct 2006 22:23:00 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1Ga3tM-0003M8-C3@sc8-sf-web3.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 19:23
Message generated for change (Settings changed) made by mklaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 19:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 10:04:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 01:04:31 -0700
Subject: [ python-Bugs-1579477 ] Use flush() before os.exevp()
Message-ID: <E1Ga6Pf-0005ow-LK@sc8-sf-web2.sourceforge.net>

Bugs item #1579477, was opened at 2006-10-18 08:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579477&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use flush() before os.exevp()

Initial Comment:
Hi,

before using one of the os.exec??? functions you should
flush all open file descriptors. (E.g.
sys.stdout.flush()). If you don't the content in the
buffer will get lost.

According to Fredrik Lundh this is a feature, not a bug.

I think the documentation should include a hint:

""".... path must contain an appropriate absolute or
relative path.

****NEW
The current process gets replaces immediately. Open
file descriptors are not flushed. You should flush all
open file descriptors (e.g. sys.stdout.flush()) before
calling one if the above exec functions.
****
"""


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579477&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 17:44:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 08:44:11 -0700
Subject: [ python-Bugs-1579796 ] Wrong syntax for PyDateTime_IMPORT in
	documentation
Message-ID: <E1GaDaV-0000wo-8p@sc8-sf-web6.sourceforge.net>

Bugs item #1579796, was opened at 2006-10-18 17:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579796&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Faure (dfaure_kde)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong syntax for PyDateTime_IMPORT in documentation

Initial Comment:
http://docs.python.org/api/datetime-objects.html says 
"macro PyDateTime_IMPORT() must be invoked."

But this doesn't compile. It's PyDateTime_IMPORT;
and not PyDateTime_IMPORT();

Also it would be useful to tell if this should be 
done once per thread or just once per process; seeing 
as it modifies a static variable I guess the latter.

Cheers,
David (still getting crashes in 
PyDateTime_FromDateAndTime though but that's another 
topic....)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579796&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 20:59:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 11:59:12 -0700
Subject: [ python-Bugs-1579931 ] not configured for tk
Message-ID: <E1GaGdE-0008Ql-FO@sc8-sf-web3.sourceforge.net>

Bugs item #1579931, was opened at 2006-10-18 11:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl Wenrich (carlwenrich)
Assigned to: Nobody/Anonymous (nobody)
Summary: not configured for tk

Initial Comment:
When I try to run the sample tkinter script (hello.py)
I get a message saying my python isn't configured for tk.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 21:37:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 12:37:04 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GaHDs-00075d-U2@sc8-sf-web6.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 19:23
Message generated for change (Comment added) made by mklaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 12:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 19:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 21:47:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 12:47:22 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GaHNq-0006Ke-EQ@sc8-sf-web1.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 19:23
Message generated for change (Comment added) made by mklaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 12:47

Message:
Logged In: YES 
user_id=1611720

I cannot yet produce an only-python script which reproduces
the problem, but I can give an overview.  There is a
generator running in one thread, an exception being raised
in another thread, and as a consequent, the generator in the
first thread is garbage-collected (triggering an exception
due to the new generator cleanup).  The problem is extremely
sensitive to timing--often the insertion/removal of print
statements, or reordering the code, causes the problem to
vanish, which is confounding my ability to create a simple
test script.

def getdocs():
    def f():
        <some somehwat time-consuming operation>
    while True:
        f()
        yield None

#
-----------------------------------------------------------------------------

class B(object):
    def __init__(self,):
        pass
    def doit(self):
        # must be an instance var to trigger segfault
        self.docIter = getdocs()
        print self.docIter # this is the generator
referred-to in the traceback
        for i, item in enumerate(self.docIter):            
            if i > 9:
                break            
        print 'exiting generator'


class A(object):
    """ Process entry point / main thread """
    def __init__(self):
  
        while True:
            try:
                self.func()
            except Exception, e:
                print 'right after raise'

  
    def func(self):        
        b = B()
        thread = threading.Thread(target=b.doit)
        thread.start()
        start_t = time.time()
        while True:
            try:
                if time.time() - start_t > 1:
                    raise Exception
            except Exception:
                print 'right before raise'
                # SIGSEGV here.  If this is changed to
                # 'break', no segfault occurs
                raise


if __name__ == '__main__':
    A()


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 12:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 19:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 23:05:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 14:05:46 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GaIbi-0002Z8-Kz@sc8-sf-web4.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-18 04:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 23:05

Message:
Logged In: YES 
user_id=21627

Can you please review/try attached patch? Can anybody tell
why gi_frame *isn't* incref'ed when the generator is created?

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 21:47

Message:
Logged In: YES 
user_id=1611720

I cannot yet produce an only-python script which reproduces
the problem, but I can give an overview.  There is a
generator running in one thread, an exception being raised
in another thread, and as a consequent, the generator in the
first thread is garbage-collected (triggering an exception
due to the new generator cleanup).  The problem is extremely
sensitive to timing--often the insertion/removal of print
statements, or reordering the code, causes the problem to
vanish, which is confounding my ability to create a simple
test script.

def getdocs():
    def f():
        <some somehwat time-consuming operation>
    while True:
        f()
        yield None

#
-----------------------------------------------------------------------------

class B(object):
    def __init__(self,):
        pass
    def doit(self):
        # must be an instance var to trigger segfault
        self.docIter = getdocs()
        print self.docIter # this is the generator
referred-to in the traceback
        for i, item in enumerate(self.docIter):            
            if i > 9:
                break            
        print 'exiting generator'


class A(object):
    """ Process entry point / main thread """
    def __init__(self):
  
        while True:
            try:
                self.func()
            except Exception, e:
                print 'right after raise'

  
    def func(self):        
        b = B()
        thread = threading.Thread(target=b.doit)
        thread.start()
        start_t = time.time()
        while True:
            try:
                if time.time() - start_t > 1:
                    raise Exception
            except Exception:
                print 'right before raise'
                # SIGSEGV here.  If this is changed to
                # 'break', no segfault occurs
                raise


if __name__ == '__main__':
    A()


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 21:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 04:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 23:06:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 14:06:31 -0700
Subject: [ python-Bugs-1579931 ] not configured for tk
Message-ID: <E1GaIcR-0002fG-3a@sc8-sf-web4.sourceforge.net>

Bugs item #1579931, was opened at 2006-10-18 20:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl Wenrich (carlwenrich)
Assigned to: Nobody/Anonymous (nobody)
Summary: not configured for tk

Initial Comment:
When I try to run the sample tkinter script (hello.py)
I get a message saying my python isn't configured for tk.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 23:06

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug? What operating system are
you using, and where do your Python binaries come from?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470

From noreply at sourceforge.net  Wed Oct 18 23:57:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 14:57:22 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GaJPe-0002DS-Pq@sc8-sf-web1.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 22:23
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-10-18 17:57

Message:
Logged In: YES 
user_id=31435

> Can anybody tell why gi_frame *isn't* incref'ed when
> the generator is created?

As documented (in concrete.tex), PyGen_New(f) steals a
reference to the frame passed to it.  Its only call site
(well, in the core) is in ceval.c, which returns immediately
after PyGen_New takes over ownership of the frame the caller
created:

"""
/* Create a new generator that owns the ready to run frame
 * and return that as the value. */
return PyGen_New(f);
"""

In short, that PyGen_New() doesn't incref the frame passed
to it is intentional.

It's possible that the intent is flawed ;-), but offhand I
don't see how.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 17:05

Message:
Logged In: YES 
user_id=21627

Can you please review/try attached patch? Can anybody tell
why gi_frame *isn't* incref'ed when the generator is created?

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 15:47

Message:
Logged In: YES 
user_id=1611720

I cannot yet produce an only-python script which reproduces
the problem, but I can give an overview.  There is a
generator running in one thread, an exception being raised
in another thread, and as a consequent, the generator in the
first thread is garbage-collected (triggering an exception
due to the new generator cleanup).  The problem is extremely
sensitive to timing--often the insertion/removal of print
statements, or reordering the code, causes the problem to
vanish, which is confounding my ability to create a simple
test script.

def getdocs():
    def f():
        <some somehwat time-consuming operation>
    while True:
        f()
        yield None

#
-----------------------------------------------------------------------------

class B(object):
    def __init__(self,):
        pass
    def doit(self):
        # must be an instance var to trigger segfault
        self.docIter = getdocs()
        print self.docIter # this is the generator
referred-to in the traceback
        for i, item in enumerate(self.docIter):            
            if i > 9:
                break            
        print 'exiting generator'


class A(object):
    """ Process entry point / main thread """
    def __init__(self):
  
        while True:
            try:
                self.func()
            except Exception, e:
                print 'right after raise'

  
    def func(self):        
        b = B()
        thread = threading.Thread(target=b.doit)
        thread.start()
        start_t = time.time()
        while True:
            try:
                if time.time() - start_t > 1:
                    raise Exception
            except Exception:
                print 'right before raise'
                # SIGSEGV here.  If this is changed to
                # 'break', no segfault occurs
                raise


if __name__ == '__main__':
    A()


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 15:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 22:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 02:12:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 17:12:03 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GaLVz-0004eG-54@sc8-sf-web4.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 19:23
Message generated for change (Comment added) made by mklaas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 17:12

Message:
Logged In: YES 
user_id=1611720

Despite Tim's reassurrance, I'm afraid that Martin's patch
does infact prevent the segfault.  Sounds like it also
introduces a memleak.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-10-18 14:57

Message:
Logged In: YES 
user_id=31435

> Can anybody tell why gi_frame *isn't* incref'ed when
> the generator is created?

As documented (in concrete.tex), PyGen_New(f) steals a
reference to the frame passed to it.  Its only call site
(well, in the core) is in ceval.c, which returns immediately
after PyGen_New takes over ownership of the frame the caller
created:

"""
/* Create a new generator that owns the ready to run frame
 * and return that as the value. */
return PyGen_New(f);
"""

In short, that PyGen_New() doesn't incref the frame passed
to it is intentional.

It's possible that the intent is flawed ;-), but offhand I
don't see how.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 14:05

Message:
Logged In: YES 
user_id=21627

Can you please review/try attached patch? Can anybody tell
why gi_frame *isn't* incref'ed when the generator is created?

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 12:47

Message:
Logged In: YES 
user_id=1611720

I cannot yet produce an only-python script which reproduces
the problem, but I can give an overview.  There is a
generator running in one thread, an exception being raised
in another thread, and as a consequent, the generator in the
first thread is garbage-collected (triggering an exception
due to the new generator cleanup).  The problem is extremely
sensitive to timing--often the insertion/removal of print
statements, or reordering the code, causes the problem to
vanish, which is confounding my ability to create a simple
test script.

def getdocs():
    def f():
        <some somehwat time-consuming operation>
    while True:
        f()
        yield None

#
-----------------------------------------------------------------------------

class B(object):
    def __init__(self,):
        pass
    def doit(self):
        # must be an instance var to trigger segfault
        self.docIter = getdocs()
        print self.docIter # this is the generator
referred-to in the traceback
        for i, item in enumerate(self.docIter):            
            if i > 9:
                break            
        print 'exiting generator'


class A(object):
    """ Process entry point / main thread """
    def __init__(self):
  
        while True:
            try:
                self.func()
            except Exception, e:
                print 'right after raise'

  
    def func(self):        
        b = B()
        thread = threading.Thread(target=b.doit)
        thread.start()
        start_t = time.time()
        while True:
            try:
                if time.time() - start_t > 1:
                    raise Exception
            except Exception:
                print 'right before raise'
                # SIGSEGV here.  If this is changed to
                # 'break', no segfault occurs
                raise


if __name__ == '__main__':
    A()


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 12:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 19:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 02:38:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Oct 2006 17:38:53 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GaLvx-0002OK-2v@sc8-sf-web5.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 22:23
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-10-18 20:38

Message:
Logged In: YES 
user_id=31435

I've attached a much simplified pure-Python script (hope.py)
that reproduces a problem very quickly, on Windows, in a
/debug/ build of current trunk.  It typically prints:

exiting generator
joined thread

at most twice before crapping out.  At the time, the `next`
argument to newtracebackobject() is 0xdddddddd, and tracing
back a level shows that, in PyTraceBack_Here(),
frame->tstate is entirely filled with 0xdd bytes.

Note that this is not a debug-build obmalloc gimmick!  This
is Microsoft's similar debug-build gimmick for their malloc,
and for some reason Python uses the system malloc directly
to obtain memory for thread states.  The Microsoft debug
free() fills newly-freed memory with 0xdd, which has the
same meaning as the debug-build obmalloc's DEADBYTE (0xdb).

So somebody is accessing a thread state here after it's been
freed.  Best guess is that the generator is getting "cleaned
up" after the thread that created it has gone away, so the
generator's frame's f_tstate is trash.

Note that a PyThreadState (a frame's f_tstate) is /not/ a
Python object -- it's just a raw C struct, and its lifetime
isn't controlled by refcounts.

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 20:12

Message:
Logged In: YES 
user_id=1611720

Despite Tim's reassurrance, I'm afraid that Martin's patch
does infact prevent the segfault.  Sounds like it also
introduces a memleak.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-10-18 17:57

Message:
Logged In: YES 
user_id=31435

> Can anybody tell why gi_frame *isn't* incref'ed when
> the generator is created?

As documented (in concrete.tex), PyGen_New(f) steals a
reference to the frame passed to it.  Its only call site
(well, in the core) is in ceval.c, which returns immediately
after PyGen_New takes over ownership of the frame the caller
created:

"""
/* Create a new generator that owns the ready to run frame
 * and return that as the value. */
return PyGen_New(f);
"""

In short, that PyGen_New() doesn't incref the frame passed
to it is intentional.

It's possible that the intent is flawed ;-), but offhand I
don't see how.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 17:05

Message:
Logged In: YES 
user_id=21627

Can you please review/try attached patch? Can anybody tell
why gi_frame *isn't* incref'ed when the generator is created?

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 15:47

Message:
Logged In: YES 
user_id=1611720

I cannot yet produce an only-python script which reproduces
the problem, but I can give an overview.  There is a
generator running in one thread, an exception being raised
in another thread, and as a consequent, the generator in the
first thread is garbage-collected (triggering an exception
due to the new generator cleanup).  The problem is extremely
sensitive to timing--often the insertion/removal of print
statements, or reordering the code, causes the problem to
vanish, which is confounding my ability to create a simple
test script.

def getdocs():
    def f():
        <some somehwat time-consuming operation>
    while True:
        f()
        yield None

#
-----------------------------------------------------------------------------

class B(object):
    def __init__(self,):
        pass
    def doit(self):
        # must be an instance var to trigger segfault
        self.docIter = getdocs()
        print self.docIter # this is the generator
referred-to in the traceback
        for i, item in enumerate(self.docIter):            
            if i > 9:
                break            
        print 'exiting generator'


class A(object):
    """ Process entry point / main thread """
    def __init__(self):
  
        while True:
            try:
                self.func()
            except Exception, e:
                print 'right after raise'

  
    def func(self):        
        b = B()
        thread = threading.Thread(target=b.doit)
        thread.start()
        start_t = time.time()
        while True:
            try:
                if time.time() - start_t > 1:
                    raise Exception
            except Exception:
                print 'right before raise'
                # SIGSEGV here.  If this is changed to
                # 'break', no segfault occurs
                raise


if __name__ == '__main__':
    A()


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 15:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 22:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 09:58:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 00:58:09 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GaSn3-0002lC-28@sc8-sf-web4.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-18 03:23
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-10-19 08:58

Message:
Logged In: YES 
user_id=6656

> and for some reason Python uses the system malloc directly
> to obtain memory for thread states.

This bit is fairly easy: they are allocated without the GIL being held, which 
breaks an assumption of PyMalloc.

No idea about the real problem, sadly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-10-19 01:38

Message:
Logged In: YES 
user_id=31435

I've attached a much simplified pure-Python script (hope.py)
that reproduces a problem very quickly, on Windows, in a
/debug/ build of current trunk.  It typically prints:

exiting generator
joined thread

at most twice before crapping out.  At the time, the `next`
argument to newtracebackobject() is 0xdddddddd, and tracing
back a level shows that, in PyTraceBack_Here(),
frame->tstate is entirely filled with 0xdd bytes.

Note that this is not a debug-build obmalloc gimmick!  This
is Microsoft's similar debug-build gimmick for their malloc,
and for some reason Python uses the system malloc directly
to obtain memory for thread states.  The Microsoft debug
free() fills newly-freed memory with 0xdd, which has the
same meaning as the debug-build obmalloc's DEADBYTE (0xdb).

So somebody is accessing a thread state here after it's been
freed.  Best guess is that the generator is getting "cleaned
up" after the thread that created it has gone away, so the
generator's frame's f_tstate is trash.

Note that a PyThreadState (a frame's f_tstate) is /not/ a
Python object -- it's just a raw C struct, and its lifetime
isn't controlled by refcounts.

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-19 01:12

Message:
Logged In: YES 
user_id=1611720

Despite Tim's reassurrance, I'm afraid that Martin's patch
does infact prevent the segfault.  Sounds like it also
introduces a memleak.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-10-18 22:57

Message:
Logged In: YES 
user_id=31435

> Can anybody tell why gi_frame *isn't* incref'ed when
> the generator is created?

As documented (in concrete.tex), PyGen_New(f) steals a
reference to the frame passed to it.  Its only call site
(well, in the core) is in ceval.c, which returns immediately
after PyGen_New takes over ownership of the frame the caller
created:

"""
/* Create a new generator that owns the ready to run frame
 * and return that as the value. */
return PyGen_New(f);
"""

In short, that PyGen_New() doesn't incref the frame passed
to it is intentional.

It's possible that the intent is flawed ;-), but offhand I
don't see how.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 22:05

Message:
Logged In: YES 
user_id=21627

Can you please review/try attached patch? Can anybody tell
why gi_frame *isn't* incref'ed when the generator is created?

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 20:47

Message:
Logged In: YES 
user_id=1611720

I cannot yet produce an only-python script which reproduces
the problem, but I can give an overview.  There is a
generator running in one thread, an exception being raised
in another thread, and as a consequent, the generator in the
first thread is garbage-collected (triggering an exception
due to the new generator cleanup).  The problem is extremely
sensitive to timing--often the insertion/removal of print
statements, or reordering the code, causes the problem to
vanish, which is confounding my ability to create a simple
test script.

def getdocs():
    def f():
        <some somehwat time-consuming operation>
    while True:
        f()
        yield None

#
-----------------------------------------------------------------------------

class B(object):
    def __init__(self,):
        pass
    def doit(self):
        # must be an instance var to trigger segfault
        self.docIter = getdocs()
        print self.docIter # this is the generator
referred-to in the traceback
        for i, item in enumerate(self.docIter):            
            if i > 9:
                break            
        print 'exiting generator'


class A(object):
    """ Process entry point / main thread """
    def __init__(self):
  
        while True:
            try:
                self.func()
            except Exception, e:
                print 'right after raise'

  
    def func(self):        
        b = B()
        thread = threading.Thread(target=b.doit)
        thread.start()
        start_t = time.time()
        while True:
            try:
                if time.time() - start_t > 1:
                    raise Exception
            except Exception:
                print 'right before raise'
                # SIGSEGV here.  If this is changed to
                # 'break', no segfault occurs
                raise


if __name__ == '__main__':
    A()


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 20:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 03:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 13:44:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 04:44:08 -0700
Subject: [ python-Bugs-1580472 ] glob.glob("c:\\[ ]\*) doesn't work
Message-ID: <E1GaWJk-0001Fp-LE@sc8-sf-web5.sourceforge.net>

Bugs item #1580472, was opened at 2006-10-19 13:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Koblaid (koblaid)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob.glob("c:\\[ ]\*) doesn't work

Initial Comment:
OS: Windows 2000 Service Pack 4
Python 2.5

glob.glob() doesn't work in directories named 
"[ ]" (with a blank in it). Another example is a 
directory named "A - [Aa-Am]"

Example:
#########################
C:\>md []
C:\>md "[ ]"
C:\>copy anyfile.txt []
        1 Datei(en) kopiert.
C:\>copy anyfile.txt "[ ]"
        1 Datei(en) kopiert.

C:\>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC 
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import glob
>>> glob.glob ("c:\\[]\*")
['c:\\[]\\anyfile.txt']
>>> glob.glob ("c:\\[ ]\*")
[]
#########################

The second glob should have resulted the same as the 
first glob since I copied the same file to both 
directories.
I may be wrong because I'm new to python. But I've 
tested it a couple of times, and I think it have to be 
a bug of python or a bug of windows.

Greets, Koblaid

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 16:21:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 07:21:56 -0700
Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working
	properly
Message-ID: <E1GaYmS-0000ls-3l@sc8-sf-web5.sourceforge.net>

Bugs item #1580563, was opened at 2006-10-19 10:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make install" for Python 2.4.4 not working properly

Initial Comment:
Running "make install" on Linux (Suse 10.1) won't
terminate properly:

Compiling /opt/python-2.4.4/lib/python2.4/user.py ...
Compiling /opt/python-2.4.4/lib/python2.4/uu.py ...
Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ...
Compiling /opt/python-2.4.4/lib/python2.4/wave.py ...
Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ...
Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/__init__.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/dom ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/sax ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ...
make: *** [libinstall] Error 1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 16:33:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 07:33:51 -0700
Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working
	properly
Message-ID: <E1GaYxz-0007Q7-ML@sc8-sf-web6.sourceforge.net>

Bugs item #1580563, was opened at 2006-10-19 10:21
Message generated for change (Comment added) made by ajung
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make install" for Python 2.4.4 not working properly

Initial Comment:
Running "make install" on Linux (Suse 10.1) won't
terminate properly:

Compiling /opt/python-2.4.4/lib/python2.4/user.py ...
Compiling /opt/python-2.4.4/lib/python2.4/uu.py ...
Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ...
Compiling /opt/python-2.4.4/lib/python2.4/wave.py ...
Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ...
Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/__init__.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/dom ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/sax ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ...
make: *** [libinstall] Error 1


----------------------------------------------------------------------

>Comment By: Andreas Jung (ajung)
Date: 2006-10-19 10:33

Message:
Logged In: YES 
user_id=11084

Same issue on MacOSX

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 16:34:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 07:34:02 -0700
Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working
	properly
Message-ID: <E1GaYyA-0001Vn-VQ@sc8-sf-web2.sourceforge.net>

Bugs item #1580563, was opened at 2006-10-19 10:21
Message generated for change (Settings changed) made by ajung
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make install" for Python 2.4.4 not working properly

Initial Comment:
Running "make install" on Linux (Suse 10.1) won't
terminate properly:

Compiling /opt/python-2.4.4/lib/python2.4/user.py ...
Compiling /opt/python-2.4.4/lib/python2.4/uu.py ...
Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ...
Compiling /opt/python-2.4.4/lib/python2.4/wave.py ...
Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ...
Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/__init__.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/dom ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/sax ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ...
make: *** [libinstall] Error 1


----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2006-10-19 10:33

Message:
Logged In: YES 
user_id=11084

Same issue on MacOSX

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 19:17:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 10:17:38 -0700
Subject: [ python-Bugs-1575945 ] from_param and _as_parameter_ truncating
	64-bit value
Message-ID: <E1GabWU-0006o4-KB@sc8-sf-web6.sourceforge.net>

Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: from_param and _as_parameter_ truncating 64-bit value

Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.

SConstruct to build library:

env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])

C code:

#include <stdio.h>
void nnz(double *ary) {
    printf("ary = %p\n", (void*)ary);
}

Python code:

import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype  = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)

Output on 32-bit system:

data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8

Output on 64-bit system:

data_as c_void_p(46912559644688)
array interface 0x2aaaae740010
ary = 0x2aaaae740010
ary = 0xae740010
_as_parameter 0x2aaaae740010

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-19 19:17

Message:
Logged In: YES 
user_id=11105

This is a ctypes 1.0.0 bug then ;-).

Python 2.5 contains ctypes 1.0.1, which is not yet released
as standalone package, but I'll do it ASAP.

Therefore I'll close this report as 'works for me', please
reopen if it still does not work with Python 2.4 and ctypes
1.0.1.

----------------------------------------------------------------------

Comment By: Stefan van der Walt (sjvdw)
Date: 2006-10-18 03:40

Message:
Logged In: YES 
user_id=1104792

On both 32 and 64-bit systems, running param.py under python
2.4 with ctypes 1.0.0 and numpy from SVN (with patch
applied) I see:

$ python param.py 
(-1264099320, False)
Traceback (most recent call last):
  File "param.py", line 16, in ?
    print hex(func(A))
ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1



----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-17 19:48

Message:
Logged In: YES 
user_id=11105

I replaced in numpy/core/_internal.py, version 1.0rc2, the
get_as_parameter method with this code:

    def get_as_parameter(self):
        ##return self._data
        return self._ctypes.c_void_p(self._data)

and here is the script and the output on a 64-bit Linux
system, with Python 2.5:

theller at tubu:~/devel/release25-maint$ cat param.py
import numpy
from numpy.ctypeslib import ndpointer
from ctypes import *
import _ctypes_test

A = numpy.eye(1280)

print A.__array_interface__['data'],
hex(A.__array_interface__['data'][0])

func = CDLL(_ctypes_test.__file__)._testfunc_p_p
func.restype = c_void_p
func.argtypes = [ndpointer(dtype=numpy.float64)]

print hex(func(A))
theller at tubu:~/devel/release25-maint$ ./python param.py
(46912527945744, False) 0x2aaaac905010
0x2aaaac905010
theller at tubu:~/devel/release25-maint$


As you can see the 64-bit pointer is passed through the
function.  _testfunc_p_p in _ctypes_test.so is simply

char * _testfunc_p_p (void *s)
{
    return (char *)s;
}


----------------------------------------------------------------------

Comment By: Albert Strasheim (albertstrasheim)
Date: 2006-10-16 18:18

Message:
Logged In: YES 
user_id=945096

Changing NumPy's _as_parameter_ to return the pointer as a
c_void_p causes ctypes to raise the following erorr:

ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-16 17:05

Message:
Logged In: YES 
user_id=11105

This is not a ctypes bug.

It seems that A.ctypes._as_parameter_ is a Python integer. 
These are passed as 'C int' type to foreign function calls.
(The C int type typically has 32 bits on 64-bit platforms,
while a pointer has 64 bit.)

To pass a pointer, A.ctypes._as_parameter_ should be a
ctypes c_void_p instance, not a Python integer.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 22:07

Message:
Logged In: YES 
user_id=21627

Thomas, can you take a look? If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 19:26:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 10:26:55 -0700
Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working
	properly
Message-ID: <E1GabfT-0001nq-Iz@sc8-sf-web1.sourceforge.net>

Bugs item #1580563, was opened at 2006-10-19 16:21
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make install" for Python 2.4.4 not working properly

Initial Comment:
Running "make install" on Linux (Suse 10.1) won't
terminate properly:

Compiling /opt/python-2.4.4/lib/python2.4/user.py ...
Compiling /opt/python-2.4.4/lib/python2.4/uu.py ...
Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ...
Compiling /opt/python-2.4.4/lib/python2.4/wave.py ...
Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ...
Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/__init__.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/dom ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/sax ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ...
make: *** [libinstall] Error 1


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-19 19:26

Message:
Logged In: YES 
user_id=580910

What are the configure arguments that you are using?

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2006-10-19 16:33

Message:
Logged In: YES 
user_id=11084

Same issue on MacOSX

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 20:00:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 11:00:39 -0700
Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working
	properly
Message-ID: <E1GacC7-0002cM-AJ@sc8-sf-web6.sourceforge.net>

Bugs item #1580563, was opened at 2006-10-19 10:21
Message generated for change (Comment added) made by ajung
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make install" for Python 2.4.4 not working properly

Initial Comment:
Running "make install" on Linux (Suse 10.1) won't
terminate properly:

Compiling /opt/python-2.4.4/lib/python2.4/user.py ...
Compiling /opt/python-2.4.4/lib/python2.4/uu.py ...
Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ...
Compiling /opt/python-2.4.4/lib/python2.4/wave.py ...
Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ...
Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/__init__.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/dom ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/sax ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ...
make: *** [libinstall] Error 1


----------------------------------------------------------------------

>Comment By: Andreas Jung (ajung)
Date: 2006-10-19 14:00

Message:
Logged In: YES 
user_id=11084

On both system just "configure --prefix=/opt/python-2.4.4"

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-19 13:26

Message:
Logged In: YES 
user_id=580910

What are the configure arguments that you are using?

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2006-10-19 10:33

Message:
Logged In: YES 
user_id=11084

Same issue on MacOSX

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 20:38:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 11:38:12 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1GacmS-0007WF-Cg@sc8-sf-web4.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris (spotvt01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 20:55:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 11:55:14 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1Gad2w-0006Va-Co@sc8-sf-web5.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Comment added) made by spotvt01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris (spotvt01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

>Comment By: Chris (spotvt01)
Date: 2006-10-19 18:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 20:56:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 11:56:42 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1Gad4M-0003EL-Ag@sc8-sf-web3.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Chris (spotvt01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 18:56

Message:
Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 18:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 21:00:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 12:00:27 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1Gad7z-00006N-KV@sc8-sf-web6.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Settings changed) made by spotvt01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Chris (spotvt01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 18:56

Message:
Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 18:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 21:04:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 12:04:28 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1GadBs-0000Vb-7S@sc8-sf-web6.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Comment added) made by spotvt01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Chris (spotvt01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

>Comment By: Chris (spotvt01)
Date: 2006-10-19 19:04

Message:
Logged In: YES 
user_id=1624982

wait, I didn't mean to change the status, sory about that.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 18:56

Message:
Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 18:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 21:06:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 12:06:17 -0700
Subject: [ python-Bugs-1580738 ] httplib hangs reading too much data
Message-ID: <E1GadDd-0003EV-1o@sc8-sf-web1.sourceforge.net>

Bugs item #1580738, was opened at 2006-10-19 14:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580738&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dustin J. Mitchell (djmitche)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib hangs reading too much data

Initial Comment:
I'm building an interface to Amazon's S3, using httplib.  It uses a
single object for multiple transactions.  What's happening is this:

HTTP > PUT /unitest-temp-1161039691 HTTP/1.1
HTTP > Date: Mon, 16 Oct 2006 23:01:32 GMT
HTTP > Authorization: AWS <<cough>>:KiTWRuq/
6aay0bI2J5DkE2TAWD0=
HTTP > (end headers)
HTTP < HTTP/1.1 200 OK
HTTP < content-length: 0
HTTP < x-amz-id-2: 40uQn0OCpTiFcX+LqjMuzG6NnufdUk/..
HTTP < server: AmazonS3
HTTP < x-amz-request-id: FF504E8FD1B86F8C
HTTP < location: /unitest-temp-1161039691
HTTP < date: Mon, 16 Oct 2006 23:01:33 GMT
HTTPConnection.__state before response.read:  Idle
HTTPConnection.__response: closed? False length: 0
reading response
HTTPConnection.__state after response.read:  Idle
HTTPConnection.__response: closed? False length: 0

 ..later in the same connection..

HTTPConnection.__state before putrequest:  Idle
HTTPConnection.__response: closed? False length: 0
HTTP > DELETE /unitest-temp-1161039691 HTTP/1.1
HTTP > Date: Mon, 16 Oct 2006 23:01:33 GMT
HTTP > Authorization: AWS <<cough>>:
a5OizuLNwwV7eBUhha0B6rEJ+CQ=
HTTP > (end headers)
HTTPConnection.__state before getresponse:  Request-sent
HTTPConnection.__response: closed? False length: 0
  File "/usr/lib64/python2.4/httplib.py", line 856, in getresponse
    raise ResponseNotReady()

If the first request does not precede it, the second request is fine.
To avoid excessive memory use, I'm calling request.read(16384)
repeatedly, instead of just calling request.read().  This seems to be
key to the problem -- if I omit the 'amt' argument to read(), then the
last line of the first request reads

HTTPConnection.__response: closed? True length: 0

and the later call to getresponse() doesn't raise ResponseNotReady.

Looking at the source for httplib.HTTPResponse.read, self.close() gets
called in the latter (working) case, but not in the former
(non-working).  It would seem sensible to add 'if self.length == 0:
self.close()' to the end of that function (and, in fact, this change makes 
the whole thing work), but this comment makes me hesitant:

# we do not use _safe_read() here because this may be a .will_close
# connection, and the user is reading more bytes than will be provided
# (for example, reading in 1k chunks)

I suspect that either (a) this is a bug or (b) the client is supposed to 
either call read() with no arguments or calculate the proper inputs to 
read(amt) based on the Content-Length header.  If (b), I would think 
the docs should be updated to reflect that?

Thanks for any assistance.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580738&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 21:14:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 12:14:59 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1GadM3-00047A-7K@sc8-sf-web2.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Chris (spotvt01)
>Assigned to: Martin v. L?wis (loewis)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 19:14

Message:
Logged In: YES 
user_id=849994

actually, this is okay, the "pending" status is
automatically set to "open" again when the OP posts an answer.

I can't read anything out of that error log, however,
perhaps Martin can.

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 19:04

Message:
Logged In: YES 
user_id=1624982

wait, I didn't mean to change the status, sory about that.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 18:56

Message:
Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 18:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 21:32:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 12:32:04 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1Gadca-0006hA-GB@sc8-sf-web3.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Comment added) made by spotvt01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Chris (spotvt01)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

>Comment By: Chris (spotvt01)
Date: 2006-10-19 19:32

Message:
Logged In: YES 
user_id=1624982

I think the important part of the mod_python compile error
is the last part where the linker fails to link in
libpython2.4.a   ... that's why I think it's an error with
the configure file for python.  It says that libpython2.4.a
should be compiled with position-independant-code.  If I
remember correctly, any static library needs to be PIC for a
x86_64 machine ... that's why it seems like an error for python.

/usr/bin/ld:
/usr/lib/python2.4/config/libpython2.4.a(abstract.o):
relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
/usr/lib/python2.4/config/libpython2.4.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 19:14

Message:
Logged In: YES 
user_id=849994

actually, this is okay, the "pending" status is
automatically set to "open" again when the OP posts an answer.

I can't read anything out of that error log, however,
perhaps Martin can.

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 19:04

Message:
Logged In: YES 
user_id=1624982

wait, I didn't mean to change the status, sory about that.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 18:56

Message:
Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 18:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 23:44:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 14:44:46 -0700
Subject: [ python-Bugs-1576861 ] potential buffer overflow in complexobject.c
Message-ID: <E1Gafh0-0006N9-F4@sc8-sf-web5.sourceforge.net>

Bugs item #1576861, was opened at 2006-10-13 17:06
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576861&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jochen Voss (jvoss2)
Assigned to: Nobody/Anonymous (nobody)
Summary: potential buffer overflow in complexobject.c

Initial Comment:
python version 2.4.3

Hello,

recently I came across the following bit of code in the
source file Objects/complexobject.c:

static void
complex_to_buf(char *buf, int bufsz, PyComplexObject
*v, int precision)
{
        char format[32];
        if (v->cval.real == 0.) {
                PyOS_snprintf(format, 32, "%%.%ig",
precision);
                PyOS_ascii_formatd(buf, bufsz, format,
v->cval.imag);
                strncat(buf, "j", bufsz);

The strncat statement in the last line is potentially
unsafe: the size argument of strncat determines how
many characters are to be added maxmimally and not how
large the buffer is in total.  Also there needs to be
space for an additional '\0' byte.

This seems currently not exploitable, because the
function 'complex_to_buf' is always called with a large
enough buffer, but it should be fixed any way (for
example to make sure that nobody copies this code for
use in another context).

I hope this helps,
Jochen


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-19 17:44

Message:
Logged In: YES 
user_id=11375

I believe this is fixed in Python 2.4.4 and Python 2.5; a
static analysis tool reported the problem.   Please take a
look at the current trunk version at
http://svn.python.org/view/python/trunk/Objects/complexobject.c?rev=50679&view=log,
and see if the code seems safe now.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576861&group_id=5470

From noreply at sourceforge.net  Thu Oct 19 23:57:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 14:57:29 -0700
Subject: [ python-Bugs-1576348 ] Example typo in section 4 of 'Installing
	Python Modules'
Message-ID: <E1GaftJ-0004NS-H0@sc8-sf-web3.sourceforge.net>

Bugs item #1576348, was opened at 2006-10-12 22:36
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576348&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: ytrewq1 (ytrewq1)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Example typo in section 4 of 'Installing Python Modules'

Initial Comment:
On 2006-10-13, in the docs.python.org version of '4
Custom Installation' of 'Installing Python Modules' (
http://docs.python.org/inst/search-path.html) I see:

python setup.py --install-base=/tmp

It seems to me that that may be missing the mention of
a command -- presumably 'install'.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-19 17:57

Message:
Logged In: YES 
user_id=11375

Fixed in revs. 52390 and 52391.  Thanks for reporting this!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576348&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 08:40:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Oct 2006 23:40:12 -0700
Subject: [ python-Bugs-1576861 ] potential buffer overflow in complexobject.c
Message-ID: <E1Gao3A-0000CO-2F@sc8-sf-web5.sourceforge.net>

Bugs item #1576861, was opened at 2006-10-13 21:06
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576861&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Jochen Voss (jvoss2)
Assigned to: Nobody/Anonymous (nobody)
Summary: potential buffer overflow in complexobject.c

Initial Comment:
python version 2.4.3

Hello,

recently I came across the following bit of code in the
source file Objects/complexobject.c:

static void
complex_to_buf(char *buf, int bufsz, PyComplexObject
*v, int precision)
{
        char format[32];
        if (v->cval.real == 0.) {
                PyOS_snprintf(format, 32, "%%.%ig",
precision);
                PyOS_ascii_formatd(buf, bufsz, format,
v->cval.imag);
                strncat(buf, "j", bufsz);

The strncat statement in the last line is potentially
unsafe: the size argument of strncat determines how
many characters are to be added maxmimally and not how
large the buffer is in total.  Also there needs to be
space for an additional '\0' byte.

This seems currently not exploitable, because the
function 'complex_to_buf' is always called with a large
enough buffer, but it should be fixed any way (for
example to make sure that nobody copies this code for
use in another context).

I hope this helps,
Jochen


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-19 21:44

Message:
Logged In: YES 
user_id=11375

I believe this is fixed in Python 2.4.4 and Python 2.5; a
static analysis tool reported the problem.   Please take a
look at the current trunk version at
http://svn.python.org/view/python/trunk/Objects/complexobject.c?rev=50679&view=log,
and see if the code seems safe now.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576861&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 09:52:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 00:52:09 -0700
Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working
	properly
Message-ID: <E1GapAn-0007iG-Tn@sc8-sf-web6.sourceforge.net>

Bugs item #1580563, was opened at 2006-10-19 16:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make install" for Python 2.4.4 not working properly

Initial Comment:
Running "make install" on Linux (Suse 10.1) won't
terminate properly:

Compiling /opt/python-2.4.4/lib/python2.4/user.py ...
Compiling /opt/python-2.4.4/lib/python2.4/uu.py ...
Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ...
Compiling /opt/python-2.4.4/lib/python2.4/wave.py ...
Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ...
Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/__init__.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/dom ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/sax ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ...
make: *** [libinstall] Error 1


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-20 09:52

Message:
Logged In: YES 
user_id=21627

I can't reproduce this. It installs fine for me (although  I
try to install to /tmp/python-2.4.4, not opt), and also not
on SuSE, but Debian unstable.

Can you please debug through compileall, to find out whether
and how exit_status gets set to a non-zero value? For that
to happen, success should be set to 0 at some point.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2006-10-19 20:00

Message:
Logged In: YES 
user_id=11084

On both system just "configure --prefix=/opt/python-2.4.4"

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-19 19:26

Message:
Logged In: YES 
user_id=580910

What are the configure arguments that you are using?

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2006-10-19 16:33

Message:
Logged In: YES 
user_id=11084

Same issue on MacOSX

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 12:13:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 03:13:08 -0700
Subject: [ python-Bugs-1581182 ] Definition of a "character" is wrong
Message-ID: <E1GarNE-0000Vk-2r@sc8-sf-web2.sourceforge.net>

Bugs item #1581182, was opened at 2006-10-20 04:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Definition of a "character" is wrong

Initial Comment:
Python's definition of a character does not match that
of Unicode.  Python's documentation should, at a
minimum, explain how python definition compares to
Unicode's definition of a code unit, code point, glyph,
grapheme cluster, or character.

Unicode's definition of a character can be found here:
http://unicode.org/reports/tr17/

Python seems to use the Code Units option given here:
http://www.unicode.org/faq/char_combmark.html#7


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 12:15:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 03:15:05 -0700
Subject: [ python-Bugs-1581183 ] pickle protocol 2 failure on int subclass 
Message-ID: <E1GarP7-0001ca-IB@sc8-sf-web4.sourceforge.net>

Bugs item #1581183, was opened at 2006-10-20 12:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581183&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders J. Munch (andersjm)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle protocol 2 failure on int subclass 

Initial Comment:
I ran into problems pickling a set containing an int
subclass which holds a reference to an object which
holds a reference to the original object.

I reduced it to the attached
int_subclass_pickle_problem.py.  There are no problems
with pickle protocols 0 and 1, but the protocol 2 unit
tests fail with an exception.

This happens for pickle and cPickle both, although with
two different excpeptions.

cPickle:
TypeError: ('set objects are unhashable', <type 'set'>,
([set([1])],))

pickle:
  File "....\lib\pickle.py", line 244, in memoize
    assert id(obj) not in self.memo
AssertionError

(For the full tracebacks, run the attached script.)

I looked into if this was because int implemented
__reduce__ or __reduce_ex__, trumping my
__getstate__/__setstate__, but that doesn't seem to be
the case:

>>> int.__reduce_ex__ is object.__reduce_ex__
True
>>> int.__reduce__ is object.__reduce__
True

After the further simplification of replacing
   self.orig = [set([E.a]), set([E.a])]
with
   self.orig = E.a
cPickle starts working, but pickle still fails.

(Seen with Python 2.4.3 and Python 2.5, on W2K.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581183&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 17:17:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 08:17:14 -0700
Subject: [ python-Bugs-1581357 ] missing __enter__ + __getattr__ forwarding
Message-ID: <E1Gaw7W-0000iM-0C@sc8-sf-web5.sourceforge.net>

Bugs item #1581357, was opened at 2006-10-21 00:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581357&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing __enter__ + __getattr__ forwarding

Initial Comment:
Hello. I encountered some unexpected behavior on "with"
statement.

First, please run attached "a.py" file.

# traditional way
<open file 'a.txt', mode 'wb' at 0x009373C8> shift_jis
<type 'instance'> True
# with statement
<open file 'a.txt', mode 'wb' at 0x009373C8> None <type
'file'> False
Traceback (most recent call last):
  File "R:\a.py", line 15, in <module>
    test(io)
  File "R:\a.py", line 8, in test
    io.write(u"?????")
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 0-4: ordin
al not in range(128)

"traditional way" runs as expected, but "with
statement" crashes. This happens because....

  1. codecs.open returns codecs.StreamReaderWriter
  2. codecs.StreamReaderWriter defines __getattr__
     like this.

    def __getattr__(self, name,
                    getattr=getattr):

        """ Inherit all other methods from the
            underlying stream.
        """
        return getattr(self.stream, name)

  3. But codecs.StreamReaderWriter doesn't have its
     __enter__ definition, so 

    srw = StreamReaderWriter(stream, ...
    srw.__enter__() # actually calls stream.__enter__
                      which returns stream not srw
                      via __getattr__

     And more worse, with statement doesn't complain
     StreamReaderWriter (currently) doesn't support
     context manager.

Is this intended behavior? If not, only this problem
can be solved by attached "a.patch". I greped library
files, I found many __getattr__ without __enter__...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581357&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 17:19:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 08:19:10 -0700
Subject: [ python-Bugs-1581357 ] missing __enter__ + __getattr__ forwarding
Message-ID: <E1Gaw9O-0000qs-1K@sc8-sf-web6.sourceforge.net>

Bugs item #1581357, was opened at 2006-10-21 00:17
Message generated for change (Settings changed) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581357&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing __enter__ + __getattr__ forwarding

Initial Comment:
Hello. I encountered some unexpected behavior on "with"
statement.

First, please run attached "a.py" file.

# traditional way
<open file 'a.txt', mode 'wb' at 0x009373C8> shift_jis
<type 'instance'> True
# with statement
<open file 'a.txt', mode 'wb' at 0x009373C8> None <type
'file'> False
Traceback (most recent call last):
  File "R:\a.py", line 15, in <module>
    test(io)
  File "R:\a.py", line 8, in test
    io.write(u"?????")
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 0-4: ordin
al not in range(128)

"traditional way" runs as expected, but "with
statement" crashes. This happens because....

  1. codecs.open returns codecs.StreamReaderWriter
  2. codecs.StreamReaderWriter defines __getattr__
     like this.

    def __getattr__(self, name,
                    getattr=getattr):

        """ Inherit all other methods from the
            underlying stream.
        """
        return getattr(self.stream, name)

  3. But codecs.StreamReaderWriter doesn't have its
     __enter__ definition, so 

    srw = StreamReaderWriter(stream, ...
    srw.__enter__() # actually calls stream.__enter__
                      which returns stream not srw
                      via __getattr__

     And more worse, with statement doesn't complain
     StreamReaderWriter (currently) doesn't support
     context manager.

Is this intended behavior? If not, only this problem
can be solved by attached "a.patch". I greped library
files, I found many __getattr__ without __enter__...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581357&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 17:40:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 08:40:33 -0700
Subject: [ python-Bugs-1581182 ] Definition of a "character" is wrong
Message-ID: <E1GawU5-0001gO-TU@sc8-sf-web4.sourceforge.net>

Bugs item #1581182, was opened at 2006-10-20 12:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Definition of a "character" is wrong

Initial Comment:
Python's definition of a character does not match that
of Unicode.  Python's documentation should, at a
minimum, explain how python definition compares to
Unicode's definition of a code unit, code point, glyph,
grapheme cluster, or character.

Unicode's definition of a character can be found here:
http://unicode.org/reports/tr17/

Python seems to use the Code Units option given here:
http://www.unicode.org/faq/char_combmark.html#7


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-20 17:40

Message:
Logged In: YES 
user_id=21627

The Python string type is not at all Unicode compliant, so I
don't see a need to use Unicode terminology to explain it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 17:41:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 08:41:02 -0700
Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working
	properly
Message-ID: <E1GawUY-0001h1-1N@sc8-sf-web4.sourceforge.net>

Bugs item #1580563, was opened at 2006-10-19 16:21
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make install" for Python 2.4.4 not working properly

Initial Comment:
Running "make install" on Linux (Suse 10.1) won't
terminate properly:

Compiling /opt/python-2.4.4/lib/python2.4/user.py ...
Compiling /opt/python-2.4.4/lib/python2.4/uu.py ...
Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ...
Compiling /opt/python-2.4.4/lib/python2.4/wave.py ...
Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ...
Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ...
Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/__init__.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/dom ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ...
Listing /opt/python-2.4.4/lib/python2.4/xml/sax ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ...
Compiling
/opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ...
Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ...
make: *** [libinstall] Error 1


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-20 09:52

Message:
Logged In: YES 
user_id=21627

I can't reproduce this. It installs fine for me (although  I
try to install to /tmp/python-2.4.4, not opt), and also not
on SuSE, but Debian unstable.

Can you please debug through compileall, to find out whether
and how exit_status gets set to a non-zero value? For that
to happen, success should be set to 0 at some point.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2006-10-19 20:00

Message:
Logged In: YES 
user_id=11084

On both system just "configure --prefix=/opt/python-2.4.4"

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-19 19:26

Message:
Logged In: YES 
user_id=580910

What are the configure arguments that you are using?

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2006-10-19 16:33

Message:
Logged In: YES 
user_id=11084

Same issue on MacOSX

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470

From noreply at sourceforge.net  Fri Oct 20 21:26:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 12:26:08 -0700
Subject: [ python-Bugs-1581476 ] Text search gives bad count if called from
	variable trace
Message-ID: <E1Gb00O-00018G-29@sc8-sf-web2.sourceforge.net>

Bugs item #1581476, was opened at 2006-10-20 12:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581476&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. L?wis (loewis)
Summary: Text search gives bad count if called from variable trace

Initial Comment:
If Text search is called from a variable trace then the count variable is 
not be updated.

I see this with Python 2.4.3 and Aqua Tcl/Tk 8.4.11 on MacOS X 10.4.7. 
I have not tested it elsewhere.

Note that this works fine in tcl/tk so this appears to be a Tkinter issue.

To see the problem run the attached python script.

(The script also includes the equivalent tcl/tk code in its comments, so 
you can easily test the issue directly in tcl/tk if desired.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581476&group_id=5470

From noreply at sourceforge.net  Sat Oct 21 01:35:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Oct 2006 16:35:30 -0700
Subject: [ python-Bugs-1581182 ] Definition of a "character" is wrong
Message-ID: <E1Gb3ti-0001SJ-2Z@sc8-sf-web4.sourceforge.net>

Bugs item #1581182, was opened at 2006-10-20 04:13
Message generated for change (Comment added) made by rhamphoryncus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Definition of a "character" is wrong

Initial Comment:
Python's definition of a character does not match that
of Unicode.  Python's documentation should, at a
minimum, explain how python definition compares to
Unicode's definition of a code unit, code point, glyph,
grapheme cluster, or character.

Unicode's definition of a character can be found here:
http://unicode.org/reports/tr17/

Python seems to use the Code Units option given here:
http://www.unicode.org/faq/char_combmark.html#7


----------------------------------------------------------------------

>Comment By: Adam Olsen (rhamphoryncus)
Date: 2006-10-20 17:35

Message:
Logged In: YES 
user_id=12364

Sorry, I wasn't clear.  I only intended this to be about the
unicode type.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-20 09:40

Message:
Logged In: YES 
user_id=21627

The Python string type is not at all Unicode compliant, so I
don't see a need to use Unicode terminology to explain it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

From noreply at sourceforge.net  Sat Oct 21 09:11:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Oct 2006 00:11:50 -0700
Subject: [ python-Bugs-1581182 ] Definition of a "character" is wrong
Message-ID: <E1GbB1K-00070Q-O9@sc8-sf-web4.sourceforge.net>

Bugs item #1581182, was opened at 2006-10-20 12:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Definition of a "character" is wrong

Initial Comment:
Python's definition of a character does not match that
of Unicode.  Python's documentation should, at a
minimum, explain how python definition compares to
Unicode's definition of a code unit, code point, glyph,
grapheme cluster, or character.

Unicode's definition of a character can be found here:
http://unicode.org/reports/tr17/

Python seems to use the Code Units option given here:
http://www.unicode.org/faq/char_combmark.html#7


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-21 09:11

Message:
Logged In: YES 
user_id=21627

Ok. Can you come up with a patch?

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2006-10-21 01:35

Message:
Logged In: YES 
user_id=12364

Sorry, I wasn't clear.  I only intended this to be about the
unicode type.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-20 17:40

Message:
Logged In: YES 
user_id=21627

The Python string type is not at all Unicode compliant, so I
don't see a need to use Unicode terminology to explain it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

From noreply at sourceforge.net  Sat Oct 21 11:53:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Oct 2006 02:53:07 -0700
Subject: [ python-Bugs-1576174 ] str(WindowsError) wrong
Message-ID: <E1GbDXP-0000Un-Tk@sc8-sf-web1.sourceforge.net>

Bugs item #1576174, was opened at 2006-10-12 22:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Thomas Heller (theller)
Summary: str(WindowsError) wrong

Initial Comment:
str(WindowsError(1001, 'a message') in Python 2.5 gives
'[Error 22] a message'.

The attached patch with test fixes this.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-10-21 11:53

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply (along with a NEWS entry,
for both 2.5 and the trunk).

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-13 20:17

Message:
Logged In: YES 
user_id=11105

Uploaded a new patch which I actually tested under Linux also.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-13 20:17

Message:
Logged In: YES 
user_id=11105

My bad.  I didn't test on Linux.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 23:53

Message:
Logged In: YES 
user_id=1326842

The part of the patch that changes EnvironmentError_str
should be removed (EnvironmentError doesn't have a winerror
member, the change causes compilation errors).  Otherwise
the patch looks fine.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-12 22:13

Message:
Logged In: YES 
user_id=11105

See also:
http://mail.python.org/pipermail/python-dev/2006-September/068869.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

From noreply at sourceforge.net  Sat Oct 21 12:00:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Oct 2006 03:00:59 -0700
Subject: [ python-Bugs-1581182 ] Definition of a "character" is wrong
Message-ID: <E1GbDf1-0001Do-Jj@sc8-sf-web1.sourceforge.net>

Bugs item #1581182, was opened at 2006-10-20 04:13
Message generated for change (Comment added) made by rhamphoryncus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Definition of a "character" is wrong

Initial Comment:
Python's definition of a character does not match that
of Unicode.  Python's documentation should, at a
minimum, explain how python definition compares to
Unicode's definition of a code unit, code point, glyph,
grapheme cluster, or character.

Unicode's definition of a character can be found here:
http://unicode.org/reports/tr17/

Python seems to use the Code Units option given here:
http://www.unicode.org/faq/char_combmark.html#7


----------------------------------------------------------------------

>Comment By: Adam Olsen (rhamphoryncus)
Date: 2006-10-21 04:00

Message:
Logged In: YES 
user_id=12364

Not at the moment.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-21 01:11

Message:
Logged In: YES 
user_id=21627

Ok. Can you come up with a patch?

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2006-10-20 17:35

Message:
Logged In: YES 
user_id=12364

Sorry, I wasn't clear.  I only intended this to be about the
unicode type.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-20 09:40

Message:
Logged In: YES 
user_id=21627

The Python string type is not at all Unicode compliant, so I
don't see a need to use Unicode terminology to explain it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581182&group_id=5470

From noreply at sourceforge.net  Sat Oct 21 20:02:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Oct 2006 11:02:26 -0700
Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if
	test_ctypes is run
Message-ID: <E1GbLAw-0001Y9-IU@sc8-sf-web3.sourceforge.net>

Bugs item #1581906, was opened at 2006-10-21 13:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run

Initial Comment:
I noticed a test_sqlite test failure on my Mac G5 the other day while trying 
to set up a buildbot for sqlalchemy.  Everything runs fine on my G4 
powerbook.  Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, 
build 5026.

I whittled the problem down to just having test_ctypes and test_sqlite 
enabled, then further whittled it down to just having Lib/ctypes/test/
test_find.py available (all other ctypes tests eliminated).  More detailed 
problem descriptions are in these two postings to python-dev:

    http://article.gmane.org/gmane.comp.python.devel/84478
    http://article.gmane.org/gmane.comp.python.devel/84481

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470

From noreply at sourceforge.net  Sat Oct 21 20:04:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Oct 2006 11:04:54 -0700
Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if
	test_ctypes is run
Message-ID: <E1GbLDK-0001tV-Ma@sc8-sf-web5.sourceforge.net>

Bugs item #1581906, was opened at 2006-10-21 13:02
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run

Initial Comment:
I noticed a test_sqlite test failure on my Mac G5 the other day while trying 
to set up a buildbot for sqlalchemy.  Everything runs fine on my G4 
powerbook.  Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, 
build 5026.

I whittled the problem down to just having test_ctypes and test_sqlite 
enabled, then further whittled it down to just having Lib/ctypes/test/
test_find.py available (all other ctypes tests eliminated).  More detailed 
problem descriptions are in these two postings to python-dev:

    http://article.gmane.org/gmane.comp.python.devel/84478
    http://article.gmane.org/gmane.comp.python.devel/84481

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-10-21 13:04

Message:
Logged In: YES 
user_id=44345

Another article here:

    http://article.gmane.org/gmane.comp.python.devel/84487


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470

From noreply at sourceforge.net  Sun Oct 22 15:16:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 22 Oct 2006 06:16:35 -0700
Subject: [ python-Bugs-1582282 ] email.header decode within word
Message-ID: <E1GbdBr-0000DC-Bk@sc8-sf-web4.sourceforge.net>

Bugs item #1582282, was opened at 2006-10-22 13:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.header decode within word

Initial Comment:
The problem is filed in mailman bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=1578539&group_id=103&atid=100103

While Microsoft Entourage's way of encoding iso-8859-1
text is not compliant with RFC-2047, Python
email.header.decode_header should treat this 'word' as
a simple us-ascii string and should not parse into
series of string/charset list.

Sm=?ISO-8859-1?B?9g==?=rg=?ISO-8859-1?B?5Q==?=sbord
should be parsed as
[('Sm=?ISO-8859-1?B?9rg==?=g=?ISO-8859-1?B?5Q==?=sbord',
None)], not as [('Sm', None), ('\xf6', 'iso-8859-1'),
('g', None), ('\xe5', 'iso-8859-1'), ('sbord', None)]



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470

From noreply at sourceforge.net  Sun Oct 22 16:20:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 22 Oct 2006 07:20:50 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1GbeC2-0000TU-4r@sc8-sf-web2.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 20:38
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Chris (spotvt01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-22 16:20

Message:
Logged In: YES 
user_id=21627

It's actually not a bug in the Python configure, but a
limitation of AMD64 (or, rather, the linker/dynamic loader
toolchain).

It complains that some object file of Python wasn't compiled
with -fPIC (position-independent code). This is a problem
only if
a) you are linking a static library into a shared one
(mod_python, in this case), and
b) the object files in the static library weren't compiled
with -fPIC, and
c) the system doesn't support position-dependent code in a
shared library

As you may have guessed by now, it is really c) which I
blame. On all other modern systems, linking non-PIC objects
into a shared library is supported (albeit sometimes with a
performance loss on startup).

So your options are
a) don't build a static libpython, instead, build Python
with --enable-shared. This will give you libpython24.so
which can then be linked "into" mod_python
b) manually add -fPIC to the list of compiler options when
building Python, by editing the Makefile after configure has run
c) find a way to overcome the platform limitation. E.g. on
Solaris, the linker supports an impure-text option which
instructs it to accept relocations in a shared library.

You might wish that the Python build process supported
option b), i.e. automatically adds -fPIC on Linux/AMD64.
IMO, this would be a bad choice, since -fPIC itself usually
causes a performance loss, and isn't needed when we link
libpython24.a into the interpreter (which is an executable,
not a shared library).

Therefore, I'll close this as "won't fix", and recommend to
go with solution a).

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 21:32

Message:
Logged In: YES 
user_id=1624982

I think the important part of the mod_python compile error
is the last part where the linker fails to link in
libpython2.4.a   ... that's why I think it's an error with
the configure file for python.  It says that libpython2.4.a
should be compiled with position-independant-code.  If I
remember correctly, any static library needs to be PIC for a
x86_64 machine ... that's why it seems like an error for python.

/usr/bin/ld:
/usr/lib/python2.4/config/libpython2.4.a(abstract.o):
relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
/usr/lib/python2.4/config/libpython2.4.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 21:14

Message:
Logged In: YES 
user_id=849994

actually, this is okay, the "pending" status is
automatically set to "open" again when the OP posts an answer.

I can't read anything out of that error log, however,
perhaps Martin can.

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 21:04

Message:
Logged In: YES 
user_id=1624982

wait, I didn't mean to change the status, sory about that.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 20:56

Message:
Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 20:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 04:00:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 22 Oct 2006 19:00:35 -0700
Subject: [ python-Bugs-1565509 ] Repair or Change installation error
Message-ID: <E1Gbp7D-0001FM-VE@sc8-sf-web4.sourceforge.net>

Bugs item #1565509, was opened at 2006-09-26 05:34
Message generated for change (Comment added) made by ghazel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565509&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Hazel (ghazel)
Assigned to: Martin v. L?wis (loewis)
Summary: Repair or Change installation error

Initial Comment:
When I re-run the Python 2.5 final installer and 
choose either Repair or Change options, it makes it to 
the "Publish product information" step then says:

"A network error occurred while attempting to read 
from the file:

C:\Documents and Settings\username\Desktop\python-2.5
[1].msi"

The thing is, I saved the file as python-2.5.msi and 
the file it mentions does not exist. If I copy python-
2.5.msi to python-2.5[1].msi, then run python-2.5.msi, 
the installation works!

----------------------------------------------------------------------

>Comment By: Greg Hazel (ghazel)
Date: 2006-10-23 02:00

Message:
Logged In: YES 
user_id=731668

Attached is the python.log you asked for. Probably what 
happened is the first time I installed it, IE called the 
binary python-2.5[1].msi. Subsequently when I downloaded a 
new one (because the old one was cleared from my IE cache 
long ago) it looked for an installer with the old name 
as "Package name retrieved from configuration data" would 
indicate.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-14 20:19

Message:
Logged In: YES 
user_id=21627

Can you please run the installer with "msiexec /i <filename>
/l*v python.log", and attach a compressed version of
python.log to this report?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565509&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 11:42:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 02:42:48 -0700
Subject: [ python-Bugs-1582742 ] Python is dumping core after the test
	test_ctypes
Message-ID: <E1GbwKW-0000th-No@sc8-sf-web5.sourceforge.net>

Bugs item #1582742, was opened at 2006-10-23 16:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: shashi (shashikala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python is dumping core after the test test_ctypes

Initial Comment:


Hi ,

  Iam building Python-2.5 on HPUX Itanium. The 
compilation is done without any error, but while 
testing the same using gmake test it is dumping core 
telling "Segementation Fault" after the test 
test_ctypes. Please help me in resolving the above 
issue.Iam attaching the output of gmake test.

Thanks in advance,



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 15:16:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 06:16:28 -0700
Subject: [ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing
	files
Message-ID: <E1GbzfI-0003Ku-Cx@sc8-sf-web1.sourceforge.net>

Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulrich Hockenbrink (uhocke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 15:21:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 06:21:57 -0700
Subject: [ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing
	files
Message-ID: <E1Gbzkb-0007Kk-Kv@sc8-sf-web3.sourceforge.net>

Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by uhocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulrich Hockenbrink (uhocke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




----------------------------------------------------------------------

>Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 15:22:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 06:22:55 -0700
Subject: [ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing
	files
Message-ID: <E1GbzlX-0007Qv-I4@sc8-sf-web3.sourceforge.net>

Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by uhocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulrich Hockenbrink (uhocke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




----------------------------------------------------------------------

>Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 15:27:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 06:27:48 -0700
Subject: [ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing
	files
Message-ID: <E1GbzqG-0004PJ-DL@sc8-sf-web1.sourceforge.net>

Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by uhocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulrich Hockenbrink (uhocke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




----------------------------------------------------------------------

>Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:27

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 16:37:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 07:37:31 -0700
Subject: [ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing
	files
Message-ID: <E1Gc0vj-00067l-HA@sc8-sf-web2.sourceforge.net>

Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulrich Hockenbrink (uhocke)
>Assigned to: Martin v. L?wis (loewis)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-23 14:37

Message:
Logged In: YES 
user_id=849994

Is building 2.5 with VC 6 still supported at all?

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:27

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 16:45:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 07:45:19 -0700
Subject: [ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing
	files
Message-ID: <E1Gc13H-0006v2-Ao@sc8-sf-web2.sourceforge.net>

Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by uhocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulrich Hockenbrink (uhocke)
Assigned to: Martin v. L?wis (loewis)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




----------------------------------------------------------------------

>Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 14:45

Message:
Logged In: YES 
user_id=1627884

Yes it is. 
Under \Python-2.5\PC\VC6 you can find a Visual Studio 6.0
workspace file.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-23 14:37

Message:
Logged In: YES 
user_id=849994

Is building 2.5 with VC 6 still supported at all?

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:27

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 17:00:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 08:00:27 -0700
Subject: [ python-Bugs-1580726 ] Configure script does not work for RHEL 4
	x86_64
Message-ID: <E1Gc1Hv-0000Bl-K3@sc8-sf-web3.sourceforge.net>

Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Comment added) made by spotvt01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Chris (spotvt01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

----------------------------------------------------------------------

>Comment By: Chris (spotvt01)
Date: 2006-10-23 15:00

Message:
Logged In: YES 
user_id=1624982

OK, thanx for the time/tutelage.

I'll ask you off line about some other difficulties I'm
having with 64 & 32-bit python library locations.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-22 14:20

Message:
Logged In: YES 
user_id=21627

It's actually not a bug in the Python configure, but a
limitation of AMD64 (or, rather, the linker/dynamic loader
toolchain).

It complains that some object file of Python wasn't compiled
with -fPIC (position-independent code). This is a problem
only if
a) you are linking a static library into a shared one
(mod_python, in this case), and
b) the object files in the static library weren't compiled
with -fPIC, and
c) the system doesn't support position-dependent code in a
shared library

As you may have guessed by now, it is really c) which I
blame. On all other modern systems, linking non-PIC objects
into a shared library is supported (albeit sometimes with a
performance loss on startup).

So your options are
a) don't build a static libpython, instead, build Python
with --enable-shared. This will give you libpython24.so
which can then be linked "into" mod_python
b) manually add -fPIC to the list of compiler options when
building Python, by editing the Makefile after configure has run
c) find a way to overcome the platform limitation. E.g. on
Solaris, the linker supports an impure-text option which
instructs it to accept relocations in a shared library.

You might wish that the Python build process supported
option b), i.e. automatically adds -fPIC on Linux/AMD64.
IMO, this would be a bad choice, since -fPIC itself usually
causes a performance loss, and isn't needed when we link
libpython24.a into the interpreter (which is an executable,
not a shared library).

Therefore, I'll close this as "won't fix", and recommend to
go with solution a).

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 19:32

Message:
Logged In: YES 
user_id=1624982

I think the important part of the mod_python compile error
is the last part where the linker fails to link in
libpython2.4.a   ... that's why I think it's an error with
the configure file for python.  It says that libpython2.4.a
should be compiled with position-independant-code.  If I
remember correctly, any static library needs to be PIC for a
x86_64 machine ... that's why it seems like an error for python.

/usr/bin/ld:
/usr/lib/python2.4/config/libpython2.4.a(abstract.o):
relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
/usr/lib/python2.4/config/libpython2.4.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 19:14

Message:
Logged In: YES 
user_id=849994

actually, this is okay, the "pending" status is
automatically set to "open" again when the OP posts an answer.

I can't read anything out of that error log, however,
perhaps Martin can.

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 19:04

Message:
Logged In: YES 
user_id=1624982

wait, I didn't mean to change the status, sory about that.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 18:56

Message:
Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

----------------------------------------------------------------------

Comment By: Chris (spotvt01)
Date: 2006-10-19 18:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 20:13:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 11:13:38 -0700
Subject: [ python-Bugs-1583060 ] class member inconsistancies
Message-ID: <E1Gc4Is-0002Zd-07@sc8-sf-web4.sourceforge.net>

Bugs item #1583060, was opened at 2006-10-23 14:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583060&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: EricDaigno (santaroga)
Assigned to: Nobody/Anonymous (nobody)
Summary: class member inconsistancies

Initial Comment:
Hi...  When coding rapid classes I stumbled upon a
strange behaviour in the way python deals with data
membership of it's instances (new style) when using C
struct like container classes


behaviour changes when data members are declared in the
class itself as opposed to be declared in the __init__
method...

I understand that python does not perform any sort of
initialization outside of __init__ but this really
create confusion as to what is allowed and what is not
and is clear inconstancy that is either a language
usability bug of a plain buf in class
creation-initialization.

The problem happens when declaring a class that does
not contain __init__ method override but contains a
bunch of data elements that are initialized in the
declaration.

Expected behaviour would be that when a new instance is
created the python interpreter would create a new
instance and initialize the members as stated in the
class declaration and then call the __init__ method
(from object or the overriden __init__ from the class)

The reality is quite different.

Immutables (string) are dealt with correctly but
mutables (list, dict) are initialized only once.  Every
subsequent instantiation of the class will therefore
see new instances of member immutables objects but will
SHARE instances of the member mutables.

I have created a small programm that illustrate the
behaviour :

------------------------------------------------CodeStart
 

class A(object):
    def __init__(self):
        
        
        self.argsList = []
        self.dictArgs = {}
        self.ARG1 = ""
        self.ARG2 = ""
    
    def multUnnammedArgs(self,
                         *argsList):
        if not argsList is None:
            self.argsList += argsList
            
            
    def multNAmmedArgument(self,
                           **argDict):
        if not argDict is None:
            for i in argDict.iteritems():
                self.dictArgs[i[0]] = i[1]
                
    def mixedArguments(self, 
                       ARG1,
                       ARG2,
                       *argList,
                       **argDict):
        self.ARG1 = ARG1
        self.ARG2 = ARG2
        
        self.multUnnammedArgs(*argList)
        
        self.multNAmmedArgument(**argDict)
            
    def __str__(self):
        string = "Object A :"
        string += "\n\t\tARG1=" + self.ARG1 
        string += "\n\t\tARG2=" + self.ARG2 
        string += "\n\tUnnammed Arguments"
        for a in self.argsList:
            string += "\n\t\t" + a

        string += "\n\tNamed Arguments"
        for a in self.dictArgs.iteritems():
            string += "\n\t\t" + a[0] + "=" + a[1]
            
        return string


if __name__ == '__main__':
    obj = A()
    
    obj.multUnnammedArgs("arg1", "arg2", "arg3")
    print obj
    
    obj.multNAmmedArgument(TOTO = "toto",
                           TITI = "titi",
                           TaTa = "tATa")
    
    print obj   
    obj.mixedArguments(ARG1="ZeArg1",
                       ARG2="ZeArg2",
                       TOTO2 = "toto2",
                       TITI2 = "titi2",
                       TaTa2 = "tATa2")
    print obj     

-----------------------------------------------Code End


Here is the dump of my python environment 

---------------------------------------------Dump Start
[eric at speigel ~]$ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /lesia/toolbox/python/lib/python2.4/site.pyc matches
/lesia/toolbox/python/lib/python2.4/site.py
import site # precompiled from
/lesia/toolbox/python/lib/python2.4/site.pyc
# /lesia/toolbox/python/lib/python2.4/os.pyc matches
/lesia/toolbox/python/lib/python2.4/os.py
import os # precompiled from
/lesia/toolbox/python/lib/python2.4/os.pyc
import posix # builtin
# /lesia/toolbox/python/lib/python2.4/posixpath.pyc
matches /lesia/toolbox/python/lib/python2.4/posixpath.py
import posixpath # precompiled from
/lesia/toolbox/python/lib/python2.4/posixpath.pyc
# /lesia/toolbox/python/lib/python2.4/stat.pyc matches
/lesia/toolbox/python/lib/python2.4/stat.py
import stat # precompiled from
/lesia/toolbox/python/lib/python2.4/stat.pyc
# /lesia/toolbox/python/lib/python2.4/UserDict.pyc
matches /lesia/toolbox/python/lib/python2.4/UserDict.py
import UserDict # precompiled from
/lesia/toolbox/python/lib/python2.4/UserDict.pyc
# /lesia/toolbox/python/lib/python2.4/copy_reg.pyc
matches /lesia/toolbox/python/lib/python2.4/copy_reg.py
import copy_reg # precompiled from
/lesia/toolbox/python/lib/python2.4/copy_reg.pyc
# /lesia/toolbox/python/lib/python2.4/types.pyc matches
/lesia/toolbox/python/lib/python2.4/types.py
import types # precompiled from
/lesia/toolbox/python/lib/python2.4/types.pyc
# /lesia/toolbox/python/lib/python2.4/warnings.pyc
matches /lesia/toolbox/python/lib/python2.4/warnings.py
import warnings # precompiled from
/lesia/toolbox/python/lib/python2.4/warnings.pyc
# /lesia/toolbox/python/lib/python2.4/linecache.pyc
matches /lesia/toolbox/python/lib/python2.4/linecache.py
import linecache # precompiled from
/lesia/toolbox/python/lib/python2.4/linecache.pyc
import encodings # directory
/lesia/toolbox/python/lib/python2.4/encodings
#
/lesia/toolbox/python/lib/python2.4/encodings/__init__.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/__init__.py
import encodings # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/__init__.pyc
# /lesia/toolbox/python/lib/python2.4/codecs.pyc
matches /lesia/toolbox/python/lib/python2.4/codecs.py
import codecs # precompiled from
/lesia/toolbox/python/lib/python2.4/codecs.pyc
import _codecs # builtin
#
/lesia/toolbox/python/lib/python2.4/encodings/aliases.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/aliases.py
import encodings.aliases # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/aliases.pyc
#
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.py
import encodings.utf_8 # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.pyc
Python 2.4.2 (#1, Aug  1 2006, 16:57:48)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
dlopen("/lesia/toolbox/python/lib/python2.4/lib-dynload/readline.so",
2);
import readline # dynamically loaded from
/lesia/toolbox/python/lib/python2.4/lib-dynload/readline.so
>>>
-------------------------------------------Dump end

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583060&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 20:17:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 11:17:48 -0700
Subject: [ python-Bugs-1583060 ] class member inconsistancies
Message-ID: <E1Gc4Mu-0000a6-S1@sc8-sf-web1.sourceforge.net>

Bugs item #1583060, was opened at 2006-10-23 14:13
Message generated for change (Comment added) made by santaroga
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583060&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: EricDaigno (santaroga)
Assigned to: Nobody/Anonymous (nobody)
Summary: class member inconsistancies

Initial Comment:
Hi...  When coding rapid classes I stumbled upon a
strange behaviour in the way python deals with data
membership of it's instances (new style) when using C
struct like container classes


behaviour changes when data members are declared in the
class itself as opposed to be declared in the __init__
method...

I understand that python does not perform any sort of
initialization outside of __init__ but this really
create confusion as to what is allowed and what is not
and is clear inconstancy that is either a language
usability bug of a plain buf in class
creation-initialization.

The problem happens when declaring a class that does
not contain __init__ method override but contains a
bunch of data elements that are initialized in the
declaration.

Expected behaviour would be that when a new instance is
created the python interpreter would create a new
instance and initialize the members as stated in the
class declaration and then call the __init__ method
(from object or the overriden __init__ from the class)

The reality is quite different.

Immutables (string) are dealt with correctly but
mutables (list, dict) are initialized only once.  Every
subsequent instantiation of the class will therefore
see new instances of member immutables objects but will
SHARE instances of the member mutables.

I have created a small programm that illustrate the
behaviour :

------------------------------------------------CodeStart
 

class A(object):
    def __init__(self):
        
        
        self.argsList = []
        self.dictArgs = {}
        self.ARG1 = ""
        self.ARG2 = ""
    
    def multUnnammedArgs(self,
                         *argsList):
        if not argsList is None:
            self.argsList += argsList
            
            
    def multNAmmedArgument(self,
                           **argDict):
        if not argDict is None:
            for i in argDict.iteritems():
                self.dictArgs[i[0]] = i[1]
                
    def mixedArguments(self, 
                       ARG1,
                       ARG2,
                       *argList,
                       **argDict):
        self.ARG1 = ARG1
        self.ARG2 = ARG2
        
        self.multUnnammedArgs(*argList)
        
        self.multNAmmedArgument(**argDict)
            
    def __str__(self):
        string = "Object A :"
        string += "\n\t\tARG1=" + self.ARG1 
        string += "\n\t\tARG2=" + self.ARG2 
        string += "\n\tUnnammed Arguments"
        for a in self.argsList:
            string += "\n\t\t" + a

        string += "\n\tNamed Arguments"
        for a in self.dictArgs.iteritems():
            string += "\n\t\t" + a[0] + "=" + a[1]
            
        return string


if __name__ == '__main__':
    obj = A()
    
    obj.multUnnammedArgs("arg1", "arg2", "arg3")
    print obj
    
    obj.multNAmmedArgument(TOTO = "toto",
                           TITI = "titi",
                           TaTa = "tATa")
    
    print obj   
    obj.mixedArguments(ARG1="ZeArg1",
                       ARG2="ZeArg2",
                       TOTO2 = "toto2",
                       TITI2 = "titi2",
                       TaTa2 = "tATa2")
    print obj     

-----------------------------------------------Code End


Here is the dump of my python environment 

---------------------------------------------Dump Start
[eric at speigel ~]$ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /lesia/toolbox/python/lib/python2.4/site.pyc matches
/lesia/toolbox/python/lib/python2.4/site.py
import site # precompiled from
/lesia/toolbox/python/lib/python2.4/site.pyc
# /lesia/toolbox/python/lib/python2.4/os.pyc matches
/lesia/toolbox/python/lib/python2.4/os.py
import os # precompiled from
/lesia/toolbox/python/lib/python2.4/os.pyc
import posix # builtin
# /lesia/toolbox/python/lib/python2.4/posixpath.pyc
matches /lesia/toolbox/python/lib/python2.4/posixpath.py
import posixpath # precompiled from
/lesia/toolbox/python/lib/python2.4/posixpath.pyc
# /lesia/toolbox/python/lib/python2.4/stat.pyc matches
/lesia/toolbox/python/lib/python2.4/stat.py
import stat # precompiled from
/lesia/toolbox/python/lib/python2.4/stat.pyc
# /lesia/toolbox/python/lib/python2.4/UserDict.pyc
matches /lesia/toolbox/python/lib/python2.4/UserDict.py
import UserDict # precompiled from
/lesia/toolbox/python/lib/python2.4/UserDict.pyc
# /lesia/toolbox/python/lib/python2.4/copy_reg.pyc
matches /lesia/toolbox/python/lib/python2.4/copy_reg.py
import copy_reg # precompiled from
/lesia/toolbox/python/lib/python2.4/copy_reg.pyc
# /lesia/toolbox/python/lib/python2.4/types.pyc matches
/lesia/toolbox/python/lib/python2.4/types.py
import types # precompiled from
/lesia/toolbox/python/lib/python2.4/types.pyc
# /lesia/toolbox/python/lib/python2.4/warnings.pyc
matches /lesia/toolbox/python/lib/python2.4/warnings.py
import warnings # precompiled from
/lesia/toolbox/python/lib/python2.4/warnings.pyc
# /lesia/toolbox/python/lib/python2.4/linecache.pyc
matches /lesia/toolbox/python/lib/python2.4/linecache.py
import linecache # precompiled from
/lesia/toolbox/python/lib/python2.4/linecache.pyc
import encodings # directory
/lesia/toolbox/python/lib/python2.4/encodings
#
/lesia/toolbox/python/lib/python2.4/encodings/__init__.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/__init__.py
import encodings # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/__init__.pyc
# /lesia/toolbox/python/lib/python2.4/codecs.pyc
matches /lesia/toolbox/python/lib/python2.4/codecs.py
import codecs # precompiled from
/lesia/toolbox/python/lib/python2.4/codecs.pyc
import _codecs # builtin
#
/lesia/toolbox/python/lib/python2.4/encodings/aliases.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/aliases.py
import encodings.aliases # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/aliases.pyc
#
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.py
import encodings.utf_8 # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.pyc
Python 2.4.2 (#1, Aug  1 2006, 16:57:48)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
dlopen("/lesia/toolbox/python/lib/python2.4/lib-dynload/readline.so",
2);
import readline # dynamically loaded from
/lesia/toolbox/python/lib/python2.4/lib-dynload/readline.so
>>>
-------------------------------------------Dump end

----------------------------------------------------------------------

>Comment By: EricDaigno (santaroga)
Date: 2006-10-23 14:17

Message:
Logged In: YES 
user_id=1628112

darn....

Attached the wrong code ...  My bad, sorry about that.

Here is the correct test programm
 ------------------------------------------------Code Start

class A(object):
    aString = "first init..."
    aList = []
    aDict = {}

    def __str__(self):
        string = ""
        
        string += "_____________" + self.aString
        
        string += "\n\t aList= "
        for elem in self.aList:
            string += "\n\t\t" + elem
        
        string += "\n\t aDict= "
        for elem in self.aDict.keys():
            string += "\n\t\t" + elem + "=" + self.aDict[elem]
        
        string += "\n--------------"
        
        return string

if __name__ == '__main__':
    firstInstance = A()
    print firstInstance
    print "This is as expected from the class declaration."
    print "Members are initialized as declared in the class "
    print "and the new instance is clean"
    
    firstInstance.aString = "firstInstance's String"
    firstInstance.aList.append("firstInstance first List
element")
    firstInstance.aList.append("firstInstance second List
element")
    firstInstance.aList.append("firstInstance third List
element")
    firstInstance.aDict["firstInstance"] =
"SpecificToFirstInstance"
    firstInstance.aDict["whatever"] = "FirstInstance's Whatever"
    
    print firstInstance
    print "Again... So far so good"
    print ""
    
    secondInstance = A()
    print secondInstance
    print "This however is completely unsuspected."
    print "The class initialized the string properly but "
    print "mutables have not been replaced with the new
instances of list and dict"
    print "as we soiuld expect from the class declaration"
    print "It gets beter..."

    secondInstance.aString = "secondInstance String"
    secondInstance.aList.append("secondInstance first List
element")
    secondInstance.aList.append("secondInstance second List
element")
    secondInstance.aList.append("secondInstance third List
element")
    secondInstance.aDict["secondInstance"] =
"SpecificToSecondInstance"
    secondInstance.aDict["whatever"] = "econdInstance's
Whatever"

    print firstInstance
    print secondInstance
    print "I therefore conclude that when dealing with "
    print "'default' initlialization that Immutables are
dealt with properly but"
    print "mutables mutables are not initialized."
    print "This behaviour is contradictory from what one
would expect when "
    print "declaring a simple class that acts like a C struct"

 ------------------------------------------Code End

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583060&group_id=5470

From noreply at sourceforge.net  Mon Oct 23 22:41:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 13:41:14 -0700
Subject: [ python-Bugs-1583060 ] class member inconsistancies
Message-ID: <E1Gc6bi-0003gl-1c@sc8-sf-web2.sourceforge.net>

Bugs item #1583060, was opened at 2006-10-23 18:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583060&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Type/class unification
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: EricDaigno (santaroga)
Assigned to: Nobody/Anonymous (nobody)
Summary: class member inconsistancies

Initial Comment:
Hi...  When coding rapid classes I stumbled upon a
strange behaviour in the way python deals with data
membership of it's instances (new style) when using C
struct like container classes


behaviour changes when data members are declared in the
class itself as opposed to be declared in the __init__
method...

I understand that python does not perform any sort of
initialization outside of __init__ but this really
create confusion as to what is allowed and what is not
and is clear inconstancy that is either a language
usability bug of a plain buf in class
creation-initialization.

The problem happens when declaring a class that does
not contain __init__ method override but contains a
bunch of data elements that are initialized in the
declaration.

Expected behaviour would be that when a new instance is
created the python interpreter would create a new
instance and initialize the members as stated in the
class declaration and then call the __init__ method
(from object or the overriden __init__ from the class)

The reality is quite different.

Immutables (string) are dealt with correctly but
mutables (list, dict) are initialized only once.  Every
subsequent instantiation of the class will therefore
see new instances of member immutables objects but will
SHARE instances of the member mutables.

I have created a small programm that illustrate the
behaviour :

------------------------------------------------CodeStart
 

class A(object):
    def __init__(self):
        
        
        self.argsList = []
        self.dictArgs = {}
        self.ARG1 = ""
        self.ARG2 = ""
    
    def multUnnammedArgs(self,
                         *argsList):
        if not argsList is None:
            self.argsList += argsList
            
            
    def multNAmmedArgument(self,
                           **argDict):
        if not argDict is None:
            for i in argDict.iteritems():
                self.dictArgs[i[0]] = i[1]
                
    def mixedArguments(self, 
                       ARG1,
                       ARG2,
                       *argList,
                       **argDict):
        self.ARG1 = ARG1
        self.ARG2 = ARG2
        
        self.multUnnammedArgs(*argList)
        
        self.multNAmmedArgument(**argDict)
            
    def __str__(self):
        string = "Object A :"
        string += "\n\t\tARG1=" + self.ARG1 
        string += "\n\t\tARG2=" + self.ARG2 
        string += "\n\tUnnammed Arguments"
        for a in self.argsList:
            string += "\n\t\t" + a

        string += "\n\tNamed Arguments"
        for a in self.dictArgs.iteritems():
            string += "\n\t\t" + a[0] + "=" + a[1]
            
        return string


if __name__ == '__main__':
    obj = A()
    
    obj.multUnnammedArgs("arg1", "arg2", "arg3")
    print obj
    
    obj.multNAmmedArgument(TOTO = "toto",
                           TITI = "titi",
                           TaTa = "tATa")
    
    print obj   
    obj.mixedArguments(ARG1="ZeArg1",
                       ARG2="ZeArg2",
                       TOTO2 = "toto2",
                       TITI2 = "titi2",
                       TaTa2 = "tATa2")
    print obj     

-----------------------------------------------Code End


Here is the dump of my python environment 

---------------------------------------------Dump Start
[eric at speigel ~]$ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /lesia/toolbox/python/lib/python2.4/site.pyc matches
/lesia/toolbox/python/lib/python2.4/site.py
import site # precompiled from
/lesia/toolbox/python/lib/python2.4/site.pyc
# /lesia/toolbox/python/lib/python2.4/os.pyc matches
/lesia/toolbox/python/lib/python2.4/os.py
import os # precompiled from
/lesia/toolbox/python/lib/python2.4/os.pyc
import posix # builtin
# /lesia/toolbox/python/lib/python2.4/posixpath.pyc
matches /lesia/toolbox/python/lib/python2.4/posixpath.py
import posixpath # precompiled from
/lesia/toolbox/python/lib/python2.4/posixpath.pyc
# /lesia/toolbox/python/lib/python2.4/stat.pyc matches
/lesia/toolbox/python/lib/python2.4/stat.py
import stat # precompiled from
/lesia/toolbox/python/lib/python2.4/stat.pyc
# /lesia/toolbox/python/lib/python2.4/UserDict.pyc
matches /lesia/toolbox/python/lib/python2.4/UserDict.py
import UserDict # precompiled from
/lesia/toolbox/python/lib/python2.4/UserDict.pyc
# /lesia/toolbox/python/lib/python2.4/copy_reg.pyc
matches /lesia/toolbox/python/lib/python2.4/copy_reg.py
import copy_reg # precompiled from
/lesia/toolbox/python/lib/python2.4/copy_reg.pyc
# /lesia/toolbox/python/lib/python2.4/types.pyc matches
/lesia/toolbox/python/lib/python2.4/types.py
import types # precompiled from
/lesia/toolbox/python/lib/python2.4/types.pyc
# /lesia/toolbox/python/lib/python2.4/warnings.pyc
matches /lesia/toolbox/python/lib/python2.4/warnings.py
import warnings # precompiled from
/lesia/toolbox/python/lib/python2.4/warnings.pyc
# /lesia/toolbox/python/lib/python2.4/linecache.pyc
matches /lesia/toolbox/python/lib/python2.4/linecache.py
import linecache # precompiled from
/lesia/toolbox/python/lib/python2.4/linecache.pyc
import encodings # directory
/lesia/toolbox/python/lib/python2.4/encodings
#
/lesia/toolbox/python/lib/python2.4/encodings/__init__.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/__init__.py
import encodings # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/__init__.pyc
# /lesia/toolbox/python/lib/python2.4/codecs.pyc
matches /lesia/toolbox/python/lib/python2.4/codecs.py
import codecs # precompiled from
/lesia/toolbox/python/lib/python2.4/codecs.pyc
import _codecs # builtin
#
/lesia/toolbox/python/lib/python2.4/encodings/aliases.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/aliases.py
import encodings.aliases # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/aliases.pyc
#
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.pyc
matches
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.py
import encodings.utf_8 # precompiled from
/lesia/toolbox/python/lib/python2.4/encodings/utf_8.pyc
Python 2.4.2 (#1, Aug  1 2006, 16:57:48)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
dlopen("/lesia/toolbox/python/lib/python2.4/lib-dynload/readline.so",
2);
import readline # dynamically loaded from
/lesia/toolbox/python/lib/python2.4/lib-dynload/readline.so
>>>
-------------------------------------------Dump end

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-23 20:41

Message:
Logged In: YES 
user_id=849994

This is not a bug. Names bound in a class namespace are
really attributes of the class object.
Class instances can access these attributes as "self.attr",
but as long as they aren't rebound
(by "self.attr = value"), they are attributes of the class,
not the instance.

----------------------------------------------------------------------

Comment By: EricDaigno (santaroga)
Date: 2006-10-23 18:17

Message:
Logged In: YES 
user_id=1628112

darn....

Attached the wrong code ...  My bad, sorry about that.

Here is the correct test programm
 ------------------------------------------------Code Start

class A(object):
    aString = "first init..."
    aList = []
    aDict = {}

    def __str__(self):
        string = ""
        
        string += "_____________" + self.aString
        
        string += "\n\t aList= "
        for elem in self.aList:
            string += "\n\t\t" + elem
        
        string += "\n\t aDict= "
        for elem in self.aDict.keys():
            string += "\n\t\t" + elem + "=" + self.aDict[elem]
        
        string += "\n--------------"
        
        return string

if __name__ == '__main__':
    firstInstance = A()
    print firstInstance
    print "This is as expected from the class declaration."
    print "Members are initialized as declared in the class "
    print "and the new instance is clean"
    
    firstInstance.aString = "firstInstance's String"
    firstInstance.aList.append("firstInstance first List
element")
    firstInstance.aList.append("firstInstance second List
element")
    firstInstance.aList.append("firstInstance third List
element")
    firstInstance.aDict["firstInstance"] =
"SpecificToFirstInstance"
    firstInstance.aDict["whatever"] = "FirstInstance's Whatever"
    
    print firstInstance
    print "Again... So far so good"
    print ""
    
    secondInstance = A()
    print secondInstance
    print "This however is completely unsuspected."
    print "The class initialized the string properly but "
    print "mutables have not been replaced with the new
instances of list and dict"
    print "as we soiuld expect from the class declaration"
    print "It gets beter..."

    secondInstance.aString = "secondInstance String"
    secondInstance.aList.append("secondInstance first List
element")
    secondInstance.aList.append("secondInstance second List
element")
    secondInstance.aList.append("secondInstance third List
element")
    secondInstance.aDict["secondInstance"] =
"SpecificToSecondInstance"
    secondInstance.aDict["whatever"] = "econdInstance's
Whatever"

    print firstInstance
    print secondInstance
    print "I therefore conclude that when dealing with "
    print "'default' initlialization that Immutables are
dealt with properly but"
    print "mutables mutables are not initialized."
    print "This behaviour is contradictory from what one
would expect when "
    print "declaring a simple class that acts like a C struct"

 ------------------------------------------Code End

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583060&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 00:15:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 15:15:00 -0700
Subject: [ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing
	files
Message-ID: <E1Gc84S-0004X4-FJ@sc8-sf-web2.sourceforge.net>

Bugs item #1582856, was opened at 2006-10-23 15:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ulrich Hockenbrink (uhocke)
Assigned to: Martin v. L?wis (loewis)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-24 00:15

Message:
Logged In: YES 
user_id=21627

It wasn't supported in Python 2.5.0. The files were still
there, but known to be non-functional.

Since that release, patches have been contributed to
reportedly make it work again. It's still not supported
anymore, i.e. it's not a release-critical bug if that build
process breaks, and reports that it broke will likely be
closed as "won't fix".

In any case, as patches have been contributed, I'm closing
this as "fixed" now - I can't actually test whether it
works, though, because I don't have VC6 anymore.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 16:45

Message:
Logged In: YES 
user_id=1627884

Yes it is. 
Under \Python-2.5\PC\VC6 you can find a Visual Studio 6.0
workspace file.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-23 16:37

Message:
Logged In: YES 
user_id=849994

Is building 2.5 with VC 6 still supported at all?

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 15:27

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 15:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 15:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 02:54:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 17:54:27 -0700
Subject: [ python-Bugs-1583276 ] Different behavior when stepping through code
	w/ pdb
Message-ID: <E1GcAYl-00051y-9Q@sc8-sf-web5.sourceforge.net>

Bugs item #1583276, was opened at 2006-10-24 00:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different behavior when stepping through code w/ pdb

Initial Comment:
The attached test case will raise a NameError when
executed in pdb by stepping though the code.  The issue
is the EnumType name, which is both a local variable in
the Enum function which is used in the lambda and the
name of an attribute on the EnumValue class.  Since it
is a local variable used in a lambda, it's a freevar. 
What apparently happens is on line 5 the property()
result is stored in frame->f_locals['EnumType'] but it
is deleted the next time FastToLocals is invoked prior
to calling back into the debugger.  This happens when
the freevars values are merged into the locals dictionary.

The example is a stripped down version of code in
turbogears.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 04:20:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 19:20:06 -0700
Subject: [ python-Bugs-1561243 ] mac installer profile patch vs. .bash_login
Message-ID: <200610240220.k9O2K69x008321@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1561243, was opened at 2006-09-19 00:32
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: mac installer profile patch vs. .bash_login

Initial Comment:
The mac installer for 2.4.3 and 2.5 patches ~/.profile or ~/.bash_profile. 
If a .bash_login file exists and no .bash_profile exists the installer 
currently creates a .profile, which won't be used by bash.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-23 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 11:21

Message:
Logged In: YES 
user_id=580910

This is probably fixed in 52238, 52239 and 52240 (trunk, 2.5, 2.4), but needs 
more testing to make sure that we now test for all edge condiditions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561243&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 04:20:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 19:20:06 -0700
Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9
Message-ID: <200610240220.k9O2K6XL008330@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1542949, was opened at 2006-08-18 18:51
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 6
Private: No
Submitted By: David Strozzi (dstrozzi)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: idle in python 2.5c1 freezes on macos 10.3.9

Initial Comment:
Hi,

I installed python 2.5b3 on a powerbook ppc laptop
running macos 10.3.9 a few days ago.  python and idle
worked.  Now I installed 2.5c1.  python works fine from
a terminal.  When I start idle, it loads, puts up its
menu bar, opens a shell window, displays usual startup
info, and gives me a prompt.  But, I can't type or get
a cursor. Whenever I move the mouse over the idle
window or menu bar, I get a spinning color wheel and
can't do anything.

I deleted the whole /library/python tree, reinstalled
2.5c1, and exactly the same thing happened.

Oh, and I rebooted :)

Not sure what is happening, or how to diagnose.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-23 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 11:34

Message:
Logged In: YES 
user_id=580910

I've just checked in a fix for this on all 3 active branches (trunk, 2.5 and 2.4).

BTW. The installer is supposed to install the files in Python.framework as 
owned by group admin, with mode 0664, admin users are supposed to be 
able to edit files and add new software without using sudo. That obviously 
didn't work as designed, the tree is owned by root:wheel on my 10.3.9 
testbox (the only one without a build-from-source install at the moment).

To fix this: open a terminal window and give the following command:
 
   sudo chgrp -R admin /Library/Framework/Python.framework

This will ask for a password, use your own password there. You have to be 
logged in with an admin account to do this.

----------------------------------------------------------------------

Comment By: David Strozzi (dstrozzi)
Date: 2006-09-26 10:01

Message:
Logged In: YES 
user_id=1056922

Great, thanks for sorting this out!

I tried the edit you suggested in your first reply.  Alas,
I'm not root on my system - I am in the admin group, but I
don't have total complete powers.  The Python.Framework dir
in /Library/Frameworks has owner admin and group wheel.  I'm
not in the wheel group, so can't edit files.

I can wait for the patch, or maybe in the future the
installer could make the group admin instead of wheel?  This
may be too esoteric to my system's setup...

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-24 11:46

Message:
Logged In: YES 
user_id=580910

It turns out to be a buglet in python2.5 after all. There is some code in 
distutils.sysconfig to strip out the -arch and -isysroot flags from the build flags 
when you ask for them through that way, but that doesn't fix all variables that 
need to be fixed.

I'll apply a patch in the morning.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-24 09:15

Message:
Logged In: YES 
user_id=580910

I'm seriously temped to call the problem you're having with numpy a bug in 
their system.

What happens is that the binary distribution for Python 2.5 (and 2.4.3 as well) 
is build as a universal binary on OSX 10.4. This is why you see '-arch ppc -
arch x86' in the compiler invocation. This works correctly on 10.4 but not on 
10.3.9, which is why distutils strips those arguments from the command-line 
on 10.3 systems.  That's all fine when you use the stock distutils, but numpy 
uses custom build commands and those don't work correctly with a universal 
build of python on 10.3.

The easiest way for you to get going again is open /Library/Frameworks/
Python.framework/Versions/2.5/lib/python2.5/config/Makefile in a text 
editor. Remove '-arch ppc -arch i386 -isysroot /Developer/SDKs/
MacOSX10.4u.sdk' from the definition of BASECFLAGS and LDFLAGS and then 
try to build numpy again


----------------------------------------------------------------------

Comment By: David Strozzi (dstrozzi)
Date: 2006-09-22 15:35

Message:
Logged In: YES 
user_id=1056922

Hi,

Python 2.5 installs, and idle runs, perfectly on my 10.3.9
system!  Kudos to our noble MacOS builder!  Looks like the
problem vanished.

I'm going to risk bugging people here about my inability to
compile numpy 1.0* (* = betas and current release candidate
1) on the same 10.3.9 system.  The end of this post is a
dump of trying to install as per numpy directions.  One line
is very suspicious:

C compiler: gcc -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common
-dynamic -DNDEBUG -g -O3

-arch pcc -arch i386??  Smells bad.

10.4u.sdk??  I have sys 10.3.9;
/Developer/SDKs/MacOSX10.3.0.sdk exists on my system, but
not 10.4u.

Right after this, I get the error:
gcc: cannot specify -o with -c or -S and multiple compilations

gcc 3.3 is my 'main' gcc, although I finked 4.0 but haven't
replaced my 'main' gcc with it.

Anyway, thoughts are greatly appreciated, both by me and
presumably the numpy people (who haven't replied to any of
my bug postings :) )

********** The whole dump **************

> python setup.py install
Running from numpy source directory.
F2PY Version 2_3198
blas_opt_info:
  FOUND:
    extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
    define_macros = [('NO_ATLAS_INFO', 3)]
    extra_compile_args = ['-faltivec',
'-I/System/Library/Frameworks/vecLib.framework/Headers']

lapack_opt_info:
  FOUND:
    extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
    define_macros = [('NO_ATLAS_INFO', 3)]
    extra_compile_args = ['-faltivec']

running install
running build
running config_fc
running build_src
building py_modules sources
building extension "numpy.core.multiarray" sources
Generating build/src.macosx-10.3-fat-2.5/numpy/core/config.h
customize NAGFCompiler
customize AbsoftFCompiler
customize IbmFCompiler
Could not locate executable f95
customize GnuFCompiler
customize GnuFCompiler
customize GnuFCompiler using config
C compiler: gcc -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common
-dynamic -DNDEBUG -g -O3

compile options:
'-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-Inumpy/core/src -Inumpy/core/include
-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-c'
gcc: _configtest.c
gcc: cannot specify -o with -c or -S and multiple compilations
gcc: cannot specify -o with -c or -S and multiple compilations
failure.
removing: _configtest.c _configtest.o
numpy/core/setup.py:50: DeprecationWarning: raising a string
exception is deprecated
  raise "ERROR: Failed to test configuration"
Traceback (most recent call last):
  File "setup.py", line 89, in <module>
    setup_package()
  File "setup.py", line 82, in setup_package
    configuration=configuration )
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/core.py",
line 174, in setup
    return old_setup(**new_attr)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py",
line 151, in setup
    dist.run_commands()
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 974, in run_commands
    self.run_command(cmd)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/install.py",
line 16, in run
    r = old_install.run(self)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/install.py",
line 506, in run
    self.run_command('build')
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py",
line 333, in run_command
    self.distribution.run_command(command)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/build.py",
line 112, in run
    self.run_command(cmd_name)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py",
line 333, in run_command
    self.distribution.run_command(command)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py",
line 87, in run
    self.build_sources()
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py",
line 106, in build_sources
    self.build_extension_sources(ext)
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py",
line 212, in build_extension_sources
    sources = self.generate_sources(sources, ext)
  File
"/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py",
line 270, in generate_sources
    source = func(extension, build_dir)
  File "numpy/core/setup.py", line 50, in generate_config_h
    raise "ERROR: Failed to test configuration"
ERROR: Failed to test configuration

strozzi2 at riata: ~/downloads/numpy-1.0rc1
> 

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-14 14:10

Message:
Logged In: YES 
user_id=580910

The scary bit is that the bug was "fixed" due to unclear differences between 
the build environment used for 2.5c1 and 2.5c2. 

I'll be building 2.5final as well, so expect this will stay fixed but I'm not 
entirely happy due to not knowing what caused the failure in the first place. It 
looks like 2.5c1 was build with a slighly different version of GCC (although 
both machines has Xcode 2.3 installed).

BTW. The issue still exists for 2.4.x, I hope to work on the 2.4 branch this 
weekend.

----------------------------------------------------------------------

Comment By: David Strozzi (dstrozzi)
Date: 2006-09-14 14:03

Message:
Logged In: YES 
user_id=1056922

I just installed python 2.5 rc 2, and IDLE works!  On the
same 10.3.9 laptop which prompted me to post this bug.  I
guess the other who had problems should try rc2, and may
this bug had been laid to rest.

Thanks to whomever fixed it.

----------------------------------------------------------------------

Comment By: diggableme (diggableme)
Date: 2006-09-09 10:18

Message:
Logged In: YES 
user_id=1594326

I am a new user that is experiencing the same exact problem.
 I have OSX.3.9 and everytime I start IDLE, it freezes and
the colorwheel somes up.  When I view the console output,
there are no errors or alert messages.

I have also tried uninstalling and re-installing from the
beginning with the same result.  I have been using the
instructions given at this site:
http://www.python.org/download/mac/
desp
I'm very interested to see if there is in fact a resolution
to this problem.  I'm at my wit's end.

-dig

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-08-28 09:59

Message:
Logged In: YES 
user_id=580910

I've created a new installer from the head of the release25-maint branch and 
that works correctly.

I'm keeping this issue open because I want to investigate why 2.5c1 doesn't 
work while the current head of the 2.5 branch does work.

----------------------------------------------------------------------

Comment By: David Strozzi (dstrozzi)
Date: 2006-08-28 08:48

Message:
Logged In: YES 
user_id=1056922

Well, if there's anything I can do as a 10.3.9 user to test
this, let me know.  Too busy to delve into the python source
code though...

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-08-28 08:22

Message:
Logged In: YES 
user_id=580910

I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, 
but then completely blocks (spinning cursor).

If I start IDLE from the commandline (/Applications/MacPython\ 2.5/
IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a 
valid command name. That requires further looking into, but is a red herring 
for this particular problem, removing the Tk-console hiding code in 
macosxSupport.py results in the same behaviour, without any further output 
on the console as well.

Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't 
help,  IDLE still hangs (Duh, that's because there's a /System/Library/
Frameworks/Tk.framework, which means a user install won't be used for 
IDLE).

The problem is also unrelated to my IDLE.app work, the same problem occurs 
when starting $prefix/lib/python2.5/idlelib/idle.py. 

According to gdb the IDLE process is handing in a semaphore call inside the 
Tcl mainloop. Time to get into serious debugging mode I guess :-(

BTW. IDLE does work correctly on a 10.4.7 system.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-08-28 06:59

Message:
Logged In: YES 
user_id=149084

Maybe priority should be higher?  Hopefully Ronald has 
time to look at this; I don't have access to a Mac.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 04:20:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Oct 2006 19:20:06 -0700
Subject: [ python-Bugs-1570284 ] Launcher reset to factory button provides bad
	command-line
Message-ID: <200610240220.k9O2K6H6008314@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1570284, was opened at 2006-10-03 14:17
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: jjackson (jejackson)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Launcher reset to factory button provides bad command-line

Initial Comment:
If I push the "Reset to factory settings" in Python Launcher's Preferences 
window, the command line gets a bogues "(null)" inserted, which makes a 
mess of things. I don't think that was what was intended.

In trying to debug this, I notice in the source for FileSettings.m, at line 
209
there are two duplicated lines:

            [NSNumber numberWithBool: nosite], @"nosite",
            [NSNumber numberWithBool: nosite], @"nosite",

Also, I notice at FileSettings.m:236

    value = [dict objectForKey: @"nosite"];
    if (value) nosite = [value boolValue];
    value = [dict objectForKey: @"nosite"];
    if (value) tabs = [value boolValue];

I'm wondering if these second "nosite"s should be "tabs", and if that 
would fix the problem.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-23 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 10:44

Message:
Logged In: YES 
user_id=580910

Fixed in revision 52229 (trunk), 52230 (2.5 branch) and 52231/52232 (2.4 
branch).

The latter checkin is a lot larger than just this fix, it is a backport of the entire 
universal binary support code from 2.5 to the official 2.4 tree (the 2.4.3. 
installer was build from an out-of-tree "branch").

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-06 03:26

Message:
Logged In: YES 
user_id=580910

I'll have a look at this this weekend. On first glance the analysis for the source 
code looks correct and both lines should be changed, but I don't have time just 
ow to do this and test the results just now (and then backport to the 2.5 and 2.4 
trees)

P.S. I'll be doing a huge checking on the 2.4 branch this weekend, backporting 
the universal python stuff to the official tree. Last week was busier than 
expected, hence the late checkin.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-03 22:48

Message:
Logged In: YES 
user_id=33168

Ronald, I'm guessing that Jack still doesn't have time.  Do
you know anything about this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 14:05:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 05:05:52 -0700
Subject: [ python-Bugs-1583537 ] tarfile incorrectly handles long filenames
Message-ID: <E1GcL2W-0005sF-Tx@sc8-sf-web6.sourceforge.net>

Bugs item #1583537, was opened at 2006-10-24 14:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Looijmans (cdwave)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile incorrectly handles long filenames

Initial Comment:
tarfile seems to incorrectly handle filenames longer
than 100 characters. This is tarfile as provided with
2.4.3 and 2.4.4. The 0.8.0 version of tarfile is even
worse - it will cut off the last character of any
filename that is exactly 100 in size.

Below the unit test that I use to reproduce the problem:

class Test00tarfile(unittest.TestCase):
    def runtest(self, longName):
        import tarfile
        dst=StringIO()
        src=StringIO("Hello world!")
        srclen = len("Hello world!")
        tar = tarfile.open(mode='w|', fileobj=dst)
        tar.add('test.py')
        info = tar.gettarinfo('test.py', longName)
        info.size = srclen
        tar.addfile(info, src)
        src.seek(0)
        tar.addfile(info, src)
        tar.close()
        dst.seek(0)
        tar = tarfile.open(mode='r|', fileobj=dst)
        info = tar.next()
        self.assertEqual(info.name, 'test.py')
        info = tar.next()
        self.assertEqual(info.size, srclen)
        self.assertEqual(info.name, longName)
        info = tar.next()
        self.assertEqual(info.name, longName)
        info = tar.next()
        self.assertEqual(None, info)
    def testLongFileName200(self):
        "tarfile with 200+ length filename"
        self.runtest("LongName/" + 200 * "x" + "/LongTail")
    def testLongFileName100(self):
        "tarfile with 100 length filename"
       
self.runtest('MyWiki/underlay/pages/(e7ae80e4bd93e4b8ade69687)MoinMoin(2fe5ae89e8a385e6898be5868c)/cache/text_html')


The "200" test fails on the standard version, on
tarfile 0.8.0 the 100 test fails too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583537&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 15:33:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 06:33:51 -0700
Subject: [ python-Bugs-1583537 ] tarfile incorrectly handles long filenames
Message-ID: <E1GcMPf-0004UM-Ra@sc8-sf-web2.sourceforge.net>

Bugs item #1583537, was opened at 2006-10-24 14:05
Message generated for change (Comment added) made by cdwave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Deleted
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Mike Looijmans (cdwave)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile incorrectly handles long filenames

Initial Comment:
tarfile seems to incorrectly handle filenames longer
than 100 characters. This is tarfile as provided with
2.4.3 and 2.4.4. The 0.8.0 version of tarfile is even
worse - it will cut off the last character of any
filename that is exactly 100 in size.

Below the unit test that I use to reproduce the problem:

class Test00tarfile(unittest.TestCase):
    def runtest(self, longName):
        import tarfile
        dst=StringIO()
        src=StringIO("Hello world!")
        srclen = len("Hello world!")
        tar = tarfile.open(mode='w|', fileobj=dst)
        tar.add('test.py')
        info = tar.gettarinfo('test.py', longName)
        info.size = srclen
        tar.addfile(info, src)
        src.seek(0)
        tar.addfile(info, src)
        tar.close()
        dst.seek(0)
        tar = tarfile.open(mode='r|', fileobj=dst)
        info = tar.next()
        self.assertEqual(info.name, 'test.py')
        info = tar.next()
        self.assertEqual(info.size, srclen)
        self.assertEqual(info.name, longName)
        info = tar.next()
        self.assertEqual(info.name, longName)
        info = tar.next()
        self.assertEqual(None, info)
    def testLongFileName200(self):
        "tarfile with 200+ length filename"
        self.runtest("LongName/" + 200 * "x" + "/LongTail")
    def testLongFileName100(self):
        "tarfile with 100 length filename"
       
self.runtest('MyWiki/underlay/pages/(e7ae80e4bd93e4b8ade69687)MoinMoin(2fe5ae89e8a385e6898be5868c)/cache/text_html')


The "200" test fails on the standard version, on
tarfile 0.8.0 the 100 test fails too.

----------------------------------------------------------------------

>Comment By: Mike Looijmans (cdwave)
Date: 2006-10-24 15:33

Message:
Logged In: YES 
user_id=1372511

Test was wrong, and there were distinct bugs in various
versions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583537&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 17:55:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 08:55:57 -0700
Subject: [ python-Bugs-1583862 ] yield+break stops tracing
Message-ID: <E1GcOdB-0004tS-CD@sc8-sf-web4.sourceforge.net>

Bugs item #1583862, was opened at 2006-10-24 17:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing

Initial Comment:
Here is an example script:

def myiter():
    for i in range(10):
        yield i
for i in myiter():
    break
print "foo"

Now, if I try to trace it:

$ python -m trace --trace --count test.py
 --- modulename: threading, funcname: settrace
threading.py(70):     _trace_hook = func
 --- modulename: test, funcname: <module>
test.py(1): def myiter():
test.py(5): for i in myiter():
 --- modulename: test, funcname: myiter
test.py(2):     for i in range(10):
test.py(3):         yield i
test.py(6):     break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
  if i<=max(p.rfind('/'), p.rfind('\\')):
foo

It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.

I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 17:57:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 08:57:04 -0700
Subject: [ python-Bugs-1583863 ] __str__ cannot be overridden on
	unicode-derived classes
Message-ID: <E1GcOeG-00072O-1O@sc8-sf-web3.sourceforge.net>

Bugs item #1583863, was opened at 2006-10-24 15:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583863&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike K (laughingboy0)
Assigned to: Nobody/Anonymous (nobody)
Summary: __str__ cannot be overridden on unicode-derived classes

Initial Comment:
class S(str):
   def __str__(self): return '__str__ overridden'

class U(unicode):
   def __str__(self): return '__str__ overridden'
   def __unicode__(self): return u'__unicode__ overridden'

s = S()
u = U()

print 's:', s
print "str(s):", str(s)
print 's substitued is "%s"\n' % s
print 'u:', u
print "str(u):", str(u)
print 'u substitued is "%s"' % u

-----------------------------------------------------

s: __str__ overridden
str(s): __str__ overridden
s substitued is "__str__ overridden"

u:
str(u): __str__ overridden
u substitued is ""

Results are identical for 2.4.2 and 2.5c2 (running
under windows).



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583863&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 18:03:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 09:03:48 -0700
Subject: [ python-Bugs-1583862 ] yield+break stops tracing
Message-ID: <E1GcOkm-0007hc-Jw@sc8-sf-web3.sourceforge.net>

Bugs item #1583862, was opened at 2006-10-24 17:55
Message generated for change (Settings changed) made by luks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing

Initial Comment:
Here is an example script:

def myiter():
    for i in range(10):
        yield i
for i in myiter():
    break
print "foo"

Now, if I try to trace it:

$ python -m trace --trace --count test.py
 --- modulename: threading, funcname: settrace
threading.py(70):     _trace_hook = func
 --- modulename: test, funcname: <module>
test.py(1): def myiter():
test.py(5): for i in myiter():
 --- modulename: test, funcname: myiter
test.py(2):     for i in range(10):
test.py(3):         yield i
test.py(6):     break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
  if i<=max(p.rfind('/'), p.rfind('\\')):
foo

It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.

I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 18:05:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 09:05:33 -0700
Subject: [ python-Bugs-1583862 ] yield+break stops tracing
Message-ID: <E1GcOmT-0007oN-06@sc8-sf-web2.sourceforge.net>

Bugs item #1583862, was opened at 2006-10-24 17:55
Message generated for change (Comment added) made by luks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing

Initial Comment:
Here is an example script:

def myiter():
    for i in range(10):
        yield i
for i in myiter():
    break
print "foo"

Now, if I try to trace it:

$ python -m trace --trace --count test.py
 --- modulename: threading, funcname: settrace
threading.py(70):     _trace_hook = func
 --- modulename: test, funcname: <module>
test.py(1): def myiter():
test.py(5): for i in myiter():
 --- modulename: test, funcname: myiter
test.py(2):     for i in range(10):
test.py(3):         yield i
test.py(6):     break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
  if i<=max(p.rfind('/'), p.rfind('\\')):
foo

It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.

I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.


----------------------------------------------------------------------

>Comment By: Lukas Lalinsky (luks)
Date: 2006-10-24 18:05

Message:
Logged In: YES 
user_id=587716

Oh, I forgot. This bug is specific to Python 2.5. It works
fine in 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 20:32:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 11:32:27 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" functions problems
	- security 
Message-ID: <E1GcR4d-0008TN-EQ@sc8-sf-web6.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 18:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" functions problems - security 

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Tue Oct 24 23:44:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 14:44:32 -0700
Subject: [ python-Bugs-1584028 ] remove() during iteration causes items to be
	skipped
Message-ID: <E1GcU4W-0006QN-9s@sc8-sf-web4.sourceforge.net>

Bugs item #1584028, was opened at 2006-10-24 14:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584028&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Rabsatt (krabsa)
Assigned to: Nobody/Anonymous (nobody)
Summary: remove() during iteration causes items to be skipped

Initial Comment:
If, when iterating over the contents of a list, the
current item is removed, the next item is skipped.

#Code:
if __name__ == '__main__':
  items = [0,1,2,3,4,5]
  for i in items:
    print i
    items.remove(i)

#End Code

Outputs:
0
2
4

I believe the behavior is undesirable.  An argument can
be made to not fix, but the issue is worth noting.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584028&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 00:05:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 15:05:15 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" functions problems
	- security 
Message-ID: <E1GcUOZ-0001ZD-10@sc8-sf-web3.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 11:32
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" functions problems - security 

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2006-10-24 15:05

Message:
Logged In: YES 
user_id=413

Yes OpenSSL 0.9.8d or later should be used for a new binary
release.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 00:40:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 15:40:21 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" functions problems
	- security 
Message-ID: <E1GcUwX-0006fu-HT@sc8-sf-web1.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 18:32
Message generated for change (Comment added) made by nagle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" functions problems - security 

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

>Comment By: John Nagle (nagle)
Date: 2006-10-24 22:40

Message:
Logged In: YES 
user_id=5571

The problem isn't in the version of OpenSSL used in Python,
which is at 0.9.8a.  OpenSSL has had the necessary functions
for years.  But Python isn't using them.

It's in  "python/trunk/Modules/_ssl.c", as described above.  

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-10-24 22:05

Message:
Logged In: YES 
user_id=413

Yes OpenSSL 0.9.8d or later should be used for a new binary
release.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 03:06:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Oct 2006 18:06:12 -0700
Subject: [ python-Bugs-1584028 ] remove() during iteration causes items to be
	skipped
Message-ID: <E1GcXDg-0005pj-Vf@sc8-sf-web1.sourceforge.net>

Bugs item #1584028, was opened at 2006-10-24 16:44
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584028&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Kevin Rabsatt (krabsa)
Assigned to: Nobody/Anonymous (nobody)
Summary: remove() during iteration causes items to be skipped

Initial Comment:
If, when iterating over the contents of a list, the
current item is removed, the next item is skipped.

#Code:
if __name__ == '__main__':
  items = [0,1,2,3,4,5]
  for i in items:
    print i
    items.remove(i)

#End Code

Outputs:
0
2
4

I believe the behavior is undesirable.  An argument can
be made to not fix, but the issue is worth noting.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-10-24 20:06

Message:
Logged In: YES 
user_id=80475

Sorry, this isn't a bug -- it is a natural side-effect of
mutating a object while iterating over it.  The various
approaches to dealing with this include:
* don't allow mutation while iterating -- dict.iterkeys()
uses this approach
* iterate over a copy of the object -- dict.keys() uses this
approach
* iterate over consecutive indices and ignore mutation --
lists use this approach

Programmers can avoid dealing with this issue by:

* precopying the list:
     for i in items[:]:
         print i
         remove(i)

* building a new list during iteration:
      items[:]  = [x for x in items if f(x)]



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584028&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 10:38:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 01:38:49 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" functions problems
	- security 
Message-ID: <E1GceHh-0007ZF-Jw@sc8-sf-web1.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 20:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" functions problems - security 

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 10:38

Message:
Logged In: YES 
user_id=21627

The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.

Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so (for use within LDAP).

Also notice that that the SSL module does little to actually
support trust: there is no verification of server-side
certs, no access to extensions of a certificate, etc. So an
application and a user should *not* trust the issuer name it
received, anyway (unless 
there is an independent verification that the server
certificate can be trusted).

All that said: If you think you need this functionality,
please provide a patch to implement it.

----------------------------------------------------------------------

Comment By: John Nagle (nagle)
Date: 2006-10-25 00:40

Message:
Logged In: YES 
user_id=5571

The problem isn't in the version of OpenSSL used in Python,
which is at 0.9.8a.  OpenSSL has had the necessary functions
for years.  But Python isn't using them.

It's in  "python/trunk/Modules/_ssl.c", as described above.  

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-10-25 00:05

Message:
Logged In: YES 
user_id=413

Yes OpenSSL 0.9.8d or later should be used for a new binary
release.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 10:39:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 01:39:26 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" functions problems
	- security 
Message-ID: <E1GceII-00077g-HN@sc8-sf-web6.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 20:32
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" functions problems - security 

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 10:38

Message:
Logged In: YES 
user_id=21627

The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.

Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so (for use within LDAP).

Also notice that that the SSL module does little to actually
support trust: there is no verification of server-side
certs, no access to extensions of a certificate, etc. So an
application and a user should *not* trust the issuer name it
received, anyway (unless 
there is an independent verification that the server
certificate can be trusted).

All that said: If you think you need this functionality,
please provide a patch to implement it.

----------------------------------------------------------------------

Comment By: John Nagle (nagle)
Date: 2006-10-25 00:40

Message:
Logged In: YES 
user_id=5571

The problem isn't in the version of OpenSSL used in Python,
which is at 0.9.8a.  OpenSSL has had the necessary functions
for years.  But Python isn't using them.

It's in  "python/trunk/Modules/_ssl.c", as described above.  

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-10-25 00:05

Message:
Logged In: YES 
user_id=413

Yes OpenSSL 0.9.8d or later should be used for a new binary
release.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 10:39:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 01:39:55 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be
	parsed
Message-ID: <E1GceIl-00005L-AN@sc8-sf-web5.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 20:32
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
>Summary: SSL "issuer" and "server" names cannot be parsed

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 10:38

Message:
Logged In: YES 
user_id=21627

The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.

Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so (for use within LDAP).

Also notice that that the SSL module does little to actually
support trust: there is no verification of server-side
certs, no access to extensions of a certificate, etc. So an
application and a user should *not* trust the issuer name it
received, anyway (unless 
there is an independent verification that the server
certificate can be trusted).

All that said: If you think you need this functionality,
please provide a patch to implement it.

----------------------------------------------------------------------

Comment By: John Nagle (nagle)
Date: 2006-10-25 00:40

Message:
Logged In: YES 
user_id=5571

The problem isn't in the version of OpenSSL used in Python,
which is at 0.9.8a.  OpenSSL has had the necessary functions
for years.  But Python isn't using them.

It's in  "python/trunk/Modules/_ssl.c", as described above.  

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-10-25 00:05

Message:
Logged In: YES 
user_id=413

Yes OpenSSL 0.9.8d or later should be used for a new binary
release.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 10:41:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 01:41:24 -0700
Subject: [ python-Bugs-1582742 ] Python is dumping core after the test
	test_ctypes
Message-ID: <E1GceKC-0005Vw-4I@sc8-sf-web3.sourceforge.net>

Bugs item #1582742, was opened at 2006-10-23 11:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shashi (shashikala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python is dumping core after the test test_ctypes

Initial Comment:


Hi ,

  Iam building Python-2.5 on HPUX Itanium. The 
compilation is done without any error, but while 
testing the same using gmake test it is dumping core 
telling "Segementation Fault" after the test 
test_ctypes. Please help me in resolving the above 
issue.Iam attaching the output of gmake test.

Thanks in advance,



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 10:41

Message:
Logged In: YES 
user_id=21627

You will need to run Python in a debugger and find out where
it crashes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 19:26:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 10:26:59 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be
	parsed
Message-ID: <E1GcmWp-00007T-CH@sc8-sf-web6.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 18:32
Message generated for change (Comment added) made by nagle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" names cannot be parsed

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

>Comment By: John Nagle (nagle)
Date: 2006-10-25 17:26

Message:
Logged In: YES 
user_id=5571

Actually, they don't do what they're "designed to do". 
According to the Python library documentation for SSL
objects, the server method "Returns a string containing the
ASN.1 distinguished name identifying the server's
certificate. (See below for an example showing what
distinguished names look like.)" The example "below" is
missing from the documentation, so the documentation gives
us no clue of what to expect.  

There are several standardized representations for ASN.1
information.  See
"http://www.oss.com/asn1/tutorial/Explain.html"  Most are
binary. The only standard textual form is "XER", which is an
XML representation of ASN.1 encoded information.  It's
essentially the same representation used for parameters in
SOAP. 

So, given the documentation and the standard, what should be
coming out is the XML representation of that data. 

Here's an entire X.509 certificate in XML:

http://www.gnu.org/software/gnutls/manual/html_node/An-X_002e509-certificate.html

The "issuer" field can be seen in there.  It's awfully
bulky.  And making SSL dependent on the SOAP module probably
isn't desireable.  But that's an ASN.1 distinguished name in
XML format, per the standard. 

That's probably not what's wanted by most users, although
the ability to retrieve an entire certificate in XML format
would be useful.

However, there's another standard string encoding, which is
defined in RFC2253.  This is comma-separated UTF-8 with
backslash escapes for special characters.  That's reliably
parseable. There's an openSSL function,
"X509_NAME_print_ex", which does this formatting, but it
doesn't output to a string.  That's the right mechanism if
it can be invoked in some way to yield a string.  It should
be invoked with flags = ASN1_STRFLGS_RFC2253, which yields a
UTF8 string, which of course should become a Python Unicode
string.

Now if someone can figure out how to get a string, instead
of file output, out of OpenSSL's "X509_NAME_print_ex", we're
home. 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 08:38

Message:
Logged In: YES 
user_id=21627

The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.

Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so (for use within LDAP).

Also notice that that the SSL module does little to actually
support trust: there is no verification of server-side
certs, no access to extensions of a certificate, etc. So an
application and a user should *not* trust the issuer name it
received, anyway (unless 
there is an independent verification that the server
certificate can be trusted).

All that said: If you think you need this functionality,
please provide a patch to implement it.

----------------------------------------------------------------------

Comment By: John Nagle (nagle)
Date: 2006-10-24 22:40

Message:
Logged In: YES 
user_id=5571

The problem isn't in the version of OpenSSL used in Python,
which is at 0.9.8a.  OpenSSL has had the necessary functions
for years.  But Python isn't using them.

It's in  "python/trunk/Modules/_ssl.c", as described above.  

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-10-24 22:05

Message:
Logged In: YES 
user_id=413

Yes OpenSSL 0.9.8d or later should be used for a new binary
release.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 20:05:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 11:05:33 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be
	parsed
Message-ID: <E1Gcn89-0002e7-2e@sc8-sf-web3.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 20:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" names cannot be parsed

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 20:05

Message:
Logged In: YES 
user_id=21627

Notice that RFC 2253 has been superceded by RFC 4514 (see my
earlier message). However, I really see no reason to fix this:
even if the ambiguity problems were fixed, you *still*
should not
use the issuer and subject names in a security-relevant context.


----------------------------------------------------------------------

Comment By: John Nagle (nagle)
Date: 2006-10-25 19:26

Message:
Logged In: YES 
user_id=5571

Actually, they don't do what they're "designed to do". 
According to the Python library documentation for SSL
objects, the server method "Returns a string containing the
ASN.1 distinguished name identifying the server's
certificate. (See below for an example showing what
distinguished names look like.)" The example "below" is
missing from the documentation, so the documentation gives
us no clue of what to expect.  

There are several standardized representations for ASN.1
information.  See
"http://www.oss.com/asn1/tutorial/Explain.html"  Most are
binary. The only standard textual form is "XER", which is an
XML representation of ASN.1 encoded information.  It's
essentially the same representation used for parameters in
SOAP. 

So, given the documentation and the standard, what should be
coming out is the XML representation of that data. 

Here's an entire X.509 certificate in XML:

http://www.gnu.org/software/gnutls/manual/html_node/An-X_002e509-certificate.html

The "issuer" field can be seen in there.  It's awfully
bulky.  And making SSL dependent on the SOAP module probably
isn't desireable.  But that's an ASN.1 distinguished name in
XML format, per the standard. 

That's probably not what's wanted by most users, although
the ability to retrieve an entire certificate in XML format
would be useful.

However, there's another standard string encoding, which is
defined in RFC2253.  This is comma-separated UTF-8 with
backslash escapes for special characters.  That's reliably
parseable. There's an openSSL function,
"X509_NAME_print_ex", which does this formatting, but it
doesn't output to a string.  That's the right mechanism if
it can be invoked in some way to yield a string.  It should
be invoked with flags = ASN1_STRFLGS_RFC2253, which yields a
UTF8 string, which of course should become a Python Unicode
string.

Now if someone can figure out how to get a string, instead
of file output, out of OpenSSL's "X509_NAME_print_ex", we're
home. 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 10:38

Message:
Logged In: YES 
user_id=21627

The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.

Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so (for use within LDAP).

Also notice that that the SSL module does little to actually
support trust: there is no verification of server-side
certs, no access to extensions of a certificate, etc. So an
application and a user should *not* trust the issuer name it
received, anyway (unless 
there is an independent verification that the server
certificate can be trusted).

All that said: If you think you need this functionality,
please provide a patch to implement it.

----------------------------------------------------------------------

Comment By: John Nagle (nagle)
Date: 2006-10-25 00:40

Message:
Logged In: YES 
user_id=5571

The problem isn't in the version of OpenSSL used in Python,
which is at 0.9.8a.  OpenSSL has had the necessary functions
for years.  But Python isn't using them.

It's in  "python/trunk/Modules/_ssl.c", as described above.  

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-10-25 00:05

Message:
Logged In: YES 
user_id=413

Yes OpenSSL 0.9.8d or later should be used for a new binary
release.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 22:36:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 13:36:48 -0700
Subject: [ python-Bugs-1472877 ] Tix: Subwidget names
Message-ID: <E1GcpUW-0000Qi-6l@sc8-sf-web2.sourceforge.net>

Bugs item #1472877, was opened at 2006-04-19 10:26
Message generated for change (Comment added) made by mkiever
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias Kievernagel (mkiever)
Assigned to: Martin v. L?wis (loewis)
Summary: Tix: Subwidget names

Initial Comment:
My system information:
------------------------------------------
uname -a:
Linux linux 2.6.4-52-default #1 Wed Apr 7 02:08:30 UTC 
2004 i686 athlon i386 GNU/Linux
Python:
Python 2.4.1 (#4, Jan 10 2006, 10:53:14) 
[GCC 3.3.3 (SuSE Linux)] on linux2
and
Python 2.3.5 (#1, Sep 12 2005, 14:56:24) 
[GCC 3.3.3 (SuSE Linux)] on linux2
------------------------------------------

Using Tix you can produce the following exception:

---------------------------------------------------
>>> from Tix import *
>>> tk = Tk ()
>>> b = Balloon ()
>>> b.subwidget ( 'label' )
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/Tix.
py", line 340, in subwidget
    return self._nametowidget(n)
  File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/
Tkinter.py", line 1015, in nametowidget
    w = w.children[name]
KeyError: 'lab'
>>> 
---------------------------------------------------

I found a commentary in Tix.py:TixWidget:__init__
stating that 'subwidget_list' should contain
Tix names. But in Tix.py:TixSubWidget:__init__
the python names are used, not the names returned
by Tix. 

I was successful with the following two
small additions (+++) near lines 400-450:
---------------------------------------------
class TixSubWidget(TixWidget):
 ...
 def __init__(self, master, name,
              destroy_physically=1,
              check_intermediate=1):
  ...
  if (not check_intermediate) or len(plist) < 2:
   # immediate descendant
   if check_intermediate:                        +++
    name = plist [0]                             +++
   TixWidget.__init__(self, master, None, None, 
                      {'name' : name})
  else:
   ...
   name = plist [-1]                             +++
   TixWidget.__init__(self, parent, None, None,
                      {'name' : name})
  self.destroy_physically = destroy_physically
...
---------------------------------------------

This replaces the python name by the name
returned from Tix.
I have not extensively tested this (sorry).
Hope this helps.

Matthias Kievernagel  (mkiever at web.de)


----------------------------------------------------------------------

>Comment By: Matthias Kievernagel (mkiever)
Date: 2006-10-25 20:36

Message:
Logged In: YES 
user_id=1477880

Solution was not complete.
Submitted a complete patch #1472877 for this
which is tested against the tix demo code
in Demo/tix/tixwidgets.py

Matthias Kievernagel
mkiever at web dot de



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&group_id=5470

From noreply at sourceforge.net  Wed Oct 25 22:52:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 13:52:22 -0700
Subject: [ python-Bugs-1584723 ] os.tempnam fails on SUSE Linux to accept
	directory argument
Message-ID: <E1Gcpja-000682-PO@sc8-sf-web4.sourceforge.net>

Bugs item #1584723, was opened at 2006-10-25 22:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tempnam fails on SUSE Linux to accept directory argument

Initial Comment:
On SUSE Linux 10.1 the function os.tempnam does not use
the "dir" argument properly. It always takes the
tmpdir, in this case "/tmp". In the example below it is
expected to get a filename of '/tmp/tmp/pref2iGGS5'
instead of '/tmp/pref2iGGS5'. 


auser at linux-m392:~> python
Python 2.5 (r25:51908, Oct 18 2006, 22:50:32)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/pref2iGGS5'
>>>
auser at linux-m392:~> ls -l /tmp/tmp
total 0
auser at linux-m392:~> ls -ld /tmp/tmp
drwxr-xr-x 2 auser users 48 2006-10-17 20:13 /tmp/tmp

This behavior is also the same on the Python version
which comes with SUSE Linux 10.1. On Solaris 10 the
behavior is as expected, e.g.

-bash-3.00$ python
Python 2.4.3 (#1, Sep 16 2006, 10:31:38) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/tmp/prefAAAIeaafH'

A patch for the test 'test_os.py' is attached to this
report. It has been tested on SUSE Linux 10.1.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 02:12:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Oct 2006 17:12:10 -0700
Subject: [ python-Bugs-1584723 ] os.tempnam fails on SUSE Linux to accept
	directory argument
Message-ID: <E1Gcsqw-0004fd-8v@sc8-sf-web2.sourceforge.net>

Bugs item #1584723, was opened at 2006-10-25 20:52
Message generated for change (Comment added) made by mkiever
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tempnam fails on SUSE Linux to accept directory argument

Initial Comment:
On SUSE Linux 10.1 the function os.tempnam does not use
the "dir" argument properly. It always takes the
tmpdir, in this case "/tmp". In the example below it is
expected to get a filename of '/tmp/tmp/pref2iGGS5'
instead of '/tmp/pref2iGGS5'. 


auser at linux-m392:~> python
Python 2.5 (r25:51908, Oct 18 2006, 22:50:32)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/pref2iGGS5'
>>>
auser at linux-m392:~> ls -l /tmp/tmp
total 0
auser at linux-m392:~> ls -ld /tmp/tmp
drwxr-xr-x 2 auser users 48 2006-10-17 20:13 /tmp/tmp

This behavior is also the same on the Python version
which comes with SUSE Linux 10.1. On Solaris 10 the
behavior is as expected, e.g.

-bash-3.00$ python
Python 2.4.3 (#1, Sep 16 2006, 10:31:38) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/tmp/prefAAAIeaafH'

A patch for the test 'test_os.py' is attached to this
report. It has been tested on SUSE Linux 10.1.



----------------------------------------------------------------------

Comment By: Matthias Kievernagel (mkiever)
Date: 2006-10-26 00:12

Message:
Logged In: YES 
user_id=1477880

This one once irritated me also.
In my case the cause was
the environment variable 'TMPDIR'.
This is the first location chosen
by os.tempnam (see 'man tempnam').
Please check again.

Matthias Kievernagel
mkiever at web dot de


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 16:50:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 07:50:26 -0700
Subject: [ python-Bugs-1585135 ] Events in list return None not True on wait()
Message-ID: <E1Gd6Ys-00029u-LF@sc8-sf-web5.sourceforge.net>

Bugs item #1585135, was opened at 2006-10-26 10:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: SpinMess (spinmess)
Assigned to: Nobody/Anonymous (nobody)
Summary: Events in list return None not True on wait()

Initial Comment:
OS: Suse Linux 10.0 
Python 2.4.1 
After I call e.set() for some event e, subsequent 
calls to e.wait() return None instead of True.  This 
happens if & only if e is an element in a list.  As a 
workaround, I can test for e.wait()==None instead of 
e.wait() itself. 
 
I've attached sample code to demonstrate the bug. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 17:34:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 08:34:03 -0700
Subject: [ python-Bugs-1585135 ] Events in list return None not True on wait()
Message-ID: <E1Gd7F5-0003uq-6Q@sc8-sf-web2.sourceforge.net>

Bugs item #1585135, was opened at 2006-10-26 10:50
Message generated for change (Comment added) made by spinmess
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: SpinMess (spinmess)
Assigned to: Nobody/Anonymous (nobody)
Summary: Events in list return None not True on wait()

Initial Comment:
OS: Suse Linux 10.0 
Python 2.4.1 
After I call e.set() for some event e, subsequent 
calls to e.wait() return None instead of True.  This 
happens if & only if e is an element in a list.  As a 
workaround, I can test for e.wait()==None instead of 
e.wait() itself. 
 
I've attached sample code to demonstrate the bug. 

----------------------------------------------------------------------

>Comment By: SpinMess (spinmess)
Date: 2006-10-26 11:34

Message:
Logged In: YES 
user_id=1630682

Bah. 
 
Never mind.  I mis-read the documentation. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 17:38:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 08:38:49 -0700
Subject: [ python-Bugs-1585135 ] Events in list return None not True on wait()
Message-ID: <E1Gd7Jh-0004Nz-Uj@sc8-sf-web2.sourceforge.net>

Bugs item #1585135, was opened at 2006-10-26 14:50
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: SpinMess (spinmess)
Assigned to: Nobody/Anonymous (nobody)
Summary: Events in list return None not True on wait()

Initial Comment:
OS: Suse Linux 10.0 
Python 2.4.1 
After I call e.set() for some event e, subsequent 
calls to e.wait() return None instead of True.  This 
happens if & only if e is an element in a list.  As a 
workaround, I can test for e.wait()==None instead of 
e.wait() itself. 
 
I've attached sample code to demonstrate the bug. 

----------------------------------------------------------------------

Comment By: SpinMess (spinmess)
Date: 2006-10-26 15:34

Message:
Logged In: YES 
user_id=1630682

Bah. 
 
Never mind.  I mis-read the documentation. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 18:55:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 09:55:47 -0700
Subject: [ python-Bugs-1584723 ] os.tempnam fails on SUSE Linux to accept
	directory argument
Message-ID: <E1Gd8WB-00052L-Lq@sc8-sf-web4.sourceforge.net>

Bugs item #1584723, was opened at 2006-10-25 22:52
Message generated for change (Comment added) made by andyfloe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tempnam fails on SUSE Linux to accept directory argument

Initial Comment:
On SUSE Linux 10.1 the function os.tempnam does not use
the "dir" argument properly. It always takes the
tmpdir, in this case "/tmp". In the example below it is
expected to get a filename of '/tmp/tmp/pref2iGGS5'
instead of '/tmp/pref2iGGS5'. 


auser at linux-m392:~> python
Python 2.5 (r25:51908, Oct 18 2006, 22:50:32)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/pref2iGGS5'
>>>
auser at linux-m392:~> ls -l /tmp/tmp
total 0
auser at linux-m392:~> ls -ld /tmp/tmp
drwxr-xr-x 2 auser users 48 2006-10-17 20:13 /tmp/tmp

This behavior is also the same on the Python version
which comes with SUSE Linux 10.1. On Solaris 10 the
behavior is as expected, e.g.

-bash-3.00$ python
Python 2.4.3 (#1, Sep 16 2006, 10:31:38) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/tmp/prefAAAIeaafH'

A patch for the test 'test_os.py' is attached to this
report. It has been tested on SUSE Linux 10.1.



----------------------------------------------------------------------

>Comment By: Andreas (andyfloe)
Date: 2006-10-26 18:55

Message:
Logged In: YES 
user_id=1292384

Your hint about the environment variable TMPDIR 
actually solves my problem. I have overlooked the 
information given in the documentation about this fact. 
Thanks.

----------------------------------------------------------------------

Comment By: Matthias Kievernagel (mkiever)
Date: 2006-10-26 02:12

Message:
Logged In: YES 
user_id=1477880

This one once irritated me also.
In my case the cause was
the environment variable 'TMPDIR'.
This is the first location chosen
by os.tempnam (see 'man tempnam').
Please check again.

Matthias Kievernagel
mkiever at web dot de


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 18:58:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 09:58:46 -0700
Subject: [ python-Bugs-1584723 ] os.tempnam fails on SUSE Linux to accept
	directory argument
Message-ID: <E1Gd8Z4-0007jf-CH@sc8-sf-web1.sourceforge.net>

Bugs item #1584723, was opened at 2006-10-25 20:52
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tempnam fails on SUSE Linux to accept directory argument

Initial Comment:
On SUSE Linux 10.1 the function os.tempnam does not use
the "dir" argument properly. It always takes the
tmpdir, in this case "/tmp". In the example below it is
expected to get a filename of '/tmp/tmp/pref2iGGS5'
instead of '/tmp/pref2iGGS5'. 


auser at linux-m392:~> python
Python 2.5 (r25:51908, Oct 18 2006, 22:50:32)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/pref2iGGS5'
>>>
auser at linux-m392:~> ls -l /tmp/tmp
total 0
auser at linux-m392:~> ls -ld /tmp/tmp
drwxr-xr-x 2 auser users 48 2006-10-17 20:13 /tmp/tmp

This behavior is also the same on the Python version
which comes with SUSE Linux 10.1. On Solaris 10 the
behavior is as expected, e.g.

-bash-3.00$ python
Python 2.4.3 (#1, Sep 16 2006, 10:31:38) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/tmp/prefAAAIeaafH'

A patch for the test 'test_os.py' is attached to this
report. It has been tested on SUSE Linux 10.1.



----------------------------------------------------------------------

Comment By: Andreas (andyfloe)
Date: 2006-10-26 16:55

Message:
Logged In: YES 
user_id=1292384

Your hint about the environment variable TMPDIR 
actually solves my problem. I have overlooked the 
information given in the documentation about this fact. 
Thanks.

----------------------------------------------------------------------

Comment By: Matthias Kievernagel (mkiever)
Date: 2006-10-26 00:12

Message:
Logged In: YES 
user_id=1477880

This one once irritated me also.
In my case the cause was
the environment variable 'TMPDIR'.
This is the first location chosen
by os.tempnam (see 'man tempnam').
Please check again.

Matthias Kievernagel
mkiever at web dot de


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 21:12:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 12:12:38 -0700
Subject: [ python-Bugs-1579796 ] Wrong syntax for PyDateTime_IMPORT in
	documentation
Message-ID: <E1GdAec-0004TT-Nt@sc8-sf-web3.sourceforge.net>

Bugs item #1579796, was opened at 2006-10-18 11:44
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579796&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Faure (dfaure_kde)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Wrong syntax for PyDateTime_IMPORT in documentation

Initial Comment:
http://docs.python.org/api/datetime-objects.html says 
"macro PyDateTime_IMPORT() must be invoked."

But this doesn't compile. It's PyDateTime_IMPORT;
and not PyDateTime_IMPORT();

Also it would be useful to tell if this should be 
done once per thread or just once per process; seeing 
as it modifies a static variable I guess the latter.

Cheers,
David (still getting crashes in 
PyDateTime_FromDateAndTime though but that's another 
topic....)

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 15:12

Message:
Logged In: YES 
user_id=11375

Fixed in trunk (rev 52446), 2.5-maint (rev. 52447), and
2.4-maint (rev. 52448).

Thanks for your report!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579796&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 21:18:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 12:18:46 -0700
Subject: [ python-Bugs-1576241 ] functools.wraps fails on builtins
Message-ID: <E1GdAkY-0005T3-Gk@sc8-sf-web1.sourceforge.net>

Bugs item #1576241, was opened at 2006-10-12 18:24
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kajiuma (kajiuma)
>Assigned to: Nick Coghlan (ncoghlan)
Summary: functools.wraps fails on builtins

Initial Comment:
functools.wraps assumes that the wrapped function 
has a __dict__ attribute, which is not true for 
builtins.

The attached patch provides an empty dictionaries 
for functions that do not have the required 
attributes. This will cause programs expecting an 
AttributeError (if there are any) to fail.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 15:18

Message:
Logged In: YES 
user_id=11375

The change seems reasonable, but arguably this is an API
change because of the AttributeError no longer being raised.
 Nick, do you want to decide whether to make this change or
not?  (I can make the edit and add a test if you agree to
apply this change.)


----------------------------------------------------------------------

Comment By: kajiuma (kajiuma)
Date: 2006-10-12 18:33

Message:
Logged In: YES 
user_id=1619773

Looks like lynx cannot send files.
The patch changed: getattr(wrapped, attr)
to: getattr(wrapped, attr, {})
At then end of line 35 of Lib/functools.py


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 21:38:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 12:38:03 -0700
Subject: [ python-Bugs-1566086 ] RE (regular expression) matching stuck in loop
Message-ID: <E1GdB3D-0005QJ-IV@sc8-sf-web5.sourceforge.net>

Bugs item #1566086, was opened at 2006-09-26 21:23
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabien Devaux (fabinator)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE (regular expression) matching stuck in loop

Initial Comment:
See the code:
http://pastebin.ca/183613
the "finditer()" call don't seems to return.
Playing with the re can bypass the problem but it looks
like a bug.
(I'm really sorry if I did something wrong and didn't
notice)

note: I can reproduce it with python2.5

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 15:38

Message:
Logged In: YES 
user_id=11375

Attaching the test script.  I've modified it to save a copy
of the HTML page's data so that running the example doesn't
require accessing a slow web site repeatedly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 21:53:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 12:53:10 -0700
Subject: [ python-Bugs-1566086 ] RE (regular expression) matching stuck in loop
Message-ID: <E1GdBHq-0008QT-CQ@sc8-sf-web3.sourceforge.net>

Bugs item #1566086, was opened at 2006-09-26 21:23
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabien Devaux (fabinator)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE (regular expression) matching stuck in loop

Initial Comment:
See the code:
http://pastebin.ca/183613
the "finditer()" call don't seems to return.
Playing with the re can bypass the problem but it looks
like a bug.
(I'm really sorry if I did something wrong and didn't
notice)

note: I can reproduce it with python2.5

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 15:53

Message:
Logged In: YES 
user_id=11375

I haven't dug very far into the code, but suspect this isn't
a bug in the regex code.

The pattern uses lots of .*? subpatterns, and this often
means the pattern takes a long time to fail if it isn't
going to match.  The regex engine matches the <link> group,
and then there's a .*?, followed by <b>.  The engine looks
at every character and if it sees a <b>, tries another .*?.
 This is O(n**2) where n is the number of character in the
string being searched, and that string is 93,000 characters
long.  If you limit the string to 5K or so, the match fails
pretty quickly.

I strongly suggest working with the HTML.  You could run the
HTML through tidy to convert to XHTML and use ElementTree on
the resulting XML.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 15:38

Message:
Logged In: YES 
user_id=11375

Attaching the test script.  I've modified it to save a copy
of the HTML page's data so that running the example doesn't
require accessing a slow web site repeatedly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 22:16:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 13:16:37 -0700
Subject: [ python-Bugs-1570255 ] redirected cookies
Message-ID: <E1GdBeX-0006nO-6D@sc8-sf-web2.sourceforge.net>

Bugs item #1570255, was opened at 2006-10-03 16:37
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: hans_moleman (hans_moleman)
Assigned to: Nobody/Anonymous (nobody)
Summary: redirected cookies

Initial Comment:
Cookies are not resend when a redirect is requested.

Blurb:
I've been trying to get a response off a server using
Python.
The response so far differs from the response using
Firefox.
In Python, I have set headers and cookies the way
Firefox does it.

I noticed that the server accepts the POST request, and
redirects the client to another address with the result
on it. This happens both with Python and Firefox correctly.

Cookie handling differs though:
The Python client, when redirected, using the standard
redirect handler, does not resend its cookies to the
redirected address.
Firefox does resend the cookies from the original request.

When I redefine the redirect handler and code it so
that it adds the cookies from the original request,
the response is the same as Firefox's response. This
confirms then that resending cookies is required to get
the server to respond correctly.

Is the default Python redirection cookie policy
different from Firefox's policy?
Could we improve the default redirection handler to
work like Firefox?
Is it a bug?

I noticed an old open bug report 511786, that looks
very much like this problem. It suggests it is fixed.

Cheers Hans Moleman. 


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 16:16

Message:
Logged In: YES 
user_id=11375

More detail is needed to figure out if there's a problem;
can you give a sample URL to exhibit the problem?  can you
provide your code?  From the description, it's unclear if
this might be a bug in the handling of redirects or in the
CookieProcessor class.

The bug in 511786 is still fixed; that bug includes sample
code, so I could check it.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470

From noreply at sourceforge.net  Thu Oct 26 22:48:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 13:48:33 -0700
Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Message-ID: <E1GdC9R-0005qt-OV@sc8-sf-web3.sourceforge.net>

Bugs item #1565525, was opened at 2006-09-26 02:58
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: gc allowing tracebacks to eat up memory

Initial Comment:
Attached is a file which demonstrates an oddity about 
traceback objects and the gc.

The observed behaviour is that when the tuple from 
sys.exc_info() is stored on an object which is inside 
the local scope, the object, thus exc_info tuple, are 
not collected even when both leave scope.

If you run the test with "s.e = sys.exc_info()" 
commented out, the observed memory footprint of the 
process quickly approaches and sits at 5,677,056 
bytes. Totally reasonable.

If you uncomment that line, the memory footprint 
climbs to 283,316,224 bytes quite rapidly. That's a 
two order of magnitude difference!

If you uncomment the "gc.collect()" line, the process 
still hits 148,910,080 bytes.

This was observed in production code, where exc_info 
tuples are saved for re-raising later to get the stack-
appending behaviour tracebacks and 'raise' perform. 
The example includes a large array to simulate 
application state. I assume this is bad behaviour 
occurring because the traceback object holds frames, 
and those frames hold a reference to the local 
objects, thus the exc_info tuple itself, thus causing 
a circular reference which involves the entire stack.
Either the gc needs to be improved to prevent this 
from growing so wildly, or the traceback objects need 
to (optionally?) hold frames which do not have 
references or have weak references instead.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 16:48

Message:
Logged In: YES 
user_id=11375

A quick grep of the stdlib turns up various uses of
sys.exc_info that do put it in a local variable., e.g.
doctest._exception_traceback, unittest._exc_info_to_string,
SimpleXMLRPCServer._marshaled_dispatch.  Do these all need
to be fixed?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-09-27 23:48

Message:
Logged In: YES 
user_id=31435

[Martin]
> tim_one: Why do you think your proposed modification of
> introducing get_traceback would help? The frame foo still
> refers to s (which is an O), and s.e will still refer
> to the traceback that includes foo.

Sorry about that!  It was an illusion, of course.  I wanted
to suggest a quick fix, and "tested it" too hastily in a
program that didn't actually bloat with /or/ without it.

For the OP, I had need last year of capturing a traceback
and (possibly) displaying it later in ZODB.  It never would
have occurred to me to try saving away exc_info(), though. 
Instead I used the `traceback` module to capture the
traceback output (a string), which was (possibly) displayed
later, with annotations, by a different thread.  No cycles,
no problems.

BTW, I must repeat that there is no simple-minded way to
'repair' this.  That isn't based on general principle, but
on knowledge of how Python is implemented.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-09-27 23:03

Message:
Logged In: YES 
user_id=21627

I disagree that the circular reference is non-obvious. I'm
not sure what your application is, but I would expect that
callers of sys.exc_info should be fully aware what a
traceback is, and how it refers to the current frames. I do
agree that it is unavoidable; I fail to see that it is a bug
because of that (something unavoidable cannot be a bug).

If you are saying that it is unavoidable in your
application: I have difficulties believing this. For
example, you could do

        s.e = sys.exc_info()[:2]

This would drop the traceback, and thus not create a cyclic
reference. Since, in the program you present, the traceback
is never used, this looks like a "legal" simplification (of
course, you don't use s.e at all in this program, so I can
only guess that you don't need the traceback in your real
application).

As for the time of cleanup not being controllable: you can
certainly control frequency of gc with gc.set_threshold; no
need to invoke gc explicitly.

tim_one: Why do you think your proposed modification of
introducing get_traceback would help? The frame foo still
refers to s (which is an O), and s.e will still refer to the
traceback that includes foo.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2006-09-27 17:07

Message:
Logged In: YES 
user_id=731668

The bug is the circular reference which is non-obvious and 
unavoidable, and cleaned up at some uncontrolable (unless 
you run a full collection) time in the future.
There are many better situations or solutions to this bug, 
depending on which you think it is. I think those should be 
investigated.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-09-27 03:49

Message:
Logged In: YES 
user_id=21627

I'm still having problems figuring out what the bug is that
you are reporting. Ok, in this case, it consumes a lot of
memory. Why is that a bug?

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2006-09-26 23:20

Message:
Logged In: YES 
user_id=731668

I have read the exc_info suggestions before, but they have 
never made any difference. Neither change you suggest 
modifies the memory footprint behaviour in any way.

Weakrefs might be slow, I offered them as an alternative to 
just removing the references entirely. I understand this 
might cause problems with existing code, but the current 
situation causes a problem which is more difficult to work 
around. Code that needs locals and globals can explicity 
store a reference to eat - it is impossible to dig in to 
the traceback object and remove those references.
The use-case of storing the exc_info is fairly simple, for 
example:
Two threads. One queues a task for the other to complete. 
That task fails an raises an exception. The exc_info is 
caught, passed back to the first thread, the exc_info is 
raised from there. The goal is to get the whole execution 
stack, which it does quite nicely, except that it has this 
terrible memory side effect.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-09-26 06:04

Message:
Logged In: YES 
user_id=31435

Your memory bloat is mostly due to the

d = range(100000)

line.  Python has no problem collecting the cyclic trash,
but you're creating 100000 * 100 = 10 million integer
objects hanging off trash cycles before invoking
gc.collect(), and those integers require at least 10 million
* 12 ~= 120MB all by themselves.  Worse, memory allocated to
"short" integers is both immortal and unbounded:  it can be
reused for /other/ integer objects, but it never goes away.

Note that memory usage in your program remains low and
steady if you force gc.collect() after every call to bar().
 Then you only create 100K integers, instead of 10M, before
the trash gets cleaned up.

There is no simple-minded way to "repair" this, BTW.  For
example, /of course/ a frame has to reference all its
locals, and moving to weak references for those instead
would be insanely inefficient (among other, and deeper,
problems).

Note that the library reference manual warns against storing
the result of exc_info() in a local variable (which you're
/effectively/ doing, since the formal parameter `s` is a
local variable within foo()), and suggests other approaches.
 Sorry, but I really couldn't tell from your description why
you want to store this stuff in an instance attribute, so
can't guess whether another more-or-less obvious approach
would help.

For example, no cyclic trash is created if you add this
method to your class O:

    def get_traceback(self):
        self.e = sys.exc_info()

and inside foo() invoke:

    s.get_traceback()

instead of doing:

    s.e = sys.exc_info()

Is that unreasonable?  Perhaps simpler is to define a
function like:

def get_exc_info():
    return sys.exc_info()

and inside foo() do:

    s.e = get_exc_info()

No cyclic trash gets created that way either.  These are the
kinds of things the manual has suggested doing for the last
10 years ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 04:20:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 19:20:03 -0700
Subject: [ python-Bugs-1563243 ] python_d python
Message-ID: <200610270220.k9R2K3pk010217@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1563243, was opened at 2006-09-21 18:20
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Grzegorz Makarewicz (makaron)
Assigned to: Nobody/Anonymous (nobody)
Summary: python_d python

Initial Comment:
I'v added _d to python (python_d.exe) while performing
standard tests ... it dies after testInfinitRecursion
without any message - just dissapears :(


----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-26 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 04:15

Message:
Logged In: YES 
user_id=849994

"I'v added _d to python" is not clear to me.
Can you give more information?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 04:21:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 19:21:04 -0700
Subject: [ python-Bugs-1580738 ] httplib hangs reading too much data
Message-ID: <E1GdHLE-0007iQ-4d@sc8-sf-web6.sourceforge.net>

Bugs item #1580738, was opened at 2006-10-20 05:06
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580738&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dustin J. Mitchell (djmitche)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib hangs reading too much data

Initial Comment:
I'm building an interface to Amazon's S3, using httplib.  It uses a
single object for multiple transactions.  What's happening is this:

HTTP > PUT /unitest-temp-1161039691 HTTP/1.1
HTTP > Date: Mon, 16 Oct 2006 23:01:32 GMT
HTTP > Authorization: AWS <<cough>>:KiTWRuq/
6aay0bI2J5DkE2TAWD0=
HTTP > (end headers)
HTTP < HTTP/1.1 200 OK
HTTP < content-length: 0
HTTP < x-amz-id-2: 40uQn0OCpTiFcX+LqjMuzG6NnufdUk/..
HTTP < server: AmazonS3
HTTP < x-amz-request-id: FF504E8FD1B86F8C
HTTP < location: /unitest-temp-1161039691
HTTP < date: Mon, 16 Oct 2006 23:01:33 GMT
HTTPConnection.__state before response.read:  Idle
HTTPConnection.__response: closed? False length: 0
reading response
HTTPConnection.__state after response.read:  Idle
HTTPConnection.__response: closed? False length: 0

 ..later in the same connection..

HTTPConnection.__state before putrequest:  Idle
HTTPConnection.__response: closed? False length: 0
HTTP > DELETE /unitest-temp-1161039691 HTTP/1.1
HTTP > Date: Mon, 16 Oct 2006 23:01:33 GMT
HTTP > Authorization: AWS <<cough>>:
a5OizuLNwwV7eBUhha0B6rEJ+CQ=
HTTP > (end headers)
HTTPConnection.__state before getresponse:  Request-sent
HTTPConnection.__response: closed? False length: 0
  File "/usr/lib64/python2.4/httplib.py", line 856, in getresponse
    raise ResponseNotReady()

If the first request does not precede it, the second request is fine.
To avoid excessive memory use, I'm calling request.read(16384)
repeatedly, instead of just calling request.read().  This seems to be
key to the problem -- if I omit the 'amt' argument to read(), then the
last line of the first request reads

HTTPConnection.__response: closed? True length: 0

and the later call to getresponse() doesn't raise ResponseNotReady.

Looking at the source for httplib.HTTPResponse.read, self.close() gets
called in the latter (working) case, but not in the former
(non-working).  It would seem sensible to add 'if self.length == 0:
self.close()' to the end of that function (and, in fact, this change makes 
the whole thing work), but this comment makes me hesitant:

# we do not use _safe_read() here because this may be a .will_close
# connection, and the user is reading more bytes than will be provided
# (for example, reading in 1k chunks)

I suspect that either (a) this is a bug or (b) the client is supposed to 
either call read() with no arguments or calculate the proper inputs to 
read(amt) based on the Content-Length header.  If (b), I would think 
the docs should be updated to reflect that?

Thanks for any assistance.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-10-27 12:21

Message:
Logged In: YES 
user_id=14198

The correct answer is indeed (b) - but note that httplib
will itself do the content-length magic for you, including
the correct handling of 'chunked' encoding.  If the .length
attribute is not None, then that is exactly how many bytes
you should read.  If .length is None, then either chunked
encoding is used (in which case you can call read() with a
fixed size until it returns an empty string), or no
content-length was supplied (which can be treated the same
as chunked, but the connection will close at the end. 
Checking ob.will_close can give you some insight into that.

Its not reasonable to add 'if self.length==0: self.close()'
- it is perfectly valid to have a zero byte response within
a keep-alive connection - we don't want to force a new
(expensive) connection to the server just because a zero
byte response was requested.

The HTTP semantics are hard to get your head around, but I
believe httplib gets it right, and a ResponseNotReady
exception in particular points at an error in the code
attempting to use the library.  Working with connections
that keep alive is tricky - you just jump through hoops to
ensure you maintain the state of the httplib object
correctly - in general, that means you must *always* consume
the entire response (even if it is zero bytes) before
attempting to begin a new request.  This requirement doesn't
exists for connections that close - if you fail to read the
entire response it can be thrown away as the next request
will happen on a new connection.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580738&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 06:20:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 21:20:11 -0700
Subject: [ python-Bugs-1570255 ] redirected cookies
Message-ID: <E1GdJCU-0007ao-V5@sc8-sf-web3.sourceforge.net>

Bugs item #1570255, was opened at 2006-10-04 09:37
Message generated for change (Comment added) made by hans_moleman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: hans_moleman (hans_moleman)
Assigned to: Nobody/Anonymous (nobody)
Summary: redirected cookies

Initial Comment:
Cookies are not resend when a redirect is requested.

Blurb:
I've been trying to get a response off a server using
Python.
The response so far differs from the response using
Firefox.
In Python, I have set headers and cookies the way
Firefox does it.

I noticed that the server accepts the POST request, and
redirects the client to another address with the result
on it. This happens both with Python and Firefox correctly.

Cookie handling differs though:
The Python client, when redirected, using the standard
redirect handler, does not resend its cookies to the
redirected address.
Firefox does resend the cookies from the original request.

When I redefine the redirect handler and code it so
that it adds the cookies from the original request,
the response is the same as Firefox's response. This
confirms then that resending cookies is required to get
the server to respond correctly.

Is the default Python redirection cookie policy
different from Firefox's policy?
Could we improve the default redirection handler to
work like Firefox?
Is it a bug?

I noticed an old open bug report 511786, that looks
very much like this problem. It suggests it is fixed.

Cheers Hans Moleman. 


----------------------------------------------------------------------

>Comment By: hans_moleman (hans_moleman)
Date: 2006-10-27 17:20

Message:
Logged In: YES 
user_id=1610873

I am using this script to obtain monthly internet usage
statistics from my ISP.
My ISP provides a screen via HTTPS, to enter a usercode and
password, after which the usage statistics are displayed on
a different address. 
I cannot send this script with my usercode and password. My
ISP might not like me doing this either.

Therefore I'll try to find another server that behaves
similarly, and send you that.



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 09:16

Message:
Logged In: YES 
user_id=11375

More detail is needed to figure out if there's a problem;
can you give a sample URL to exhibit the problem?  can you
provide your code?  From the description, it's unclear if
this might be a bug in the handling of redirects or in the
CookieProcessor class.

The bug in 511786 is still fixed; that bug includes sample
code, so I could check it.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 08:14:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 23:14:12 -0700
Subject: [ python-Bugs-1580472 ] glob.glob("c:\\[ ]\*) doesn't work
Message-ID: <E1GdKyq-0001i8-GY@sc8-sf-web3.sourceforge.net>

Bugs item #1580472, was opened at 2006-10-19 04:44
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Koblaid (koblaid)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob.glob("c:\\[ ]\*) doesn't work

Initial Comment:
OS: Windows 2000 Service Pack 4
Python 2.5

glob.glob() doesn't work in directories named 
"[ ]" (with a blank in it). Another example is a 
directory named "A - [Aa-Am]"

Example:
#########################
C:\>md []
C:\>md "[ ]"
C:\>copy anyfile.txt []
        1 Datei(en) kopiert.
C:\>copy anyfile.txt "[ ]"
        1 Datei(en) kopiert.

C:\>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC 
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import glob
>>> glob.glob ("c:\\[]\*")
['c:\\[]\\anyfile.txt']
>>> glob.glob ("c:\\[ ]\*")
[]
#########################

The second glob should have resulted the same as the 
first glob since I copied the same file to both 
directories.
I may be wrong because I'm new to python. But I've 
tested it a couple of times, and I think it have to be 
a bug of python or a bug of windows.

Greets, Koblaid

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-26 23:14

Message:
Logged In: YES 
user_id=341410

This is a known issue with the fnmatch module (what glob
uses under the covers).  According to the documentation of
the translate method that converts patterns into regular
expressions... "There is no way to quote meta-characters." 
The fact that "[]" works but "[ ]" doesn't work is a
convenient bug, for those who want to use "[]".

If you can come up with some similar but non-ambiguous
syntax to update the fnmatch module, I'm sure it would be
considered, but as-is, I can't see this as a "bug" per-se.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 08:19:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 23:19:33 -0700
Subject: [ python-Bugs-1545696 ] structmember T_LONG won't accept a python long
Message-ID: <E1GdL41-0002DM-8x@sc8-sf-web1.sourceforge.net>

Bugs item #1545696, was opened at 2006-08-24 07:07
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: structmember T_LONG won't accept a python long

Initial Comment:
An attribute defined as T_LONG throws a vague error
when set to a python long, even when the value is 
within the range of a LONG.

TypeError: bad argument type for built-in operation


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-27 08:19

Message:
Logged In: YES 
user_id=21627

Patch committed, so this is now fixed.

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-08-30 07:06

Message:
Logged In: YES 
user_id=771074

Submitted patch 1549049.

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-08-28 04:23

Message:
Logged In: YES 
user_id=771074

In the process of creating a patch for this, I came across 
some more 'ugh'-liness.  T_UINT's are returned via 
PyInt_FromLong, so you actually get back a negative value 
for large numbers.  Changing it to use 
PyLong_FromUnsignedLong will break backward compatibility, 
but this is so wrong I can't possibly see keeping it.  Your 
call. (plus it makes it impossible to test T_UINT with 
values larger than INT_MAX)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-25 02:52

Message:
Logged In: YES 
user_id=33168

Ugh.  This code is lax in checking/conversion.  Do you think
you could provide a patch?

All of the int cases should call PyInt_AsLong() if this call
fails (returns -1), then that should be returned from
PyMember_SetOne.  If it succeeds, there should be a range
check that ensures the value is valid.  If that fails a
warning should be produced.  We need to issue a warning
rather than an error for backwards compatability (at least
for 2.6).

The float/double cases can be simplified some by calling
PyFloat_AsDouble and doing similar checks as in the int cases.

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-08-24 21:56

Message:
Logged In: YES 
user_id=771074

The DEVMODE object from pywintypes has attributes defined 
as T_LONG via the structmember API.

>>> import pywintypes
>>> dm=pywintypes.DEVMODEType()
>>> dm.Position_x=3
>>> dm.Position_x
3
>>> dm.Position_x=long(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation
>>>

Here's the relevant code from structmember.c
that throws the error:
	case T_LONG:
		if (!PyInt_Check(v)) {
			PyErr_BadArgument();
			return -1;
		}
		*(long*)addr = PyInt_AsLong(v);
		break;


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 20:30

Message:
Logged In: YES 
user_id=33168

Can you provide example code that demonstrates what you mean?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 08:19:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 23:19:48 -0700
Subject: [ python-Bugs-1566140 ] T_ULONG -> double rounding in
	PyMember_GetOne()
Message-ID: <E1GdL4G-0002DB-Am@sc8-sf-web3.sourceforge.net>

Bugs item #1566140, was opened at 2006-09-27 07:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.6
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Piet Delport (pjdelport)
Assigned to: Nobody/Anonymous (nobody)
Summary: T_ULONG -> double rounding in PyMember_GetOne()

Initial Comment:
Problem:

Python/structmember.c's PyMember_GetOne currently
handles getting T_ULONG members as follows:

case T_ULONG:
        v = PyLong_FromDouble((double) *(unsigned
long*)addr);
        break;

On platforms with 64-bit longs, the double won't have
enough precision to hold big values without rounding.

The fix should be simple:

v = PyLong_FromUnsignedLong(*(unsigned long*)addr);

-- Piet Delport <pjd at satori.za.net>


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-10-27 08:19

Message:
Logged In: YES 
user_id=21627

This was fixed with said patch.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-09-27 10:56

Message:
Logged In: YES 
user_id=1326842

Patch #1549049:
http://www.python.org/sf/1549049

has a fix for this and some other bugs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 08:23:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Oct 2006 23:23:19 -0700
Subject: [ python-Bugs-1583276 ] Different behavior when stepping through code
	w/ pdb
Message-ID: <E1GdL7f-0007lO-Ie@sc8-sf-web4.sourceforge.net>

Bugs item #1583276, was opened at 2006-10-23 17:54
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different behavior when stepping through code w/ pdb

Initial Comment:
The attached test case will raise a NameError when
executed in pdb by stepping though the code.  The issue
is the EnumType name, which is both a local variable in
the Enum function which is used in the lambda and the
name of an attribute on the EnumValue class.  Since it
is a local variable used in a lambda, it's a freevar. 
What apparently happens is on line 5 the property()
result is stored in frame->f_locals['EnumType'] but it
is deleted the next time FastToLocals is invoked prior
to calling back into the debugger.  This happens when
the freevars values are merged into the locals dictionary.

The example is a stripped down version of code in
turbogears.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-26 23:23

Message:
Logged In: YES 
user_id=341410

This seems to be a duplicate of http://python.org/sf/1583276 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 12:14:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 03:14:14 -0700
Subject: [ python-Bugs-1585690 ] csv.reader.line_num missing 'new in 2.5'
Message-ID: <E1GdOj8-0005LS-Cd@sc8-sf-web4.sourceforge.net>

Bugs item #1585690, was opened at 2006-10-27 10:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585690&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: csv.reader.line_num missing 'new in 2.5'

Initial Comment:
In this page: http://docs.python.org/lib/node265.html
in the docs for csv.reader.line_num

It should be noted that this attribute is new in Python
2.5.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585690&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 14:16:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 05:16:25 -0700
Subject: [ python-Bugs-1570255 ] redirected cookies
Message-ID: <E1GdQdN-0007Hk-R0@sc8-sf-web2.sourceforge.net>

Bugs item #1570255, was opened at 2006-10-03 16:37
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: hans_moleman (hans_moleman)
Assigned to: Nobody/Anonymous (nobody)
Summary: redirected cookies

Initial Comment:
Cookies are not resend when a redirect is requested.

Blurb:
I've been trying to get a response off a server using
Python.
The response so far differs from the response using
Firefox.
In Python, I have set headers and cookies the way
Firefox does it.

I noticed that the server accepts the POST request, and
redirects the client to another address with the result
on it. This happens both with Python and Firefox correctly.

Cookie handling differs though:
The Python client, when redirected, using the standard
redirect handler, does not resend its cookies to the
redirected address.
Firefox does resend the cookies from the original request.

When I redefine the redirect handler and code it so
that it adds the cookies from the original request,
the response is the same as Firefox's response. This
confirms then that resending cookies is required to get
the server to respond correctly.

Is the default Python redirection cookie policy
different from Firefox's policy?
Could we improve the default redirection handler to
work like Firefox?
Is it a bug?

I noticed an old open bug report 511786, that looks
very much like this problem. It suggests it is fixed.

Cheers Hans Moleman. 


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 08:16

Message:
Logged In: YES 
user_id=11375

Given the sensitive data in your script, it's certainly best
to not post it.  You'll have to dig into urllib2 yourself, I
think.

Start by looking at the code in redirect_request(), around
line 520 of urllib2.py, and adding some debug prints.  Print
out the contents of req.headers; is the cookie line in
there?  Change the __init__ of AbstractHTTPHandler to
default debuglevel to 1, not 0; this will print out all the
HTTP lines being sent and received.


----------------------------------------------------------------------

Comment By: hans_moleman (hans_moleman)
Date: 2006-10-27 00:20

Message:
Logged In: YES 
user_id=1610873

I am using this script to obtain monthly internet usage
statistics from my ISP.
My ISP provides a screen via HTTPS, to enter a usercode and
password, after which the usage statistics are displayed on
a different address. 
I cannot send this script with my usercode and password. My
ISP might not like me doing this either.

Therefore I'll try to find another server that behaves
similarly, and send you that.



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 16:16

Message:
Logged In: YES 
user_id=11375

More detail is needed to figure out if there's a problem;
can you give a sample URL to exhibit the problem?  can you
provide your code?  From the description, it's unclear if
this might be a bug in the handling of redirects or in the
CookieProcessor class.

The bug in 511786 is still fixed; that bug includes sample
code, so I could check it.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 14:19:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 05:19:19 -0700
Subject: [ python-Bugs-1585690 ] csv.reader.line_num missing 'new in 2.5'
Message-ID: <E1GdQgB-0007Zy-HX@sc8-sf-web2.sourceforge.net>

Bugs item #1585690, was opened at 2006-10-27 06:14
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585690&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kent Johnson (kjohnson)
>Assigned to: A.M. Kuchling (akuchling)
Summary: csv.reader.line_num missing 'new in 2.5'

Initial Comment:
In this page: http://docs.python.org/lib/node265.html
in the docs for csv.reader.line_num

It should be noted that this attribute is new in Python
2.5.

Thanks!

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 08:19

Message:
Logged In: YES 
user_id=11375

Fixed in trunk and 25-maint.  Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585690&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 14:32:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 05:32:31 -0700
Subject: [ python-Bugs-1580472 ] glob.glob("c:\\[ ]\*) doesn't work
Message-ID: <E1GdQsx-0000OE-1S@sc8-sf-web2.sourceforge.net>

Bugs item #1580472, was opened at 2006-10-19 11:44
Message generated for change (Comment added) made by potten
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Koblaid (koblaid)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob.glob("c:\\[ ]\*) doesn't work

Initial Comment:
OS: Windows 2000 Service Pack 4
Python 2.5

glob.glob() doesn't work in directories named 
"[ ]" (with a blank in it). Another example is a 
directory named "A - [Aa-Am]"

Example:
#########################
C:\>md []
C:\>md "[ ]"
C:\>copy anyfile.txt []
        1 Datei(en) kopiert.
C:\>copy anyfile.txt "[ ]"
        1 Datei(en) kopiert.

C:\>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC 
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import glob
>>> glob.glob ("c:\\[]\*")
['c:\\[]\\anyfile.txt']
>>> glob.glob ("c:\\[ ]\*")
[]
#########################

The second glob should have resulted the same as the 
first glob since I copied the same file to both 
directories.
I may be wrong because I'm new to python. But I've 
tested it a couple of times, and I think it have to be 
a bug of python or a bug of windows.

Greets, Koblaid

----------------------------------------------------------------------

Comment By: Peter Otten (potten)
Date: 2006-10-27 12:32

Message:
Logged In: YES 
user_id=703365

Not a bug. "[abc]" matches exactly one character which may be "a", "b" or "c". 
Therefore "[ ]" matches one space character. If you want a literal "[", put it in brackets, 
e. g. glob.glob("C:\\[[] ]\\*").  
 
--- 
 
By the way, do you think this problem is common enough to warrant the addition of a 
fnmatch.escape() function? I have something like this in mind: 
 
>>> import re 
>>> r = re.compile("(%s)" % "|".join(re.escape(c) for c in "*?[")) 
>>> def escape(s): 
...     return r.sub(r"[\1]", s) 
... 
>>> escape("c:\\[a-z]\\*") 
'c:\\[[]a-z]\\[*]' 
 

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-27 06:14

Message:
Logged In: YES 
user_id=341410

This is a known issue with the fnmatch module (what glob
uses under the covers).  According to the documentation of
the translate method that converts patterns into regular
expressions... "There is no way to quote meta-characters." 
The fact that "[]" works but "[ ]" doesn't work is a
convenient bug, for those who want to use "[]".

If you can come up with some similar but non-ambiguous
syntax to update the fnmatch module, I'm sure it would be
considered, but as-is, I can't see this as a "bug" per-se.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 14:54:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 05:54:33 -0700
Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be
	parsed
Message-ID: <E1GdREH-0001cw-SM@sc8-sf-web6.sourceforge.net>

Bugs item #1583946, was opened at 2006-10-24 14:32
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" names cannot be parsed

Initial Comment:
(Python 2.5 library)

    The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()".  These return strings.

    The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format.  But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/". 

    However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.

    This is more than a theoretical problem.  The
issuer field of Verisign certificates has a "/" in the
middle of a text field:

"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".

Note the 

  "OU=Terms of use at www.verisign.com/rpa (c)00"

with a "/" in the middle of the value field.  Oops.

    Worse, this is potentially exploitable.  By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else.  Just order a
certificate from GoDaddy, enter something like this in
the "Name" field

    "Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"

and Python code will be spoofed into thinking you're eBay.

   Fortunately, browsers don't use Python code.

   The actual bug is in

    python/trunk/Modules/_ssl.c

at

    if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
       
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
                  self->server, X509_NAME_MAXLEN);
       
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
                  self->issuer, X509_NAME_MAXLEN);

The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string.  This is a debug function, not one
for use in production code.  The SSL documentation for
"X509_name_oneline" says:   

    "The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies.  Their use is strongly discouraged in
new applications."

What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry().  A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly. 

X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.

So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server".  The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)

The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info.  Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.

And, of course, this needs to be fixed as part of
Unicode support.  


                John Nagle
                Animats


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 08:54

Message:
Logged In: YES 
user_id=11375

I've reworded the description in the documentation to say
something like this: "Returns a string describing the issuer
of the server's certificate.
Useful for debugging purposes; do not parse the content of
this string
because its format can't be parsed unambiguously."

For adding new features: please submit a patch.  Python's
maintainers probably don't use SSL in 
any sophisticated way and therefore have no idea what shape
better SSL/X.509 support would take.



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 14:05

Message:
Logged In: YES 
user_id=21627

Notice that RFC 2253 has been superceded by RFC 4514 (see my
earlier message). However, I really see no reason to fix this:
even if the ambiguity problems were fixed, you *still*
should not
use the issuer and subject names in a security-relevant context.


----------------------------------------------------------------------

Comment By: John Nagle (nagle)
Date: 2006-10-25 13:26

Message:
Logged In: YES 
user_id=5571

Actually, they don't do what they're "designed to do". 
According to the Python library documentation for SSL
objects, the server method "Returns a string containing the
ASN.1 distinguished name identifying the server's
certificate. (See below for an example showing what
distinguished names look like.)" The example "below" is
missing from the documentation, so the documentation gives
us no clue of what to expect.  

There are several standardized representations for ASN.1
information.  See
"http://www.oss.com/asn1/tutorial/Explain.html"  Most are
binary. The only standard textual form is "XER", which is an
XML representation of ASN.1 encoded information.  It's
essentially the same representation used for parameters in
SOAP. 

So, given the documentation and the standard, what should be
coming out is the XML representation of that data. 

Here's an entire X.509 certificate in XML:

http://www.gnu.org/software/gnutls/manual/html_node/An-X_002e509-certificate.html

The "issuer" field can be seen in there.  It's awfully
bulky.  And making SSL dependent on the SOAP module probably
isn't desireable.  But that's an ASN.1 distinguished name in
XML format, per the standard. 

That's probably not what's wanted by most users, although
the ability to retrieve an entire certificate in XML format
would be useful.

However, there's another standard string encoding, which is
defined in RFC2253.  This is comma-separated UTF-8 with
backslash escapes for special characters.  That's reliably
parseable. There's an openSSL function,
"X509_NAME_print_ex", which does this formatting, but it
doesn't output to a string.  That's the right mechanism if
it can be invoked in some way to yield a string.  It should
be invoked with flags = ASN1_STRFLGS_RFC2253, which yields a
UTF8 string, which of course should become a Python Unicode
string.

Now if someone can figure out how to get a string, instead
of file output, out of OpenSSL's "X509_NAME_print_ex", we're
home. 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 04:38

Message:
Logged In: YES 
user_id=21627

The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.

Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so (for use within LDAP).

Also notice that that the SSL module does little to actually
support trust: there is no verification of server-side
certs, no access to extensions of a certificate, etc. So an
application and a user should *not* trust the issuer name it
received, anyway (unless 
there is an independent verification that the server
certificate can be trusted).

All that said: If you think you need this functionality,
please provide a patch to implement it.

----------------------------------------------------------------------

Comment By: John Nagle (nagle)
Date: 2006-10-24 18:40

Message:
Logged In: YES 
user_id=5571

The problem isn't in the version of OpenSSL used in Python,
which is at 0.9.8a.  OpenSSL has had the necessary functions
for years.  But Python isn't using them.

It's in  "python/trunk/Modules/_ssl.c", as described above.  

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-10-24 18:05

Message:
Logged In: YES 
user_id=413

Yes OpenSSL 0.9.8d or later should be used for a new binary
release.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 15:07:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 06:07:35 -0700
Subject: [ python-Bugs-1562583 ] asyncore.dispatcher.set_reuse_addr not
	documented.
Message-ID: <E1GdRQt-0003qK-Ti@sc8-sf-web2.sourceforge.net>

Bugs item #1562583, was opened at 2006-09-20 21:21
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562583&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Noah Spurrier (noah)
>Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore.dispatcher.set_reuse_addr not documented.

Initial Comment:
I could not find this in
http://docs.python.org/lib/module-asyncore.html
nor in http://docs.python.org/lib/genindex.html


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 09:07

Message:
Logged In: YES 
user_id=11375

Added to the docs on the trunk, 25-maint, and 24-maint
branches.  Thanks for your report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562583&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 15:36:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 06:36:46 -0700
Subject: [ python-Bugs-1542016 ] inconsistency in PCALL conditional code in
	ceval.c
Message-ID: <E1GdRt8-0000BJ-K9@sc8-sf-web4.sourceforge.net>

Bugs item #1542016, was opened at 2006-08-17 10:21
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542016&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
>Assigned to: A.M. Kuchling (akuchling)
Summary: inconsistency in PCALL conditional code in ceval.c

Initial Comment:
While there are macros to profile PCALL_POP, the
reporting of it via sys.callstats() is broken.

This patch solves it.

Index: Python/ceval.c
===================================================================
--- Python/ceval.c      (revisi?n: 51339)
+++ Python/ceval.c      (copia de trabajo)
@@ -186,10 +186,10 @@
 PyObject *
 PyEval_GetCallStats(PyObject *self)
 {
-       return Py_BuildValue("iiiiiiiiii",
+       return Py_BuildValue("iiiiiiiiiii",
                             pcall[0], pcall[1],
pcall[2], pcall[3],
                             pcall[4], pcall[5],
pcall[6], pcall[7],
-                            pcall[8], pcall[9]);
+                            pcall[8], pcall[9],
pcall[10]);
 }
 #else
 #define PCALL(O)


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 09:36

Message:
Logged In: YES 
user_id=11375

Committed to the trunk in rev. 52469, to 25-maint in rev.
52470, and to 24-maint in rev. 52472.  Thanks for your bug
report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542016&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 16:01:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 07:01:12 -0700
Subject: [ python-Bugs-1580472 ] glob.glob("c:\\[ ]\*) doesn't work
Message-ID: <E1GdSGk-0003Yp-LY@sc8-sf-web5.sourceforge.net>

Bugs item #1580472, was opened at 2006-10-19 11:44
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Koblaid (koblaid)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob.glob("c:\\[ ]\*) doesn't work

Initial Comment:
OS: Windows 2000 Service Pack 4
Python 2.5

glob.glob() doesn't work in directories named 
"[ ]" (with a blank in it). Another example is a 
directory named "A - [Aa-Am]"

Example:
#########################
C:\>md []
C:\>md "[ ]"
C:\>copy anyfile.txt []
        1 Datei(en) kopiert.
C:\>copy anyfile.txt "[ ]"
        1 Datei(en) kopiert.

C:\>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC 
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import glob
>>> glob.glob ("c:\\[]\*")
['c:\\[]\\anyfile.txt']
>>> glob.glob ("c:\\[ ]\*")
[]
#########################

The second glob should have resulted the same as the 
first glob since I copied the same file to both 
directories.
I may be wrong because I'm new to python. But I've 
tested it a couple of times, and I think it have to be 
a bug of python or a bug of windows.

Greets, Koblaid

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-27 14:01

Message:
Logged In: YES 
user_id=849994

Not a bug, as Peter said.

----------------------------------------------------------------------

Comment By: Peter Otten (potten)
Date: 2006-10-27 12:32

Message:
Logged In: YES 
user_id=703365

Not a bug. "[abc]" matches exactly one character which may be "a", "b" or "c". 
Therefore "[ ]" matches one space character. If you want a literal "[", put it in brackets, 
e. g. glob.glob("C:\\[[] ]\\*").  
 
--- 
 
By the way, do you think this problem is common enough to warrant the addition of a 
fnmatch.escape() function? I have something like this in mind: 
 
>>> import re 
>>> r = re.compile("(%s)" % "|".join(re.escape(c) for c in "*?[")) 
>>> def escape(s): 
...     return r.sub(r"[\1]", s) 
... 
>>> escape("c:\\[a-z]\\*") 
'c:\\[[]a-z]\\[*]' 
 

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-27 06:14

Message:
Logged In: YES 
user_id=341410

This is a known issue with the fnmatch module (what glob
uses under the covers).  According to the documentation of
the translate method that converts patterns into regular
expressions... "There is no way to quote meta-characters." 
The fact that "[]" works but "[ ]" doesn't work is a
convenient bug, for those who want to use "[]".

If you can come up with some similar but non-ambiguous
syntax to update the fnmatch module, I'm sure it would be
considered, but as-is, I can't see this as a "bug" per-se.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 18:07:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 09:07:52 -0700
Subject: [ python-Bugs-1576241 ] functools.wraps fails on builtins
Message-ID: <E1GdUFM-0006jM-EK@sc8-sf-web4.sourceforge.net>

Bugs item #1576241, was opened at 2006-10-13 08:24
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kajiuma (kajiuma)
Assigned to: Nick Coghlan (ncoghlan)
Summary: functools.wraps fails on builtins

Initial Comment:
functools.wraps assumes that the wrapped function 
has a __dict__ attribute, which is not true for 
builtins.

The attached patch provides an empty dictionaries 
for functions that do not have the required 
attributes. This will cause programs expecting an 
AttributeError (if there are any) to fail.


----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-10-28 02:07

Message:
Logged In: YES 
user_id=1038590

I was mainly considering the decorator use case when I wrote
the function, so the idea of a wrapped function without a
dict attribute didn't occur to me (obviously!).

So definitely fix it on the trunk, and I'd say backport it
to 2.5 as well. My reasoning regarding the latter is that
the example code in the documentation for functools.wraps is
actually buggy with the current behaviour. With this bug
fixed, the documentation example will work as intended.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 05:18

Message:
Logged In: YES 
user_id=11375

The change seems reasonable, but arguably this is an API
change because of the AttributeError no longer being raised.
 Nick, do you want to decide whether to make this change or
not?  (I can make the edit and add a test if you agree to
apply this change.)


----------------------------------------------------------------------

Comment By: kajiuma (kajiuma)
Date: 2006-10-13 08:33

Message:
Logged In: YES 
user_id=1619773

Looks like lynx cannot send files.
The patch changed: getattr(wrapped, attr)
to: getattr(wrapped, attr, {})
At then end of line 35 of Lib/functools.py


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 18:42:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 09:42:30 -0700
Subject: [ python-Bugs-1576241 ] functools.wraps fails on builtins
Message-ID: <E1GdUms-0003oH-4C@sc8-sf-web3.sourceforge.net>

Bugs item #1576241, was opened at 2006-10-12 18:24
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: kajiuma (kajiuma)
>Assigned to: A.M. Kuchling (akuchling)
Summary: functools.wraps fails on builtins

Initial Comment:
functools.wraps assumes that the wrapped function 
has a __dict__ attribute, which is not true for 
builtins.

The attached patch provides an empty dictionaries 
for functions that do not have the required 
attributes. This will cause programs expecting an 
AttributeError (if there are any) to fail.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 12:42

Message:
Logged In: YES 
user_id=11375

Committed to trunk (rev.52476) and 25-maint (rev. 52477). 
thanks for your patch!

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-10-27 12:07

Message:
Logged In: YES 
user_id=1038590

I was mainly considering the decorator use case when I wrote
the function, so the idea of a wrapped function without a
dict attribute didn't occur to me (obviously!).

So definitely fix it on the trunk, and I'd say backport it
to 2.5 as well. My reasoning regarding the latter is that
the example code in the documentation for functools.wraps is
actually buggy with the current behaviour. With this bug
fixed, the documentation example will work as intended.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 15:18

Message:
Logged In: YES 
user_id=11375

The change seems reasonable, but arguably this is an API
change because of the AttributeError no longer being raised.
 Nick, do you want to decide whether to make this change or
not?  (I can make the edit and add a test if you agree to
apply this change.)


----------------------------------------------------------------------

Comment By: kajiuma (kajiuma)
Date: 2006-10-12 18:33

Message:
Logged In: YES 
user_id=1619773

Looks like lynx cannot send files.
The patch changed: getattr(wrapped, attr)
to: getattr(wrapped, attr, {})
At then end of line 35 of Lib/functools.py


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470

From noreply at sourceforge.net  Fri Oct 27 21:17:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 12:17:50 -0700
Subject: [ python-Bugs-1576174 ] str(WindowsError) wrong
Message-ID: <E1GdXDC-0000ca-8g@sc8-sf-web5.sourceforge.net>

Bugs item #1576174, was opened at 2006-10-12 22:12
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: str(WindowsError) wrong

Initial Comment:
str(WindowsError(1001, 'a message') in Python 2.5 gives
'[Error 22] a message'.

The attached patch with test fixes this.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-10-27 21:17

Message:
Logged In: YES 
user_id=11105

Committed as rev 52485 (trunk) and 52486 (release25-maint).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-10-21 11:53

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply (along with a NEWS entry,
for both 2.5 and the trunk).

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-13 20:17

Message:
Logged In: YES 
user_id=11105

Uploaded a new patch which I actually tested under Linux also.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-13 20:17

Message:
Logged In: YES 
user_id=11105

My bad.  I didn't test on Linux.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-10-12 23:53

Message:
Logged In: YES 
user_id=1326842

The part of the patch that changes EnvironmentError_str
should be removed (EnvironmentError doesn't have a winerror
member, the change causes compilation errors).  Otherwise
the patch looks fine.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-10-12 22:13

Message:
Logged In: YES 
user_id=11105

See also:
http://mail.python.org/pipermail/python-dev/2006-September/068869.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470

From noreply at sourceforge.net  Sat Oct 28 00:53:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 15:53:51 -0700
Subject: [ python-Bugs-1580738 ] httplib hangs reading too much data
Message-ID: <E1GdaaF-00075S-0V@sc8-sf-web6.sourceforge.net>

Bugs item #1580738, was opened at 2006-10-19 14:06
Message generated for change (Comment added) made by djmitche
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580738&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dustin J. Mitchell (djmitche)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib hangs reading too much data

Initial Comment:
I'm building an interface to Amazon's S3, using httplib.  It uses a
single object for multiple transactions.  What's happening is this:

HTTP > PUT /unitest-temp-1161039691 HTTP/1.1
HTTP > Date: Mon, 16 Oct 2006 23:01:32 GMT
HTTP > Authorization: AWS <<cough>>:KiTWRuq/
6aay0bI2J5DkE2TAWD0=
HTTP > (end headers)
HTTP < HTTP/1.1 200 OK
HTTP < content-length: 0
HTTP < x-amz-id-2: 40uQn0OCpTiFcX+LqjMuzG6NnufdUk/..
HTTP < server: AmazonS3
HTTP < x-amz-request-id: FF504E8FD1B86F8C
HTTP < location: /unitest-temp-1161039691
HTTP < date: Mon, 16 Oct 2006 23:01:33 GMT
HTTPConnection.__state before response.read:  Idle
HTTPConnection.__response: closed? False length: 0
reading response
HTTPConnection.__state after response.read:  Idle
HTTPConnection.__response: closed? False length: 0

 ..later in the same connection..

HTTPConnection.__state before putrequest:  Idle
HTTPConnection.__response: closed? False length: 0
HTTP > DELETE /unitest-temp-1161039691 HTTP/1.1
HTTP > Date: Mon, 16 Oct 2006 23:01:33 GMT
HTTP > Authorization: AWS <<cough>>:
a5OizuLNwwV7eBUhha0B6rEJ+CQ=
HTTP > (end headers)
HTTPConnection.__state before getresponse:  Request-sent
HTTPConnection.__response: closed? False length: 0
  File "/usr/lib64/python2.4/httplib.py", line 856, in getresponse
    raise ResponseNotReady()

If the first request does not precede it, the second request is fine.
To avoid excessive memory use, I'm calling request.read(16384)
repeatedly, instead of just calling request.read().  This seems to be
key to the problem -- if I omit the 'amt' argument to read(), then the
last line of the first request reads

HTTPConnection.__response: closed? True length: 0

and the later call to getresponse() doesn't raise ResponseNotReady.

Looking at the source for httplib.HTTPResponse.read, self.close() gets
called in the latter (working) case, but not in the former
(non-working).  It would seem sensible to add 'if self.length == 0:
self.close()' to the end of that function (and, in fact, this change makes 
the whole thing work), but this comment makes me hesitant:

# we do not use _safe_read() here because this may be a .will_close
# connection, and the user is reading more bytes than will be provided
# (for example, reading in 1k chunks)

I suspect that either (a) this is a bug or (b) the client is supposed to 
either call read() with no arguments or calculate the proper inputs to 
read(amt) based on the Content-Length header.  If (b), I would think 
the docs should be updated to reflect that?

Thanks for any assistance.


----------------------------------------------------------------------

>Comment By: Dustin J. Mitchell (djmitche)
Date: 2006-10-27 17:53

Message:
Logged In: YES 
user_id=7446

Excellent -- the first paragraph, where you talk about the .length attribute, makes things quite clear, so I agree that (b) is the correct solution: include the content of that 
paragraph in the documentation.  Thanks!

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-10-26 21:21

Message:
Logged In: YES 
user_id=14198

The correct answer is indeed (b) - but note that httplib
will itself do the content-length magic for you, including
the correct handling of 'chunked' encoding.  If the .length
attribute is not None, then that is exactly how many bytes
you should read.  If .length is None, then either chunked
encoding is used (in which case you can call read() with a
fixed size until it returns an empty string), or no
content-length was supplied (which can be treated the same
as chunked, but the connection will close at the end. 
Checking ob.will_close can give you some insight into that.

Its not reasonable to add 'if self.length==0: self.close()'
- it is perfectly valid to have a zero byte response within
a keep-alive connection - we don't want to force a new
(expensive) connection to the server just because a zero
byte response was requested.

The HTTP semantics are hard to get your head around, but I
believe httplib gets it right, and a ResponseNotReady
exception in particular points at an error in the code
attempting to use the library.  Working with connections
that keep alive is tricky - you just jump through hoops to
ensure you maintain the state of the httplib object
correctly - in general, that means you must *always* consume
the entire response (even if it is zero bytes) before
attempting to begin a new request.  This requirement doesn't
exists for connections that close - if you fail to read the
entire response it can be thrown away as the next request
will happen on a new connection.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580738&group_id=5470

From noreply at sourceforge.net  Sat Oct 28 06:56:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 21:56:25 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GdgF7-0005zq-BB@sc8-sf-web5.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 19:23
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-27 21:56

Message:
Logged In: YES 
user_id=33168

Mike, what platform are you having the problem on?

I tried Tim's hope.py on Linux x86_64 and Mac OS X 10.4 with
debug builds and neither one crashed.  Tim's guess looks
pretty damn good too.  Here's the result of valgrind:

Invalid read of size 8                                     
                    
   at 0x4CEBFE: PyTraceBack_Here (traceback.c:117)         
                    
   by 0x49C1F1: PyEval_EvalFrameEx (ceval.c:2515)          
                    
   by 0x4F615D: gen_send_ex (genobject.c:82)               
                    
   by 0x4F6326: gen_close (genobject.c:128)                
                    
   by 0x4F645E: gen_del (genobject.c:163)                  
                    
   by 0x4F5F00: gen_dealloc (genobject.c:31)               
                    
   by 0x44D207: _Py_Dealloc (object.c:1928)                
                    
   by 0x44534E: dict_dealloc (dictobject.c:801)            
                    
   by 0x44D207: _Py_Dealloc (object.c:1928)                
                    
   by 0x4664FF: subtype_dealloc (typeobject.c:686)         
                    
   by 0x44D207: _Py_Dealloc (object.c:1928)                
                    
   by 0x42325D: instancemethod_dealloc (classobject.c:2287)
                    
 Address 0x56550C0 is 88 bytes inside a block of size 152
free'd                
   at 0x4A1A828: free (vg_replace_malloc.c:233)            
                    
   by 0x4C3899: tstate_delete_common (pystate.c:256)       
                    
   by 0x4C3926: PyThreadState_DeleteCurrent (pystate.c:282)
                    
   by 0x4D4043: t_bootstrap (threadmodule.c:448)           
                    
   by 0x4B24C48: pthread_start_thread (in
/lib/libpthread-0.10.so)              

The only way I can think to fix this is to keep a set of
active generators in the PyThreadState and calling
gen_send_ex(exc=1) for all the active generators before
killing the tstate in t_bootstrap.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-10-19 00:58

Message:
Logged In: YES 
user_id=6656

> and for some reason Python uses the system malloc directly
> to obtain memory for thread states.

This bit is fairly easy: they are allocated without the GIL being held, which 
breaks an assumption of PyMalloc.

No idea about the real problem, sadly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-10-18 17:38

Message:
Logged In: YES 
user_id=31435

I've attached a much simplified pure-Python script (hope.py)
that reproduces a problem very quickly, on Windows, in a
/debug/ build of current trunk.  It typically prints:

exiting generator
joined thread

at most twice before crapping out.  At the time, the `next`
argument to newtracebackobject() is 0xdddddddd, and tracing
back a level shows that, in PyTraceBack_Here(),
frame->tstate is entirely filled with 0xdd bytes.

Note that this is not a debug-build obmalloc gimmick!  This
is Microsoft's similar debug-build gimmick for their malloc,
and for some reason Python uses the system malloc directly
to obtain memory for thread states.  The Microsoft debug
free() fills newly-freed memory with 0xdd, which has the
same meaning as the debug-build obmalloc's DEADBYTE (0xdb).

So somebody is accessing a thread state here after it's been
freed.  Best guess is that the generator is getting "cleaned
up" after the thread that created it has gone away, so the
generator's frame's f_tstate is trash.

Note that a PyThreadState (a frame's f_tstate) is /not/ a
Python object -- it's just a raw C struct, and its lifetime
isn't controlled by refcounts.

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 17:12

Message:
Logged In: YES 
user_id=1611720

Despite Tim's reassurrance, I'm afraid that Martin's patch
does infact prevent the segfault.  Sounds like it also
introduces a memleak.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-10-18 14:57

Message:
Logged In: YES 
user_id=31435

> Can anybody tell why gi_frame *isn't* incref'ed when
> the generator is created?

As documented (in concrete.tex), PyGen_New(f) steals a
reference to the frame passed to it.  Its only call site
(well, in the core) is in ceval.c, which returns immediately
after PyGen_New takes over ownership of the frame the caller
created:

"""
/* Create a new generator that owns the ready to run frame
 * and return that as the value. */
return PyGen_New(f);
"""

In short, that PyGen_New() doesn't incref the frame passed
to it is intentional.

It's possible that the intent is flawed ;-), but offhand I
don't see how.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 14:05

Message:
Logged In: YES 
user_id=21627

Can you please review/try attached patch? Can anybody tell
why gi_frame *isn't* incref'ed when the generator is created?

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 12:47

Message:
Logged In: YES 
user_id=1611720

I cannot yet produce an only-python script which reproduces
the problem, but I can give an overview.  There is a
generator running in one thread, an exception being raised
in another thread, and as a consequent, the generator in the
first thread is garbage-collected (triggering an exception
due to the new generator cleanup).  The problem is extremely
sensitive to timing--often the insertion/removal of print
statements, or reordering the code, causes the problem to
vanish, which is confounding my ability to create a simple
test script.

def getdocs():
    def f():
        <some somehwat time-consuming operation>
    while True:
        f()
        yield None

#
-----------------------------------------------------------------------------

class B(object):
    def __init__(self,):
        pass
    def doit(self):
        # must be an instance var to trigger segfault
        self.docIter = getdocs()
        print self.docIter # this is the generator
referred-to in the traceback
        for i, item in enumerate(self.docIter):            
            if i > 9:
                break            
        print 'exiting generator'


class A(object):
    """ Process entry point / main thread """
    def __init__(self):
  
        while True:
            try:
                self.func()
            except Exception, e:
                print 'right after raise'

  
    def func(self):        
        b = B()
        thread = threading.Thread(target=b.doit)
        thread.start()
        start_t = time.time()
        while True:
            try:
                if time.time() - start_t > 1:
                    raise Exception
            except Exception:
                print 'right before raise'
                # SIGSEGV here.  If this is changed to
                # 'break', no segfault occurs
                raise


if __name__ == '__main__':
    A()


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 12:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 19:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Sat Oct 28 07:18:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Oct 2006 22:18:13 -0700
Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Message-ID: <E1GdgaD-00029X-OK@sc8-sf-web6.sourceforge.net>

Bugs item #1579370, was opened at 2006-10-17 22:23
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Mike Klaas (mklaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault provoked by generators and exceptions

Initial Comment:
A reproducible segfault when using heavily-nested
generators and exceptions.

Unfortunately, I haven't yet been able to provoke this
behaviour with a standalone python2.5 script.  There
are, however, no third-party c extensions running in
the process so I'm fairly confident that it is a
problem in the core.

The gist of the code is a series of nested generators
which leave scope when an exception is raised.  This
exception is caught and re-raised in an outer loop. 
The old exception was holding on to the frame which was
keeping the generators alive, and the sequence of
generator destruction and new finalization caused the
segfault.   

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-10-28 01:18

Message:
Logged In: YES 
user_id=31435

> I tried Tim's hope.py on Linux x86_64 and
> Mac OS X 10.4 with debug builds and neither
> one crashed.  Tim's guess looks pretty damn
> good too.

Neal, note that it's the /Windows/ malloc that fills freed
memory with "dangerous bytes" in a debug build -- this
really has nothing to do with that it's a debug build of
/Python/ apart from that on Windows a debug build of Python
also links in the debug version of Microsoft's malloc.

The valgrind report is pointing at the same thing.  Whether
this leads to a crash is purely an accident of when and how
the system malloc happens to reuse the freed memory.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-28 00:56

Message:
Logged In: YES 
user_id=33168

Mike, what platform are you having the problem on?

I tried Tim's hope.py on Linux x86_64 and Mac OS X 10.4 with
debug builds and neither one crashed.  Tim's guess looks
pretty damn good too.  Here's the result of valgrind:

Invalid read of size 8                                     
                    
   at 0x4CEBFE: PyTraceBack_Here (traceback.c:117)         
                    
   by 0x49C1F1: PyEval_EvalFrameEx (ceval.c:2515)          
                    
   by 0x4F615D: gen_send_ex (genobject.c:82)               
                    
   by 0x4F6326: gen_close (genobject.c:128)                
                    
   by 0x4F645E: gen_del (genobject.c:163)                  
                    
   by 0x4F5F00: gen_dealloc (genobject.c:31)               
                    
   by 0x44D207: _Py_Dealloc (object.c:1928)                
                    
   by 0x44534E: dict_dealloc (dictobject.c:801)            
                    
   by 0x44D207: _Py_Dealloc (object.c:1928)                
                    
   by 0x4664FF: subtype_dealloc (typeobject.c:686)         
                    
   by 0x44D207: _Py_Dealloc (object.c:1928)                
                    
   by 0x42325D: instancemethod_dealloc (classobject.c:2287)
                    
 Address 0x56550C0 is 88 bytes inside a block of size 152
free'd                
   at 0x4A1A828: free (vg_replace_malloc.c:233)            
                    
   by 0x4C3899: tstate_delete_common (pystate.c:256)       
                    
   by 0x4C3926: PyThreadState_DeleteCurrent (pystate.c:282)
                    
   by 0x4D4043: t_bootstrap (threadmodule.c:448)           
                    
   by 0x4B24C48: pthread_start_thread (in
/lib/libpthread-0.10.so)              

The only way I can think to fix this is to keep a set of
active generators in the PyThreadState and calling
gen_send_ex(exc=1) for all the active generators before
killing the tstate in t_bootstrap.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-10-19 03:58

Message:
Logged In: YES 
user_id=6656

> and for some reason Python uses the system malloc directly
> to obtain memory for thread states.

This bit is fairly easy: they are allocated without the GIL being held, which 
breaks an assumption of PyMalloc.

No idea about the real problem, sadly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-10-18 20:38

Message:
Logged In: YES 
user_id=31435

I've attached a much simplified pure-Python script (hope.py)
that reproduces a problem very quickly, on Windows, in a
/debug/ build of current trunk.  It typically prints:

exiting generator
joined thread

at most twice before crapping out.  At the time, the `next`
argument to newtracebackobject() is 0xdddddddd, and tracing
back a level shows that, in PyTraceBack_Here(),
frame->tstate is entirely filled with 0xdd bytes.

Note that this is not a debug-build obmalloc gimmick!  This
is Microsoft's similar debug-build gimmick for their malloc,
and for some reason Python uses the system malloc directly
to obtain memory for thread states.  The Microsoft debug
free() fills newly-freed memory with 0xdd, which has the
same meaning as the debug-build obmalloc's DEADBYTE (0xdb).

So somebody is accessing a thread state here after it's been
freed.  Best guess is that the generator is getting "cleaned
up" after the thread that created it has gone away, so the
generator's frame's f_tstate is trash.

Note that a PyThreadState (a frame's f_tstate) is /not/ a
Python object -- it's just a raw C struct, and its lifetime
isn't controlled by refcounts.

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 20:12

Message:
Logged In: YES 
user_id=1611720

Despite Tim's reassurrance, I'm afraid that Martin's patch
does infact prevent the segfault.  Sounds like it also
introduces a memleak.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-10-18 17:57

Message:
Logged In: YES 
user_id=31435

> Can anybody tell why gi_frame *isn't* incref'ed when
> the generator is created?

As documented (in concrete.tex), PyGen_New(f) steals a
reference to the frame passed to it.  Its only call site
(well, in the core) is in ceval.c, which returns immediately
after PyGen_New takes over ownership of the frame the caller
created:

"""
/* Create a new generator that owns the ready to run frame
 * and return that as the value. */
return PyGen_New(f);
"""

In short, that PyGen_New() doesn't incref the frame passed
to it is intentional.

It's possible that the intent is flawed ;-), but offhand I
don't see how.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-18 17:05

Message:
Logged In: YES 
user_id=21627

Can you please review/try attached patch? Can anybody tell
why gi_frame *isn't* incref'ed when the generator is created?

----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 15:47

Message:
Logged In: YES 
user_id=1611720

I cannot yet produce an only-python script which reproduces
the problem, but I can give an overview.  There is a
generator running in one thread, an exception being raised
in another thread, and as a consequent, the generator in the
first thread is garbage-collected (triggering an exception
due to the new generator cleanup).  The problem is extremely
sensitive to timing--often the insertion/removal of print
statements, or reordering the code, causes the problem to
vanish, which is confounding my ability to create a simple
test script.

def getdocs():
    def f():
        <some somehwat time-consuming operation>
    while True:
        f()
        yield None

#
-----------------------------------------------------------------------------

class B(object):
    def __init__(self,):
        pass
    def doit(self):
        # must be an instance var to trigger segfault
        self.docIter = getdocs()
        print self.docIter # this is the generator
referred-to in the traceback
        for i, item in enumerate(self.docIter):            
            if i > 9:
                break            
        print 'exiting generator'


class A(object):
    """ Process entry point / main thread """
    def __init__(self):
  
        while True:
            try:
                self.func()
            except Exception, e:
                print 'right after raise'

  
    def func(self):        
        b = B()
        thread = threading.Thread(target=b.doit)
        thread.start()
        start_t = time.time()
        while True:
            try:
                if time.time() - start_t > 1:
                    raise Exception
            except Exception:
                print 'right before raise'
                # SIGSEGV here.  If this is changed to
                # 'break', no segfault occurs
                raise


if __name__ == '__main__':
    A()


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-18 15:37

Message:
Logged In: YES 
user_id=1611720

I've produced a simplified traceback with a single generator
.  Note the frame being used in the traceback (#0) is the
same frame being dealloc'd (#11).

The relevant call in traceback.c is:
PyTraceBack_Here(PyFrameObject *frame)
{
        PyThreadState *tstate = frame->f_tstate;
        PyTracebackObject *oldtb = (PyTracebackObject *)
tstate->curexc_traceback;
        PyTracebackObject *tb = newtracebackobject(oldtb,
frame);

and I can verify that oldtb contains garbage:
(gdb) print frame
$1 = (PyFrameObject *) 0x8964d94
(gdb) print frame->f_tstate
$2 = (PyThreadState *) 0x895b178
(gdb) print $2->curexc_traceback
$3 = (PyObject *) 0x66



#0  0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb7cca4ac,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb7cca4ac) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb7cca4ac) at
Objects/genobject.c:31
#6  0x080815b9 in dict_dealloc (mp=0xb7cc913c) at
Objects/dictobject.c:801
#7  0x080927b2 in subtype_dealloc (self=0xb7cca76c) at
Objects/typeobject.c:686
#8  0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at
Objects/classobject.c:2285
#9  0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at
Objects/dictobject.c:801
#10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at
Objects/typeobject.c:686
#11 0x081028c5 in frame_dealloc (f=0x8964a94) at
Objects/frameobject.c:416
#12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at
Python/traceback.c:34
#13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at
Python/traceback.c:33
#14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020,
hash=1492466088, value=0xb7ccd054)
    at Objects/dictobject.c:394
#15 0x080811a4 in PyDict_SetItem (op=0xb7f99824,
key=0xb7ccd020, value=0xb7ccd054)
    at Objects/dictobject.c:619
#16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824,
key=0x8129284 "exc_traceback", 
    item=0xb7ccd054) at Objects/dictobject.c:2103
#17 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb7ccd054)
    at Python/sysmodule.c:82
#18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934,
throwflag=0) at Python/ceval.c:2954
---Type <return> to continue, or q <return> to quit---
#19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8,
globals=0xb7fafa44, locals=0x0, 
    args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2833
#20 0x08104083 in function_call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/funcobject.c:517
#21 0x0805a660 in PyObject_Call (func=0xb7cc7294,
arg=0xb7cc5fec, kw=0x0)
    at Objects/abstract.c:1860


----------------------------------------------------------------------

Comment By: Mike Klaas (mklaas)
Date: 2006-10-17 22:23

Message:
Logged In: YES 
user_id=1611720

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208400192 (LWP 26235)]
0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
94              if ((next != NULL &&
!PyTraceBack_Check(next)) ||
(gdb) bt
#0  0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at
Python/traceback.c:94
#1  0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4,
throwflag=1) at Python/ceval.c:2459
#2  0x08101a40 in gen_send_ex (gen=0xb64f880c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#3  0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at
Objects/genobject.c:128
#4  0x08101cde in gen_del (self=0xb64f880c) at
Objects/genobject.c:163
#5  0x0810195b in gen_dealloc (gen=0xb64f880c) at
Objects/genobject.c:31
#6  0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c,
throwflag=1) at Python/ceval.c:2491
#7  0x08101a40 in gen_send_ex (gen=0xb64f362c,
arg=0x81333e0, exc=1) at Objects/genobject.c:82
#8  0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at
Objects/genobject.c:128
#9  0x08101cde in gen_del (self=0xb64f362c) at
Objects/genobject.c:163
#10 0x0810195b in gen_dealloc (gen=0xb64f362c) at
Objects/genobject.c:31
#11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at
Objects/dictobject.c:801
#12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at
Objects/typeobject.c:686
#13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at
Objects/classobject.c:2285
#14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at
Objects/dictobject.c:801
#15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at
Objects/typeobject.c:686
#16 0x081028c5 in frame_dealloc (f=0x9c272bc) at
Objects/frameobject.c:416
#17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at
Python/traceback.c:34
#18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at
Python/traceback.c:33
#19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at
Python/traceback.c:33
#20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930,
hash=1492466088, value=0xb3fb9914)
    at Objects/dictobject.c:394
#21 0x080811a4 in PyDict_SetItem (op=0xb7f56824,
key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619
#22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824,
key=0x8129284 "exc_traceback", item=0xb3fb9914)
    at Objects/dictobject.c:2103
#23 0x080e2837 in PySys_SetObject (name=0x8129284
"exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82
#24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c,
throwflag=0) at Python/ceval.c:2954
#25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890,
globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1,
    kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1,
closure=0x0) at Python/ceval.c:2833
#26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c,
throwflag=0) at Python/ceval.c:3662
#27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848,
globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1,
    kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#28 0x08104083 in function_call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517
#29 0x0805a660 in PyObject_Call (func=0xb7b79c34,
arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860
#30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c,
throwflag=0) at Python/ceval.c:3846
#31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608,
globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2,
    kws=0x9b77664, kwcount=0, defs=0x0, defcount=0,
closure=0xb7cfe874) at Python/ceval.c:2833
#32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c,
throwflag=0) at Python/ceval.c:3662
#33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c,
throwflag=0) at Python/ceval.c:3652
#34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728,
globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0,
    kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0,
closure=0xb796410c) at Python/ceval.c:2833
#35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc,
throwflag=0) at Python/ceval.c:3662
#36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770,
globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0,
    kws=0x99086c0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2833
#37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584,
throwflag=0) at Python/ceval.c:3662
#38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0,
    kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2833
---Type <return> to continue, or q <return> to quit---
#39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8,
globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494
#40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008,
filename=0xbfffd4a3 "scoreserver.py", start=257,
    globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1,
flags=0xbfffd298) at Python/pythonrun.c:1264
#41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp"
is not available.
) at Python/pythonrun.c:870
#42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at
Modules/main.c:496
#43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6
#44 0x08056051 in _start ()



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470

From noreply at sourceforge.net  Sat Oct 28 23:22:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 14:22:48 -0700
Subject: [ python-Bugs-1586414 ] tarfile.extract() may cause file
	fragmentation on Windows XP
Message-ID: <E1Gdvdg-0002sd-Gv@sc8-sf-web1.sourceforge.net>

Bugs item #1586414, was opened at 2006-10-28 21:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Enoch Julias (enochjul)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.extract() may cause file fragmentation on Windows XP

Initial Comment:
When I use tarfile.extract() to extract all the files
from a large tar archive with lots of files tends to
cause file fragmentation in Windows. Apparently NTFS
cluster allocation interacts badly with such operations
if Windows is not aware of the size of each file.

The solution is to use a combination of the Win32 APIs
SetFilePointer() and SetEndOfFile() before writing to
the target file. This helps Windows choose a contiguous
free space for the file.

I tried it on the 2.6 trunk by calling file.truncate()
(which seems to implement the appropriate calls on
Windows) to set the file size before writing to a file.
It helps to avoid fragmentation for the extracted files
on my Windows XP x64 system.

Can this be added to tarfile to improve its performance
on Windows?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470

From noreply at sourceforge.net  Sat Oct 28 23:59:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 14:59:44 -0700
Subject: [ python-Bugs-1565514 ] does not raise SystemError on too many nested
	blocks
Message-ID: <E1GdwDQ-0006T9-Tc@sc8-sf-web1.sourceforge.net>

Bugs item #1565514, was opened at 2006-09-25 23:10
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: does not raise SystemError on too many nested blocks

Initial Comment:
Simple script attached, in python 2.4.3 I get 
reasonable results:

C:\>.\python24\python.exe nested.py
  File "nested.py", line 22
    while 22:
SystemError: too many statically nested blocks

C:\>

However in python 2.5 I get nothing:

C:\>.\python25\python.exe nested.py

C:\>


Shouldn't the same error be raised? (Note that it's 
not executing the file, or the prints would occur).

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-28 14:59

Message:
Logged In: YES 
user_id=33168

Committed revision 52510. (2.5)
Committed revision 52504. (2.6)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-26 21:45

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem.  I'm not so sure that
the error should be a SystemError, but some exception should
definitely be produced.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 00:05:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 15:05:41 -0700
Subject: [ python-Bugs-1548092 ] curses module segfaults on invalid tparm
	arguments
Message-ID: <E1GdwJB-0007GG-8Q@sc8-sf-web3.sourceforge.net>

Bugs item #1548092, was opened at 2006-08-28 10:47
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Marien Zwart (marienz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: curses module segfaults on invalid tparm arguments

Initial Comment:
At least on my platform the ncurses "tparm" function
returns NULL on certain invalid arguments.
PyCurses_tparm does not check the return value, it just
passes it to PyString_FromString. This means:

python -c "import curses;curses.setupterm();print
curses.tparm('', curses.COLOR_GREEN)"

gives me:

zsh: segmentation fault  python -c

(tested with python 2.4.3)

I am not sure what the best fix is. An exception would
make sense to me, but the (related) tigetstr function
returns None to python if the wrapped c function
returns NULL, and I have not used the curses module
enough to know what is more common.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-28 15:05

Message:
Logged In: YES 
user_id=33168

2.5.1 - r51723
this wasn't backported to 2.4.4.  there are not more 2.4.x
releases planned.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-01 19:51

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 51683. 2.6
Needs to be backported to 2.5.1 and earlier.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-01 19:25

Message:
Logged In: YES 
user_id=33168

reproduced with 2.5

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 00:45:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 15:45:56 -0700
Subject: [ python-Bugs-1566611 ] Idle 1.2 - Calltips Hotkey does not work
Message-ID: <E1Gdww8-000555-6X@sc8-sf-web6.sourceforge.net>

Bugs item #1566611, was opened at 2006-09-27 13:24
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: fladd (fladd710)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Idle 1.2 - Calltips Hotkey does not work

Initial Comment:
Hitting CTRL+Backslash does not show the calltip (which
is not shown by default) on Windows Xp with Python 1.5
Final.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 00:45:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 15:45:56 -0700
Subject: [ python-Bugs-1571112 ] simple moves freeze IDLE
Message-ID: <E1Gdww8-00054y-6a@sc8-sf-web6.sourceforge.net>

Bugs item #1571112, was opened at 2006-10-04 21:46
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Douglas W. Goodall (douglas_goodall)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: simple moves freeze IDLE

Initial Comment:
Using version 2.5 for Windows...

import os

then type "print os." and wait for the 
hint window. then scroll to the bottom (spawnv).

That's it. At this point IDLE is frozen.

I have done it a few times in a row. It seems
very reproduceable to me.

Be well. Doug

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 10:47

Message:
Logged In: YES 
user_id=580910

As an additional data point: this seems to work just fine on Mac OS X.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-10-07 20:16

Message:
Logged In: YES 
user_id=80475

I can reproduce this in Py2.5 final.  This may be a 
TkInter bug and not unique to IDLE or to Windows.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 09:58

Message:
Logged In: YES 
user_id=341410

I can reproduce this on 2.5 beta 2, and it dies exactly when
'spawnv' is highlighted.  I have no suggested fixes, only
reproducing to verify that this is not user-specific bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 00:48:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 15:48:48 -0700
Subject: [ python-Bugs-1542677 ] IDLE shell doesn\'t accept non ascii char
	input
Message-ID: <E1Gdwyu-0002nz-LG@sc8-sf-web1.sourceforge.net>

Bugs item #1542677, was opened at 2006-08-18 07:37
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542677&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
>Assigned to: Kurt B. Kaiser (kbk)
>Summary: IDLE shell doesn\'t accept non ascii char input

Initial Comment:
in bug 1528802 ( see
https://sourceforge.net/tracker/index.php?func=detail&aid=1528802&group_id=5470&atid=105470
) , I noticed that idle shell behaviour WRT
non-ascii chars was different than python console, and
possibly broken.

For example, IDLE produces:

>>> print u"?"
??
>>> print len(u"?")
2
>>> print "?"
?
>>> print len("?")
2

-------
a python shell (gnome-terminal):

>>> print u"?"
?
>>> print len(u"?")
1
>>> print "?"
?
>>> print len("?")
2

Both are using es_ES.utf-8 system encoding.

IDLE can manage unicode, it is just input that gives
problems:

>>> import unicodedata
>>> print unicodedata.lookup("LATIN SMALL LETTER A
WITH ACUTE")
?
>>> print len(unicodedata.lookup("LATIN SMALL
LETTER A WITH
ACUTE"))
1

Not that I like that much the violation of the least
surprising behaviour that python console offers with
non-ascii letters, but at least some internal
consistency would be great, until python 3000 gives us
true strings.

I'm using python 2.5 (svn trunk) --with-unicode=ucs4



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542677&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 00:49:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 15:49:37 -0700
Subject: [ python-Bugs-1562193 ] IDLE Hung up after open script by command
	line...
Message-ID: <E1Gdwzh-0007IO-7f@sc8-sf-web6.sourceforge.net>

Bugs item #1562193, was opened at 2006-09-20 06:10
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marek Nowicki (faramir2)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE Hung up after open script by command line...

Initial Comment:
Hello,

I wrote that code in python and saved as prx.py:
--- CUT ---
from BaseHTTPServer import HTTPServer, 
BaseHTTPRequestHandler
from time import strftime, gmtime
import urllib2
import thread
 from sys import stdout
class RequestHandler(BaseHTTPRequestHandler):
     def serve(self):
         print "%s %s %s\r\n%s" % (self.command, 
self.path,  
self.request_version, self.headers)
         header={}
         header["content-length"]=0
         for i in str(self.headers).split("\r\n"):
             j=i.split(":", 1)
             if len(j)==2:
                 header[j[0].strip().lower()] = 
j[1].strip()
         content=self.rfile.read(int(header["content-
length"]))
         print content
         url="http://faramir2.prv.pl"
         u=urllib2.urlopen(url)
         for i,j in u.info().items():
             print "%s: %s" % (i,j)
         self.server_version = "Apache"
         self.sys_version = ""
         self.send_response(200)
         self.send_header("Content-type", "text/html; 
charset=ISO-8859-2")
         self.send_header("Connectin", "close")
         self.end_headers()
     def do_POST(self): self.serve()
     def do_HEAD(self): self.serve()
     def do_GET(self): self.serve()
address = ("", 80)
server = HTTPServer(address, RequestHandler)
thread.start_new_thread(server.serve_forever, () )
--- CUT ---
 
When I right click on that file and select "Edit with 
IDLE" it opens. Then  
when I push F5 the script is running. *Python Shell* 
is restarting. But  
when I try to connect by browser to http://
localhost:80/ IDLE Hung-up. I  
don't see that hung ups when I open IDLE from shortcut 
and then in IDLE  
open file prx.py and run it works normally - good. 
IDLE does't hung up.
 
I don't know why it works like that, but I think that 
it's bug..
 
Python version: 2.5c2
Tk version: 8.4
IDLE version: 1.2c2
OS Version: Microsoft Windows XP Professional with SP2

---
Again:
* Freeze:
> 
"C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw"
 -n -e "prx.py"
// then F5 on IDLE
// when run open Browser and try to open page: http://
localhost:80
// IDLE freezes

* Works ok:
> 
"C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw"
 -e
// open prx.py in IDLE
// press F5 on IDLE
// run Browwser and try to open page: http://
localhost:80
// all works ok
---

regards,
Marek

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 00:58:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 15:58:11 -0700
Subject: [ python-Bugs-1543306 ] "from __future__ import foobar;
	" causes wrong SyntaxError
Message-ID: <E1Gdx7z-0007MK-NJ@sc8-sf-web4.sourceforge.net>

Bugs item #1543306, was opened at 2006-08-19 19:16
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Private: No
Submitted By: daniel hahler (blueyed)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: "from __future__ import foobar;" causes wrong SyntaxError

Initial Comment:
Instead of "SyntaxError: future feature foobar is not 
defined", you will get "SyntaxError: from __future__ 
imports must occur at the beginning of the file", if 
you use a semicolon at the end of the line (which is 
valid for existing future-imports of course).

Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> from __future__ import foobar;
  File "<stdin>", line 1
SyntaxError: from __future__ imports must occur at 
the beginning of the file
>>> from __future__ import generators;
>>>


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-28 15:58

Message:
Logged In: YES 
user_id=33168

As Georg noted, this is fixed in 2.5.  2.4 is no longer
supported.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-08-20 07:33

Message:
Logged In: YES 
user_id=849994

The 2.5+ AST compiler gives the correct error message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 00:58:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 15:58:33 -0700
Subject: [ python-Bugs-1586448 ] compiler module dont emit LIST_APPEND w/ list
	comprehension
Message-ID: <E1Gdx8L-0003Aq-Ra@sc8-sf-web5.sourceforge.net>

Bugs item #1586448, was opened at 2006-10-29 00:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586448&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: sebastien Martini (seb_martini)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module dont emit LIST_APPEND  w/ list comprehension

Initial Comment:
In the module compiler, list comprehensions are
implemented without emitting this bytecode.

For example:
>>> src = "[a for a in range(3)]"
>>> co = compiler.compile(src, 'lc1', 'exec')
>>> co

<code object <module> at 0x404927b8, file "lc1", line 1>
>>> dis.dis(co)

  1           0 BUILD_LIST               0
              3 DUP_TOP
              4 LOAD_ATTR                0 (append)
              7 STORE_NAME               1 ($append0)
             10 LOAD_NAME                2 (range)
             13 LOAD_CONST               1 (3)
             16 CALL_FUNCTION            1
             19 GET_ITER
        >>   20 FOR_ITER                16 (to 39)
             23 STORE_NAME               3 (a)
             26 LOAD_NAME                1 ($append0)
             29 LOAD_NAME                3 (a)
             32 CALL_FUNCTION            1
             35 POP_TOP
             36 JUMP_ABSOLUTE           20
        >>   39 DELETE_NAME              1 ($append0)
             42 POP_TOP
             43 LOAD_CONST               0 (None)
             46 RETURN_VALUE
>>> co2 = compile(src, 'lc2', 'exec')
>>> co2

<code object <module> at 0x40492770, file "lc2", line 1>
>>> dis.dis(co2)

  1           0 BUILD_LIST               0
              3 DUP_TOP
              4 STORE_NAME               0 (_[1])
              7 LOAD_NAME                1 (range)
             10 LOAD_CONST               0 (3)
             13 CALL_FUNCTION            1
             16 GET_ITER
        >>   17 FOR_ITER                13 (to 33)
             20 STORE_NAME               2 (a)
             23 LOAD_NAME                0 (_[1])
             26 LOAD_NAME                2 (a)
             29 LIST_APPEND
             30 JUMP_ABSOLUTE           17
        >>   33 DELETE_NAME              0 (_[1])
             36 POP_TOP
             37 LOAD_CONST               1 (None)
             40 RETURN_VALUE 

-- 
s?bastien martini

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586448&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 02:02:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 18:02:51 -0700
Subject: [ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the
	compile comman
Message-ID: <E1Gdz4d-0006hx-N0@sc8-sf-web5.sourceforge.net>

Bugs item #1491574, was opened at 2006-05-19 06:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-28 18:02

Message:
Logged In: YES 
user_id=33168

Based on last comment, I'm closing this report.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-30 01:39

Message:
Logged In: YES 
user_id=144552

Done.

AFAIAC you can close this issue or we wait for the outcome
of the discussion on python-dev

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-05-23 14:11

Message:
Logged In: YES 
user_id=21627

Yes, please move discussion to python-dev, although
discussion of the build process usually fails to attract
anybody.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-23 02:13

Message:
Logged In: YES 
user_id=144552

Looking through the code of distutils I finally found that
plenty of information is recoved from the _current_
environment in distutils/sysconfig.py.

Thus the LDFLAGS env.var. I had defined when configuring
python is not stored somewhere. So when e.g. installing
numarray, I need to set the LDFLAGS env.var. again.

Would'nt it be better if python would store the
flags/options that were used to compile python itself. This
guarantees that the extension modules will be
compiled/linked with the same flags and guarantees a maximal
compatibility?

If you prefer to move this discussion to the python-ml ....

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-05-22 15:27

Message:
Logged In: YES 
user_id=21627

Something like that, yes. It's quite involved, so it is not
easy to see what the right approach is.

If you can come up with a patch that works for you, I can
review the patch to find out what else it breaks.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-22 06:09

Message:
Logged In: YES 
user_id=144552

Indeed the -xcode=pic32 is not at fault here. The problem
though still is that distutils is not linking the shared
libraries using the link-option '-xarch=v9'. The linker
therefore complains about a mix of 32bit and 64bit code.

Should'nt distutils copy the content of LDFLAGS of when
python is being configured and add these options to the
link-line ?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-05-19 23:31

Message:
Logged In: YES 
user_id=21627

You must be misunderstanding something. -xcode=pic32 does
*not* mean that the code ought to be compiled for the 32-bit
processor mode. Instead, it means that the PIC (position
independent code) offsets are encoded using 32-bit numbers,
which works for both 32-bit and 64-bit code as long as the
size of the code does not exceed 4GiB.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 03:05:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 19:05:36 -0700
Subject: [ python-Bugs-1582742 ] Python is dumping core after the test
	test_ctypes
Message-ID: <E1Ge03M-0005A6-EQ@sc8-sf-web3.sourceforge.net>

Bugs item #1582742, was opened at 2006-10-23 02:42
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shashi (shashikala)
>Assigned to: Thomas Heller (theller)
Summary: Python is dumping core after the test test_ctypes

Initial Comment:


Hi ,

  Iam building Python-2.5 on HPUX Itanium. The 
compilation is done without any error, but while 
testing the same using gmake test it is dumping core 
telling "Segementation Fault" after the test 
test_ctypes. Please help me in resolving the above 
issue.Iam attaching the output of gmake test.

Thanks in advance,



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-28 19:05

Message:
Logged In: YES 
user_id=33168

This is the code that crashes:

from ctypes import *
print cast(c_void_p(0), POINTER(c_int))

***

#0  ffi_call_unix+0x20 ()
    at trunk/Modules/_ctypes/libffi/src/ia64/unix.S:63
#1  0x2000000079194d30:0 in ffi_call (cif=0x7fffe020,
fn=0x7913a860, 
    rvalue=0x7fffe090, avalue=0x7fffe070)
    at trunk/Modules/_ctypes/libffi/src/ia64/ffi.c:372
#2  0x20000000791762f0:0 in _call_function_pointer (flags=4101, 
    pProc=0x7913a860, avalues=0x7fffe070, atypes=0x7fffe050, 
    restype=0x40081de8, resmem=0x7fffe090, argcount=3)
    at trunk/Modules/_ctypes/callproc.c:665
#3  0x20000000791781d0:0 in _CallProc (pProc=0x7913a860,
argtuple=0x401cdd78, 
    flags=4101, argtypes=0x401ef7b8, restype=0x400eacd8,
checker=0x0)
    at trunk/Modules/_ctypes/callproc.c:1001
#4  0x2000000079165350:0 in CFuncPtr_call (self=0x4007abe8,
inargs=0x401cdd78, 
    kwds=0x0)
    at trunk/Modules/_ctypes/_ctypes.c:3364

***

Also note there are a bunch of errors like this:

Warning: could not import ctypes.test.test_cfuncs:
Unsatisfied code symbol '__divsf3' in load module
'trunk/build/lib.hp-ux-B.11.23-ia64-2.6/_ctypes_test.so'.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-10-25 01:41

Message:
Logged In: YES 
user_id=21627

You will need to run Python in a debugger and find out where
it crashes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 03:56:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Oct 2006 19:56:29 -0700
Subject: [ python-Bugs-1586513 ] codecs.open problem with "with" statement
Message-ID: <E1Ge0qb-0005wk-0N@sc8-sf-web4.sourceforge.net>

Bugs item #1586513, was opened at 2006-10-28 21:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shaun Cutts (shauncutts)
Assigned to: Nobody/Anonymous (nobody)
Summary: codecs.open problem with "with" statement

Initial Comment:
Codecs.open does not seem to properly support the
"with" protocol. Using codecs.open with "with" and
without "with" hill give different results in a simple
test.

-----------------------------------------
from __future__ import with_statement
import codecs

fn = 'test.txt'
f = open( fn, 'w' )
f.write( '\xc5' )
f.close()


f = codecs.open( fn, 'r', 'L1' )
print repr( f.read() )
f.close()

with codecs.open( fn, 'r', 'L1' ) as f:
    print repr( f.read() )
---------------------------------------
output:
---------------------------------------
u'\xc5'
'\xc5'
---------------------------------------
Note: 2nd string not unicode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586513&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 08:10:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 00:10:03 -0700
Subject: [ python-Bugs-1586513 ] codecs.open problem with "with" statement
Message-ID: <E1Ge4nz-0008Tw-1m@sc8-sf-web5.sourceforge.net>

Bugs item #1586513, was opened at 2006-10-28 21:56
Message generated for change (Settings changed) made by shauncutts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shaun Cutts (shauncutts)
Assigned to: Nobody/Anonymous (nobody)
Summary: codecs.open problem with "with" statement

Initial Comment:
Codecs.open does not seem to properly support the
"with" protocol. Using codecs.open with "with" and
without "with" hill give different results in a simple
test.

-----------------------------------------
from __future__ import with_statement
import codecs

fn = 'test.txt'
f = open( fn, 'w' )
f.write( '\xc5' )
f.close()


f = codecs.open( fn, 'r', 'L1' )
print repr( f.read() )
f.close()

with codecs.open( fn, 'r', 'L1' ) as f:
    print repr( f.read() )
---------------------------------------
output:
---------------------------------------
u'\xc5'
'\xc5'
---------------------------------------
Note: 2nd string not unicode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586513&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 09:39:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 01:39:50 -0700
Subject: [ python-Bugs-1586513 ] codecs.open problem with "with" statement
Message-ID: <E1Ge6Cs-0000pK-I7@sc8-sf-web1.sourceforge.net>

Bugs item #1586513, was opened at 2006-10-29 02:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Shaun Cutts (shauncutts)
>Assigned to: Georg Brandl (gbrandl)
Summary: codecs.open problem with "with" statement

Initial Comment:
Codecs.open does not seem to properly support the
"with" protocol. Using codecs.open with "with" and
without "with" hill give different results in a simple
test.

-----------------------------------------
from __future__ import with_statement
import codecs

fn = 'test.txt'
f = open( fn, 'w' )
f.write( '\xc5' )
f.close()


f = codecs.open( fn, 'r', 'L1' )
print repr( f.read() )
f.close()

with codecs.open( fn, 'r', 'L1' ) as f:
    print repr( f.read() )
---------------------------------------
output:
---------------------------------------
u'\xc5'
'\xc5'
---------------------------------------
Note: 2nd string not unicode.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-29 08:39

Message:
Logged In: YES 
user_id=849994

Thanks for the report, this is now fixed in rev. 52517,
52518 (2.5).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586513&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 09:54:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 01:54:14 -0700
Subject: [ python-Bugs-1586448 ] compiler module dont emit LIST_APPEND w/ list
	comprehension
Message-ID: <E1Ge6Qo-00084B-GG@sc8-sf-web4.sourceforge.net>

Bugs item #1586448, was opened at 2006-10-28 22:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586448&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: sebastien Martini (seb_martini)
>Assigned to: Georg Brandl (gbrandl)
Summary: compiler module dont emit LIST_APPEND  w/ list comprehension

Initial Comment:
In the module compiler, list comprehensions are
implemented without emitting this bytecode.

For example:
>>> src = "[a for a in range(3)]"
>>> co = compiler.compile(src, 'lc1', 'exec')
>>> co

<code object <module> at 0x404927b8, file "lc1", line 1>
>>> dis.dis(co)

  1           0 BUILD_LIST               0
              3 DUP_TOP
              4 LOAD_ATTR                0 (append)
              7 STORE_NAME               1 ($append0)
             10 LOAD_NAME                2 (range)
             13 LOAD_CONST               1 (3)
             16 CALL_FUNCTION            1
             19 GET_ITER
        >>   20 FOR_ITER                16 (to 39)
             23 STORE_NAME               3 (a)
             26 LOAD_NAME                1 ($append0)
             29 LOAD_NAME                3 (a)
             32 CALL_FUNCTION            1
             35 POP_TOP
             36 JUMP_ABSOLUTE           20
        >>   39 DELETE_NAME              1 ($append0)
             42 POP_TOP
             43 LOAD_CONST               0 (None)
             46 RETURN_VALUE
>>> co2 = compile(src, 'lc2', 'exec')
>>> co2

<code object <module> at 0x40492770, file "lc2", line 1>
>>> dis.dis(co2)

  1           0 BUILD_LIST               0
              3 DUP_TOP
              4 STORE_NAME               0 (_[1])
              7 LOAD_NAME                1 (range)
             10 LOAD_CONST               0 (3)
             13 CALL_FUNCTION            1
             16 GET_ITER
        >>   17 FOR_ITER                13 (to 33)
             20 STORE_NAME               2 (a)
             23 LOAD_NAME                0 (_[1])
             26 LOAD_NAME                2 (a)
             29 LIST_APPEND
             30 JUMP_ABSOLUTE           17
        >>   33 DELETE_NAME              0 (_[1])
             36 POP_TOP
             37 LOAD_CONST               1 (None)
             40 RETURN_VALUE 

-- 
s?bastien martini

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-29 08:54

Message:
Logged In: YES 
user_id=849994

I "fixed" this in rev. 52520, now the compiler module
generates the same bytecode for listcomps as the builtin
compiler.

Not backporting this, as it isn't really a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586448&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 09:55:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 01:55:08 -0700
Subject: [ python-Bugs-1586414 ] tarfile.extract() may cause file
	fragmentation on Windows XP
Message-ID: <E1Ge6Rg-000898-PA@sc8-sf-web4.sourceforge.net>

Bugs item #1586414, was opened at 2006-10-28 21:22
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Enoch Julias (enochjul)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.extract() may cause file fragmentation on Windows XP

Initial Comment:
When I use tarfile.extract() to extract all the files
from a large tar archive with lots of files tends to
cause file fragmentation in Windows. Apparently NTFS
cluster allocation interacts badly with such operations
if Windows is not aware of the size of each file.

The solution is to use a combination of the Win32 APIs
SetFilePointer() and SetEndOfFile() before writing to
the target file. This helps Windows choose a contiguous
free space for the file.

I tried it on the 2.6 trunk by calling file.truncate()
(which seems to implement the appropriate calls on
Windows) to set the file size before writing to a file.
It helps to avoid fragmentation for the extracted files
on my Windows XP x64 system.

Can this be added to tarfile to improve its performance
on Windows?

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-29 08:55

Message:
Logged In: YES 
user_id=849994

Can you try to come up with a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 10:05:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 01:05:19 -0800
Subject: [ python-Bugs-1357915 ] suprocess cannot handle shell arguments
Message-ID: <E1Ge6bX-0000hq-Pz@sc8-sf-web4.sourceforge.net>

Bugs item #1357915, was opened at 2005-11-16 08:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357915&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Pierre Ossman (dr7eus)
>Assigned to: Georg Brandl (gbrandl)
Summary: suprocess cannot handle shell arguments

Initial Comment:
If you try and include arguments to the shell in
subprocess you get a traceback:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/subprocess.py", line 558, in
__init__
    errread, errwrite)
  File "/usr/lib/python2.4/subprocess.py", line 907, in
_execute_child
    args = ["/bin/sh", "-c"] + args
TypeError: can only concatenate list (not "tuple") to list

A simple list() should solve the issue.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-29 09:05

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 52522, 52523 (2.5).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357915&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 12:14:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 03:14:01 -0800
Subject: [ python-Bugs-1586613 ] zlib/bz2_codec doesn't support incremental
	decoding
Message-ID: <E1Ge8c5-0007Ww-HA@sc8-sf-web3.sourceforge.net>

Bugs item #1586613, was opened at 2006-10-29 20:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586613&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Topia (topia)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib/bz2_codec doesn't support incremental decoding

Initial Comment:
http://svn.python.org/view/python/trunk/Lib/encodings/zlib_codec.py?rev=43045&view=auto

Incremental encoding/decoding must be stateful.
Please use compressobj/decompressobj object.

Incremental(Encoder|Decoder)/Stream(Reader|Writer)
don't work with current code at all.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586613&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 15:40:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 06:40:37 -0800
Subject: [ python-Bugs-1586613 ] zlib/bz2_codec doesn't support incremental
	decoding
Message-ID: <E1GeBq1-0008FM-Jt@sc8-sf-web4.sourceforge.net>

Bugs item #1586613, was opened at 2006-10-29 11:14
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586613&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Topia (topia)
>Assigned to: Georg Brandl (gbrandl)
Summary: zlib/bz2_codec doesn't support incremental decoding

Initial Comment:
http://svn.python.org/view/python/trunk/Lib/encodings/zlib_codec.py?rev=43045&view=auto

Incremental encoding/decoding must be stateful.
Please use compressobj/decompressobj object.

Incremental(Encoder|Decoder)/Stream(Reader|Writer)
don't work with current code at all.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-29 14:40

Message:
Logged In: YES 
user_id=849994

Fixed the incremental coders/decoders in rev. 52529, 52530
(2.5).

The StreamReaders/Writers can't be fixed as easily, because
their encode/decode methods don't have a "final" flag, so
they wouldn't know when to flush the compress object.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586613&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 15:47:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 06:47:51 -0800
Subject: [ python-Bugs-1581357 ] missing __enter__ + __getattr__ forwarding
Message-ID: <E1GeBx1-0000V0-Ol@sc8-sf-web4.sourceforge.net>

Bugs item #1581357, was opened at 2006-10-20 15:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581357&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
>Assigned to: Georg Brandl (gbrandl)
Summary: missing __enter__ + __getattr__ forwarding

Initial Comment:
Hello. I encountered some unexpected behavior on "with"
statement.

First, please run attached "a.py" file.

# traditional way
<open file 'a.txt', mode 'wb' at 0x009373C8> shift_jis
<type 'instance'> True
# with statement
<open file 'a.txt', mode 'wb' at 0x009373C8> None <type
'file'> False
Traceback (most recent call last):
  File "R:\a.py", line 15, in <module>
    test(io)
  File "R:\a.py", line 8, in test
    io.write(u"?????")
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 0-4: ordin
al not in range(128)

"traditional way" runs as expected, but "with
statement" crashes. This happens because....

  1. codecs.open returns codecs.StreamReaderWriter
  2. codecs.StreamReaderWriter defines __getattr__
     like this.

    def __getattr__(self, name,
                    getattr=getattr):

        """ Inherit all other methods from the
            underlying stream.
        """
        return getattr(self.stream, name)

  3. But codecs.StreamReaderWriter doesn't have its
     __enter__ definition, so 

    srw = StreamReaderWriter(stream, ...
    srw.__enter__() # actually calls stream.__enter__
                      which returns stream not srw
                      via __getattr__

     And more worse, with statement doesn't complain
     StreamReaderWriter (currently) doesn't support
     context manager.

Is this intended behavior? If not, only this problem
can be solved by attached "a.patch". I greped library
files, I found many __getattr__ without __enter__...



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-29 14:47

Message:
Logged In: YES 
user_id=849994

This is a duplicate of #1586513 which has been fixed today.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581357&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 18:45:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 09:45:45 -0800
Subject: [ python-Bugs-1586773 ] hashlib documentation is insuficient
Message-ID: <E1GeEjB-0002fY-Ju@sc8-sf-web1.sourceforge.net>

Bugs item #1586773, was opened at 2006-10-29 17:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586773&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marcos Daniel Marado Torres (mindbooster)
Assigned to: Nobody/Anonymous (nobody)
Summary: hashlib documentation is insuficient

Initial Comment:
Greetings,

While the documentation of hashlib present on
http://docs.python.org/lib/module-hashlib.html is
preety good, doing help(hashlib) on python gives a
really mediocre documentation. The suggestion is to
write new documentation for hashlib based on the one
already there on the web.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586773&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 19:01:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 10:01:42 -0800
Subject: [ python-Bugs-1586773 ] hashlib documentation is insuficient
Message-ID: <E1GeEyc-0002zu-W3@sc8-sf-web4.sourceforge.net>

Bugs item #1586773, was opened at 2006-10-29 17:45
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586773&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Marcos Daniel Marado Torres (mindbooster)
>Assigned to: Georg Brandl (gbrandl)
Summary: hashlib documentation is insuficient

Initial Comment:
Greetings,

While the documentation of hashlib present on
http://docs.python.org/lib/module-hashlib.html is
preety good, doing help(hashlib) on python gives a
really mediocre documentation. The suggestion is to
write new documentation for hashlib based on the one
already there on the web.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-29 18:01

Message:
Logged In: YES 
user_id=849994

I added some of the online doc to the docstring. It should
now be clearer. (rev. 52532, 52533 (2.5))

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586773&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 19:53:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 10:53:39 -0800
Subject: [ python-Bugs-1570255 ] redirected cookies
Message-ID: <E1GeFmt-0000pp-Ha@sc8-sf-web1.sourceforge.net>

Bugs item #1570255, was opened at 2006-10-04 09:37
Message generated for change (Comment added) made by hans_moleman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: hans_moleman (hans_moleman)
Assigned to: Nobody/Anonymous (nobody)
Summary: redirected cookies

Initial Comment:
Cookies are not resend when a redirect is requested.

Blurb:
I've been trying to get a response off a server using
Python.
The response so far differs from the response using
Firefox.
In Python, I have set headers and cookies the way
Firefox does it.

I noticed that the server accepts the POST request, and
redirects the client to another address with the result
on it. This happens both with Python and Firefox correctly.

Cookie handling differs though:
The Python client, when redirected, using the standard
redirect handler, does not resend its cookies to the
redirected address.
Firefox does resend the cookies from the original request.

When I redefine the redirect handler and code it so
that it adds the cookies from the original request,
the response is the same as Firefox's response. This
confirms then that resending cookies is required to get
the server to respond correctly.

Is the default Python redirection cookie policy
different from Firefox's policy?
Could we improve the default redirection handler to
work like Firefox?
Is it a bug?

I noticed an old open bug report 511786, that looks
very much like this problem. It suggests it is fixed.

Cheers Hans Moleman. 


----------------------------------------------------------------------

>Comment By: hans_moleman (hans_moleman)
Date: 2006-10-30 07:53

Message:
Logged In: YES 
user_id=1610873

OK. I'll have a look at that. 
Thanks for the pointers.
 

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-28 01:16

Message:
Logged In: YES 
user_id=11375

Given the sensitive data in your script, it's certainly best
to not post it.  You'll have to dig into urllib2 yourself, I
think.

Start by looking at the code in redirect_request(), around
line 520 of urllib2.py, and adding some debug prints.  Print
out the contents of req.headers; is the cookie line in
there?  Change the __init__ of AbstractHTTPHandler to
default debuglevel to 1, not 0; this will print out all the
HTTP lines being sent and received.


----------------------------------------------------------------------

Comment By: hans_moleman (hans_moleman)
Date: 2006-10-27 17:20

Message:
Logged In: YES 
user_id=1610873

I am using this script to obtain monthly internet usage
statistics from my ISP.
My ISP provides a screen via HTTPS, to enter a usercode and
password, after which the usage statistics are displayed on
a different address. 
I cannot send this script with my usercode and password. My
ISP might not like me doing this either.

Therefore I'll try to find another server that behaves
similarly, and send you that.



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 09:16

Message:
Logged In: YES 
user_id=11375

More detail is needed to figure out if there's a problem;
can you give a sample URL to exhibit the problem?  can you
provide your code?  From the description, it's unclear if
this might be a bug in the handling of redirects or in the
CookieProcessor class.

The bug in 511786 is still fixed; that bug includes sample
code, so I could check it.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470

From noreply at sourceforge.net  Sun Oct 29 23:58:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Oct 2006 14:58:24 -0800
Subject: [ python-Bugs-1580472 ] glob.glob("c:\\[ ]\*) doesn't work
Message-ID: <E1GeJbk-0008IV-0a@sc8-sf-web6.sourceforge.net>

Bugs item #1580472, was opened at 2006-10-19 13:44
Message generated for change (Comment added) made by koblaid
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Koblaid (koblaid)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob.glob("c:\\[ ]\*) doesn't work

Initial Comment:
OS: Windows 2000 Service Pack 4
Python 2.5

glob.glob() doesn't work in directories named 
"[ ]" (with a blank in it). Another example is a 
directory named "A - [Aa-Am]"

Example:
#########################
C:\>md []
C:\>md "[ ]"
C:\>copy anyfile.txt []
        1 Datei(en) kopiert.
C:\>copy anyfile.txt "[ ]"
        1 Datei(en) kopiert.

C:\>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC 
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import glob
>>> glob.glob ("c:\\[]\*")
['c:\\[]\\anyfile.txt']
>>> glob.glob ("c:\\[ ]\*")
[]
#########################

The second glob should have resulted the same as the 
first glob since I copied the same file to both 
directories.
I may be wrong because I'm new to python. But I've 
tested it a couple of times, and I think it have to be 
a bug of python or a bug of windows.

Greets, Koblaid

----------------------------------------------------------------------

>Comment By: Koblaid (koblaid)
Date: 2006-10-29 23:58

Message:
Logged In: YES 
user_id=1624709

Thanks for your answers. Although I'm pretty new at Python, but I disagree with you.

I see, it's not a bug. And folders like "[ ]" aren't very common.
But if you scan your filesystem recursively using glob, you will lose all folders named like 
"[ ]":
>>def scanDir(path):
>>  elements = glob.glob(directoryPath + "\\*")
>>  for currentElement in elements:
>>	if os.path.isfile(currentElement):
>>      print currentElement
>>    else:
>>      scanDir(currentElement)

Even if these folders are very rare, the damage could be great. You lose files without 
recognizing it.
A programmer assums that a language works correctly in all cases. So I think this should be 
changed.

One easy solution is to add a second optional boolean parameter for glob, which have to be 
true, if you want to use regular expressions.
But this and other similar solutions fail, if you try to use glob recursively, as the example 
above shows.
A solution that would work with my example could be that glob returns the paths and puts every 
"[" and "]" (and other affected charecters) in brackets, as potten recommended. On the other 
hand, the result is unhandily if you don't want to use it for glob again.
So I don't no a nice solution. Maybe you have better ideas...

Thanks, Koblaid

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-27 16:01

Message:
Logged In: YES 
user_id=849994

Not a bug, as Peter said.

----------------------------------------------------------------------

Comment By: Peter Otten (potten)
Date: 2006-10-27 14:32

Message:
Logged In: YES 
user_id=703365

Not a bug. "[abc]" matches exactly one character which may be "a", "b" or "c". 
Therefore "[ ]" matches one space character. If you want a literal "[", put it in brackets, 
e. g. glob.glob("C:\\[[] ]\\*").  
 
--- 
 
By the way, do you think this problem is common enough to warrant the addition of a 
fnmatch.escape() function? I have something like this in mind: 
 
>>> import re 
>>> r = re.compile("(%s)" % "|".join(re.escape(c) for c in "*?[")) 
>>> def escape(s): 
...     return r.sub(r"[\1]", s) 
... 
>>> escape("c:\\[a-z]\\*") 
'c:\\[[]a-z]\\[*]' 
 

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-27 08:14

Message:
Logged In: YES 
user_id=341410

This is a known issue with the fnmatch module (what glob
uses under the covers).  According to the documentation of
the translate method that converts patterns into regular
expressions... "There is no way to quote meta-characters." 
The fact that "[]" works but "[ ]" doesn't work is a
convenient bug, for those who want to use "[]".

If you can come up with some similar but non-ambiguous
syntax to update the fnmatch module, I'm sure it would be
considered, but as-is, I can't see this as a "bug" per-se.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470

From noreply at sourceforge.net  Mon Oct 30 17:15:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Oct 2006 08:15:57 -0800
Subject: [ python-Bugs-1583276 ] Different behavior when stepping through code
	w/ pdb
Message-ID: <E1GeZnp-0007fc-LU@sc8-sf-web6.sourceforge.net>

Bugs item #1583276, was opened at 2006-10-24 00:54
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different behavior when stepping through code w/ pdb

Initial Comment:
The attached test case will raise a NameError when
executed in pdb by stepping though the code.  The issue
is the EnumType name, which is both a local variable in
the Enum function which is used in the lambda and the
name of an attribute on the EnumValue class.  Since it
is a local variable used in a lambda, it's a freevar. 
What apparently happens is on line 5 the property()
result is stored in frame->f_locals['EnumType'] but it
is deleted the next time FastToLocals is invoked prior
to calling back into the debugger.  This happens when
the freevars values are merged into the locals dictionary.

The example is a stripped down version of code in
turbogears.

----------------------------------------------------------------------

>Comment By: John Ehresman (jpe)
Date: 2006-10-30 16:15

Message:
Logged In: YES 
user_id=22785

I'm a bit confused -- http://python.org/sf/1583276 seems to
resolve to this bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-27 06:23

Message:
Logged In: YES 
user_id=341410

This seems to be a duplicate of http://python.org/sf/1583276 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

From noreply at sourceforge.net  Mon Oct 30 17:41:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Oct 2006 08:41:11 -0800
Subject: [ python-Bugs-1583276 ] Different behavior when stepping through code
	w/ pdb
Message-ID: <E1GeaCF-00045w-8h@sc8-sf-web2.sourceforge.net>

Bugs item #1583276, was opened at 2006-10-23 17:54
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different behavior when stepping through code w/ pdb

Initial Comment:
The attached test case will raise a NameError when
executed in pdb by stepping though the code.  The issue
is the EnumType name, which is both a local variable in
the Enum function which is used in the lambda and the
name of an attribute on the EnumValue class.  Since it
is a local variable used in a lambda, it's a freevar. 
What apparently happens is on line 5 the property()
result is stored in frame->f_locals['EnumType'] but it
is deleted the next time FastToLocals is invoked prior
to calling back into the debugger.  This happens when
the freevars values are merged into the locals dictionary.

The example is a stripped down version of code in
turbogears.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-30 08:41

Message:
Logged In: YES 
user_id=341410

Sorry!  What I meant to say is that this seems to be a
duplicate of http://python.org/sf/1569356 .

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2006-10-30 08:15

Message:
Logged In: YES 
user_id=22785

I'm a bit confused -- http://python.org/sf/1583276 seems to
resolve to this bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-26 23:23

Message:
Logged In: YES 
user_id=341410

This seems to be a duplicate of http://python.org/sf/1583276 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

From noreply at sourceforge.net  Mon Oct 30 17:47:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Oct 2006 08:47:59 -0800
Subject: [ python-Bugs-1583276 ] Different behavior when stepping through code
	w/ pdb
Message-ID: <E1GeaIp-00023Z-FF@sc8-sf-web1.sourceforge.net>

Bugs item #1583276, was opened at 2006-10-24 00:54
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different behavior when stepping through code w/ pdb

Initial Comment:
The attached test case will raise a NameError when
executed in pdb by stepping though the code.  The issue
is the EnumType name, which is both a local variable in
the Enum function which is used in the lambda and the
name of an attribute on the EnumValue class.  Since it
is a local variable used in a lambda, it's a freevar. 
What apparently happens is on line 5 the property()
result is stored in frame->f_locals['EnumType'] but it
is deleted the next time FastToLocals is invoked prior
to calling back into the debugger.  This happens when
the freevars values are merged into the locals dictionary.

The example is a stripped down version of code in
turbogears.

----------------------------------------------------------------------

>Comment By: John Ehresman (jpe)
Date: 2006-10-30 16:47

Message:
Logged In: YES 
user_id=22785

It looks like a dup to me.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-30 16:41

Message:
Logged In: YES 
user_id=341410

Sorry!  What I meant to say is that this seems to be a
duplicate of http://python.org/sf/1569356 .

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2006-10-30 16:15

Message:
Logged In: YES 
user_id=22785

I'm a bit confused -- http://python.org/sf/1583276 seems to
resolve to this bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-27 06:23

Message:
Logged In: YES 
user_id=341410

This seems to be a duplicate of http://python.org/sf/1583276 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470

From noreply at sourceforge.net  Mon Oct 30 17:53:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Oct 2006 08:53:29 -0800
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1GeaO9-0002yA-GH@sc8-sf-web6.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: applebucks (scott_marks)
Assigned to: Martin v. L?wis (loewis)
Summary: sys.settrace cause curried parms to show up as attributes

Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not. 
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail. 
Reported v 2.4, but the same behavior on 2.5.  Any ideas?

""" Demonstrace that tracing messes up curried class
definitions """

# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys

def usage( ):
    print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
    sys.exit( 1 )

if 1 == len( sys.argv ):
    pass
elif 2 == len( sys.argv ):
    if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
        def trace ( frame, event, arg ):
            # print frame, event, arg
            return trace
        sys.settrace( trace )
    else:
        usage( )
else:
    usage( )



# The test: define a class factory with a curried
member function

def the_factory( parm1 ):
    class the_class( object ):
        def curried( self ): return parm1
    return the_class

x = the_factory( 42 )

y = x( )

try:
    x.parm1
    print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
    print "Success with the manufactured class!"

try:
    y.parm1
    print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
    print "Success with the instance!"

assert y.curried( ) == 42, "Currying didn't work?!" 

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2006-10-30 16:53

Message:
Logged In: YES 
user_id=22785

This could & probably should be fixed, at the cost of making
the core debugger support more complicated.  The current
version of TurboGears has code that triggers the same bug. 
That said, I don't have a patch to fix the core...

----------------------------------------------------------------------

Comment By: applebucks (scott_marks)
Date: 2006-10-08 23:54

Message:
Logged In: YES 
user_id=120857

I didn't say Python is lame.  I use Python heavily,
apparently an uncommonly large subset of Python
functionality at that, and largely love it.  That's why the
failure of semantic transparency caused by something
apparently irrelevant (tracing, as opposed to some kind of
deliberate stack frame munging) is disturbing.  

Not to mention it makes my debugging tough. :)

More seriously, one of the users of the subsystem in which
this bug shows us just (on Friday) lost a few hours chasing
a real bug that should have been obvious but which was
masked by this error as manifest by a bdb-based debugger.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 16:54

Message:
Logged In: YES 
user_id=341410

I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:

..."just makes Python seem ... lame."

is insulting to those who have helped to develop Python over
the years.  In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).

----------------------------------------------------------------------

Comment By: applebucks (scott_marks)
Date: 2006-10-04 02:32

Message:
Logged In: YES 
user_id=120857

"Cannot be fixed" sounds pretty final, and also a little
pessimistic.  From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does.  In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.

Not to mention that the workaround ("be sure to rename your
class factory function parameters so that they don't collide
with intended attributes of the created class") just makes
Python seem ... lame.

I hope for a more optimistic reply.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 06:49

Message:
Logged In: YES 
user_id=849994

I'm afraid that this cannot be fixed.

In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.

If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.

Martin, do you you have an additional opinion?

----------------------------------------------------------------------

Comment By: applebucks (scott_marks)
Date: 2006-10-02 16:02

Message:
Logged In: YES 
user_id=120857

This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation.  The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470

From noreply at sourceforge.net  Tue Oct 31 06:07:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Oct 2006 21:07:45 -0800
Subject: [ python-Bugs-1586414 ] tarfile.extract() may cause file
	fragmentation on Windows XP
Message-ID: <E1Gelqj-000498-Oa@sc8-sf-web4.sourceforge.net>

Bugs item #1586414, was opened at 2006-10-28 21:22
Message generated for change (Comment added) made by enochjul
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Enoch Julias (enochjul)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.extract() may cause file fragmentation on Windows XP

Initial Comment:
When I use tarfile.extract() to extract all the files
from a large tar archive with lots of files tends to
cause file fragmentation in Windows. Apparently NTFS
cluster allocation interacts badly with such operations
if Windows is not aware of the size of each file.

The solution is to use a combination of the Win32 APIs
SetFilePointer() and SetEndOfFile() before writing to
the target file. This helps Windows choose a contiguous
free space for the file.

I tried it on the 2.6 trunk by calling file.truncate()
(which seems to implement the appropriate calls on
Windows) to set the file size before writing to a file.
It helps to avoid fragmentation for the extracted files
on my Windows XP x64 system.

Can this be added to tarfile to improve its performance
on Windows?

----------------------------------------------------------------------

>Comment By: Enoch Julias (enochjul)
Date: 2006-10-31 05:07

Message:
Logged In: YES 
user_id=6071

I submitted patch #1587674 for this, though I am not sure if
it is a good idea to use truncate() for such a purpose.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-29 08:55

Message:
Logged In: YES 
user_id=849994

Can you try to come up with a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470

From noreply at sourceforge.net  Tue Oct 31 06:46:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Oct 2006 21:46:17 -0800
Subject: [ python-Bugs-1587679 ] scipy gammaincinv gives incorrect answers
Message-ID: <E1GemS1-0001qe-PG@sc8-sf-web5.sourceforge.net>

Bugs item #1587679, was opened at 2006-10-31 05:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1587679&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David J.C. MacKay (djcmackay)
Assigned to: Nobody/Anonymous (nobody)
Summary: scipy gammaincinv gives incorrect answers

Initial Comment:
For extreme values, gamaincinv gives the answer '0.0'
when it should not do so.
Examples:

>>> import scipy.special as S
>>> S.gammainc( 50 , 12.00 )
2.3998794536786009e-16
>>> S.gammaincinv( 50 , 2.39e-16 )
11.996909478523992
>>> S.gammainc( 50 , 11.00 )
8.2075477738848345e-18
>>> S.gammaincinv( 50 , 8e-18 )
0.0


Python 2.4.3 (#2, Oct  6 2006, 07:52:30) 
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

David
mackay at mrao.cam.ac.uk


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1587679&group_id=5470

From noreply at sourceforge.net  Tue Oct 31 19:28:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 31 Oct 2006 10:28:38 -0800
Subject: [ python-Bugs-1587679 ] scipy gammaincinv gives incorrect answers
Message-ID: <E1GeyLm-0007mk-05@sc8-sf-web6.sourceforge.net>

Bugs item #1587679, was opened at 2006-10-31 06:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1587679&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: David J.C. MacKay (djcmackay)
Assigned to: Nobody/Anonymous (nobody)
Summary: scipy gammaincinv gives incorrect answers

Initial Comment:
For extreme values, gamaincinv gives the answer '0.0'
when it should not do so.
Examples:

>>> import scipy.special as S
>>> S.gammainc( 50 , 12.00 )
2.3998794536786009e-16
>>> S.gammaincinv( 50 , 2.39e-16 )
11.996909478523992
>>> S.gammainc( 50 , 11.00 )
8.2075477738848345e-18
>>> S.gammaincinv( 50 , 8e-18 )
0.0


Python 2.4.3 (#2, Oct  6 2006, 07:52:30) 
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

David
mackay at mrao.cam.ac.uk


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2006-10-31 19:28

Message:
Logged In: YES 
user_id=21627

Can you please report this to the SciPy Trac, at

http://projects.scipy.org/scipy/scipy

This tracker is for the "core" Python distribution only.
Closing as third-party.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1587679&group_id=5470

From noreply at sourceforge.net  Tue Oct 31 22:06:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 31 Oct 2006 13:06:59 -0800
Subject: [ python-Bugs-1588217 ] quoted printable parse the sequence '= '
	incorrectly
Message-ID: <E1Gf0p1-0001NY-0F@sc8-sf-web3.sourceforge.net>

Bugs item #1588217, was opened at 2006-10-31 13:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588217&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: quoted printable parse the sequence '= ' incorrectly

Initial Comment:
>>> import quopri

>>> s = 'I say= a secret message\r\nThank you'

>>> quopri.a2b_qp
<built-in function a2b_qp>
>>> quopri.decodestring(s)  # use the c version 
binascii.a2b_qp() to decode
'I sayThank you'

>>> quopri.a2b_qp=None
>>> quopri.decodestring(s)  # use the python version 
quopri.decode() to decode
'I say= a secret message\nThank you'


Note that the sequence '= ' is invalid according to 
RFC 2045 section 6.7:

-------------------------------------------------------
An "=" followed by a character that is neither a 
hexadecimal digit (including "abcdef") nor the CR 
character of a CRLF pair is illegal ... A reasonable 
approach by a robust implementation might be to 
include the "=" character and the following character 
in the decoded data without any transformation
-------------------------------------------------------

The lenient interpretation is used by the Python 
version parser quopri.decode() to produce the second 
string. Most email clients use a similar lenient 
interpretation.

The C version parser binascii.a2b_qp(), which is used 
in preference to the Python verison, produce a 
surprising result with the string 'a secret message' 
omitted.

This may create an opportunity for spammers to insert 
secret message after '= ' so that it is not visible to 
Python based spam filter but woiuld display in non-
Python based email client.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588217&group_id=5470

From noreply at sourceforge.net  Tue Oct 31 22:18:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 31 Oct 2006 13:18:05 -0800
Subject: [ python-Bugs-1588217 ] quoted printable parse the sequence '= '
	incorrectly
Message-ID: <E1Gf0zl-00067n-1j@sc8-sf-web1.sourceforge.net>

Bugs item #1588217, was opened at 2006-10-31 13:06
Message generated for change (Comment added) made by tungwaiyip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588217&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: quoted printable parse the sequence '= ' incorrectly

Initial Comment:
>>> import quopri

>>> s = 'I say= a secret message\r\nThank you'

>>> quopri.a2b_qp
<built-in function a2b_qp>
>>> quopri.decodestring(s)  # use the c version 
binascii.a2b_qp() to decode
'I sayThank you'

>>> quopri.a2b_qp=None
>>> quopri.decodestring(s)  # use the python version 
quopri.decode() to decode
'I say= a secret message\nThank you'


Note that the sequence '= ' is invalid according to 
RFC 2045 section 6.7:

-------------------------------------------------------
An "=" followed by a character that is neither a 
hexadecimal digit (including "abcdef") nor the CR 
character of a CRLF pair is illegal ... A reasonable 
approach by a robust implementation might be to 
include the "=" character and the following character 
in the decoded data without any transformation
-------------------------------------------------------

The lenient interpretation is used by the Python 
version parser quopri.decode() to produce the second 
string. Most email clients use a similar lenient 
interpretation.

The C version parser binascii.a2b_qp(), which is used 
in preference to the Python verison, produce a 
surprising result with the string 'a secret message' 
omitted.

This may create an opportunity for spammers to insert 
secret message after '= ' so that it is not visible to 
Python based spam filter but woiuld display in non-
Python based email client.


----------------------------------------------------------------------

>Comment By: Wai Yip Tung (tungwaiyip)
Date: 2006-10-31 13:18

Message:
Logged In: YES 
user_id=561546

The problem may come from binascii_a2b_qp() in binascii.c. It 
considers the '= ' or '=\t' sequence as a soft line break. Such 
interpretation appears to have no basis. It could be an 
misinterpretation of RFC 2045:

-------------------------------------------------------------------
In particular, an "=" at the end of an encoded line, indicating a 
soft line break (see rule #5) may follow one or more TAB (HT) or 
SPACE characters.
-------------------------------------------------------------------

This passage reminds readers they might find TAB or SPACE before 
an "=", but not after it. "= " is plain illegal as far as I know.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588217&group_id=5470

From jeremy at alum.mit.edu  Wed Oct  4 17:33:37 2006
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 04 Oct 2006 15:33:37 -0000
Subject: sys.settrace closure interaction bug
In-Reply-To: <e3f9e0dd0610010932l30594867pd8d6b862759986d@mail.gmail.com>
References: <e3f9e0dd0610010932l30594867pd8d6b862759986d@mail.gmail.com>
Message-ID: <e8bf7a530610040833g424108e1r618e8ae83d0b3d63@mail.gmail.com>

Can you file a bug report for this?  I'm guessing that the trace code
has some bad interaction with LOAD_LOCALS, such that a free variable
passed through the class gets treated as local instead.  I can
reproduce this problem in Python 2.4, so it's a long-standing bug.

Also, as a matter of terminology, there is no currying going on.  It's
just a problem with closures.

Jeremy

On 10/1/06, Scott Marks <scott.c.marks at gmail.com> wrote:
> The code below exhibits different behavior depending on whether it invokes
> sys.settrace ('-t' option) or not.  This means that (in a more complicated
> case) debugging the code (which uses sys.settrace) makes it fail.  Any
> ideas?
>
> """ Demonstrace that tracing messes up curried class definitions """
>
>  # Some simple command line parsing: -t or --trace means trace, nothing
> means don't trace
>  import sys
>
> def usage( ):
>      print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
>     sys.exit( 1 )
>
> if 1 == len( sys.argv ):
>      pass
> elif 2 == len( sys.argv ):
>      if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
>         def trace ( frame, event, arg ):
>             # print frame, event, arg
>              return trace
>         sys.settrace( trace )
>      else:
>         usage( )
>  else:
>     usage( )
>
>
>
> # The test: define a class factory with a curried member function
>
> def the_factory( parm1 ):
>      class the_class( object ):
>         def curried( self ): return parm1
>      return the_class
>
>  x = the_factory( 42 )
>
> y = x( )
>
> try:
>     x.parm1
>     print "Failure: x (the manufactured class) has attribute parm1?!"
>  except AttributeError:
>     print "Success with the manufactured class!"
>
> try:
>      y.parm1
>     print "Failure: y (the instance) has attribute parm1?!"
>  except AttributeError:
>     print "Success with the instance!"
>
> assert y.curried( ) == 42, "Currying didn't work?!"
>
>
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe:
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
>
>

From jolley84 at yahoo.com.cn  Mon Oct  9 14:51:36 2006
From: jolley84 at yahoo.com.cn (=?gb2312?q?=B7=C5=DC=F8=20=CC=B8?=)
Date: Mon, 09 Oct 2006 12:51:36 -0000
Subject: TypeError: decoding Unicode is not supported
Message-ID: <20061009125129.79706.qmail@web15610.mail.cnb.yahoo.com>

later after some small revisions, it comes here:
   
  Traceback (most recent call last):
  File "C:\BitTornado-0.3.15\BitTornado-CVS\btdownloadgui.py", line 2349, in _next
    savedas = dow.saveAs(choosefile,d.newpath)
  File "C:\BitTornado-0.3.15\BitTornado-CVS\BitTornado\download_bt1.py", line 411, in saveAs
    existing = 1
TypeError: decoding Unicode is not supported
   
  and i donot know how to handle with it, 
  if len(listdir(file)) > 0:  # if it's not empty
                        for x in self.info['files']:
                            if path.exists(path.join(file, x['path'][0])):
                                existing = 1
  here is the revision,and formerly i make some revisions on 
   
  import sys
  if path.exists(path.join(unicode(file,'utf-8'), unicode(x['path'][0],'utf-8')):
   
  and since then the TypeError remains though i have removed that statement.
  thanks, if anyone can be helpful.
  jolley
  
 

 		
---------------------------------
 ????????????-3.5G??????20M????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-bugs-list/attachments/20061009/113bcea4/attachment.html 

From jolley84 at yahoo.com.cn  Mon Oct  9 14:52:58 2006
From: jolley84 at yahoo.com.cn (=?gb2312?q?=B7=C5=DC=F8=20=CC=B8?=)
Date: Mon, 09 Oct 2006 12:52:58 -0000
Subject: UnicodeDecodeError problem when run BitTorrent module 
Message-ID: <20061009124609.88115.qmail@web15614.mail.cnb.yahoo.com>

hello guys, i have a problem that when i compile one of bittornado source file named:btdownloadgui.py and i get such a error message: 
    Code: [Download]    
     
   BitTorrent T-0.3.15 (BitTornado)   
   OS: win32   
   Python version: 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]   
   wxWindows version: 2.6.3.3   
     
   Traceback (most recent call last):   
     File "C:\BitTornado-0.3.15\BitTornado-CVS\btdownloadgui.py", line 2334, in _next   
       savedas = dow.saveAs(choosefile, d.newpath)   
     File "C:\BitTornado-0.3.15\BitTornado-CVS\BitTornado\download_bt1.py", line 409, in saveAs   
       if path.exists(path.join(file, x['path'][0])):   
     File "C:\Python24\lib\ntpath.py", line 102, in join   
       path += "\\" + b   
   UnicodeDecodeError: 'ascii' codec can't decode byte 0xb9 in position 1: ordinal not in range(128)   
     
   


of those errors: one is from bittornado source file btdownloadgui.py itself,and one is from the the bittornado library,also one is from the python library. weird,isn't it? 
later i get something more about bittorrent encodings and decodings,utf-8,utf-16,ascii,latin.etc.and i try almost all of these decodings and encodings,such as use decode('utf-8'),or encode('utf-16')etc.and those doings donot come out effectively. 
later i use 
    Code: [Download]    
     
   try:   
       from sys import getfilesystemencoding   
       ENCODING = getfilesystemencoding()   
   except:   
       from sys import getdefaultencoding   
       ENCODING = getdefaultencoding()   
     
   


in the btdowngui.py source file,however the bug remains. 
does it means the bittornado library or the python library itself is misleading? 
so help. 
thanks if anyone can be useful. 
regards, 
jolley


 		
---------------------------------
 Mp3??????-??????????????   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-bugs-list/attachments/20061009/c2e73c71/attachment.htm