From noreply at sourceforge.net  Thu Feb  1 00:00:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 Jan 2007 15:00:33 -0800
Subject: [ python-Bugs-1372650 ] Cookie and multiple names
Message-ID: <E1HCORN-0001gW-KR@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: Viraj Alankar (valankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cookie and multiple names

Initial Comment:
The cookie specification described here:

http://wp.netscape.com/newsref/std/cookie_spec.html

states that multiple names of cookies can be sent. This does not seem 
to parse correctly with the Cookie module due to its dictionary storage.  
When parsing cookies via modpython, only the last cookie is used. I 
think it would be better to only use the first value, since that is what 
the specification says. Or provide for a way to store multiple names 
with different paths.


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

Comment By: John J Lee (jjlee)
Date: 2007-01-31 23:00

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

The discussion of this issue is here:

http://python.org/sf/1372650


No conclusion has been reached about whether it should be applied.  I've
said all I want to say about it already...


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

Comment By: John J Lee (jjlee)
Date: 2006-12-03 16:49

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

loewis: In the Netscape cookie protocol (which is specified approximately,
though ambiguously, and incorrectly in places, by cookie_spec.html),
cookies sent from client to server in the Cookie: header do not include the
path (neither as "path=/foo/bar", nor even as "$path=/foo/bar").  In
valankar's first example of 2005-12-04 16:07, the two cookies must be
interpreted as having different paths (if they do not have different paths,
the client is not behaving correctly).  See the section titled "Second
Example transaction sequence:" in cookie_spec.html for an example of this. 
So, the part of cookie_spec.html you quote is not relevant (in fact, it
refers to client behaviour, not server behaviour -- though it doesn't say
so explicitly!).

BTW, I said earlier: "clients are supposed to (and do) send the most
specific cookie last".  That's backwards: in fact, clients send the most
specific (longest-path) cookie first.  Cookie.py always ignores all but the
last cookie (it overwrites the first), so it will only store the
least-specific cookie, so my point stands.

Also note that valankar's second example of 2005-12-04 16:07 is incorrect
(unless he meant Set-Cookie: instead of Cookie:): the Cookie header should
never contain path cookie-attributes (see penultimate paragraph of this
comment, and perhaps more clearly, method
cookielib.CookieJar._cookie_attrs()).  By "cookie-attribute" I mean a
string of the form "<name>=<value>", i.e. the same thing as represented by
instances of Cookie.Morsel .

AFAIK (not 100% sure here) when several cookies are returned, none of the
cookie standards defines which cookie servers should or should not look at,
so Cookie.py should probably make all of the cookies available through some
interface.  If it chooses to only provide one cookie (as it does), it would
seem that a good choice would be the first cookie in the string passed to
.load(), since that should be the one with the longest path.  Cookie.py
instead takes the last cookie (probably by accident).  That's not good, but
I'm unsure whether it should be changed, since it may break old code.

I'm puzzled by Cookie.py's design: First, poor naming: BaseCookie (and
therefore a SimpleCookie instance) seems to represent multiple HTTP
cookies.  Second, BaseCookie.load(string) treats attributes like "path"
specially, and I do not understand why.  The documentation says you're
intended to pass the value of HTTP_COOKIE to that string, but AFAICS, if
the client obeys any of the cookie protocols (either the de facto Netscape
protocol or any of the RFCs) then HTTP_COOKIE should never contain a string
like "; path=x", where x is replaced by any arbitrary string (assuming here
that HTTP_COOKIE is always simply the value of the HTTP header named
"Cookie", and for simplicity that there are no quoted strings in the Cookie
header).  Third, BaseCookie does not allow storing several cookies of the
same name.  As I understand it, this last problem is the one valankar was
complaining about.

I've always found cookies highly confusing, I must say, so it's always
possible I've got something mixed up by now... but I don't think so.


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

Comment By: Martin v. L?wis (loewis)
Date: 2006-12-03 12:44

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

I fail to see the bug. Where in the spec does it say that the first value
should be used? On the contrary, the spec seems to say that the last value
should be used:

# Instances of the same path and name will overwrite each other, 
# with the latest instance taking precedence.

So if that's what the current module does, there is no bug.

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

Comment By: Viraj Alankar (valankar)
Date: 2005-12-04 22:46

Message:
Logged In: YES 
user_id=107970

Heh I guess that means I should try to write a patch. Might be a good
learning 
experience for me.

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

Comment By: John J Lee (jjlee)
Date: 2005-12-04 18:16

Message:
Logged In: YES 
user_id=261020

OK, I see.

I agree that it's a bug, but I'm undecided whether the
existing behaviour should be fixed.  It's true that clients
are supposed to (and do) send the most specific cookie last,
so this bug could cause servers to see the cookie from, eg
path '/cgi-bin' instead of from path '/mystuff/cgi-bin'. 
However, module Cookie is old and stable, and a patch might
break servers expecting the current behaviour.  I *suppose*
such breakage is fairly unlikely, so I wouldn't object to a
patch.

I certainly don't see anybody objecting to a patch to add a
new method to allow access to multiple cookies of the same
name  without altering the existing dict interface (repr()
could change, but not eg. .get()).

Either way, I suspect a patch is only likely to appear from
somebody who is actually using such cookies, though :-)


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

Comment By: Viraj Alankar (valankar)
Date: 2005-12-04 16:07

Message:
Logged In: YES 
user_id=107970

Basically, sometimes a web client will send 2 instances of the same name:

Cookie: mycookie=foo; mycookie=bar

The specs say that the first one is the one that should be used. The other

cookies listed are the inherited ones from paths that a prefix of the
current 
URL. When this is parsed by the Cookie module, mycookie gets set to bar 
when it should be foo.

Another example might be:

Cookie: mycookie=foo; path=bar
Cookie: mycookie=foo; path=baz

In this case there should be 2 cookies with the name 'mycookie'. The 
uniqueness is determined by the different paths.

Thanks.


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

Comment By: John J Lee (jjlee)
Date: 2005-12-04 15:52

Message:
Logged In: YES 
user_id=261020

I don't get it:

>>> import Cookie
>>> c = Cookie.SimpleCookie()
>>> c.load("foo=bar; bar=baz")
>>> c
<SimpleCookie: bar='baz' foo='bar'>


Where's the problem?

In general, don't pay too much attention to that standard, BTW:

http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards


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

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

From noreply at sourceforge.net  Thu Feb  1 00:15:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 Jan 2007 15:15:24 -0800
Subject: [ python-Bugs-1372650 ] Cookie and multiple names
Message-ID: <E1HCOfk-0005UW-H7@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: Viraj Alankar (valankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cookie and multiple names

Initial Comment:
The cookie specification described here:

http://wp.netscape.com/newsref/std/cookie_spec.html

states that multiple names of cookies can be sent. This does not seem 
to parse correctly with the Cookie module due to its dictionary storage.  
When parsing cookies via modpython, only the last cookie is used. I 
think it would be better to only use the first value, since that is what 
the specification says. Or provide for a way to store multiple names 
with different paths.


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

Comment By: John J Lee (jjlee)
Date: 2007-01-31 23:15

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

Ignore last comment.  I thought a patch had been added, but it seems I
mixed up the bug and patch trackers.  Curse this SF bug/patch tracker
distinction!


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

Comment By: John J Lee (jjlee)
Date: 2007-01-31 23:00

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

The discussion of this issue is here:

http://python.org/sf/1372650


No conclusion has been reached about whether it should be applied.  I've
said all I want to say about it already...


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

Comment By: John J Lee (jjlee)
Date: 2006-12-03 16:49

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

loewis: In the Netscape cookie protocol (which is specified approximately,
though ambiguously, and incorrectly in places, by cookie_spec.html),
cookies sent from client to server in the Cookie: header do not include the
path (neither as "path=/foo/bar", nor even as "$path=/foo/bar").  In
valankar's first example of 2005-12-04 16:07, the two cookies must be
interpreted as having different paths (if they do not have different paths,
the client is not behaving correctly).  See the section titled "Second
Example transaction sequence:" in cookie_spec.html for an example of this. 
So, the part of cookie_spec.html you quote is not relevant (in fact, it
refers to client behaviour, not server behaviour -- though it doesn't say
so explicitly!).

BTW, I said earlier: "clients are supposed to (and do) send the most
specific cookie last".  That's backwards: in fact, clients send the most
specific (longest-path) cookie first.  Cookie.py always ignores all but the
last cookie (it overwrites the first), so it will only store the
least-specific cookie, so my point stands.

Also note that valankar's second example of 2005-12-04 16:07 is incorrect
(unless he meant Set-Cookie: instead of Cookie:): the Cookie header should
never contain path cookie-attributes (see penultimate paragraph of this
comment, and perhaps more clearly, method
cookielib.CookieJar._cookie_attrs()).  By "cookie-attribute" I mean a
string of the form "<name>=<value>", i.e. the same thing as represented by
instances of Cookie.Morsel .

AFAIK (not 100% sure here) when several cookies are returned, none of the
cookie standards defines which cookie servers should or should not look at,
so Cookie.py should probably make all of the cookies available through some
interface.  If it chooses to only provide one cookie (as it does), it would
seem that a good choice would be the first cookie in the string passed to
.load(), since that should be the one with the longest path.  Cookie.py
instead takes the last cookie (probably by accident).  That's not good, but
I'm unsure whether it should be changed, since it may break old code.

I'm puzzled by Cookie.py's design: First, poor naming: BaseCookie (and
therefore a SimpleCookie instance) seems to represent multiple HTTP
cookies.  Second, BaseCookie.load(string) treats attributes like "path"
specially, and I do not understand why.  The documentation says you're
intended to pass the value of HTTP_COOKIE to that string, but AFAICS, if
the client obeys any of the cookie protocols (either the de facto Netscape
protocol or any of the RFCs) then HTTP_COOKIE should never contain a string
like "; path=x", where x is replaced by any arbitrary string (assuming here
that HTTP_COOKIE is always simply the value of the HTTP header named
"Cookie", and for simplicity that there are no quoted strings in the Cookie
header).  Third, BaseCookie does not allow storing several cookies of the
same name.  As I understand it, this last problem is the one valankar was
complaining about.

I've always found cookies highly confusing, I must say, so it's always
possible I've got something mixed up by now... but I don't think so.


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

Comment By: Martin v. L?wis (loewis)
Date: 2006-12-03 12:44

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

I fail to see the bug. Where in the spec does it say that the first value
should be used? On the contrary, the spec seems to say that the last value
should be used:

# Instances of the same path and name will overwrite each other, 
# with the latest instance taking precedence.

So if that's what the current module does, there is no bug.

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

Comment By: Viraj Alankar (valankar)
Date: 2005-12-04 22:46

Message:
Logged In: YES 
user_id=107970

Heh I guess that means I should try to write a patch. Might be a good
learning 
experience for me.

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

Comment By: John J Lee (jjlee)
Date: 2005-12-04 18:16

Message:
Logged In: YES 
user_id=261020

OK, I see.

I agree that it's a bug, but I'm undecided whether the
existing behaviour should be fixed.  It's true that clients
are supposed to (and do) send the most specific cookie last,
so this bug could cause servers to see the cookie from, eg
path '/cgi-bin' instead of from path '/mystuff/cgi-bin'. 
However, module Cookie is old and stable, and a patch might
break servers expecting the current behaviour.  I *suppose*
such breakage is fairly unlikely, so I wouldn't object to a
patch.

I certainly don't see anybody objecting to a patch to add a
new method to allow access to multiple cookies of the same
name  without altering the existing dict interface (repr()
could change, but not eg. .get()).

Either way, I suspect a patch is only likely to appear from
somebody who is actually using such cookies, though :-)


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

Comment By: Viraj Alankar (valankar)
Date: 2005-12-04 16:07

Message:
Logged In: YES 
user_id=107970

Basically, sometimes a web client will send 2 instances of the same name:

Cookie: mycookie=foo; mycookie=bar

The specs say that the first one is the one that should be used. The other

cookies listed are the inherited ones from paths that a prefix of the
current 
URL. When this is parsed by the Cookie module, mycookie gets set to bar 
when it should be foo.

Another example might be:

Cookie: mycookie=foo; path=bar
Cookie: mycookie=foo; path=baz

In this case there should be 2 cookies with the name 'mycookie'. The 
uniqueness is determined by the different paths.

Thanks.


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

Comment By: John J Lee (jjlee)
Date: 2005-12-04 15:52

Message:
Logged In: YES 
user_id=261020

I don't get it:

>>> import Cookie
>>> c = Cookie.SimpleCookie()
>>> c.load("foo=bar; bar=baz")
>>> c
<SimpleCookie: bar='baz' foo='bar'>


Where's the problem?

In general, don't pay too much attention to that standard, BTW:

http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards


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

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

From noreply at sourceforge.net  Thu Feb  1 00:45:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 Jan 2007 15:45:36 -0800
Subject: [ python-Bugs-1580738 ] httplib hangs reading too much data
Message-ID: <E1HCP8y-00033O-LL@sc8-sf-web11.sourceforge.net>

Bugs item #1580738, was opened at 2006-10-19 20:06
Message generated for change (Comment added) made by jjlee
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: John J Lee (jjlee)
Date: 2007-01-31 23:45

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

I disagree with mhammond.  Mark is correct that closing the connection
would be wrong, but self.close() in the function in question does *not*
close the connection.  Client code is not expected to explicitly call
HTTPResponse.read() with an explicit amt argument even when persistent
connections are involved.  All that's required is (of course) that you have
to read to the end of the current response before you get to read the next
response on that connection.

I think Dustin is more or less right in his diagnosis, but I haven't
written a patch yet...


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

Comment By: Dustin J. Mitchell (djmitche)
Date: 2006-10-27 23: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-27 03: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  Thu Feb  1 01:17:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 Jan 2007 16:17:42 -0800
Subject: [ python-Bugs-1647037 ] cookielib.CookieJar does not handle cookies
	when port in url
Message-ID: <E1HCPe2-0006hZ-96@sc8-sf-monitor2.sourceforge.net>

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

Please note that this 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: STS (tools-sts)
Assigned to: Nobody/Anonymous (nobody)
Summary: cookielib.CookieJar does not handle cookies when port in url

Initial Comment:
In Python 2.5 the cookielib.CookieJar does not handle cookies (i.e., recognise the Set-Cookie: header) when the port is specified in the URL.

e.g., 
import urllib2, cookielib
cookiejar = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))
# add proxy to view results
proxy_handler = urllib2.ProxyHandler({'http':'127.0.0.1:8080'})
opener.add_handler(proxy_handler)
# Install opener globally so it can be used with urllib2.
urllib2.install_opener(opener)
# The ':80' will cause the CookieJar to never handle the 
# cookie set by Google
request = urllib2.Request('http://www.google.com.au:80/')
response = opener.open(request)
response = opener.open(request) # No Cookie:
# But this works
request = urllib2.Request('http://www.google.com.au/')
response = opener.open(request)
response = opener.open(request)# Cookie: PREF=ID=d2de0..

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

Comment By: John J Lee (jjlee)
Date: 2007-02-01 00:17

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

This is not a bug.  If you turn on cookielib logging (see below), you'll
see that Google sends back a cookie for google.com (not .com.au) on the
first request iff you add the port number.  That cookie should not be sent
back to the server.  My copy of Firefox 1.5.0.9 doesn't send back a cookie
here either.

(note they do send a .com.au cookie when you do a search, presumably
because the search button lands you at a URL without the :80 on the end. 
It's probably just a minor oversight or an optimisation that they don't
send the .com.au cookie when you include the :80)

To turn on logging:

import sys, logging
logger = logging.getLogger("cookielib")
logger.addHandler(logging.StreamHandler(sys.stdout))
logger.setLevel(logging.DEBUG)


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

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

From noreply at sourceforge.net  Thu Feb  1 03:20:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 Jan 2007 18:20:07 -0800
Subject: [ python-Bugs-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HCRYV-0006sy-OE@sc8-sf-web7.sourceforge.net>

Bugs item #1649329, was opened at 2007-01-31 18:20
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=1649329&group_id=5470

Please note that this 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
Private: No
Submitted By: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

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

From noreply at sourceforge.net  Thu Feb  1 04:20:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 Jan 2007 19:20:18 -0800
Subject: [ python-Bugs-1566611 ] Idle 1.2 - Calltips Hotkey does not work
Message-ID: <200702010320.l113KICH013690@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1566611, was opened at 2006-09-27 13:24
Message generated for change (Comment added) made by sf-robot
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: Closed
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.


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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-01-31 19:20

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

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: 2007-01-17 13:29

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

fladd: Please supply the additional information asked for so that we are
able to process this bug.

Setting status to Pending.

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

Comment By: Tal Einat (taleinat)
Date: 2006-12-09 09:45

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

You mean 2.5 final is suppose...
Works for me, Python 2.5 final, WinXP Pro.

Does this never work or only sometimes?
Have you checked you key definitions?
Does it work in the Shell window?

Please be more specific...

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

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

From noreply at sourceforge.net  Thu Feb  1 13:10:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 04:10:43 -0800
Subject: [ python-Bugs-1647037 ] cookielib.CookieJar does not handle cookies
	when port in url
Message-ID: <E1HCam3-00036Q-3q@sc8-sf-web5.sourceforge.net>

Bugs item #1647037, was opened at 2007-01-29 12:31
Message generated for change (Comment added) made by tools-sts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647037&group_id=5470

Please note that this 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: None
Priority: 5
Private: No
Submitted By: STS (tools-sts)
Assigned to: Nobody/Anonymous (nobody)
Summary: cookielib.CookieJar does not handle cookies when port in url

Initial Comment:
In Python 2.5 the cookielib.CookieJar does not handle cookies (i.e., recognise the Set-Cookie: header) when the port is specified in the URL.

e.g., 
import urllib2, cookielib
cookiejar = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))
# add proxy to view results
proxy_handler = urllib2.ProxyHandler({'http':'127.0.0.1:8080'})
opener.add_handler(proxy_handler)
# Install opener globally so it can be used with urllib2.
urllib2.install_opener(opener)
# The ':80' will cause the CookieJar to never handle the 
# cookie set by Google
request = urllib2.Request('http://www.google.com.au:80/')
response = opener.open(request)
response = opener.open(request) # No Cookie:
# But this works
request = urllib2.Request('http://www.google.com.au/')
response = opener.open(request)
response = opener.open(request)# Cookie: PREF=ID=d2de0..

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

>Comment By: STS (tools-sts)
Date: 2007-02-01 12:10

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

You're right! I will close this now...Sorry about that. Also, thanks for
the logging/DEBUG code this will be very useful going forward.

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

Comment By: John J Lee (jjlee)
Date: 2007-02-01 00:17

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

This is not a bug.  If you turn on cookielib logging (see below), you'll
see that Google sends back a cookie for google.com (not .com.au) on the
first request iff you add the port number.  That cookie should not be sent
back to the server.  My copy of Firefox 1.5.0.9 doesn't send back a cookie
here either.

(note they do send a .com.au cookie when you do a search, presumably
because the search button lands you at a URL without the :80 on the end. 
It's probably just a minor oversight or an optimisation that they don't
send the .com.au cookie when you include the :80)

To turn on logging:

import sys, logging
logger = logging.getLogger("cookielib")
logger.addHandler(logging.StreamHandler(sys.stdout))
logger.setLevel(logging.DEBUG)


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

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

From noreply at sourceforge.net  Thu Feb  1 19:20:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 10:20:59 -0800
Subject: [ python-Bugs-1650053 ] decimals compare badly to floats
Message-ID: <E1HCgYN-0003fF-5s@sc8-sf-web1.sourceforge.net>

Bugs item #1650053, was opened at 2007-02-01 19:20
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=1650053&group_id=5470

Please note that this 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: Brian Sutherland (jinty_)
Assigned to: Nobody/Anonymous (nobody)
Summary: decimals compare badly to floats

Initial Comment:
This behaviour is so unexpected that I'm pretty sure it's a bug. If decimals can't be compared to floats, at least it should error.

Found in python2.4 and 2.5 by at least 2 people:

Python 2.5 (release25-maint, Dec  9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> 1172837167.27 > Decimal("1172837136.0800")
False
>>> 1172837167.27 > Decimal("1")
False


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

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

From noreply at sourceforge.net  Thu Feb  1 20:12:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 11:12:52 -0800
Subject: [ python-Bugs-1582742 ] Python is dumping core after the test
	test_ctypes
Message-ID: <E1HChMa-00022i-DC@sc8-sf-web5.sourceforge.net>

Bugs item #1582742, was opened at 2006-10-23 11:42
Message generated for change (Comment added) made by theller
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: Thomas Heller (theller)
Date: 2007-02-01 20:12

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

Martin, -lgcc alone does not work, I had to specify library_dirs.
Linking is done with 'ld -l' by default.

How do I specify that gcc should be used for linking (and should I expect
'configure' to determine this correctly)?  Is it a bug in 'configure'?

Ok: when I export LDSHARED="gcc -shared", than do configure and make the
missing symbol error disappears, even without using -lgcc.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-01-31 22:58

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

Thomas, the libgcc problem might be a gcc installation problem. Just
specifying -lgcc should be enough to get libgcc linked in. Furthermore,
depending on how the linking is done (gcc -shared?), it shouldn't be
necessary *at all* to provide -lgcc. This isn't so much a HPUX question but
more a gcc question: if you link with gcc, it *ought* to work (if you link
with ld(1), you are on your own).

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

Comment By: Thomas Heller (theller)
Date: 2007-01-31 22:00

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

I did also try the Python 2.5 release tarball and could not reproduce the
bug.  Machine info:

bash-3.00$ uname -a
HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license
bash-3.00$ gcc --version
gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

bash-3.00$ ./python
Python 2.5 (r25:51908, Jan 31 2007, 15:56:22)
[GCC 3.4.3] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>>
bash-3.00$


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

Comment By: Thomas Heller (theller)
Date: 2007-01-31 21:15

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

I finally found time (and energy) to try out the td176 HPUX host on HP
testdrive.

I downloaded the python25.tar.bz2 snapshot from svn.python.org, and built
it with the installed gcc 3.4.3.  First, I got errors in the ctypes tests
because the _ctypes_test extension/shared library could not be loaded
because of a missing symbol __divsf3.

Googling around I found http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
which mentions a GCC runtime library libgcc.a (see the link 'soft float
library routines' on ths page).  When this library is specified when
building _ctypes_test.so, all ctypes unittests pass.  Without any crash.

It is strange, to link against the libgcc.a library it seems needed to
specify the location of the library
'/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/' - no idea why.  Can some HPUX
guru provide some insight?

The attached patch to setup.py is what was needed, but it is a hack of
course.
File Added: setup.py.patch

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

Comment By: Thomas Heller (theller)
Date: 2006-11-02 22:02

Message:
Logged In: YES 
user_id=11105

Neal, I see no connection between the code that you show and
the stack dump.

For the failure when importing ctypes.test.test_cfuncs it
seems that a library (?) is missing
that _ctypes_test.so requires.  Any idea?  (I know that HP
offers shell access to HPUX boxes,
but I hesitate to try that out...).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-29 03: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 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  Thu Feb  1 20:20:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 11:20:32 -0800
Subject: [ python-Bugs-1650090 ] doctest doesn't find nested functions
Message-ID: <E1HChU0-000535-Pt@sc8-sf-web2.sourceforge.net>

Bugs item #1650090, was opened at 2007-02-01 20:20
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=1650090&group_id=5470

Please note that this 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: Daniel Brown (danb37)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest doesn't find nested functions

Initial Comment:
If a nested function has doctests, they won't be run:
{{{
def f():
  '''
  >>> 'a'
  'a'
  '''

  def g():
    '''
    >>> 'a'
    'b'
    '''
    pass

  pass
}}}

DocTestFinder will only find f's doctest and won't recurse to find g's, surprising the programmer when they (hopefully) discover that their inner doctest is incorrect!

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

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

From noreply at sourceforge.net  Thu Feb  1 20:54:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 11:54:43 -0800
Subject: [ python-Bugs-1582742 ] Python is dumping core after the test
	test_ctypes
Message-ID: <E1HCi15-0004Ad-IE@sc8-sf-monitor2.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: 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: Martin v. L?wis (loewis)
Date: 2007-02-01 20:54

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

configure.in sets LDSHARED to "ld -b" around line 1477. Whether this is a
bug, I don't know - there may have been HP-UX systems where this was the
proper way of doing things.

These days, on most systems (not sure whether this includes HP-UX), direct
linking with ld is discouraged; one should use the C compiler for linking.

Unless somebody steps in and can tell the full story, I would advise to
use $(CC) for linking on HPUX if the compiler is gcc (see SunOS processing
as to how to determine gcc).

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

Comment By: Thomas Heller (theller)
Date: 2007-02-01 20:12

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

Martin, -lgcc alone does not work, I had to specify library_dirs.
Linking is done with 'ld -l' by default.

How do I specify that gcc should be used for linking (and should I expect
'configure' to determine this correctly)?  Is it a bug in 'configure'?

Ok: when I export LDSHARED="gcc -shared", than do configure and make the
missing symbol error disappears, even without using -lgcc.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-01-31 22:58

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

Thomas, the libgcc problem might be a gcc installation problem. Just
specifying -lgcc should be enough to get libgcc linked in. Furthermore,
depending on how the linking is done (gcc -shared?), it shouldn't be
necessary *at all* to provide -lgcc. This isn't so much a HPUX question
but more a gcc question: if you link with gcc, it *ought* to work (if you
link with ld(1), you are on your own).

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

Comment By: Thomas Heller (theller)
Date: 2007-01-31 22:00

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

I did also try the Python 2.5 release tarball and could not reproduce the
bug.  Machine info:

bash-3.00$ uname -a
HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license
bash-3.00$ gcc --version
gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

bash-3.00$ ./python
Python 2.5 (r25:51908, Jan 31 2007, 15:56:22)
[GCC 3.4.3] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>>
bash-3.00$


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

Comment By: Thomas Heller (theller)
Date: 2007-01-31 21:15

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

I finally found time (and energy) to try out the td176 HPUX host on HP
testdrive.

I downloaded the python25.tar.bz2 snapshot from svn.python.org, and built
it with the installed gcc 3.4.3.  First, I got errors in the ctypes tests
because the _ctypes_test extension/shared library could not be loaded
because of a missing symbol __divsf3.

Googling around I found http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
which mentions a GCC runtime library libgcc.a (see the link 'soft float
library routines' on ths page).  When this library is specified when
building _ctypes_test.so, all ctypes unittests pass.  Without any crash.

It is strange, to link against the libgcc.a library it seems needed to
specify the location of the library
'/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/' - no idea why.  Can some
HPUX guru provide some insight?

The attached patch to setup.py is what was needed, but it is a hack of
course.
File Added: setup.py.patch

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

Comment By: Thomas Heller (theller)
Date: 2006-11-02 22:02

Message:
Logged In: YES 
user_id=11105

Neal, I see no connection between the code that you show and
the stack dump.

For the failure when importing ctypes.test.test_cfuncs it
seems that a library (?) is missing
that _ctypes_test.so requires.  Any idea?  (I know that HP
offers shell access to HPUX boxes,
but I hesitate to try that out...).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-29 03: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 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  Thu Feb  1 21:24:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 12:24:18 -0800
Subject: [ python-Bugs-1650053 ] decimals compare badly to floats
Message-ID: <E1HCiTi-0002qk-SO@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Brian Sutherland (jinty_)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: decimals compare badly to floats

Initial Comment:
This behaviour is so unexpected that I'm pretty sure it's a bug. If decimals can't be compared to floats, at least it should error.

Found in python2.4 and 2.5 by at least 2 people:

Python 2.5 (release25-maint, Dec  9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> 1172837167.27 > Decimal("1172837136.0800")
False
>>> 1172837167.27 > Decimal("1")
False


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-01 15:24

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

It was intended that Decimals not be compared to floats, but I think we
can do better than returning a useless result

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

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

From noreply at sourceforge.net  Thu Feb  1 22:04:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 13:04:34 -0800
Subject: [ python-Bugs-1648179 ] set update problem with class derived from
	dict
Message-ID: <E1HCj6g-0003b3-9C@sc8-sf-web4.sourceforge.net>

Bugs item #1648179, was opened at 2007-01-30 15:00
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648179&group_id=5470

Please note that this 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
Private: No
Submitted By: duncan (urubu147)
Assigned to: Raymond Hettinger (rhettinger)
Summary: set update problem with class derived from dict

Initial Comment:
Class derived from dict with __iter__ method returning itervalues() has keys (rather than values) added to set when using set update method.  Works as expected in 2.4.  Windows XP (Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32).  Unsure of platform for Peter Otten's minimal example in (hopefully) attached file.

Duncan Smith

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-01 16:04

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

Fixed.  See versions 53616 and 53617.

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

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

From noreply at sourceforge.net  Thu Feb  1 22:05:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 13:05:31 -0800
Subject: [ python-Bugs-1574217 ] isinstance swallows exceptions
Message-ID: <E1HCj7b-0003h5-Ke@sc8-sf-web4.sourceforge.net>

Bugs item #1574217, was opened at 2006-10-09 21:55
Message generated for change (Comment added) made by rhettinger
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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: Brian Harring (ferringb)
>Assigned to: Neal Norwitz (nnorwitz)
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: Raymond Hettinger (rhettinger)
Date: 2007-02-01 16:05

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

Neal, do you have time to look at this one?

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

Comment By: Brian Harring (ferringb)
Date: 2006-11-04 23:06

Message:
Logged In: YES 
user_id=874085

quicky patch for this; basically, wipe the exception only if
it's AttributeError, else let it bubble it's way up.

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

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  Fri Feb  2 02:00:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Feb 2007 17:00:21 -0800
Subject: [ python-Bugs-1574217 ] isinstance swallows exceptions
Message-ID: <E1HCmmr-0006fh-Px@sc8-sf-web9.sourceforge.net>

Bugs item #1574217, was opened at 2006-10-09 19:55
Message generated for change (Comment added) made by nnorwitz
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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Brian Harring (ferringb)
Assigned to: Neal Norwitz (nnorwitz)
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: Neal Norwitz (nnorwitz)
Date: 2007-02-01 17:00

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

Possibly in a week or so.  It's unlikely I'll get to it sooner.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-01 13:05

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

Neal, do you have time to look at this one?

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

Comment By: Brian Harring (ferringb)
Date: 2006-11-04 20:06

Message:
Logged In: YES 
user_id=874085

quicky patch for this; basically, wipe the exception only if
it's AttributeError, else let it bubble it's way up.

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

Comment By: Brian Harring (ferringb)
Date: 2006-10-09 19: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  Fri Feb  2 15:33:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Feb 2007 06:33:34 -0800
Subject: [ python-Bugs-1650090 ] doctest doesn't find nested functions
Message-ID: <E1HCzTq-0003KH-9I@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Daniel Brown (danb37)
>Assigned to: Tim Peters (tim_one)
Summary: doctest doesn't find nested functions

Initial Comment:
If a nested function has doctests, they won't be run:
{{{
def f():
  '''
  >>> 'a'
  'a'
  '''

  def g():
    '''
    >>> 'a'
    'b'
    '''
    pass

  pass
}}}

DocTestFinder will only find f's doctest and won't recurse to find g's, surprising the programmer when they (hopefully) discover that their inner doctest is incorrect!

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

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

From noreply at sourceforge.net  Fri Feb  2 20:27:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Feb 2007 11:27:30 -0800
Subject: [ python-Bugs-1650899 ] sys.excepthook does not work with -m command
	line switch
Message-ID: <E1HD44I-0008OB-Qv@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.excepthook does not work with -m command line switch

Initial Comment:
crashlog.py is the following:
  import sys

  def excepthook(type, value, traceback):
      print "BUMMER"

  sys.excepthook = excepthook

When crash.py is like:
  import crashlog
  raise ValueError("so sad")

The it works as expected:
  [mtebeka at lakshmi - 11:22] ~ $python crash.py 
  BUMMER
  [mtebeka at lakshmi - 11:23] ~ $

However when I try to load crashlog using -m and leave crash.py like:
  raise ValueError("so sad")

The nothing (not even original excepthook is called):
  [mtebeka at lakshmi - 11:23] ~ $python -m crashlog crash.py
  [mtebeka at lakshmi - 11:25] ~ $



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

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

From noreply at sourceforge.net  Fri Feb  2 20:41:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Feb 2007 11:41:30 -0800
Subject: [ python-Bugs-1650903 ] PyFloat_FromString deprecated form
Message-ID: <E1HD4Hq-0007pp-8l@sc8-sf-web5.sourceforge.net>

Bugs item #1650903, was opened at 2007-02-02 14:41
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=1650903&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyFloat_FromString deprecated form

Initial Comment:
PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API.

Extracts from Tim's 2000 comment:


Since we can't change the interface of a public API function, pend is still supported but now *officially* useless:  if pend is not NULL, *pend is set to NULL.


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

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

From noreply at sourceforge.net  Fri Feb  2 20:42:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Feb 2007 11:42:16 -0800
Subject: [ python-Bugs-1650899 ] sys.excepthook does not work with -m command
	line switch
Message-ID: <E1HD4Ia-0006U5-5N@sc8-sf-web4.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.excepthook does not work with -m command line switch

Initial Comment:
crashlog.py is the following:
  import sys

  def excepthook(type, value, traceback):
      print "BUMMER"

  sys.excepthook = excepthook

When crash.py is like:
  import crashlog
  raise ValueError("so sad")

The it works as expected:
  [mtebeka at lakshmi - 11:22] ~ $python crash.py 
  BUMMER
  [mtebeka at lakshmi - 11:23] ~ $

However when I try to load crashlog using -m and leave crash.py like:
  raise ValueError("so sad")

The nothing (not even original excepthook is called):
  [mtebeka at lakshmi - 11:23] ~ $python -m crashlog crash.py
  [mtebeka at lakshmi - 11:25] ~ $



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

>Comment By: Miki Tebeka (tebeka)
Date: 2007-02-02 21:42

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

Didn't understand how -m works, my bad

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

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

From noreply at sourceforge.net  Fri Feb  2 21:20:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Feb 2007 12:20:16 -0800
Subject: [ python-Bugs-1646068 ] Dict lookups fail if sizeof(Py_ssize_t) <
	sizeof(long)
Message-ID: <E1HD4tM-00055n-Ap@sc8-sf-web3.sourceforge.net>

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

Please note that this 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: 6
Private: No
Submitted By: ked-tao (ked-tao)
Assigned to: Tim Peters (tim_one)
Summary: Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long)

Initial Comment:
Portation problem.

Include/dictobject.h defines PyDictEntry.me_hash as a Py_ssize_t. Everywhere else uses a C 'long' for hashes.

On the system I'm porting to, ints and pointers (and ssize_t) are 32-bit, but longs and long longs are 64-bit. Therefore, the assignments to me_hash truncate the hash and subsequent lookups fail.

I've changed the definition of me_hash to 'long' and (in Objects/dictobject.c) removed the casting from the various assignments and changed the definition of 'i' in dict_popitem(). This has fixed my immediate problems, but I guess I've just reintroduced whatever problem it got changed for. The comment in the header says:

/* Cached hash code of me_key.  Note that hash codes are C longs.
 * We have to use Py_ssize_t instead because dict_popitem() abuses
 * me_hash to hold a search finger.
 */

... but that doesn't really explain what it is about dict_popitem() that requires the different type.

Thanks. Kev.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-02-02 15:20

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

The whole point of a hash is that if it doesn't match, you can skip an
expensive comparison.  How big to make the hash is a tradeoff between how
much you'll waste calculating and storing it vs how often it will save a
"real" comparison.

The comment means that, as an implementation detail, popitem assumes it
can store a pointer there instead, so hashes need to be at least as big as
a pointer.  

Going to the larger of the two sizes will certainly solve your problem; it
just wastes some space, and maybe some time calculating the hash.  

If you want to get that space back, just make sure the truncation is
correct and consistent.  I *suspect* your problem is that when there is a
collision, either 

(1)  It is comparing a truncated value to an untruncated value, or
(2)  The perturbation to find the next slot is going wrong, because of
when the truncation happens.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-27 14:40

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

This is your code, Tim.

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

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

From noreply at sourceforge.net  Fri Feb  2 22:48:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Feb 2007 13:48:18 -0800
Subject: [ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences"
	selected
Message-ID: <E1HD6GY-00026C-52@sc8-sf-web4.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Mick L (mehum)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE crashes on OS X 10.4 when "Preferences" selected

Initial Comment:
When I select 'preferences' (on IDLE 1.2, Python 2.5)  or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears.

Terminal reports a "Segmentation fault" upon the crash.

My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable.  

IDLE also appears stable until I select this option.

The Python crash log is attached.

Please, can anyone suggest what may be causing this problem?  Thank you.



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

Comment By: Fran?ois Scholder (f_scholder)
Date: 2007-02-02 22:48

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

A similar problem arises with WinXP when trying to configure IDLE via the
"Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no
effect. However when closing the window by clicking on either the window
close button (top right 'X') or the 'Cancel' button, several bahaviors are
observed depending on how many times one has clicked on the 'Ok' and/or
'Cancel' buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is resumed
and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text
editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32 -> WinXP SP2

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

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

From noreply at sourceforge.net  Fri Feb  2 22:55:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Feb 2007 13:55:10 -0800
Subject: [ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences"
	selected
Message-ID: <E1HD6NC-0002lu-H9@sc8-sf-web4.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Mick L (mehum)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE crashes on OS X 10.4 when "Preferences" selected

Initial Comment:
When I select 'preferences' (on IDLE 1.2, Python 2.5)  or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears.

Terminal reports a "Segmentation fault" upon the crash.

My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable.  

IDLE also appears stable until I select this option.

The Python crash log is attached.

Please, can anyone suggest what may be causing this problem?  Thank you.



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

Comment By: Fran?ois Scholder (f_scholder)
Date: 2007-02-02 22:55

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

Erratum:

A similar problem arises with WinXP when trying to configure IDLE via the
"Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no
effect. However when closing the window by clicking on either the window
close button (top right 'X') or the 'Cancel' button, several bahaviors
are
observed depending on how many times one has clicked on the 'Ok' and/or
---->'Apply'<---- buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is
resumed
and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text
editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32 -> WinXP SP2

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

Comment By: Fran?ois Scholder (f_scholder)
Date: 2007-02-02 22:48

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

A similar problem arises with WinXP when trying to configure IDLE via the
"Options>Configure IDLE..." menu.

Clicking on the 'Ok' or 'Apply' buttons of the dialog seemingly has no
effect. However when closing the window by clicking on either the window
close button (top right 'X') or the 'Cancel' button, several bahaviors are
observed depending on how many times one has clicked on the 'Ok' and/or
'Cancel' buttons before:
- 0 clicks => expected behavior (dialog is closed, IDLE session is resumed
and working fine)
- 1 or 2 clicks => dialog is closed but the IDLE shell behaves as a text
editor instead of an interpreter
- 3 or more clicks => IDLE crashes...

Note: I'm running Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32 -> WinXP SP2

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

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

From noreply at sourceforge.net  Sat Feb  3 15:05:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 03 Feb 2007 06:05:22 -0800
Subject: [ python-Bugs-1651235 ] ctypes.Structure formal parameter dies given
	tuple
Message-ID: <E1HDLW6-0003eE-O7@sc8-sf-web11.sourceforge.net>

Bugs item #1651235, was opened at 2007-02-03 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=1651235&group_id=5470

Please note that this 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: Gary Bishop (tgbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes.Structure formal parameter dies given tuple

Initial Comment:
With a structure like:

class CvRect(ctypes.Structure):
    _fields_ = [("x", ctypes.c_int),
                ("y", ctypes.c_int),
                ("width", ctypes.c_int),
                ("height", ctypes.c_int)]

and a foreign function like:

cvSetImageROI = _cxDLL.cvSetImageROI
cvSetImageROI.restype = None # void
cvSetImageROI.argtypes = [
    ctypes.c_void_p, # IplImage* image
    CvRect # CvRect rect
    ]

The call

cvSetImageROI(img, CvRect(1,2,3,4))

works fine but the mistaken call:

cvSetImageROI(img, (1,2,3,4))

Produces the "Send Error Report" dialog from Windows.

Other erroneous arguments produce a message about correct argument type but the tuple triggers some other behavior.


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

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

From noreply at sourceforge.net  Sat Feb  3 18:52:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 03 Feb 2007 09:52:58 -0800
Subject: [ python-Bugs-1651235 ] ctypes.Structure formal parameter dies given
	tuple
Message-ID: <E1HDP4M-0000OW-IV@sc8-sf-web11.sourceforge.net>

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

Please note that this 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: Gary Bishop (tgbishop)
>Assigned to: Thomas Heller (theller)
Summary: ctypes.Structure formal parameter dies given tuple

Initial Comment:
With a structure like:

class CvRect(ctypes.Structure):
    _fields_ = [("x", ctypes.c_int),
                ("y", ctypes.c_int),
                ("width", ctypes.c_int),
                ("height", ctypes.c_int)]

and a foreign function like:

cvSetImageROI = _cxDLL.cvSetImageROI
cvSetImageROI.restype = None # void
cvSetImageROI.argtypes = [
    ctypes.c_void_p, # IplImage* image
    CvRect # CvRect rect
    ]

The call

cvSetImageROI(img, CvRect(1,2,3,4))

works fine but the mistaken call:

cvSetImageROI(img, (1,2,3,4))

Produces the "Send Error Report" dialog from Windows.

Other erroneous arguments produce a message about correct argument type but the tuple triggers some other behavior.


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

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

From noreply at sourceforge.net  Sat Feb  3 22:18:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 03 Feb 2007 13:18:36 -0800
Subject: [ python-Bugs-1651427 ] readline needs termcap on my FC6
Message-ID: <E1HDSHM-0005pC-4S@sc8-sf-web6.sourceforge.net>

Bugs item #1651427, was opened at 2007-02-03 22: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=1651427&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: guichaz (guichaz)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline needs termcap on my FC6

Initial Comment:
Compiling python-2.5 and trunk (r53624) on my Fedora Core 6 i386 works but does not use GNU readline because of the following excerpt from config.log:

configure:21255: gcc -pthread -o conftest -O2 -march=i386 -mtune=pentium-m -fomit-frame-pointer   conftest.c -lreadline  -lpthread -l
dl  -lutil >&5
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `PC'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetflag'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetent'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `UP'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tputs'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgoto'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetnum'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `BC'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status

This seems related to http://mail.python.org/pipermail/python-checkins/2006-January/048725.html

python-2.4.4 works fine, but it does not contain the aforementionned commit.

Thanks.


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

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

From noreply at sourceforge.net  Sat Feb  3 22:31:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 03 Feb 2007 13:31:17 -0800
Subject: [ python-Bugs-1651427 ] readline needs termcap on my FC6
Message-ID: <E1HDSTd-0000kM-JS@sc8-sf-web5.sourceforge.net>

Bugs item #1651427, was opened at 2007-02-03 22:18
Message generated for change (Comment added) made by guichaz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1651427&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: guichaz (guichaz)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline needs termcap on my FC6

Initial Comment:
Compiling python-2.5 and trunk (r53624) on my Fedora Core 6 i386 works but does not use GNU readline because of the following excerpt from config.log:

configure:21255: gcc -pthread -o conftest -O2 -march=i386 -mtune=pentium-m -fomit-frame-pointer   conftest.c -lreadline  -lpthread -l
dl  -lutil >&5
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `PC'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetflag'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetent'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `UP'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tputs'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgoto'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetnum'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `BC'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status

This seems related to http://mail.python.org/pipermail/python-checkins/2006-January/048725.html

python-2.4.4 works fine, but it does not contain the aforementionned commit.

Thanks.


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

>Comment By: guichaz (guichaz)
Date: 2007-02-03 22:31

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

And if you wonder why I complain about not using GNU readline, here is a
simple test case:

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

import readline
import signal
from threading import Thread

Thread(target=lambda: raw_input('Press Control-C now')).start()
signal.pause()

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

With GNU readline, Ctrl-C would wake up the pause() and I would resort to
dirty tricks to wake up the raw_input (dup2), but that's another story ;-)

With Python >= 2.5, Ctrl-C would segfault or in a debug build abort with:
Fatal Python error: Invalid thread state for this thread

and here is the corresponding stack trace:

Program terminated with signal 6, Aborted.
#0  0xb7f13410 in ?? ()
(gdb) bt
#0  0xb7f13410 in ?? ()
#1  0xb7c2daec in ?? ()
#2  0x00000006 in ?? ()
#3  0x000003b3 in ?? ()
#4  0x48f68d40 in raise () from /lib/libc.so.6
#5  0x48f6a591 in abort () from /lib/libc.so.6
#6  0x08111000 in Py_FatalError (msg=0x81720d4 "Invalid thread state for
this thread") at Python/pythonrun.c:1562
#7  0x0810d142 in PyThreadState_Swap (newts=0x8219438) at
Python/pystate.c:318
#8  0x080dbbb4 in PyEval_RestoreThread (tstate=0x8219438) at
Python/ceval.c:316
#9  0x08139180 in PyOS_Readline (sys_stdin=0x49079420,
sys_stdout=0x490794c0, prompt=0xb7e9eb3c "Press Control-C now")
    at Parser/myreadline.c:210
#10 0x080d8dbc in builtin_raw_input (self=0x0, args=0xb7eafc74) at
Python/bltinmodule.c:1747
#11 0x0814643e in PyCFunction_Call (func=0xb7ec6574, arg=0xb7eafc74,
kw=0x0) at Objects/methodobject.c:73
#12 0x080e89ab in call_function (pp_stack=0xb7c2e234, oparg=1) at
Python/ceval.c:3567
#13 0x080e4234 in PyEval_EvalFrameEx (f=0x821c0dc, throwflag=0) at
Python/ceval.c:2279
#14 0x080e66cf in PyEval_EvalCodeEx (co=0xb7ef16e8, globals=0xb7edf174,
locals=0x0, args=0xb7eb7048, argcount=0, kws=0xb7c46028, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2843
#15 0x08145b7d in function_call (func=0xb7ea8354, arg=0xb7eb7034,
kw=0xb7eb03f4) at Objects/funcobject.c:517
#16 0x0805ff90 in PyObject_Call (func=0xb7ea8354, arg=0xb7eb7034,
kw=0xb7eb03f4) at Objects/abstract.c:1858
#17 0x080e97e9 in ext_do_call (func=0xb7ea8354, pp_stack=0xb7c2e900,
flags=3, na=0, nk=0) at Python/ceval.c:3847
#18 0x080e446e in PyEval_EvalFrameEx (f=0x821b9e4, throwflag=0) at
Python/ceval.c:2319
#19 0x080e8de6 in fast_function (func=0xb7c42bc4, pp_stack=0xb7c2ef04,
n=1, na=1, nk=0) at Python/ceval.c:3653
#20 0x080e8b41 in call_function (pp_stack=0xb7c2ef04, oparg=0) at
Python/ceval.c:3588
#21 0x080e4234 in PyEval_EvalFrameEx (f=0x8215dec, throwflag=0) at
Python/ceval.c:2279
#22 0x080e66cf in PyEval_EvalCodeEx (co=0xb7c33748, globals=0xb7ea6ad4,
locals=0x0, args=0xb7eaf240, argcount=1, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2843
#23 0x08145b7d in function_call (func=0xb7c42c14, arg=0xb7eaf22c, kw=0x0)
at Objects/funcobject.c:517
#24 0x0805ff90 in PyObject_Call (func=0xb7c42c14, arg=0xb7eaf22c, kw=0x0)
at Objects/abstract.c:1858
#25 0x08069416 in instancemethod_call (func=0xb7c42c14, arg=0xb7eaf22c,
kw=0x0) at Objects/classobject.c:2497
#26 0x0805ff90 in PyObject_Call (func=0xb7e8b2b4, arg=0xb7eb7034, kw=0x0)
at Objects/abstract.c:1858
#27 0x080e81bb in PyEval_CallObjectWithKeywords (func=0xb7e8b2b4,
arg=0xb7eb7034, kw=0x0) at Python/ceval.c:3436
#28 0x0811e8f1 in t_bootstrap (boot_raw=0xb7ebf3e8) at
./Modules/threadmodule.c:424
#29 0x490b33db in start_thread () from /lib/libpthread.so.0
#30 0x4900d26e in clone () from /lib/libc.so.6

So maybe there is more than the readline build requirement to fix ;-)

Thanks.


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

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

From noreply at sourceforge.net  Sun Feb  4 15:11:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 04 Feb 2007 06:11:11 -0800
Subject: [ python-Bugs-1646068 ] Dict lookups fail if sizeof(Py_ssize_t) <
	sizeof(long)
Message-ID: <E1HDi5H-0004ZV-T9@sc8-sf-web7.sourceforge.net>

Bugs item #1646068, was opened at 2007-01-27 18:23
Message generated for change (Comment added) made by ked-tao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646068&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: ked-tao (ked-tao)
Assigned to: Tim Peters (tim_one)
Summary: Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long)

Initial Comment:
Portation problem.

Include/dictobject.h defines PyDictEntry.me_hash as a Py_ssize_t. Everywhere else uses a C 'long' for hashes.

On the system I'm porting to, ints and pointers (and ssize_t) are 32-bit, but longs and long longs are 64-bit. Therefore, the assignments to me_hash truncate the hash and subsequent lookups fail.

I've changed the definition of me_hash to 'long' and (in Objects/dictobject.c) removed the casting from the various assignments and changed the definition of 'i' in dict_popitem(). This has fixed my immediate problems, but I guess I've just reintroduced whatever problem it got changed for. The comment in the header says:

/* Cached hash code of me_key.  Note that hash codes are C longs.
 * We have to use Py_ssize_t instead because dict_popitem() abuses
 * me_hash to hold a search finger.
 */

... but that doesn't really explain what it is about dict_popitem() that requires the different type.

Thanks. Kev.

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

>Comment By: ked-tao (ked-tao)
Date: 2007-02-04 14:11

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

Hi Jim. I understand what the problem is (perhaps I didn't state it
clearly enough) - me_hash is a cache of the dict item's hash which is
compared against the hash of the object being looked up before going any
further with expensive richer comparisons. On my system, me_hash is a
32-bit quantity but hashes in general are declared 'long' which is a
64-bit quantity. Therefore for any object whose hash has any of the top 32
bits set, a dict lookup will fail as it will never get past that first
check (regardless of why that slot is being checked - it has nothing to do
with the perturbation to find the next slot).

The deal is that my system is basically a 32-bit system (sizeof(int) ==
sizeof(void *) == 4, and therefore ssize_t is not unreasonably also
32-bit), but C longs are 64-bit.

You say "popitem assumes it can store a pointer there", but AFAICS it's
just storing an _index_, not a pointer. I was concerned that making that
index a 64-bit quantity might tickle some subtlety in the code, thinking
that perhaps it was changed from 'long' to 'Py_ssize_t' because it had to
be 32-bit for some reason. However, it seems much more likely that it was
defined like that to be more correct on a system with 64-bit addressing
and 32-bit longs (which would be more common). With that in mind, I've
attached a suggested patch which selects a reasonable type according to
the SIZEOF_ configuration defines.

WRT forcing the hashes 32-bit to "save space and time" - that means
inventing a 'Py_hash_t' type and going through the entire python source
looking for 'long's that might be used to store/calculate hashes. I think
I'll pass on that ;)

Regards, Kev.
File Added: dict.diff

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-02-02 20:20

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

The whole point of a hash is that if it doesn't match, you can skip an
expensive comparison.  How big to make the hash is a tradeoff between how
much you'll waste calculating and storing it vs how often it will save a
"real" comparison.

The comment means that, as an implementation detail, popitem assumes it
can store a pointer there instead, so hashes need to be at least as big as
a pointer.  

Going to the larger of the two sizes will certainly solve your problem; it
just wastes some space, and maybe some time calculating the hash.  

If you want to get that space back, just make sure the truncation is
correct and consistent.  I *suspect* your problem is that when there is a
collision, either 

(1)  It is comparing a truncated value to an untruncated value, or
(2)  The perturbation to find the next slot is going wrong, because of
when the truncation happens.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-27 19:40

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

This is your code, Tim.

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

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

From noreply at sourceforge.net  Sun Feb  4 17:35:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 04 Feb 2007 08:35:56 -0800
Subject: [ python-Bugs-1646068 ] Dict lookups fail if sizeof(Py_ssize_t) <
	sizeof(long)
Message-ID: <E1HDkLM-0001Qa-9D@sc8-sf-web11.sourceforge.net>

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

Please note that this 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: 6
Private: No
Submitted By: ked-tao (ked-tao)
Assigned to: Tim Peters (tim_one)
Summary: Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long)

Initial Comment:
Portation problem.

Include/dictobject.h defines PyDictEntry.me_hash as a Py_ssize_t. Everywhere else uses a C 'long' for hashes.

On the system I'm porting to, ints and pointers (and ssize_t) are 32-bit, but longs and long longs are 64-bit. Therefore, the assignments to me_hash truncate the hash and subsequent lookups fail.

I've changed the definition of me_hash to 'long' and (in Objects/dictobject.c) removed the casting from the various assignments and changed the definition of 'i' in dict_popitem(). This has fixed my immediate problems, but I guess I've just reintroduced whatever problem it got changed for. The comment in the header says:

/* Cached hash code of me_key.  Note that hash codes are C longs.
 * We have to use Py_ssize_t instead because dict_popitem() abuses
 * me_hash to hold a search finger.
 */

... but that doesn't really explain what it is about dict_popitem() that requires the different type.

Thanks. Kev.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-02-04 11:35

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

Yes, I'm curious about what system this is ... is it a characteristic of
the whole system, or a compiler choice to get longer ints?

As to using a Py_hash_t -- it probably wouldn't be as bad as you think. 
You might get away with just masking it to throw away the high order bits
in dict and set.  (That might not work with perturbation.)  

Even if you have to change it everywhere at the source, then there is some
prior art (from when hash was allowed to be a python long), and it is
almost certainly limited to methods with "hash" in the name which generate
a hash.  (eq/ne on the same objects may use the hash.)  Consumers of hash
really are limited to dict and derivatives.  I think dict, set, and
defaultdict may be the full list for the default distribution.


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

Comment By: ked-tao (ked-tao)
Date: 2007-02-04 09:11

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

Hi Jim. I understand what the problem is (perhaps I didn't state it
clearly enough) - me_hash is a cache of the dict item's hash which is
compared against the hash of the object being looked up before going any
further with expensive richer comparisons. On my system, me_hash is a
32-bit quantity but hashes in general are declared 'long' which is a 64-bit
quantity. Therefore for any object whose hash has any of the top 32 bits
set, a dict lookup will fail as it will never get past that first check
(regardless of why that slot is being checked - it has nothing to do with
the perturbation to find the next slot).

The deal is that my system is basically a 32-bit system (sizeof(int) ==
sizeof(void *) == 4, and therefore ssize_t is not unreasonably also
32-bit), but C longs are 64-bit.

You say "popitem assumes it can store a pointer there", but AFAICS it's
just storing an _index_, not a pointer. I was concerned that making that
index a 64-bit quantity might tickle some subtlety in the code, thinking
that perhaps it was changed from 'long' to 'Py_ssize_t' because it had to
be 32-bit for some reason. However, it seems much more likely that it was
defined like that to be more correct on a system with 64-bit addressing and
32-bit longs (which would be more common). With that in mind, I've attached
a suggested patch which selects a reasonable type according to the SIZEOF_
configuration defines.

WRT forcing the hashes 32-bit to "save space and time" - that means
inventing a 'Py_hash_t' type and going through the entire python source
looking for 'long's that might be used to store/calculate hashes. I think
I'll pass on that ;)

Regards, Kev.
File Added: dict.diff

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-02-02 15:20

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

The whole point of a hash is that if it doesn't match, you can skip an
expensive comparison.  How big to make the hash is a tradeoff between how
much you'll waste calculating and storing it vs how often it will save a
"real" comparison.

The comment means that, as an implementation detail, popitem assumes it
can store a pointer there instead, so hashes need to be at least as big as
a pointer.  

Going to the larger of the two sizes will certainly solve your problem; it
just wastes some space, and maybe some time calculating the hash.  

If you want to get that space back, just make sure the truncation is
correct and consistent.  I *suspect* your problem is that when there is a
collision, either 

(1)  It is comparing a truncated value to an untruncated value, or
(2)  The perturbation to find the next slot is going wrong, because of
when the truncation happens.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-27 14:40

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

This is your code, Tim.

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

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

From noreply at sourceforge.net  Sun Feb  4 23:34:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 04 Feb 2007 14:34:48 -0800
Subject: [ python-Bugs-1651995 ] sgmllib _convert_ref UnicodeDecodeError
	exception, new in 2.
Message-ID: <E1HDpwe-0001aP-Av@sc8-sf-web8.sourceforge.net>

Bugs item #1651995, was opened at 2007-02-04 22: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=1651995&group_id=5470

Please note that this 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: sgmllib _convert_ref UnicodeDecodeError exception, new in 2.

Initial Comment:
   I'm running a website page through BeautifulSoup.  It parses OK with Python 2.4, but Python 2.5 fails with an exception:

Traceback (most recent call last):
  File "./sitetruth/InfoSitePage.py", line 268, in httpfetch
    self.pagetree = BeautifulSoup.BeautifulSoup(sitetext) # parse into tree form
  File "./sitetruth/BeautifulSoup.py", line 1326, in __init__
    BeautifulStoneSoup.__init__(self, *args, **kwargs)
  File "./sitetruth/BeautifulSoup.py", line 973, in __init__
    self._feed()
  File "./sitetruth/BeautifulSoup.py", line 998, in _feed
    SGMLParser.feed(self, markup or "")
  File "/usr/lib/python2.5/sgmllib.py", line 99, in feed
    self.goahead(0)
  File "/usr/lib/python2.5/sgmllib.py", line 133, in goahead
    k = self.parse_starttag(i)
  File "/usr/lib/python2.5/sgmllib.py", line 291, in parse_starttag
    self.finish_starttag(tag, attrs)
  File "/usr/lib/python2.5/sgmllib.py", line 340, in finish_starttag
    self.handle_starttag(tag, method, attrs)
  File "/usr/lib/python2.5/sgmllib.py", line 376, in handle_starttag
    method(attrs)
  File "./sitetruth/BeautifulSoup.py", line 1416, in start_meta
    self._feed(self.declaredHTMLEncoding)
  File "./sitetruth/BeautifulSoup.py", line 998, in _feed
    SGMLParser.feed(self, markup or "")
  File "/usr/lib/python2.5/sgmllib.py", line 99, in feed
    self.goahead(0)
  File "/usr/lib/python2.5/sgmllib.py", line 133, in goahead
    k = self.parse_starttag(i)
  File "/usr/lib/python2.5/sgmllib.py", line 285, in parse_starttag
    self._convert_ref, attrvalue)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa7 in position 0: ordinal not in range(128)

    The code that's failing is in "_convert_ref", which is new in Python 2.5. That function wasn't present in 2.4.  I think the code is trying to handle single quotes inside of double quotes in HTML attributes, or something like that.

    To replicate, run

	http://www.bankofamerica.com
or
	http://www.gm.com

through BeautifulSoup.  

Something about this code doesn't like big companies. Web sites of smaller companies are going through OK.

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

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

From noreply at sourceforge.net  Mon Feb  5 07:18:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 04 Feb 2007 22:18:22 -0800
Subject: [ python-Bugs-1562193 ] IDLE Hung up after open script by command
	line...
Message-ID: <E1HDxBG-0005s8-AF@sc8-sf-web5.sourceforge.net>

Bugs item #1562193, was opened at 2006-09-20 09:10
Message generated for change (Comment added) made by kbk
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: Pending
>Resolution: Invalid
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

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2007-02-05 01:18

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

Well, Tal Einat has more patience than I do, and it sounds like he
diagnosed your problem.  I'm setting this pending, it will close in a
couple of weeks if you don't respond with further comments.

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

Comment By: Tal Einat (taleinat)
Date: 2006-12-09 12:54

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

Well, the issue obviously only happens when IDLE is running without a
subprocess.

The code you pasted is unindtented so I'm not going to try it out...

My guess would be that your server is blocking in a way that it blocks all
threads. This is why, when it is run in the same process as IDLE's GUI,
IDLE hangs. However, when you run IDLE with a subprocess, it's the
subprocess which is blocked, so IDLE works normally. (this is what the
subprocess is there for :)

In any case, IDLE is behaving just fine here. This isn't a bug in IDLE.


This could be a bug with the thread module, or a bug in BaseHTTPServer, or
several other places. But it is most likely caused by some misunderstanding
on your part of blocking operations, threads, and the interaction between
them.

You should have tried posting this on c.l.py before posting a bug on SF,
and I suggest you do so now.

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

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

From noreply at sourceforge.net  Mon Feb  5 08:16:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 04 Feb 2007 23:16:58 -0800
Subject: [ python-Bugs-1651995 ] sgmllib _convert_ref UnicodeDecodeError
	exception, new in 2.
Message-ID: <E1HDy5y-0000Xf-TP@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: sgmllib _convert_ref UnicodeDecodeError exception, new in 2.

Initial Comment:
   I'm running a website page through BeautifulSoup.  It parses OK with Python 2.4, but Python 2.5 fails with an exception:

Traceback (most recent call last):
  File "./sitetruth/InfoSitePage.py", line 268, in httpfetch
    self.pagetree = BeautifulSoup.BeautifulSoup(sitetext) # parse into tree form
  File "./sitetruth/BeautifulSoup.py", line 1326, in __init__
    BeautifulStoneSoup.__init__(self, *args, **kwargs)
  File "./sitetruth/BeautifulSoup.py", line 973, in __init__
    self._feed()
  File "./sitetruth/BeautifulSoup.py", line 998, in _feed
    SGMLParser.feed(self, markup or "")
  File "/usr/lib/python2.5/sgmllib.py", line 99, in feed
    self.goahead(0)
  File "/usr/lib/python2.5/sgmllib.py", line 133, in goahead
    k = self.parse_starttag(i)
  File "/usr/lib/python2.5/sgmllib.py", line 291, in parse_starttag
    self.finish_starttag(tag, attrs)
  File "/usr/lib/python2.5/sgmllib.py", line 340, in finish_starttag
    self.handle_starttag(tag, method, attrs)
  File "/usr/lib/python2.5/sgmllib.py", line 376, in handle_starttag
    method(attrs)
  File "./sitetruth/BeautifulSoup.py", line 1416, in start_meta
    self._feed(self.declaredHTMLEncoding)
  File "./sitetruth/BeautifulSoup.py", line 998, in _feed
    SGMLParser.feed(self, markup or "")
  File "/usr/lib/python2.5/sgmllib.py", line 99, in feed
    self.goahead(0)
  File "/usr/lib/python2.5/sgmllib.py", line 133, in goahead
    k = self.parse_starttag(i)
  File "/usr/lib/python2.5/sgmllib.py", line 285, in parse_starttag
    self._convert_ref, attrvalue)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa7 in position 0: ordinal not in range(128)

    The code that's failing is in "_convert_ref", which is new in Python 2.5. That function wasn't present in 2.4.  I think the code is trying to handle single quotes inside of double quotes in HTML attributes, or something like that.

    To replicate, run

	http://www.bankofamerica.com
or
	http://www.gm.com

through BeautifulSoup.  

Something about this code doesn't like big companies. Web sites of smaller companies are going through OK.

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

Comment By: wrstl prmpft (wrstlprmpft)
Date: 2007-02-05 08:16

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

I had a similar problem recently and did not have time to file a
bug-report. Thanks for doing that.

The problem is the code that handles entity and character references in
SGMLParser.parse_starttag. Seems that it is not careful about unicode/str
issues.
(But maybe Beautifulsoup needs to tell it to?)

My quick'n'dirty workaround was to remove the offending char-entity from
the website before feeding it to Beautifulsoup::

  text = text.replace('&#174;', '') # remove rights reserved sign entity

cheers,
stefan


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

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

From noreply at sourceforge.net  Mon Feb  5 09:11:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 00:11:12 -0800
Subject: [ python-Bugs-1648960 ] HP-UX11.23: module zlib missing
Message-ID: <E1HDywS-00051l-Fo@sc8-sf-web6.sourceforge.net>

Bugs item #1648960, was opened at 2007-01-31 16:13
Message generated for change (Settings changed) made by jabt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648960&group_id=5470

Please note that this 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: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: Johannes Abt (jabt)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP-UX11.23: module zlib missing

Initial Comment:
The build processes does not build module zlib, so 
zipimport does not work, either.

/usr/local/lib/hpux32/libz.so exists.

configure tells me:
checking for inflateCopy in -lz... yes


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

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

From noreply at sourceforge.net  Mon Feb  5 12:13:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 03:13:23 -0800
Subject: [ python-Bugs-1562193 ] IDLE Hung up after open script by command
	line...
Message-ID: <E1HE1ml-0005Vw-A3@sc8-sf-web2.sourceforge.net>

Bugs item #1562193, was opened at 2006-09-20 13:10
Message generated for change (Comment added) made by faramir2
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: Invalid
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

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

>Comment By: Marek Nowicki (faramir2)
Date: 2007-02-05 11:13

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

Ok. You can close this now. Thanks for responses.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2007-02-05 06:18

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

Well, Tal Einat has more patience than I do, and it sounds like he
diagnosed your problem.  I'm setting this pending, it will close in a
couple of weeks if you don't respond with further comments.

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

Comment By: Tal Einat (taleinat)
Date: 2006-12-09 17:54

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

Well, the issue obviously only happens when IDLE is running without a
subprocess.

The code you pasted is unindtented so I'm not going to try it out...

My guess would be that your server is blocking in a way that it blocks all
threads. This is why, when it is run in the same process as IDLE's GUI,
IDLE hangs. However, when you run IDLE with a subprocess, it's the
subprocess which is blocked, so IDLE works normally. (this is what the
subprocess is there for :)

In any case, IDLE is behaving just fine here. This isn't a bug in IDLE.


This could be a bug with the thread module, or a bug in BaseHTTPServer, or
several other places. But it is most likely caused by some misunderstanding
on your part of blocking operations, threads, and the interaction between
them.

You should have tried posting this on c.l.py before posting a bug on SF,
and I suggest you do so now.

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

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

From noreply at sourceforge.net  Mon Feb  5 14:35:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 05:35:21 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HE409-0002RT-8m@sc8-sf-web2.sourceforge.net>

Bugs item #1652387, was opened at 2007-02-05 13: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=1652387&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

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

From noreply at sourceforge.net  Mon Feb  5 18:40:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 09:40:50 -0800
Subject: [ python-Bugs-1479785 ] Quitter object masked
Message-ID: <E1HE7pi-0000bF-1K@sc8-sf-web7.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Quitter object masked

Initial Comment:
2.5 introduces a Quitter object (defined in site.py) 
to make the quit/exit message more friendly.

Lines 480-482 of PyShell.py override this, so that 
users of Idle never see the improved feature.

Unfortunately, simply removing those lines isn't quite 
enough to solve the problem, as IDLE catches 
SystemExit exceptions.  Getting around that, I didn't 
have time to track down yet.




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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2007-02-05 12:40

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

I don't see how to easily eliminate the dialog.  When quit() runs,
Quitter.__call__() closes IDLE's sys.stdin, and (since __call__() is still
executing) that's trapped by PyShell.py using the logic which requires the
user to confirm exit if he clicks on the Shell's close widget
(WM_DELETE_WINDOW) while his code is running.  If File.close() had a
parameter, we might be able to do something about this.

The extra confirmation probably doesn't hurt.  Aficionados will use Ctrl-D
etc. anyway.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-08-28 12:43

Message:
Logged In: YES 
user_id=580910

When I type quit() in the Python Shell window I get a dialog that says:

> The program is still running!
> Do you want to kill it?

(Python 2.5c1)

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-08-16 01:03

Message:
Logged In: YES 
user_id=149084

Rev 51306: Patch #1540892

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

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

From noreply at sourceforge.net  Mon Feb  5 19:31:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 10:31:27 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HE8ch-00023N-7O@sc8-sf-web8.sourceforge.net>

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

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 18:31

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

Sadly you didn't attach the definition of the class "MyObj".

I assume it is like this:

class MyObj:
    Lines = []

In this case, the Lines list object is shared by all instances of MyObj.
Please post to the python-list mailing list for further questions about
this behavior.

If your bug is different, please feel free to reopen this.

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

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

From noreply at sourceforge.net  Mon Feb  5 21:34:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 12:34:48 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HEAY4-0004gg-L4@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

>Comment By: kkelchev (kkelchev)
Date: 2007-02-05 20:34

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

Sorry :(
I forgot to paste definision of Class MyObj
yes it is:

class MyObj:
    Lines = []
--------------------------------------
is this a bug ? 
Or always in Python data in nested object are shared between all objects
from same class

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 18:31

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

Sadly you didn't attach the definition of the class "MyObj".

I assume it is like this:

class MyObj:
    Lines = []

In this case, the Lines list object is shared by all instances of MyObj.
Please post to the python-list mailing list for further questions about
this behavior.

If your bug is different, please feel free to reopen this.

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

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

From noreply at sourceforge.net  Mon Feb  5 21:35:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 12:35:55 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HEAZ9-0004mk-Vv@sc8-sf-web5.sourceforge.net>

Bugs item #1652387, was opened at 2007-02-05 13:35
Message generated for change (Settings changed) made by kkelchev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652387&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

Comment By: kkelchev (kkelchev)
Date: 2007-02-05 20:34

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

Sorry :(
I forgot to paste definision of Class MyObj
yes it is:

class MyObj:
    Lines = []
--------------------------------------
is this a bug ? 
Or always in Python data in nested object are shared between all objects
from same class

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 18:31

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

Sadly you didn't attach the definition of the class "MyObj".

I assume it is like this:

class MyObj:
    Lines = []

In this case, the Lines list object is shared by all instances of MyObj.
Please post to the python-list mailing list for further questions about
this behavior.

If your bug is different, please feel free to reopen this.

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

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

From noreply at sourceforge.net  Mon Feb  5 21:37:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 12:37:05 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HEAaH-0004tq-KR@sc8-sf-web5.sourceforge.net>

Bugs item #1652387, was opened at 2007-02-05 13:35
Message generated for change (Settings changed) made by kkelchev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652387&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

Comment By: kkelchev (kkelchev)
Date: 2007-02-05 20:34

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

Sorry :(
I forgot to paste definision of Class MyObj
yes it is:

class MyObj:
    Lines = []
--------------------------------------
is this a bug ? 
Or always in Python data in nested object are shared between all objects
from same class

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 18:31

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

Sadly you didn't attach the definition of the class "MyObj".

I assume it is like this:

class MyObj:
    Lines = []

In this case, the Lines list object is shared by all instances of MyObj.
Please post to the python-list mailing list for further questions about
this behavior.

If your bug is different, please feel free to reopen this.

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

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

From noreply at sourceforge.net  Mon Feb  5 21:37:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 12:37:39 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HEAap-0004yV-9z@sc8-sf-web5.sourceforge.net>

Bugs item #1652387, was opened at 2007-02-05 13:35
Message generated for change (Settings changed) made by kkelchev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652387&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

Comment By: kkelchev (kkelchev)
Date: 2007-02-05 20:34

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

Sorry :(
I forgot to paste definision of Class MyObj
yes it is:

class MyObj:
    Lines = []
--------------------------------------
is this a bug ? 
Or always in Python data in nested object are shared between all objects
from same class

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 18:31

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

Sadly you didn't attach the definition of the class "MyObj".

I assume it is like this:

class MyObj:
    Lines = []

In this case, the Lines list object is shared by all instances of MyObj.
Please post to the python-list mailing list for further questions about
this behavior.

If your bug is different, please feel free to reopen this.

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

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

From noreply at sourceforge.net  Mon Feb  5 21:54:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 12:54:49 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HEArR-00038B-82@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 20:54

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

Yes, this is exactly what I had written in my previous answer.

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

Comment By: kkelchev (kkelchev)
Date: 2007-02-05 20:34

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

Sorry :(
I forgot to paste definision of Class MyObj
yes it is:

class MyObj:
    Lines = []
--------------------------------------
is this a bug ? 
Or always in Python data in nested object are shared between all objects
from same class

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 18:31

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

Sadly you didn't attach the definition of the class "MyObj".

I assume it is like this:

class MyObj:
    Lines = []

In this case, the Lines list object is shared by all instances of MyObj.
Please post to the python-list mailing list for further questions about
this behavior.

If your bug is different, please feel free to reopen this.

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

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

From noreply at sourceforge.net  Mon Feb  5 22:55:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 13:55:01 -0800
Subject: [ python-Feature Requests-500698 ] Taint a la Perl?
Message-ID: <E1HEBnh-0000UE-Br@sc8-sf-web6.sourceforge.net>

Feature Requests item #500698, was opened at 2002-01-08 03:48
Message generated for change (Comment added) made by jcrocholl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=500698&group_id=5470

Please note that this 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: 5
Private: No
Submitted By: Peter Scott (sketerpot)
Assigned to: Nobody/Anonymous (nobody)
Summary: Taint a la Perl?

Initial Comment:
This might just add unnecessary bloat, but since Python is being 
used in CGI scripts, it can be used to narrow a security hole. One way 
of breaking security is for a naiive programmer (don't try to deny 
their existance) to run an arbitrary command from the page 
viewer.

Perl has developed an interesting mechanism for 
helping with this: taint. The way it works is, when something comes 
directly from the user, like a key in a form, it is considered to have 
taint unless specifically untainted. Things like os.exec() would 
create a warning message if you passed tainted strings to 
them.

As I said, this might just add unnecessary bloat, but for 
an option that can be left out for most builds of Python I think it 
would be pretty nice.

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

Comment By: Johann C. Rocholl (jcrocholl)
Date: 2007-02-05 22:55

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

I have come up with a class called SafeString which is the opposite of a
tainted string. In my model, all strings are tainted by default, and you
have to call untaint() to create a SafeString. Then I replace all functions
in the os module with wrapper functions that check all parameters first and
raise TaintError if any string is not safe. If I can figure out how to
attach a file here, I will post it. Otherwise you may find it on
comp.lang.python by the name of taint.py.

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

Comment By: Peter Scott (sketerpot)
Date: 2003-02-14 18:21

Message:
Logged In: YES 
user_id=252564

Thanks for the idea, phr. I wrote a small class called 
TaintString, derived from string, that has a taint attribute. This 
is probably the least difficult part. The difficult part will be in 
modifying functions like os.system() to raise warnings or 
exceptions when tainted strings are passed to them. I'm 
currently thinking of making wrapper modules with names like 
taint.os, or taint.cgi, but the problem with this is that you 
have to manually use taint.* for certain functions. If anybody 
can think of something that can simplify this, please post it.

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

Comment By: paul rubin (phr)
Date: 2003-02-14 05:47

Message:
Logged In: YES 
user_id=72053

With new-style classes, maybe this can be done by
subclassing string somehow.  There would be a subclass for
tainted strings and trying to do most things with them would
raise an exception.  With taint checking enabled, functions
like os.getenv and cgi.FieldStorage would make objects
containing tainted strings.  You'd untaint them by passing
them to re.search or re.match and pulling out the match
variables, like in Per.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-03 02:25

Message:
Logged In: YES 
user_id=44345

Took awhile for a response to this feature request. ;-)

Perl's heavy integration of regular expressions with its
taint facility probably wouldn't work all that well in
Python.  For one, Python has more ways of searching
strings than with regular expressions.  Second, regular
expressions are not nearly as tightly wound into Python
as they are in Perl.  I think you'd have to add a taint
attribute to strings and just rely on the programmer to
properly clear that attribute.

I think a first cut at an implementation would go much
further toward getting the concept seriously considered
for addition to Python.


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

Comment By: Neal McBurnett (nealmcb)
Date: 2003-01-02 22:20

Message:
Logged In: YES 
user_id=105956

I really like taint mode.
I think this would make Python a better choice for CGI scripts.

See http://www.perldoc.com/perl5.8.0/pod/perlsec.html
and http://gunther.web66.com/FAQS/taintmode.html
for more background.


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

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

From noreply at sourceforge.net  Tue Feb  6 00:03:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 15:03:14 -0800
Subject: [ python-Bugs-791968 ] Arguments tooltip wrong if def contains tuple
Message-ID: <E1HECri-0007O7-KR@sc8-sf-monitor2.sourceforge.net>

Bugs item #791968, was opened at 2003-08-20 11:16
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470

Please note that this 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: 5
Private: No
Submitted By: Christos Georgiou (tzot)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Arguments tooltip wrong if def contains tuple

Initial Comment:
This happens in IDLE on Windows 2000, from 2.3 EXE 
installer.  Type the following:

&gt;&gt;&gt; def f((a,b), c):
	print a, b, c

&gt;&gt;&gt; f(

The tooltip shows up containing the following exact 
string (but the triple quotes):
&quot;&quot;&quot;(.0, c)&quot;&quot;&quot;


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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2007-02-05 18:03

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

Used your idea of displaying "<tuple>'

Rev 53641

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 17:56

Message:
Logged In: YES 
user_id=149084

Problem still exists in 2.5 as of Rev 50739.

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

Comment By: Christos Georgiou (tzot)
Date: 2003-08-20 12:02

Message:
Logged In: YES 
user_id=539787

I tried this:

def f((a,b), c, (d,e)): pass

and f.func_code.co_varnames is

('.0', 'c', '.4', 'a', 'b', 'd', 'e')

That means .0 and .4 are dummy placeholders for the 
argument tuples.  I couldn't find a direct way to know the 
length of each tuple, though --unless one analyzes the first 
UNPACK_SEQUENCE bytecodes of fob.func_code.co_code, 
and then uses the tuple fob.func_code.co_varnames
[fob.func_code.co_argcount:] to recreate the tuples; should 
we get into this trouble, or just do a regular expression 
replace a la:

argText = &quot;(%s)&quot; % re.sub(&quot;\.\d+&quot;,
&quot;&lt;tuple&gt;&quot;, argText)

at line 144?

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

Comment By: Christos Georgiou (tzot)
Date: 2003-08-20 11:44

Message:
Logged In: YES 
user_id=539787

Quite fast, Neal! :)
It seems it's not exactly an IDLE bug; check ToolTip.py, line 
134 (vanilla 2.3); it's the f.func_code.co_varnames that 
returns this tuple:
('.0', 'c', 'a', 'b')

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

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

From noreply at sourceforge.net  Tue Feb  6 00:42:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 15:42:31 -0800
Subject: [ python-Bugs-1652788 ] logging formatter %(lineno)d does not work
Message-ID: <E1HEDTj-0001Ry-17@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: lx_jakal (alex_petry)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging formatter %(lineno)d does not work

Initial Comment:
The current line number produced by the module is "1072" which is static over all logging calls. It refers to a the denoted line in logging/__init__.py

A possible patch is attached.


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

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

From noreply at sourceforge.net  Tue Feb  6 02:07:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 17:07:55 -0800
Subject: [ python-Bugs-1652788 ] logging formatter %(lineno)d does not work
Message-ID: <E1HEEoN-00029y-FJ@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: lx_jakal (alex_petry)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging formatter %(lineno)d does not work

Initial Comment:
The current line number produced by the module is "1072" which is static over all logging calls. It refers to a the denoted line in logging/__init__.py

A possible patch is attached.


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

>Comment By: lx_jakal (alex_petry)
Date: 2007-02-06 02:07

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

File Added: python-logging-2.5-fixed.patch

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

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

From noreply at sourceforge.net  Tue Feb  6 04:23:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 19:23:32 -0800
Subject: [ python-Bugs-1562193 ] IDLE Hung up after open script by command
	line...
Message-ID: <E1HEGvc-0007nl-Sb@sc8-sf-web1.sourceforge.net>

Bugs item #1562193, was opened at 2006-09-20 09:10
Message generated for change (Comment added) made by kbk
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: Closed
Resolution: Invalid
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

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2007-02-05 22:23

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

OK, thanks.

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

Comment By: Marek Nowicki (faramir2)
Date: 2007-02-05 06:13

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

Ok. You can close this now. Thanks for responses.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2007-02-05 01:18

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

Well, Tal Einat has more patience than I do, and it sounds like he
diagnosed your problem.  I'm setting this pending, it will close in a
couple of weeks if you don't respond with further comments.

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

Comment By: Tal Einat (taleinat)
Date: 2006-12-09 12:54

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

Well, the issue obviously only happens when IDLE is running without a
subprocess.

The code you pasted is unindtented so I'm not going to try it out...

My guess would be that your server is blocking in a way that it blocks all
threads. This is why, when it is run in the same process as IDLE's GUI,
IDLE hangs. However, when you run IDLE with a subprocess, it's the
subprocess which is blocked, so IDLE works normally. (this is what the
subprocess is there for :)

In any case, IDLE is behaving just fine here. This isn't a bug in IDLE.


This could be a bug with the thread module, or a bug in BaseHTTPServer, or
several other places. But it is most likely caused by some misunderstanding
on your part of blocking operations, threads, and the interaction between
them.

You should have tried posting this on c.l.py before posting a bug on SF,
and I suggest you do so now.

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

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

From noreply at sourceforge.net  Tue Feb  6 08:07:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 23:07:16 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HEKQ8-0002vB-RG@sc8-sf-web7.sourceforge.net>

Bugs item #1652387, was opened at 2007-02-05 13:35
Message generated for change (Settings changed) made by kkelchev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652387&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 20:54

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

Yes, this is exactly what I had written in my previous answer.

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

Comment By: kkelchev (kkelchev)
Date: 2007-02-05 20:34

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

Sorry :(
I forgot to paste definision of Class MyObj
yes it is:

class MyObj:
    Lines = []
--------------------------------------
is this a bug ? 
Or always in Python data in nested object are shared between all objects
from same class

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 18:31

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

Sadly you didn't attach the definition of the class "MyObj".

I assume it is like this:

class MyObj:
    Lines = []

In this case, the Lines list object is shared by all instances of MyObj.
Please post to the python-list mailing list for further questions about
this behavior.

If your bug is different, please feel free to reopen this.

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

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

From noreply at sourceforge.net  Tue Feb  6 08:08:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Feb 2007 23:08:42 -0800
Subject: [ python-Bugs-1652387 ] Nested Objects scope problem
Message-ID: <E1HEKRW-00031k-08@sc8-sf-web7.sourceforge.net>

Bugs item #1652387, was opened at 2007-02-05 13:35
Message generated for change (Settings changed) made by kkelchev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652387&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: kkelchev (kkelchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Objects scope problem

Initial Comment:
K = MyObj()
K.Lines.append('First line to Obj "K"')
K.Lines.append('Second line to Obj "K"')
L = MyObj()
L.Lines.append('First line to Obj "L"')
print 'Lines from Obj "K"',K.Lines
print 'Lines from Obj "L"',L.Lines


Result is:
[Dbg]>>> 
Lines from Obj "K" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
Lines from Obj "L" ['First line to Obj "K"', 'Second line to Obj "K"', 'First line to Obj "L"']
>>> 

Why data appended into nested list filed ?Lines?  into different object ?K? and ?L?  appears in both objects ?



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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 20:54

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

Yes, this is exactly what I had written in my previous answer.

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

Comment By: kkelchev (kkelchev)
Date: 2007-02-05 20:34

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

Sorry :(
I forgot to paste definision of Class MyObj
yes it is:

class MyObj:
    Lines = []
--------------------------------------
is this a bug ? 
Or always in Python data in nested object are shared between all objects
from same class

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-05 18:31

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

Sadly you didn't attach the definition of the class "MyObj".

I assume it is like this:

class MyObj:
    Lines = []

In this case, the Lines list object is shared by all instances of MyObj.
Please post to the python-list mailing list for further questions about
this behavior.

If your bug is different, please feel free to reopen this.

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

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

From noreply at sourceforge.net  Tue Feb  6 10:54:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 01:54:21 -0800
Subject: [ python-Bugs-1653121 ] Double free/corruption?
Message-ID: <E1HEN1p-0006Yq-Bj@sc8-sf-web5.sourceforge.net>

Bugs item #1653121, was opened at 2007-02-06 10: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=1653121&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jarek Zgoda (zgoda)
Assigned to: Nobody/Anonymous (nobody)
Summary: Double free/corruption?

Initial Comment:
Today I encountered a problem with system complaining on double free/corruption, but as I don't know C, I cann't say it's a problem with Python or with MySQLdb.
Attached is a stack trace that I saw in screen session termination window. I am unable to reproduce this error, I tried few times, but it does not happen.

If this is a MySQLdb (or even MySQL) problem, I'll report the bug as appriopriate, just let me know.

The system is pretty standard FC4. Below is as some system information, let me know if I should provide you anything more.

$ python
Python 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2

$ uname -a
Linux localhost 2.6.17-1.2139_FC4smp #1 SMP Fri Jun 23 21:12:13 EDT 2006 i686 i686 i386 GNU/Linux

$ yum list installed glibc
Installed Packages
glibc.i686                               2.3.6-3

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

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

From noreply at sourceforge.net  Tue Feb  6 11:31:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 02:31:18 -0800
Subject: [ python-Bugs-1653121 ] Double free/corruption?
Message-ID: <E1HENba-0001hu-Bb@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jarek Zgoda (zgoda)
Assigned to: Nobody/Anonymous (nobody)
Summary: Double free/corruption?

Initial Comment:
Today I encountered a problem with system complaining on double free/corruption, but as I don't know C, I cann't say it's a problem with Python or with MySQLdb.
Attached is a stack trace that I saw in screen session termination window. I am unable to reproduce this error, I tried few times, but it does not happen.

If this is a MySQLdb (or even MySQL) problem, I'll report the bug as appriopriate, just let me know.

The system is pretty standard FC4. Below is as some system information, let me know if I should provide you anything more.

$ python
Python 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2

$ uname -a
Linux localhost 2.6.17-1.2139_FC4smp #1 SMP Fri Jun 23 21:12:13 EDT 2006 i686 i686 i386 GNU/Linux

$ yum list installed glibc
Installed Packages
glibc.i686                               2.3.6-3

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

>Comment By: Tim Peters (tim_one)
Date: 2007-02-06 05:31

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

Since the top 6 or 7 stack entries are all in
/usr/lib/mysql/libmysqlclient_r.so.14, and shows it trying to using its own
free() function (my_no_flags_free()), it's almost certainly a problem in
the extension module (as opposed to in Python).

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

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

From noreply at sourceforge.net  Tue Feb  6 11:51:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 02:51:24 -0800
Subject: [ python-Feature Requests-500698 ] Taint a la Perl?
Message-ID: <E1HENv2-0000ry-NZ@sc8-sf-monitor2.sourceforge.net>

Feature Requests item #500698, was opened at 2002-01-08 03:48
Message generated for change (Comment added) made by jcrocholl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=500698&group_id=5470

Please note that this 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: 5
Private: No
Submitted By: Peter Scott (sketerpot)
Assigned to: Nobody/Anonymous (nobody)
Summary: Taint a la Perl?

Initial Comment:
This might just add unnecessary bloat, but since Python is being 
used in CGI scripts, it can be used to narrow a security hole. One way 
of breaking security is for a naiive programmer (don't try to deny 
their existance) to run an arbitrary command from the page 
viewer.

Perl has developed an interesting mechanism for 
helping with this: taint. The way it works is, when something comes 
directly from the user, like a key in a form, it is considered to have 
taint unless specifically untainted. Things like os.exec() would 
create a warning message if you passed tainted strings to 
them.

As I said, this might just add unnecessary bloat, but for 
an option that can be left out for most builds of Python I think it 
would be pretty nice.

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

Comment By: Johann C. Rocholl (jcrocholl)
Date: 2007-02-06 11:51

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

http://svn.rocholl.net/taint/trunk/taint.py

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

Comment By: Johann C. Rocholl (jcrocholl)
Date: 2007-02-05 22:55

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

I have come up with a class called SafeString which is the opposite of a
tainted string. In my model, all strings are tainted by default, and you
have to call untaint() to create a SafeString. Then I replace all
functions in the os module with wrapper functions that check all
parameters first and raise TaintError if any string is not safe. If I can
figure out how to attach a file here, I will post it. Otherwise you may
find it on comp.lang.python by the name of taint.py.

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

Comment By: Peter Scott (sketerpot)
Date: 2003-02-14 18:21

Message:
Logged In: YES 
user_id=252564

Thanks for the idea, phr. I wrote a small class called 
TaintString, derived from string, that has a taint attribute. This 
is probably the least difficult part. The difficult part will be in 
modifying functions like os.system() to raise warnings or 
exceptions when tainted strings are passed to them. I'm 
currently thinking of making wrapper modules with names like 
taint.os, or taint.cgi, but the problem with this is that you 
have to manually use taint.* for certain functions. If anybody 
can think of something that can simplify this, please post it.

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

Comment By: paul rubin (phr)
Date: 2003-02-14 05:47

Message:
Logged In: YES 
user_id=72053

With new-style classes, maybe this can be done by
subclassing string somehow.  There would be a subclass for
tainted strings and trying to do most things with them would
raise an exception.  With taint checking enabled, functions
like os.getenv and cgi.FieldStorage would make objects
containing tainted strings.  You'd untaint them by passing
them to re.search or re.match and pulling out the match
variables, like in Per.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-03 02:25

Message:
Logged In: YES 
user_id=44345

Took awhile for a response to this feature request. ;-)

Perl's heavy integration of regular expressions with its
taint facility probably wouldn't work all that well in
Python.  For one, Python has more ways of searching
strings than with regular expressions.  Second, regular
expressions are not nearly as tightly wound into Python
as they are in Perl.  I think you'd have to add a taint
attribute to strings and just rely on the programmer to
properly clear that attribute.

I think a first cut at an implementation would go much
further toward getting the concept seriously considered
for addition to Python.


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

Comment By: Neal McBurnett (nealmcb)
Date: 2003-01-02 22:20

Message:
Logged In: YES 
user_id=105956

I really like taint mode.
I think this would make Python a better choice for CGI scripts.

See http://www.perldoc.com/perl5.8.0/pod/perlsec.html
and http://gunther.web66.com/FAQS/taintmode.html
for more background.


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

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

From noreply at sourceforge.net  Tue Feb  6 12:24:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 03:24:53 -0800
Subject: [ python-Bugs-1653121 ] Double free/corruption?
Message-ID: <E1HEORR-00048y-3b@sc8-sf-monitor2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jarek Zgoda (zgoda)
Assigned to: Nobody/Anonymous (nobody)
Summary: Double free/corruption?

Initial Comment:
Today I encountered a problem with system complaining on double free/corruption, but as I don't know C, I cann't say it's a problem with Python or with MySQLdb.
Attached is a stack trace that I saw in screen session termination window. I am unable to reproduce this error, I tried few times, but it does not happen.

If this is a MySQLdb (or even MySQL) problem, I'll report the bug as appriopriate, just let me know.

The system is pretty standard FC4. Below is as some system information, let me know if I should provide you anything more.

$ python
Python 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2

$ uname -a
Linux localhost 2.6.17-1.2139_FC4smp #1 SMP Fri Jun 23 21:12:13 EDT 2006 i686 i686 i386 GNU/Linux

$ yum list installed glibc
Installed Packages
glibc.i686                               2.3.6-3

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

>Comment By: Jarek Zgoda (zgoda)
Date: 2007-02-06 12:24

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

Thank you, will try my luck with MySQLdb.

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

Comment By: Tim Peters (tim_one)
Date: 2007-02-06 11:31

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

Since the top 6 or 7 stack entries are all in
/usr/lib/mysql/libmysqlclient_r.so.14, and shows it trying to using its
own free() function (my_no_flags_free()), it's almost certainly a problem
in the extension module (as opposed to in Python).

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

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

From noreply at sourceforge.net  Tue Feb  6 12:52:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 03:52:25 -0800
Subject: [ python-Bugs-1653121 ] Double free/corruption?
Message-ID: <E1HEOs5-0005xR-WA@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Jarek Zgoda (zgoda)
Assigned to: Nobody/Anonymous (nobody)
Summary: Double free/corruption?

Initial Comment:
Today I encountered a problem with system complaining on double free/corruption, but as I don't know C, I cann't say it's a problem with Python or with MySQLdb.
Attached is a stack trace that I saw in screen session termination window. I am unable to reproduce this error, I tried few times, but it does not happen.

If this is a MySQLdb (or even MySQL) problem, I'll report the bug as appriopriate, just let me know.

The system is pretty standard FC4. Below is as some system information, let me know if I should provide you anything more.

$ python
Python 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2

$ uname -a
Linux localhost 2.6.17-1.2139_FC4smp #1 SMP Fri Jun 23 21:12:13 EDT 2006 i686 i686 i386 GNU/Linux

$ yum list installed glibc
Installed Packages
glibc.i686                               2.3.6-3

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

Comment By: Jarek Zgoda (zgoda)
Date: 2007-02-06 11:24

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

Thank you, will try my luck with MySQLdb.

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

Comment By: Tim Peters (tim_one)
Date: 2007-02-06 10:31

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

Since the top 6 or 7 stack entries are all in
/usr/lib/mysql/libmysqlclient_r.so.14, and shows it trying to using its own
free() function (my_no_flags_free()), it's almost certainly a problem in
the extension module (as opposed to in Python).

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

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

From noreply at sourceforge.net  Tue Feb  6 16:43:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 07:43:24 -0800
Subject: [ python-Bugs-1124861 ] subprocess fails on GetStdHandle in
	interactive GUI
Message-ID: <E1HESTc-0004Do-8F@sc8-sf-monitor2.sourceforge.net>

Bugs item #1124861, was opened at 2005-02-17 17:23
Message generated for change (Comment added) made by astrand
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: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: davids (davidschein)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess fails on 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: Peter ?strand (astrand)
Date: 2007-02-06 16:43

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

I've applied 1124861.3.patch to both trunk (rev 53646) and the
release25-maint branch (rev 53647). 

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

Comment By: Peter ?strand (astrand)
Date: 2007-01-30 21:05

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

Please review 1124861.3.patch. 

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

Comment By: Peter ?strand (astrand)
Date: 2007-01-30 21:04

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

File Added: 1124861.3.patch

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

Comment By: Peter ?strand (astrand)
Date: 2007-01-29 22:42

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

Some ideas of possible solutions for this bug:

1) As Roger Upole suggests, throw an readable error when GetStdHandle
fails. This would not really change much, besides of subprocess being a
little less confusing. 

2) Automatically create PIPEs for those handles that fails. The PIPE could
either be left open or closed. A WriteFile in the child would get
ERROR_BROKEN_PIPE, if the parent has closed it. Not as good as
ERROR_INVALID_HANDLE, but pretty close. (Or should I say pretty closed?
:-)

3) Try to attach the handles to a NUL device, as 1238747 suggests. 

4) Hope for the best and actually pass invalid handles in
startupinfo.hStdInput, startupinfo.hStdOutput, or
startupinfo.hStdError. It would be nice if this was possible: If
GetStdHandle fails in the current process, it makes sense that
GetStdHandle will fail in the child as well. But, as far as I understand,
it's not possible or safe to pass invalid handles in the startupinfo
structure. 

Currently, I'm leaning towards solution 2), with closing the parents PIPE
ends. 

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

Comment By: Peter ?strand (astrand)
Date: 2007-01-22 20:36

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

The following bugs have been marked as duplicate of this bug:

1358527
1603907
1126208
1238747



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

Comment By: craig (codecraig)
Date: 2006-10-13 17: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 16: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 22: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  Tue Feb  6 17:23:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 08:23:54 -0800
Subject: [ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?
Message-ID: <E1HET6o-0000AC-7b@sc8-sf-web4.sourceforge.net>

Bugs item #1653416, was opened at 2007-02-06 17: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=1653416&group_id=5470

Please note that this 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: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?

Initial Comment:
When using
  print >> f, "Hello"
on a file f opened for reading, no exception is raised.  Is this normal?

This situation has to be contrasted with
  f.write("Hello")
which raises an exception.

Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:

In [1]: f=open("start.01")
In [2]: f.write("Hello")
<type 'exceptions.IOError'>: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()

NB: file f is not modified, despite the "print" statement yielding no error, above.

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

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

From noreply at sourceforge.net  Tue Feb  6 18:08:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 09:08:40 -0800
Subject: [ python-Bugs-1653457 ] Python misbehaves when installed in / (patch
	attached)
Message-ID: <E1HETo8-00034c-PV@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Webb (chris_arachsys)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python misbehaves when installed in / (patch attached)

Initial Comment:
reduce() in getpath.c chops down a path to the empty string rather than to /. As a result, if you build python with --prefix='' in the usual way for software to be installed into /, it tries to find its libraries in the current directory instead of in /lib:

$ python
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Python 2.5 (r25:51908, Feb  6 2007, 16:15:42) 
[GCC 3.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 

This is fixed by the attached patch.

$ python
Python 2.5 (r25:51908, Feb  6 2007, 16:19:38) 
[GCC 3.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 



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

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

From noreply at sourceforge.net  Tue Feb  6 18:31:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 09:31:53 -0800
Subject: [ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?
Message-ID: <E1HEUAb-0004YP-4D@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?

Initial Comment:
When using
  print >> f, "Hello"
on a file f opened for reading, no exception is raised.  Is this normal?

This situation has to be contrasted with
  f.write("Hello")
which raises an exception.

Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:

In [1]: f=open("start.01")
In [2]: f.write("Hello")
<type 'exceptions.IOError'>: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()

NB: file f is not modified, despite the "print" statement yielding no error, above.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-06 17:31

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

If this happens, it's a bug. Though it doesn't seem to occur under Linux
here.

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

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

From noreply at sourceforge.net  Tue Feb  6 18:45:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 09:45:28 -0800
Subject: [ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?
Message-ID: <E1HEUNk-0001J4-Mf@sc8-sf-web11.sourceforge.net>

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

Please note that this 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: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?

Initial Comment:
When using
  print >> f, "Hello"
on a file f opened for reading, no exception is raised.  Is this normal?

This situation has to be contrasted with
  f.write("Hello")
which raises an exception.

Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:

In [1]: f=open("start.01")
In [2]: f.write("Hello")
<type 'exceptions.IOError'>: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()

NB: file f is not modified, despite the "print" statement yielding no error, above.

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

>Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-06 18:45

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

Interesting point, about Linux.   The incorrect behavior is even seen in
the  default python 2.3 that ships with Mac OS X!


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-06 18:31

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

If this happens, it's a bug. Though it doesn't seem to occur under Linux
here.

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

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

From noreply at sourceforge.net  Tue Feb  6 19:49:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 10:49:05 -0800
Subject: [ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?
Message-ID: <E1HEVNJ-0003ta-HS@sc8-sf-web7.sourceforge.net>

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

Please note that this 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: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?

Initial Comment:
When using
  print >> f, "Hello"
on a file f opened for reading, no exception is raised.  Is this normal?

This situation has to be contrasted with
  f.write("Hello")
which raises an exception.

Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:

In [1]: f=open("start.01")
In [2]: f.write("Hello")
<type 'exceptions.IOError'>: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()

NB: file f is not modified, despite the "print" statement yielding no error, above.

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

>Comment By: Skip Montanaro (montanaro)
Date: 2007-02-06 12:49

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

I verified this behavior on my Mac with /usr/bin/python, Python 2.5 and
Python 2.6a0, both built from SVN.

Skip


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

Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-06 11:45

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

Interesting point, about Linux.   The incorrect behavior is even seen in
the  default python 2.3 that ships with Mac OS X!


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-06 11:31

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

If this happens, it's a bug. Though it doesn't seem to occur under Linux
here.

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

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

From noreply at sourceforge.net  Tue Feb  6 20:43:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 11:43:38 -0800
Subject: [ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HEWE6-0001KX-QS@sc8-sf-web6.sourceforge.net>

Feature Requests item #1649329, was opened at 2007-02-01 03:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this 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: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 20:43

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

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

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

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

From noreply at sourceforge.net  Tue Feb  6 20:49:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 11:49:36 -0800
Subject: [ python-Bugs-1648268 ] Parameter list mismatches (portation problem)
Message-ID: <E1HEWJs-0005df-Hj@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parameter list mismatches (portation problem)

Initial Comment:
On the system I'm porting to(*), an application will trap if the caller does not pass the exact parameter list that the callee requires. This is causing problems running Python.

One common instance where this appears to be causing problems is where functions are registered as METH_NOARGS methods. For example, in Obejcts/dictobject.c, dict_popitem() is declared:

static PyObject *dict_popitem(dictobject *mp);

However, as it is declared in the method array as METH_NOARGS, it will be called by Objects/methodobject.c:PyCFunction_Call() as "(*meth)(self, NULL)" (i.e., an extra NULL parameter is passed for some reason). This will fail on my target system.

I've no problem submitting a patch for this (dictobject.c is by no means the only place this is happening - it's just the first one encountered because it's used so much - though some places _do_ correctly declare a second, ignored parameter). However, I'd like to get agreement on the correct form it should be changed to before I put the effort in to produce a patch (it's going to be a fairly tedious process to identify and fix all these).

In various modules, the functions are called internally as well as being registered as METH_NOARGS methods.

Therefore, the change can either be:

static PyObject *foo(PyObject *self)
{
  ...
}

static PyObject *foo_noargs(PyObject *self, void *noargs_null)
{
   return foo(self);
}

... where 'foo' is called internally and 'foo_noargs' is registered as a METH_NOARGS method.

or:

static PyObject *foo(PyObject *self, void *noargs_null)
{
  ...
}

... and any internal calls in the module have to pass a second, NULL, argument in each call.

The former favours internal module calls over METH_NOARGS calls, the latter penalises them. Which is preferred? Should this be raised on a different forum? Does anyone care? ;)

Thanks, Kev.

(*) Details on request.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 20:49

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

The current specification says that these should be PyCFunction pointers,
see

http://docs.python.org/api/common-structs.html

My initial implementation of METH_NOARGS had it differently, and nobody
ever bothered fixing them all when this was changed. Please do submit a
patch to correct all such errors, both in code and documentation.

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

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

From noreply at sourceforge.net  Tue Feb  6 21:03:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 12:03:44 -0800
Subject: [ python-Bugs-1646068 ] Dict lookups fail if sizeof(Py_ssize_t) <
	sizeof(long)
Message-ID: <E1HEWXY-0003GC-BR@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: 6
Private: No
Submitted By: ked-tao (ked-tao)
Assigned to: Tim Peters (tim_one)
Summary: Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long)

Initial Comment:
Portation problem.

Include/dictobject.h defines PyDictEntry.me_hash as a Py_ssize_t. Everywhere else uses a C 'long' for hashes.

On the system I'm porting to, ints and pointers (and ssize_t) are 32-bit, but longs and long longs are 64-bit. Therefore, the assignments to me_hash truncate the hash and subsequent lookups fail.

I've changed the definition of me_hash to 'long' and (in Objects/dictobject.c) removed the casting from the various assignments and changed the definition of 'i' in dict_popitem(). This has fixed my immediate problems, but I guess I've just reintroduced whatever problem it got changed for. The comment in the header says:

/* Cached hash code of me_key.  Note that hash codes are C longs.
 * We have to use Py_ssize_t instead because dict_popitem() abuses
 * me_hash to hold a search finger.
 */

... but that doesn't really explain what it is about dict_popitem() that requires the different type.

Thanks. Kev.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 21:03

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

ked-tao: as for "doesn't really explain", please take a look at this
comment:

        /* Set ep to "the first" dict entry with a value.  We abuse the
hash
         * field of slot 0 to hold a search finger:
         * If slot 0 has a value, use slot 0.
         * Else slot 0 is being used to hold a search finger,
         * and we use its hash value as the first index to look.
         */

So .popitem first returns (and removes) the item in slot 0. Afterwards, it
does a 
linear scan through the dictionary, returning one item at a time. To
avoid
re-scanning the emptying dictionary over and over again, the me_hash
value of slot 0 indicates the place to start searching when the next
.popitem
call is made. Of course, this value may start out bogus and out-of-range,
or may become out-of-range if the dictionary shrinks; in that case, it
starts over at index 1. If it is bogus (i.e. never set as a search
finger)
and in-range, that's fine: it will just start searching for a non-empty
slot at me_hash.

Because it is a slot number, me_hash must be large enough to hold a
Py_ssize_t. On some systems (Win64 in particular), long is not large
enough to hold Py_ssize_t.

I believe the proposed patch is fine.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-02-04 17:35

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

Yes, I'm curious about what system this is ... is it a characteristic of
the whole system, or a compiler choice to get longer ints?

As to using a Py_hash_t -- it probably wouldn't be as bad as you think. 
You might get away with just masking it to throw away the high order bits
in dict and set.  (That might not work with perturbation.)  

Even if you have to change it everywhere at the source, then there is some
prior art (from when hash was allowed to be a python long), and it is
almost certainly limited to methods with "hash" in the name which generate
a hash.  (eq/ne on the same objects may use the hash.)  Consumers of hash
really are limited to dict and derivatives.  I think dict, set, and
defaultdict may be the full list for the default distribution.


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

Comment By: ked-tao (ked-tao)
Date: 2007-02-04 15:11

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

Hi Jim. I understand what the problem is (perhaps I didn't state it
clearly enough) - me_hash is a cache of the dict item's hash which is
compared against the hash of the object being looked up before going any
further with expensive richer comparisons. On my system, me_hash is a
32-bit quantity but hashes in general are declared 'long' which is a 64-bit
quantity. Therefore for any object whose hash has any of the top 32 bits
set, a dict lookup will fail as it will never get past that first check
(regardless of why that slot is being checked - it has nothing to do with
the perturbation to find the next slot).

The deal is that my system is basically a 32-bit system (sizeof(int) ==
sizeof(void *) == 4, and therefore ssize_t is not unreasonably also
32-bit), but C longs are 64-bit.

You say "popitem assumes it can store a pointer there", but AFAICS it's
just storing an _index_, not a pointer. I was concerned that making that
index a 64-bit quantity might tickle some subtlety in the code, thinking
that perhaps it was changed from 'long' to 'Py_ssize_t' because it had to
be 32-bit for some reason. However, it seems much more likely that it was
defined like that to be more correct on a system with 64-bit addressing and
32-bit longs (which would be more common). With that in mind, I've attached
a suggested patch which selects a reasonable type according to the SIZEOF_
configuration defines.

WRT forcing the hashes 32-bit to "save space and time" - that means
inventing a 'Py_hash_t' type and going through the entire python source
looking for 'long's that might be used to store/calculate hashes. I think
I'll pass on that ;)

Regards, Kev.
File Added: dict.diff

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-02-02 21:20

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

The whole point of a hash is that if it doesn't match, you can skip an
expensive comparison.  How big to make the hash is a tradeoff between how
much you'll waste calculating and storing it vs how often it will save a
"real" comparison.

The comment means that, as an implementation detail, popitem assumes it
can store a pointer there instead, so hashes need to be at least as big as
a pointer.  

Going to the larger of the two sizes will certainly solve your problem; it
just wastes some space, and maybe some time calculating the hash.  

If you want to get that space back, just make sure the truncation is
correct and consistent.  I *suspect* your problem is that when there is a
collision, either 

(1)  It is comparing a truncated value to an untruncated value, or
(2)  The perturbation to find the next slot is going wrong, because of
when the truncation happens.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-27 20:40

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

This is your code, Tim.

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

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

From noreply at sourceforge.net  Tue Feb  6 23:28:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 14:28:30 -0800
Subject: [ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HEYne-0003gk-KC@sc8-sf-web11.sourceforge.net>

Feature Requests item #1649329, was opened at 2007-01-31 18:20
Message generated for change (Comment added) made by jjinux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this 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: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

>Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-06 14:28

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

Sorry, yes, this is a feature request.  The most important thing that I'm
requesting is to refactor the code.  That "find" function implements a
certain algorithm that has nothing to do with the filesystem.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 11:43

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

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

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

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

From noreply at sourceforge.net  Wed Feb  7 02:15:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 17:15:19 -0800
Subject: [ python-Bugs-1653736 ] Problems in datetime.c and typeobject.c.
Message-ID: <E1HEbP5-0001GV-H7@sc8-sf-monitor2.sourceforge.net>

Bugs item #1653736, was opened at 2007-02-07 01: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=1653736&group_id=5470

Please note that this 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: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems in datetime.c and typeobject.c.

Initial Comment:
This is related to [python-Bugs-1648268], but I think these problems might be important enough to consider fixing prior to any patch being produced for that item.

Modules/datetimemodule.c:time_isoformat() is declared in time_methods[] as METH_KEYWORDS. However, I believe it is better declared as METH_NOARGS (calling it with args and kwargs doesn't raise any exception, but it doesn't accept them).

Objects/typeobject.c:4428 - slot_nb_inplace_power is declared with the SLOT1() macro. I'm not sure I entirely grok what's going on here (not enough to supply a python-level failure case), but it seems to me that it should be declared with the SLOT2() macro (it's a ternary op). FWIW, I changed it from:

SLOT1(slot_nb_inplace_power, "__ipow__", PyObject *, "O")

to:

SLOT2(slot_nb_inplace_power, "__ipow__", PyObject *, PyObject *, "OO")

... and that ran the failing tests OK.

Hopefully someone familiar with this code can determine if this is correct or not.

Thanks, Kev.




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

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

From noreply at sourceforge.net  Wed Feb  7 02:56:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 17:56:53 -0800
Subject: [ python-Bugs-1653753 ] crash / abort during install
Message-ID: <E1HEc3J-0005Hn-WA@sc8-sf-monitor2.sourceforge.net>

Bugs item #1653753, was opened at 2007-02-06 17: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=1653753&group_id=5470

Please note that this 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
Private: No
Submitted By: SAndreason (sandreas41)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash / abort during install

Initial Comment:
linux-2.4.33
installing Python-2.5.tar.bz2  9357099 bytes

After a successful make,
su # make install
...[clip]...
PYTHONPATH=/usr/local/lib/python2.5   \
        ./python -Wi -tt /usr/local/lib/python2.5/compileall.py \
        -d /usr/local/lib/python2.5 -f \
        -x 'bad_coding|badsyntax|site-packages' /usr/local/lib/python2.5
Listing /usr/local/lib/python2.5 ...
Compiling /usr/local/lib/python2.5/BaseHTTPServer.py ...
...[clip]...
Compiling /usr/local/lib/python2.5/xmlrpclib.py ...
Compiling /usr/local/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1


Can installation be finished manually? or is there a patch or workaround for this?

Stewart

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

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

From noreply at sourceforge.net  Wed Feb  7 03:15:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 18:15:17 -0800
Subject: [ python-Bugs-1653757 ] configure does not check/warn/stop for tk/tcl
Message-ID: <E1HEcL7-0000z7-Uq@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: SAndreason (sandreas41)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure does not check/warn/stop for tk/tcl

Initial Comment:
linux-2.4.33
installing Python-2.5.tar.bz2 9357099 bytes

During the first configure/make process, there were no errors until compilation failed.
Looking back at the configure output, I see:
...[clip]...
checking for UCS-4 tcl... no
...[clip]...

Because during make, it said:
...[clip]...
/usr/src/Python-2.5/Modules/_tkinter.c:80:2: #error "Tk older than 8.2 not supported"
/usr/src/Python-2.5/Modules/_tkinter.c:92:2: #error "unsupported Tcl configuration"
...[clip]...and many pages of:...
/usr/src/Python-2.5/Modules/_tkinter.c:xxxx: errors

Ok, so I upgraded the tk and tcl packages without incident.

Now, Why during the clean re-configuration, do I get the same message, and also an error in the config.log that matches??

make did (appear to) finish ok

Perhaps this may have relevance to the other bug.
[ 1653753 ] crash / abort during install

config.log is attached there.


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

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

From noreply at sourceforge.net  Wed Feb  7 07:45:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 22:45:44 -0800
Subject: [ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HEgYq-0006Fx-Ic@sc8-sf-web2.sourceforge.net>

Feature Requests item #1649329, was opened at 2007-02-01 03:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this 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: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-07 07:45

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

Do you have a proposal on how to do the refactoring? It would be fine to
split find into two parts; it would not be acceptable (to me) to teach it
egg: URLs.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-06 23:28

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

Sorry, yes, this is a feature request.  The most important thing that I'm
requesting is to refactor the code.  That "find" function implements a
certain algorithm that has nothing to do with the filesystem.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 20:43

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

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

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

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

From noreply at sourceforge.net  Wed Feb  7 08:57:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Feb 2007 23:57:19 -0800
Subject: [ python-Bugs-1651995 ] sgmllib _convert_ref UnicodeDecodeError
	exception, new in 2.
Message-ID: <E1HEhg7-0004tJ-N0@sc8-sf-web3.sourceforge.net>

Bugs item #1651995, was opened at 2007-02-04 22:34
Message generated for change (Comment added) made by nagle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1651995&group_id=5470

Please note that this 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: sgmllib _convert_ref UnicodeDecodeError exception, new in 2.

Initial Comment:
   I'm running a website page through BeautifulSoup.  It parses OK with Python 2.4, but Python 2.5 fails with an exception:

Traceback (most recent call last):
  File "./sitetruth/InfoSitePage.py", line 268, in httpfetch
    self.pagetree = BeautifulSoup.BeautifulSoup(sitetext) # parse into tree form
  File "./sitetruth/BeautifulSoup.py", line 1326, in __init__
    BeautifulStoneSoup.__init__(self, *args, **kwargs)
  File "./sitetruth/BeautifulSoup.py", line 973, in __init__
    self._feed()
  File "./sitetruth/BeautifulSoup.py", line 998, in _feed
    SGMLParser.feed(self, markup or "")
  File "/usr/lib/python2.5/sgmllib.py", line 99, in feed
    self.goahead(0)
  File "/usr/lib/python2.5/sgmllib.py", line 133, in goahead
    k = self.parse_starttag(i)
  File "/usr/lib/python2.5/sgmllib.py", line 291, in parse_starttag
    self.finish_starttag(tag, attrs)
  File "/usr/lib/python2.5/sgmllib.py", line 340, in finish_starttag
    self.handle_starttag(tag, method, attrs)
  File "/usr/lib/python2.5/sgmllib.py", line 376, in handle_starttag
    method(attrs)
  File "./sitetruth/BeautifulSoup.py", line 1416, in start_meta
    self._feed(self.declaredHTMLEncoding)
  File "./sitetruth/BeautifulSoup.py", line 998, in _feed
    SGMLParser.feed(self, markup or "")
  File "/usr/lib/python2.5/sgmllib.py", line 99, in feed
    self.goahead(0)
  File "/usr/lib/python2.5/sgmllib.py", line 133, in goahead
    k = self.parse_starttag(i)
  File "/usr/lib/python2.5/sgmllib.py", line 285, in parse_starttag
    self._convert_ref, attrvalue)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa7 in position 0: ordinal not in range(128)

    The code that's failing is in "_convert_ref", which is new in Python 2.5. That function wasn't present in 2.4.  I think the code is trying to handle single quotes inside of double quotes in HTML attributes, or something like that.

    To replicate, run

	http://www.bankofamerica.com
or
	http://www.gm.com

through BeautifulSoup.  

Something about this code doesn't like big companies. Web sites of smaller companies are going through OK.

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

>Comment By: John Nagle (nagle)
Date: 2007-02-07 07:57

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

Found the problem. In sgmllib.py for Python 2.5, in convert_charref, the
code for handling character escapes assumes that ASCII characters have
values up to 255.
But the correct limit is 127, of course.

If a Unicode string is run through SGMLparser, and that string has a
character in an attribute with a value between 128 and 255, which is valid
in Unicode, the
value is passed through as a character with "chr", creating a
one-character invalid ASCII string.  

Then, when the bad string is later converted to Unicode as the output is
assembled, the UnicodeDecodeError exception is raised. 

So the fix is to change 255 to 127 in convert_charref in sgmllib.py,
as shown below.  This forces characters above 127 to be expressed with
escape sequences.  Please patch accordingly.  Thanks.

def convert_charref(self, name):
    """Convert character reference, may be overridden."""
    try:
        n = int(name)
    except ValueError:
        return
    if not 0 <= n <= 127 : # ASCII ends at 127, not 255
        return
    return self.convert_codepoint(n)


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

Comment By: wrstl prmpft (wrstlprmpft)
Date: 2007-02-05 07:16

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

I had a similar problem recently and did not have time to file a
bug-report. Thanks for doing that.

The problem is the code that handles entity and character references in
SGMLParser.parse_starttag. Seems that it is not careful about unicode/str
issues.
(But maybe Beautifulsoup needs to tell it to?)

My quick'n'dirty workaround was to remove the offending char-entity from
the website before feeding it to Beautifulsoup::

  text = text.replace('&#174;', '') # remove rights reserved sign entity

cheers,
stefan


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

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

From noreply at sourceforge.net  Wed Feb  7 09:41:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 00:41:58 -0800
Subject: [ python-Bugs-1653753 ] crash / abort during install
Message-ID: <E1HEiNK-0002t9-EI@sc8-sf-web1.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: SAndreason (sandreas41)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash / abort during install

Initial Comment:
linux-2.4.33
installing Python-2.5.tar.bz2  9357099 bytes

After a successful make,
su # make install
...[clip]...
PYTHONPATH=/usr/local/lib/python2.5   \
        ./python -Wi -tt /usr/local/lib/python2.5/compileall.py \
        -d /usr/local/lib/python2.5 -f \
        -x 'bad_coding|badsyntax|site-packages' /usr/local/lib/python2.5
Listing /usr/local/lib/python2.5 ...
Compiling /usr/local/lib/python2.5/BaseHTTPServer.py ...
...[clip]...
Compiling /usr/local/lib/python2.5/xmlrpclib.py ...
Compiling /usr/local/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1


Can installation be finished manually? or is there a patch or workaround for this?

Stewart

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-07 08:41

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

Please check if your issue is the same as http://python.org/sf/1594809,
i.e. if you have PYTHON* environment variables set while compiling, which
is not supported.

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

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

From noreply at sourceforge.net  Wed Feb  7 10:25:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 01:25:41 -0800
Subject: [ python-Bugs-1653940 ] popen - wrong order on fileobjects in tuple
	returned
Message-ID: <E1HEj3d-0007B4-PP@sc8-sf-web1.sourceforge.net>

Bugs item #1653940, was opened at 2007-02-07 10: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=1653940&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Emil Lind (noflux)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen - wrong order on fileobjects in tuple returned

Initial Comment:
http://docs.python.org/lib/module-popen2.html

(child_stdout, child_stdin, child_stderr)
should probably be 
(child_stdin, child_stdout, child_stderr)

and so on.


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

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

From noreply at sourceforge.net  Wed Feb  7 10:27:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 01:27:14 -0800
Subject: [ python-Bugs-1653940 ] popen - docs - wrong order on fileobjects in
	tuple returned
Message-ID: <E1HEj58-00078V-Ox@sc8-sf-monitor2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Emil Lind (noflux)
Assigned to: Nobody/Anonymous (nobody)
>Summary: popen - docs - wrong order on fileobjects in tuple returned

Initial Comment:
http://docs.python.org/lib/module-popen2.html

(child_stdout, child_stdin, child_stderr)
should probably be 
(child_stdin, child_stdout, child_stderr)

and so on.


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

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

From noreply at sourceforge.net  Wed Feb  7 17:04:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 08:04:30 -0800
Subject: [ python-Bugs-1653753 ] crash / abort during install
Message-ID: <E1HEpHa-0007PP-Ha@sc8-sf-web4.sourceforge.net>

Bugs item #1653753, was opened at 2007-02-06 17:56
Message generated for change (Comment added) made by sandreas41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653753&group_id=5470

Please note that this 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: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: SAndreason (sandreas41)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash / abort during install

Initial Comment:
linux-2.4.33
installing Python-2.5.tar.bz2  9357099 bytes

After a successful make,
su # make install
...[clip]...
PYTHONPATH=/usr/local/lib/python2.5   \
        ./python -Wi -tt /usr/local/lib/python2.5/compileall.py \
        -d /usr/local/lib/python2.5 -f \
        -x 'bad_coding|badsyntax|site-packages' /usr/local/lib/python2.5
Listing /usr/local/lib/python2.5 ...
Compiling /usr/local/lib/python2.5/BaseHTTPServer.py ...
...[clip]...
Compiling /usr/local/lib/python2.5/xmlrpclib.py ...
Compiling /usr/local/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1


Can installation be finished manually? or is there a patch or workaround for this?

Stewart

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

>Comment By: SAndreason (sandreas41)
Date: 2007-02-07 08:04

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

Ah! That is the same problem. 
Works for me.

Thank you

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-07 00:41

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

Please check if your issue is the same as http://python.org/sf/1594809,
i.e. if you have PYTHON* environment variables set while compiling, which
is not supported.

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

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

From noreply at sourceforge.net  Wed Feb  7 18:12:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 09:12:28 -0800
Subject: [ python-Feature Requests-1654367 ] [PATCH] Debuggers need a way to
	change the locals of a frame
Message-ID: <E1HEqLM-0000ph-GL@sc8-sf-web3.sourceforge.net>

Feature Requests item #1654367, was opened at 2007-02-07 17:12
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=1654367&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabio Zadrozny (fabioz)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] Debuggers need a way to change the locals of a frame

Initial Comment:
Debuggers need a way to change the local variables in a given frame... currently, this works only if this change is done in the topmost frame (and under certain circumstances), but it should work for any frame.

Initial discussion at:
http://mail.python.org/pipermail/python-dev/2007-February/070884.html

Apparently, the problem is the order in which PyFrame_LocalsToFast / PyFrame_FastToLocals is called.

The proposed solution to this is having a savelocals() method in the frame object and have it reflect the changes in its returned dict into its locals. It will simply enable users to call PyFrame_LocalsToFast externally after a change, to be sure that it will not be changed (and it must be done before another call to PyFrame_LocalsToFast -- which I don't see as a large problem, because it is of restrict use -- mainly for debuggers).


--------- frameobject.c Patch part 1: -----------------

static PyObject *
PyFrame_SaveLocals(PyFrameObject *f)
{
    PyFrame_LocalsToFast(f, 0);
	Py_INCREF(Py_None);
	return Py_None;
}

static PyMethodDef frame_methodlist[] = {
    {"savelocals", (PyCFunction)PyFrame_SaveLocals, METH_NOARGS,
     "After a change in f_locals, this method should be called to save the changes internally."
    },
    {NULL}  /* Sentinel */
};


---------- frameobject.c Patch part 2: ---------------
Add to PyTypeObject PyFrame_Type:

frame_methodlist,/* tp_methods */

------------------ end patch -------------------------

I'm sorry that this is not in an actual patch format... but as I didn't get it from the cvs, it is easier for me to explain it (as it is a rather small patch).

Attached is a test-case for this patch.

Thanks, 

Fabio

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

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

From noreply at sourceforge.net  Wed Feb  7 18:50:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 09:50:09 -0800
Subject: [ python-Bugs-1654408 ] Installer should split tcl/tk and tkinter
	install options.
Message-ID: <E1HEqvp-00028a-FV@sc8-sf-web11.sourceforge.net>

Bugs item #1654408, was opened at 2007-02-07 11: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=1654408&group_id=5470

Please note that this 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: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Adam (ron_adam)
Assigned to: Martin v. L?wis (loewis)
Summary: Installer should split tcl/tk and tkinter install options.

Initial Comment:
On Windows, installing tcl/tk separately without removing tcl/tk from python can cause tkinter to be very unstable. These bugs happen even if the versions differ by only a minor release number from the version shipped with python.

Selecting to not install tcl/tk with the installer also removes tkinter, and idle.  Which is what you don't want in this case.

To be able to use tkinter and idle and a full installation of tcl/tk you need to manually remove the following:

 - python/tcl directory
 - python/dlls/tcl84.dll
 - python/dlls/tk84.dll
 - python/dlls/tclpip84.dll

(or the corresponding versions)

And then make sure tcl's bin directory is in the path. 

This also avoids problems resulting from attempting to install tcl extensions into the python tcl directory (or tcl into pythons tcl directory) which tends to not work. 

Separating the tcl/tk and tkinter/idle in the installer along with adding advise on using a separate tcl installation with python would be helpful to some people.


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

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

From noreply at sourceforge.net  Wed Feb  7 19:14:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 10:14:24 -0800
Subject: [ python-Bugs-1654429 ] thread join() with timeout hangs on Windows
	2003 x64
Message-ID: <E1HErJI-0006Zw-8O@sc8-sf-monitor2.sourceforge.net>

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

Please note that this 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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bentoi (bentoi)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread join() with timeout hangs on Windows 2003 x64

Initial Comment:
If join() is called on a thread which is alive with a timeout, it hangs for the duration of the timeout even if the thread terminated before. This appears to only happen on Windows 2003 x64.

Here's a test case:
---
#!/usr/bin/env python                                                           
                                                                                
from threading import Thread                                                    
import time                                                                     
                                                                                
class ReaderThread(Thread):                                                     
    def __init__(self):                                                         
        Thread.__init__(self)                                                   
                                                                                
    def run(self):                                                              
                                                                                
        print "sleeping"                                                        
        time.sleep(5)                                                           
        print "finished sleeping"                                               
                                                                                
                                                                                
thread = ReaderThread()                                                         
thread.start()                                                                  
print "joining..."                                                              
thread.join(60)                                                                 
print "joined"                                                                  
 ----


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

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

From noreply at sourceforge.net  Wed Feb  7 22:14:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 13:14:42 -0800
Subject: [ python-Bugs-1654408 ] Installer should split tcl/tk and tkinter
	install options.
Message-ID: <E1HEu7m-0000Iw-IM@sc8-sf-web6.sourceforge.net>

Bugs item #1654408, was opened at 2007-02-07 18:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1654408&group_id=5470

Please note that this 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: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Adam (ron_adam)
Assigned to: Martin v. L?wis (loewis)
Summary: Installer should split tcl/tk and tkinter install options.

Initial Comment:
On Windows, installing tcl/tk separately without removing tcl/tk from python can cause tkinter to be very unstable. These bugs happen even if the versions differ by only a minor release number from the version shipped with python.

Selecting to not install tcl/tk with the installer also removes tkinter, and idle.  Which is what you don't want in this case.

To be able to use tkinter and idle and a full installation of tcl/tk you need to manually remove the following:

 - python/tcl directory
 - python/dlls/tcl84.dll
 - python/dlls/tk84.dll
 - python/dlls/tclpip84.dll

(or the corresponding versions)

And then make sure tcl's bin directory is in the path. 

This also avoids problems resulting from attempting to install tcl extensions into the python tcl directory (or tcl into pythons tcl directory) which tends to not work. 

Separating the tcl/tk and tkinter/idle in the installer along with adding advise on using a separate tcl installation with python would be helpful to some people.


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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-07 22:14

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

I cannot understand why Python's Tkinter becomes unstable when Tcl is
installed, or vice versa. Are you setting any environment variables (like
TCL_HOME)? You should not do that.

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

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

From noreply at sourceforge.net  Wed Feb  7 23:24:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 14:24:39 -0800
Subject: [ python-Bugs-1575169 ] isSequenceType returns True for dict
	subclasses (<> 2.3)
Message-ID: <E1HEvDT-0000G4-QC@sc8-sf-web5.sourceforge.net>

Bugs item #1575169, was opened at 2006-10-11 05:35
Message generated for change (Comment added) 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: Closed
>Resolution: Fixed
Priority: 5
Private: No
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.






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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-07 17:24

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

Fixed in revisions 53661 and 53662.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-11-27 13:28

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

Hmm, it may be possible to make the test smarter by checking base classes
known mappings or known sequences in cases where the __getitem__ method
hasn't been overridden.  That would reduce false positives in cases like
this where there is some hint as to whether the __getitem__ method is for
mapping or for sequence behavior.

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

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

From noreply at sourceforge.net  Thu Feb  8 01:07:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 16:07:50 -0800
Subject: [ python-Feature Requests-1326277 ] itertools.count wraps around
	after maxint
Message-ID: <E1HEwpK-0000GK-PP@sc8-sf-web6.sourceforge.net>

Feature Requests item #1326277, was opened at 2005-10-13 18:27
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1326277&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: itertools.count wraps around after maxint

Initial Comment:
See below.  This goes against the notion of int/long
unification and can cause weird unexpected behavior,
almost like a buffer overflow.  It should promote to a
long at the appropriate time, or that's not feasible,
then raise an exception, don't wrap around silently. 
Xrange is also not so great about this.  It at least
raises an exception if you give it too large an
endpoint, but promoting to long would be better.

Steven D'Aprano and others on clpy pointed this out.

>>> from itertools import count
>>> b=2**31 - 3
>>> c = count(b)
>>> for i in range(5):
...    print c.next()
...
2147483645
2147483646
2147483647
-2147483648
-2147483647
>>>


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-07 19:07

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

Nows raises an OverflowError instead of silently wrapping around.  See
revisions 53665 and 53666.

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

Comment By: paul rubin (phr)
Date: 2005-10-14 10:11

Message:
Logged In: YES 
user_id=72053

You're right, the docs do describe that behavior of
itertools.count (someone on clpy thought otherwise, IIRC). 
I don't see anything in
http://docs.python.org/lib/built-in-funcs.html about what
enumerate does.  It looks my p3-750 can enumerate about 400k
iterations of itertools.repeat(None) per second, so it can
reach maxint in about 1.5 hours, but I don't feel like
running it that long to see what happens. At minimum,
enumerate's doc should be updated to say what it does.

I suppose it's a matter of opinion but I'd take the view
that both of these wraparounds (assuming enumerate wraps
around) are bugs even if they're documented bugs. 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-14 02:12

Message:
Logged In: YES 
user_id=80475

It's not a bug -- it is the documented behavior.

The simple work-around is to roll your own generators:

    def count(n):
        while 1:
             yield n
             n += 1

    def enumerate(iterable):
         c = 0
         for elem in iterable:
               yield (c, elem)
               c += 1

Will look at possibly enhancing this for Py2.5.

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

Comment By: paul rubin (phr)
Date: 2005-10-14 00:53

Message:
Logged In: YES 
user_id=72053

If both fixes are feasible then promoting to long is
definitely the correct one.  Raising an exception is just a
kludge to at least not do something horrible silently. 
However, on a fast 32 bit machine, counting past 2**31 or
something is quite realistic.  A web server might send out
that many packets in a few days or weeks.  It shouldn't
crash or go crazy after running for a long time and
overflowing maxint.

It occurs to me, the enumerate iterator should also be
checked and fixed if needed.  It, too, can overflow maxint
if counting something like a network stream.  Maybe there
are some more iterators besides these, which need the same
attention.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-14 00:18

Message:
Logged In: YES 
user_id=33168

I agree something should be done.  Raymond, which behaviour
would you prefer?  I can implement if you want (just let me
know and assign back to me).

BTW, I don't have the same problem.  I need to set b = 2**63
- 3 :-)
(using current CVS).

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

Comment By: paul rubin (phr)
Date: 2005-10-13 18:29

Message:
Logged In: YES 
user_id=72053

I forgot to say, the test example is Python 2.4.1 on linux.
 I don't know if 2.4.2 has a fix.  I don't see anything
about it in the database.

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

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

From noreply at sourceforge.net  Thu Feb  8 01:08:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 16:08:30 -0800
Subject: [ python-Bugs-1512504 ] builtin enumerate overflows
Message-ID: <E1HEwpy-0001mU-Dl@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: James Harlow (hythloday)
Assigned to: Raymond Hettinger (rhettinger)
Summary: builtin enumerate overflows

Initial Comment:
The index that the builtin function enumerate() returns
is a mere integer and will wrap back to a negative
number when it overflows. This seems to be by design
(unless I'm misunderstanding the point of
PyInt_FromLong), but is sufficiently surprising that
I'd suggest it's a bug anyway. I've attached a test
case - it takes a while to execute, but the results are
so deeply exciting that it's worth doing just for fun!

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-07 19:08

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

Nows raises an OverflowError instead of silently wrapping around.  See
revisions 53665 and 53666.

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

Comment By: James Harlow (hythloday)
Date: 2006-06-27 02:25

Message:
Logged In: YES 
user_id=458963

Fair enough, I take your points both about the ease of
making a new generator. Is it possible to make the existing
one a bit less surprising, though, by having it raise an
exception when it wraps? I'm at a loss to think of any
algorithm that would work correctly when it wraps, so a new
exception wouldn't be a change in interface reeeeeeeeally. ;)

Failing that, is it possible to document it?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-06-27 00:13

Message:
Logged In: YES 
user_id=80475

You're correct.  The behavior was by design, emphasizing 
speed and simplicity over a toy limiting case.  If some 
app actually requires enumeration of over 2**31 objects, 
it is trivial to write a generator that gives the desired 
flexibility.  Of course, on 64 bit machines, the limit is 
a bit higher ;-)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-26 22:22

Message:
Logged In: YES 
user_id=33168

Raymond, any comments?

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

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

From noreply at sourceforge.net  Thu Feb  8 01:09:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 16:09:13 -0800
Subject: [ python-Feature Requests-1326277 ] itertools.count wraps around
	after maxint
Message-ID: <E1HEwqf-0005PY-3s@sc8-sf-web11.sourceforge.net>

Feature Requests item #1326277, was opened at 2005-10-13 18:27
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1326277&group_id=5470

Please note that this 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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: itertools.count wraps around after maxint

Initial Comment:
See below.  This goes against the notion of int/long
unification and can cause weird unexpected behavior,
almost like a buffer overflow.  It should promote to a
long at the appropriate time, or that's not feasible,
then raise an exception, don't wrap around silently. 
Xrange is also not so great about this.  It at least
raises an exception if you give it too large an
endpoint, but promoting to long would be better.

Steven D'Aprano and others on clpy pointed this out.

>>> from itertools import count
>>> b=2**31 - 3
>>> c = count(b)
>>> for i in range(5):
...    print c.next()
...
2147483645
2147483646
2147483647
-2147483648
-2147483647
>>>


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-07 19:07

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

Nows raises an OverflowError instead of silently wrapping around.  See
revisions 53665 and 53666.

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

Comment By: paul rubin (phr)
Date: 2005-10-14 10:11

Message:
Logged In: YES 
user_id=72053

You're right, the docs do describe that behavior of
itertools.count (someone on clpy thought otherwise, IIRC). 
I don't see anything in
http://docs.python.org/lib/built-in-funcs.html about what
enumerate does.  It looks my p3-750 can enumerate about 400k
iterations of itertools.repeat(None) per second, so it can
reach maxint in about 1.5 hours, but I don't feel like
running it that long to see what happens. At minimum,
enumerate's doc should be updated to say what it does.

I suppose it's a matter of opinion but I'd take the view
that both of these wraparounds (assuming enumerate wraps
around) are bugs even if they're documented bugs. 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-14 02:12

Message:
Logged In: YES 
user_id=80475

It's not a bug -- it is the documented behavior.

The simple work-around is to roll your own generators:

    def count(n):
        while 1:
             yield n
             n += 1

    def enumerate(iterable):
         c = 0
         for elem in iterable:
               yield (c, elem)
               c += 1

Will look at possibly enhancing this for Py2.5.

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

Comment By: paul rubin (phr)
Date: 2005-10-14 00:53

Message:
Logged In: YES 
user_id=72053

If both fixes are feasible then promoting to long is
definitely the correct one.  Raising an exception is just a
kludge to at least not do something horrible silently. 
However, on a fast 32 bit machine, counting past 2**31 or
something is quite realistic.  A web server might send out
that many packets in a few days or weeks.  It shouldn't
crash or go crazy after running for a long time and
overflowing maxint.

It occurs to me, the enumerate iterator should also be
checked and fixed if needed.  It, too, can overflow maxint
if counting something like a network stream.  Maybe there
are some more iterators besides these, which need the same
attention.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-14 00:18

Message:
Logged In: YES 
user_id=33168

I agree something should be done.  Raymond, which behaviour
would you prefer?  I can implement if you want (just let me
know and assign back to me).

BTW, I don't have the same problem.  I need to set b = 2**63
- 3 :-)
(using current CVS).

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

Comment By: paul rubin (phr)
Date: 2005-10-13 18:29

Message:
Logged In: YES 
user_id=72053

I forgot to say, the test example is Python 2.4.1 on linux.
 I don't know if 2.4.2 has a fix.  I don't see anything
about it in the database.

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

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

From noreply at sourceforge.net  Thu Feb  8 01:12:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 16:12:36 -0800
Subject: [ python-Feature Requests-1619060 ] bisect on presorted list
Message-ID: <E1HEwtw-00047W-8c@sc8-sf-web1.sourceforge.net>

Feature Requests item #1619060, was opened at 2006-12-19 16:14
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1619060&group_id=5470

Please note that this 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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeffrey C. Jacobs (timehorse)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bisect on presorted list

Initial Comment:
The python and c implementation of bisect do not support custom-sorted lists using the list.sort method.

In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I have added 3 corresponding parameters to the bisect methods for bisection and insort (insert-sorted) corresponding to the parameters in sort.  This would be useful if a list is initially sorted by its sort method and then the client wishes to maintain the sort order (or reverse-sort order) while inserting an element.  In this case, being able to use the same, arbitrary binary function cmp, unary function key and boolean reverse flag to preserve the list order.

The change imposes 3 new branch conditions and potential no-op function calls for when key is None.  I have here implemented and partially tested the python implementation and if someone besides me would find this useful, I will update the _bisectmodule.c for this change as well.

The Heap functions may also find use of an arbitrary predicate function so I may look at that later, but because bisect goes hand in hand with sorting, I wanted to tackle that first.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-12-19 16:43

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

I'm -1 on this patch.  At first blush it would seem nice to progagate
sort's notion of a key= function; however, sort() is an all at once
operation that can guarantee the function gets called only once per key. 
In contrast, bisect() is more granualar so consecutive calls may need to
invoke the same key= function again and again.  This is almost always the
the-wrong-way-to-do-it (the key function should be precomputed and either
stored separately or follow a decorate-sort pattern).  By including custom
sorting in bisect's API we would be diverting users away from better
approaches.

A better idea would be to create a recipe for a SortedList class that
performed pre-calculated custom keys upon insertion and maintained an
internal, decorated list.

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

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

From noreply at sourceforge.net  Thu Feb  8 01:13:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 16:13:07 -0800
Subject: [ python-Bugs-1602378 ] Incorrect docs for bisect_left
Message-ID: <E1HEwuR-0003v8-Fu@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: 4
Private: No
Submitted By: Daniel Eloff (eloff)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Incorrect docs for bisect_left

Initial Comment:
Quote:
Return the index where to insert item x in list a, assuming a is sorted.
    
The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x.  So if x already appears in the list, i points just before the leftmost x already there.

The last sentence is incorrect, and it contradicts what comes earlier. Not knowing which is correct, I had to test it in the shell.

>>> from bisect import *
>>> l = [1,2,3,3,3,4,5]
>>> bisect_left(l,3)
2
>>> l[2:]
[3, 3, 3, 4, 5]

It should be changed to read "i points at the leftmost x already there"

-Dan

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

Comment By: Daniel Eloff (eloff)
Date: 2006-12-03 17:39

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

That makes more sense, but if that's explained anywhere it was hidden away
where I've never discovered it. I would be in favor of you're suggested fix
to the line in question.

-Dan

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

Comment By: Tim Peters (tim_one)
Date: 2006-11-24 14:16

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

The docs are written from the POV that indices in Python point /between/
array elements, which is the easiest way to understand slices, and that
there are n+1 non-negative indices that "make obvious sense" in slices of a
sequence with n elements:  index 0 points "just before" element a[0], and
index n "just after" element a[n-1], while for 0 < i < n-1, index i points
"just before" element [i] /and/ "just after" element a[i-1].

This is also the sanest way to understand the return value of the bisect
functions, which again can return n+1 values given a sequence with n
elements.

That said, I agree the docs are cryptic if you don't understand that
first.  I'm not sure this is the best place to explain it.  The specific
line in question could be "repaired" by saying a[i] is the leftmost x
already there, identifying one of the n elements instead of one of the n+1
sequence positions.

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

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

From noreply at sourceforge.net  Thu Feb  8 01:13:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 16:13:39 -0800
Subject: [ python-Feature Requests-1462228 ] custom comparison function for
	bisect module
Message-ID: <E1HEwux-0002Ne-1V@sc8-sf-web5.sourceforge.net>

Feature Requests item #1462228, was opened at 2006-03-31 11:31
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462228&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt Fleming (splitscreen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: custom comparison function for bisect module

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

The patch is from the current trunk, r43488.

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

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

Please review, any comments welcome.

matt

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-03 17:39

Message:
Logged In: YES 
user_id=1126061

Jonathan Joseph kindly pointed out some redundant if
statements to me.

I've updated the patch with a newer version.

Matt

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

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

From noreply at sourceforge.net  Thu Feb  8 01:49:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 16:49:41 -0800
Subject: [ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HExTp-0000su-0Q@sc8-sf-web11.sourceforge.net>

Feature Requests item #1649329, was opened at 2007-01-31 18:20
Message generated for change (Comment added) made by jjinux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this 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: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

>Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:49

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

File Added: gettext.patch

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 22:45

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

Do you have a proposal on how to do the refactoring? It would be fine to
split find into two parts; it would not be acceptable (to me) to teach it
egg: URLs.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-06 14:28

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

Sorry, yes, this is a feature request.  The most important thing that I'm
requesting is to refactor the code.  That "find" function implements a
certain algorithm that has nothing to do with the filesystem.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 11:43

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

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

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

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

From noreply at sourceforge.net  Thu Feb  8 01:52:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 16:52:30 -0800
Subject: [ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HExWY-0001Ab-2E@sc8-sf-web11.sourceforge.net>

Feature Requests item #1649329, was opened at 2007-01-31 18:20
Message generated for change (Comment added) made by jjinux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this 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: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

>Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:52

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

Ok, I've uploaded a patch with a possible way to refactor the code.  I'm
okay if you mark this bug as WONTFIX.  I'm raising it as a concern because
I know there are a lot of people out there using Web frameworks such as
Pylons, Turbo Gears, etc. that are going to have to duplicate the code in
"find" in order to use eggs.  I hate to have see them do that. :-/

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:49

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

File Added: gettext.patch

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 22:45

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

Do you have a proposal on how to do the refactoring? It would be fine to
split find into two parts; it would not be acceptable (to me) to teach it
egg: URLs.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-06 14:28

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

Sorry, yes, this is a feature request.  The most important thing that I'm
requesting is to refactor the code.  That "find" function implements a
certain algorithm that has nothing to do with the filesystem.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 11:43

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

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

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

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

From noreply at sourceforge.net  Thu Feb  8 02:19:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 17:19:49 -0800
Subject: [ python-Bugs-1654408 ] Installer should split tcl/tk and tkinter
	install options.
Message-ID: <E1HExwz-000634-8j@sc8-sf-monitor2.sourceforge.net>

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

Please note that this 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: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Adam (ron_adam)
Assigned to: Martin v. L?wis (loewis)
Summary: Installer should split tcl/tk and tkinter install options.

Initial Comment:
On Windows, installing tcl/tk separately without removing tcl/tk from python can cause tkinter to be very unstable. These bugs happen even if the versions differ by only a minor release number from the version shipped with python.

Selecting to not install tcl/tk with the installer also removes tkinter, and idle.  Which is what you don't want in this case.

To be able to use tkinter and idle and a full installation of tcl/tk you need to manually remove the following:

 - python/tcl directory
 - python/dlls/tcl84.dll
 - python/dlls/tk84.dll
 - python/dlls/tclpip84.dll

(or the corresponding versions)

And then make sure tcl's bin directory is in the path. 

This also avoids problems resulting from attempting to install tcl extensions into the python tcl directory (or tcl into pythons tcl directory) which tends to not work. 

Separating the tcl/tk and tkinter/idle in the installer along with adding advise on using a separate tcl installation with python would be helpful to some people.


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

>Comment By: Ron Adam (ron_adam)
Date: 2007-02-07 19:19

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

I think part of my problem was because of having python/dlls directory in
windows file path.  So that does explain some of it. Probably due to
following instructions like this.

  
http://mail.python.org/pipermail/python-win32/2002-September/000497.html

It still would be nice to have the option to not install tcl/tk (but keep
tkinter) and use the newest update of tcl with python.

I use BLT to do graphs, and it installs fine if you remove tcl from
python, install tcl and BLT together.  Keeping tcl in python results in
the errors reported in th e above link. And following the advice and
adding python/dlls to the path can result in conflicts.  

Is that clearer.  I know this isn't a common occurrence and not a problem
with python directly.  That's why I listed it as a feature request and not
as a bug.



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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-07 15:14

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

I cannot understand why Python's Tkinter becomes unstable when Tcl is
installed, or vice versa. Are you setting any environment variables (like
TCL_HOME)? You should not do that.

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

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

From noreply at sourceforge.net  Thu Feb  8 08:39:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Feb 2007 23:39:07 -0800
Subject: [ python-Bugs-1653753 ] crash / abort during install
Message-ID: <E1HF3s3-0003Fl-Un@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: SAndreason (sandreas41)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash / abort during install

Initial Comment:
linux-2.4.33
installing Python-2.5.tar.bz2  9357099 bytes

After a successful make,
su # make install
...[clip]...
PYTHONPATH=/usr/local/lib/python2.5   \
        ./python -Wi -tt /usr/local/lib/python2.5/compileall.py \
        -d /usr/local/lib/python2.5 -f \
        -x 'bad_coding|badsyntax|site-packages' /usr/local/lib/python2.5
Listing /usr/local/lib/python2.5 ...
Compiling /usr/local/lib/python2.5/BaseHTTPServer.py ...
...[clip]...
Compiling /usr/local/lib/python2.5/xmlrpclib.py ...
Compiling /usr/local/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1


Can installation be finished manually? or is there a patch or workaround for this?

Stewart

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-08 07:39

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

Does this also fix the other bug you filed?

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

Comment By: SAndreason (sandreas41)
Date: 2007-02-07 16:04

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

Ah! That is the same problem. 
Works for me.

Thank you

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-07 08:41

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

Please check if your issue is the same as http://python.org/sf/1594809,
i.e. if you have PYTHON* environment variables set while compiling, which
is not supported.

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

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

From noreply at sourceforge.net  Thu Feb  8 09:27:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 00:27:17 -0800
Subject: [ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HF4cf-0007v8-8F@sc8-sf-web5.sourceforge.net>

Feature Requests item #1649329, was opened at 2007-02-01 03:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this 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: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-08 09:27

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

Ok, I see how this fixes find(). What about translation() (which calls
find, then also performs open())? Wouldn't this need to be fixed as well?

Also, what about os.path.join? It might depend on the structure of the
storage, as well (suppose you have the .mo data stored in a relational
database)?

In principle, I'm willing to fix this. I just want to avoid adding a
hack.

For example, it might be sensible to come up with a MOOpener interface,
that has an .exists method, taking a list of strings, a .join method,
taking a list of strings and returning something that can be passed to the
.open method, which would take something that .join returned and returning
a file-like object. It might be possible to extend the meaning of the
localedir parameter to be either a string (understood as a directory name),
or a MOOpener object.

In any case, people *will* have to duplicate find for the moment, as any
changes we discuss will only appear in 2.6.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-08 01:52

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

Ok, I've uploaded a patch with a possible way to refactor the code.  I'm
okay if you mark this bug as WONTFIX.  I'm raising it as a concern because
I know there are a lot of people out there using Web frameworks such as
Pylons, Turbo Gears, etc. that are going to have to duplicate the code in
"find" in order to use eggs.  I hate to have see them do that. :-/

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-08 01:49

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

File Added: gettext.patch

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-07 07:45

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

Do you have a proposal on how to do the refactoring? It would be fine to
split find into two parts; it would not be acceptable (to me) to teach it
egg: URLs.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-06 23:28

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

Sorry, yes, this is a feature request.  The most important thing that I'm
requesting is to refactor the code.  That "find" function implements a
certain algorithm that has nothing to do with the filesystem.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 20:43

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

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

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

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

From noreply at sourceforge.net  Thu Feb  8 09:38:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 00:38:32 -0800
Subject: [ python-Feature Requests-1654367 ] [PATCH] Debuggers need a way to
	change the locals of a frame
Message-ID: <E1HF4nY-0007T3-OX@sc8-sf-web6.sourceforge.net>

Feature Requests item #1654367, was opened at 2007-02-07 18:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654367&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabio Zadrozny (fabioz)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] Debuggers need a way to change the locals of a frame

Initial Comment:
Debuggers need a way to change the local variables in a given frame... currently, this works only if this change is done in the topmost frame (and under certain circumstances), but it should work for any frame.

Initial discussion at:
http://mail.python.org/pipermail/python-dev/2007-February/070884.html

Apparently, the problem is the order in which PyFrame_LocalsToFast / PyFrame_FastToLocals is called.

The proposed solution to this is having a savelocals() method in the frame object and have it reflect the changes in its returned dict into its locals. It will simply enable users to call PyFrame_LocalsToFast externally after a change, to be sure that it will not be changed (and it must be done before another call to PyFrame_LocalsToFast -- which I don't see as a large problem, because it is of restrict use -- mainly for debuggers).


--------- frameobject.c Patch part 1: -----------------

static PyObject *
PyFrame_SaveLocals(PyFrameObject *f)
{
    PyFrame_LocalsToFast(f, 0);
	Py_INCREF(Py_None);
	return Py_None;
}

static PyMethodDef frame_methodlist[] = {
    {"savelocals", (PyCFunction)PyFrame_SaveLocals, METH_NOARGS,
     "After a change in f_locals, this method should be called to save the changes internally."
    },
    {NULL}  /* Sentinel */
};


---------- frameobject.c Patch part 2: ---------------
Add to PyTypeObject PyFrame_Type:

frame_methodlist,/* tp_methods */

------------------ end patch -------------------------

I'm sorry that this is not in an actual patch format... but as I didn't get it from the cvs, it is easier for me to explain it (as it is a rather small patch).

Attached is a test-case for this patch.

Thanks, 

Fabio

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-08 09:38

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

Why don't you set the clear parameter to 1?

Please do submit a patch, you can use 'diff -ur' to create a recursive
unified diff between source trees. Please also try to come up with a patch
to the documentation.

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

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

From noreply at sourceforge.net  Thu Feb  8 10:18:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 01:18:06 -0800
Subject: [ python-Bugs-1653736 ] Problems in datetime.c and typeobject.c.
Message-ID: <E1HF5Po-0006gn-Lj@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems in datetime.c and typeobject.c.

Initial Comment:
This is related to [python-Bugs-1648268], but I think these problems might be important enough to consider fixing prior to any patch being produced for that item.

Modules/datetimemodule.c:time_isoformat() is declared in time_methods[] as METH_KEYWORDS. However, I believe it is better declared as METH_NOARGS (calling it with args and kwargs doesn't raise any exception, but it doesn't accept them).

Objects/typeobject.c:4428 - slot_nb_inplace_power is declared with the SLOT1() macro. I'm not sure I entirely grok what's going on here (not enough to supply a python-level failure case), but it seems to me that it should be declared with the SLOT2() macro (it's a ternary op). FWIW, I changed it from:

SLOT1(slot_nb_inplace_power, "__ipow__", PyObject *, "O")

to:

SLOT2(slot_nb_inplace_power, "__ipow__", PyObject *, PyObject *, "OO")

... and that ran the failing tests OK.

Hopefully someone familiar with this code can determine if this is correct or not.

Thanks, Kev.




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

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

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

Thanks for the report. I have fixed the first bug, in r53671 and r53672.

As for the second bug: I think your suggested change is wrong. __ipow__ is
supposed to take only two arguments. I'm unsure why nb_inplace_power is
defined with three arguments; the third argument is set to Py_None in all
places I could find. So it is, at a minimum,
ok if slot_nb_inplace_power discards its third argument; I wonder whether
the API should be changed to drop this argument entirely. This is for
python-dev to discuss.

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

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

From noreply at sourceforge.net  Thu Feb  8 10:21:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 01:21:53 -0800
Subject: [ python-Feature Requests-1654408 ] Installer should split tcl/tk and
	tkinter install options.
Message-ID: <E1HF5TV-00073T-Fz@sc8-sf-web1.sourceforge.net>

Feature Requests item #1654408, was opened at 2007-02-07 18:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654408&group_id=5470

Please note that this 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: Ron Adam (ron_adam)
Assigned to: Martin v. L?wis (loewis)
Summary: Installer should split tcl/tk and tkinter install options.

Initial Comment:
On Windows, installing tcl/tk separately without removing tcl/tk from python can cause tkinter to be very unstable. These bugs happen even if the versions differ by only a minor release number from the version shipped with python.

Selecting to not install tcl/tk with the installer also removes tkinter, and idle.  Which is what you don't want in this case.

To be able to use tkinter and idle and a full installation of tcl/tk you need to manually remove the following:

 - python/tcl directory
 - python/dlls/tcl84.dll
 - python/dlls/tk84.dll
 - python/dlls/tclpip84.dll

(or the corresponding versions)

And then make sure tcl's bin directory is in the path. 

This also avoids problems resulting from attempting to install tcl extensions into the python tcl directory (or tcl into pythons tcl directory) which tends to not work. 

Separating the tcl/tk and tkinter/idle in the installer along with adding advise on using a separate tcl installation with python would be helpful to some people.


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

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

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

Moving it to the feature-requests tracker.

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

Comment By: Ron Adam (ron_adam)
Date: 2007-02-08 02:19

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

I think part of my problem was because of having python/dlls directory in
windows file path.  So that does explain some of it. Probably due to
following instructions like this.

  
http://mail.python.org/pipermail/python-win32/2002-September/000497.html

It still would be nice to have the option to not install tcl/tk (but keep
tkinter) and use the newest update of tcl with python.

I use BLT to do graphs, and it installs fine if you remove tcl from
python, install tcl and BLT together.  Keeping tcl in python results in the
errors reported in th e above link. And following the advice and adding
python/dlls to the path can result in conflicts.  

Is that clearer.  I know this isn't a common occurrence and not a problem
with python directly.  That's why I listed it as a feature request and not
as a bug.



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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-07 22:14

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

I cannot understand why Python's Tkinter becomes unstable when Tcl is
installed, or vice versa. Are you setting any environment variables (like
TCL_HOME)? You should not do that.

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

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

From noreply at sourceforge.net  Thu Feb  8 18:16:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 09:16:04 -0800
Subject: [ python-Bugs-1655392 ] thirdparty extensions, --enable-shared,
	static linking
Message-ID: <E1HFCsO-0007kt-B3@sc8-sf-web8.sourceforge.net>

Bugs item #1655392, was opened at 2007-02-08 18: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=1655392&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: thirdparty extensions, --enable-shared, static linking

Initial Comment:
(I'm filing this under the "Build" category which may not be entirely accurate, but couldn't find a closer match. Is there a description of what the categories mean somewhere?).

Python 2.5 built with --enable-shared on linux produces a shared libpython2.5.so in the "normal" libdir and only a static libpython2.5.a in /usr/lib/python2.5/config. Normally when you build extensions you want them to link to the dynamic one. However python-config --ldflags has -L/usr/lib/python2.5/config in its output, causing build processes using it to prefer the static library over the dynamic one.

This is somewhat similar to bug 1600860: distutils does the same thing when compiling extensions in an --enable-shared python 2.5.

I think either python-config should be modified to not mention that "config" dir on an --enable-shared build or the build process should be modified to put a .so file next to the .a file in that directory.


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

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

From noreply at sourceforge.net  Thu Feb  8 20:09:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 11:09:31 -0800
Subject: [ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HFEeB-0003up-Nf@sc8-sf-web4.sourceforge.net>

Feature Requests item #1649329, was opened at 2007-01-31 18:20
Message generated for change (Comment added) made by jjinux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this 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: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

>Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-08 11:09

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

> What about translation() (which calls find, then also performs open())?
Wouldn't this need to be fixed as well?

Perhaps, but it's probably not as critical.  I.e. if the code gets
duplicated to deal with eggs, it's not as big a loss.  I really wish the
distutils guys would weigh in on this one.

> Also, what about os.path.join?

I think it's relatively harmless.  One can work around that.  One can't
work around os.path.exists.

> In principle, I'm willing to fix this. I just want to avoid adding a
hack.

I agree.  The patch isn't smelling too pretty.  Neither of us wants to
commit to a virtual filesystem layer which is how I've handled problems
like this in the past.  However, doing nothing results in a ton of code
being duplicated in any project that uses gettext and zipped eggs.  Should
we see if Phillip Eby has any ideas since he's Mr. Eggs?

> For example, it might be sensible to come up with a MOOpener interface,
that has an .exists method, taking a list of strings, a .join method,
taking a list of strings and returning something that can be passed to
the
.open method, which would take something that .join returned and
returning
a file-like object. It might be possible to extend the meaning of the
localedir parameter to be either a string (understood as a directory
name),
or a MOOpener object.

That's a light virtual filesystem layer ;)  If you want that, I have code
for that.

> In any case, people *will* have to duplicate find for the moment, as any
changes we discuss will only appear in 2.6.

True.  Alas, this may be a moot point.

Thanks for your time.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-08 00:27

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

Ok, I see how this fixes find(). What about translation() (which calls
find, then also performs open())? Wouldn't this need to be fixed as well?

Also, what about os.path.join? It might depend on the structure of the
storage, as well (suppose you have the .mo data stored in a relational
database)?

In principle, I'm willing to fix this. I just want to avoid adding a
hack.

For example, it might be sensible to come up with a MOOpener interface,
that has an .exists method, taking a list of strings, a .join method,
taking a list of strings and returning something that can be passed to the
.open method, which would take something that .join returned and returning
a file-like object. It might be possible to extend the meaning of the
localedir parameter to be either a string (understood as a directory name),
or a MOOpener object.

In any case, people *will* have to duplicate find for the moment, as any
changes we discuss will only appear in 2.6.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:52

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

Ok, I've uploaded a patch with a possible way to refactor the code.  I'm
okay if you mark this bug as WONTFIX.  I'm raising it as a concern because
I know there are a lot of people out there using Web frameworks such as
Pylons, Turbo Gears, etc. that are going to have to duplicate the code in
"find" in order to use eggs.  I hate to have see them do that. :-/

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:49

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

File Added: gettext.patch

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 22:45

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

Do you have a proposal on how to do the refactoring? It would be fine to
split find into two parts; it would not be acceptable (to me) to teach it
egg: URLs.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-06 14:28

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

Sorry, yes, this is a feature request.  The most important thing that I'm
requesting is to refactor the code.  That "find" function implements a
certain algorithm that has nothing to do with the filesystem.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 11:43

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

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

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

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

From noreply at sourceforge.net  Thu Feb  8 20:11:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 11:11:50 -0800
Subject: [ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Message-ID: <E1HFEgQ-00047N-MP@sc8-sf-web4.sourceforge.net>

Feature Requests item #1649329, was opened at 2007-01-31 18:20
Message generated for change (Comment added) made by jjinux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this 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: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

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

>Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-08 11:11

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

Perhaps instead of committing to a special virtual filesystem layer,
perhaps we should just take something that matches some subset of the posix
interface.  We can document the functions we need.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-08 11:09

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

> What about translation() (which calls find, then also performs open())?
Wouldn't this need to be fixed as well?

Perhaps, but it's probably not as critical.  I.e. if the code gets
duplicated to deal with eggs, it's not as big a loss.  I really wish the
distutils guys would weigh in on this one.

> Also, what about os.path.join?

I think it's relatively harmless.  One can work around that.  One can't
work around os.path.exists.

> In principle, I'm willing to fix this. I just want to avoid adding a
hack.

I agree.  The patch isn't smelling too pretty.  Neither of us wants to
commit to a virtual filesystem layer which is how I've handled problems
like this in the past.  However, doing nothing results in a ton of code
being duplicated in any project that uses gettext and zipped eggs.  Should
we see if Phillip Eby has any ideas since he's Mr. Eggs?

> For example, it might be sensible to come up with a MOOpener interface,
that has an .exists method, taking a list of strings, a .join method,
taking a list of strings and returning something that can be passed to
the
.open method, which would take something that .join returned and
returning
a file-like object. It might be possible to extend the meaning of the
localedir parameter to be either a string (understood as a directory
name),
or a MOOpener object.

That's a light virtual filesystem layer ;)  If you want that, I have code
for that.

> In any case, people *will* have to duplicate find for the moment, as any
changes we discuss will only appear in 2.6.

True.  Alas, this may be a moot point.

Thanks for your time.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-08 00:27

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

Ok, I see how this fixes find(). What about translation() (which calls
find, then also performs open())? Wouldn't this need to be fixed as well?

Also, what about os.path.join? It might depend on the structure of the
storage, as well (suppose you have the .mo data stored in a relational
database)?

In principle, I'm willing to fix this. I just want to avoid adding a
hack.

For example, it might be sensible to come up with a MOOpener interface,
that has an .exists method, taking a list of strings, a .join method,
taking a list of strings and returning something that can be passed to the
.open method, which would take something that .join returned and returning
a file-like object. It might be possible to extend the meaning of the
localedir parameter to be either a string (understood as a directory name),
or a MOOpener object.

In any case, people *will* have to duplicate find for the moment, as any
changes we discuss will only appear in 2.6.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:52

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

Ok, I've uploaded a patch with a possible way to refactor the code.  I'm
okay if you mark this bug as WONTFIX.  I'm raising it as a concern because
I know there are a lot of people out there using Web frameworks such as
Pylons, Turbo Gears, etc. that are going to have to duplicate the code in
"find" in order to use eggs.  I hate to have see them do that. :-/

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:49

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

File Added: gettext.patch

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 22:45

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

Do you have a proposal on how to do the refactoring? It would be fine to
split find into two parts; it would not be acceptable (to me) to teach it
egg: URLs.

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

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-06 14:28

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

Sorry, yes, this is a feature request.  The most important thing that I'm
requesting is to refactor the code.  That "find" function implements a
certain algorithm that has nothing to do with the filesystem.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 11:43

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

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

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

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

From noreply at sourceforge.net  Fri Feb  9 00:37:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 15:37:14 -0800
Subject: [ python-Bugs-900092 ] hotshot.stats.load
Message-ID: <E1HFIpG-0008Kk-04@sc8-sf-web1.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Brett Cannon (bcannon)
Summary: hotshot.stats.load

Initial Comment:
trying to do a 

hotshot.stats.load("myprofiling_file.prof")

fails with assertionerror

assert not self._stack


python 2.3.2 on WinXP



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

Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 23:37

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

Has this ever been reported again since it was closed ? I just got it
today (python 2.5). The prof file is 11MB, I'll see if I can reproduce the
bug with a smaller one.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-08-15 18:14

Message:
Logged In: YES 
user_id=12800

Patches applied for Python 2.4.2 and 2.5a1


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-08 15:02

Message:
Logged In: YES 
user_id=12800

900092-patch-2.txt fixes the test suite for the extra return
event.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-07 23:26

Message:
Logged In: YES 
user_id=12800

See 900092-patch.txt for a candidate patch against Python
2.4.1.  Props to Justin Campbell for most of the heavily
lifting (but you can blame me for any problems ;).

This fix restore the tracing of a 'return' event for
exceptions that cause a function to exit.

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

Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 23:54

Message:
Logged In: YES 
user_id=86307

Well, the superficial fix doesn't work (sorry for posting
too soon).  It turns out that PyTrace_EXCEPTION is sent for
any exception, not just one causing the function to exit. 
So I guess the best fix may be to have hotshot always
install its profiler_callback to handle CALLS and RETURNS,
and then optionally install the tracer_callback to handle
only LINEs.  Anyway, that works for the one test case I've
been using (a runcall of a function which simply does
"import pickle").

By the way, I'm testing with 2.4b1.

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

Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 23:32

Message:
Logged In: YES 
user_id=86307

I ran into this today, so I decided to look into it.  It
looks to me like the problem only happens if you profile
with lineevents enabled.  In that case, hotshot uses the
tracer_callback function (in _hotshot.c) to dispatch trace
events.  This function explicitly ignores exception returns
(PyTrace_EXCEPTION), which can lead to an unbalanced stack
of calls/returns when the log is loaded (if an profiled
function exits with an exception).

It seems on the surface that tracer_callback ought to handle
exceptions the same way as normal returns.  This would be
consistent with what happens when profiler_callback is used,
since PyEval_EvalFrame dispatches sends a Py_RETURN to
c_profilefunc when exiting because of an exception.


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-09-27 14:41

Message:
Logged In: YES 
user_id=12800

Could this be related to 1019882?


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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 22:00

Message:
Logged In: YES 
user_id=469548

Hmm, the file was too big, even though it was compressed.
I've uploaded it to
http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2
now.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 21:58

Message:
Logged In: YES 
user_id=469548

While the original report isn't very useful, I've ran into
this problem multiple times as well. I can reproduce it
using the attached profile file (compressed because of the
large size) and the following console session:

Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import hotshot.stats
>>> stats = hotshot.stats.load('roundup.prof')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load
    return StatsLoader(filename).load()
  File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load
    assert not self._stack
AssertionError
>>>

I'm not sure who's baby hotshot really is, so I'm leaving
this unassigned.

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

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

From noreply at sourceforge.net  Fri Feb  9 01:08:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 16:08:53 -0800
Subject: [ python-Bugs-900092 ] hotshot.stats.load
Message-ID: <E1HFJJt-0006Fy-QI@sc8-sf-web6.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Brett Cannon (bcannon)
Summary: hotshot.stats.load

Initial Comment:
trying to do a 

hotshot.stats.load("myprofiling_file.prof")

fails with assertionerror

assert not self._stack


python 2.3.2 on WinXP



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

Comment By: George Sakkis (gsakkis)
Date: 2007-02-09 00:08

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

Ok, I reduced the prof file to 38K. Can I upload an attachment here ? I
don't see how.

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

Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 23:37

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

Has this ever been reported again since it was closed ? I just got it
today (python 2.5). The prof file is 11MB, I'll see if I can reproduce the
bug with a smaller one.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-08-15 18:14

Message:
Logged In: YES 
user_id=12800

Patches applied for Python 2.4.2 and 2.5a1


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-08 15:02

Message:
Logged In: YES 
user_id=12800

900092-patch-2.txt fixes the test suite for the extra return
event.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-07 23:26

Message:
Logged In: YES 
user_id=12800

See 900092-patch.txt for a candidate patch against Python
2.4.1.  Props to Justin Campbell for most of the heavily
lifting (but you can blame me for any problems ;).

This fix restore the tracing of a 'return' event for
exceptions that cause a function to exit.

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

Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 23:54

Message:
Logged In: YES 
user_id=86307

Well, the superficial fix doesn't work (sorry for posting
too soon).  It turns out that PyTrace_EXCEPTION is sent for
any exception, not just one causing the function to exit. 
So I guess the best fix may be to have hotshot always
install its profiler_callback to handle CALLS and RETURNS,
and then optionally install the tracer_callback to handle
only LINEs.  Anyway, that works for the one test case I've
been using (a runcall of a function which simply does
"import pickle").

By the way, I'm testing with 2.4b1.

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

Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 23:32

Message:
Logged In: YES 
user_id=86307

I ran into this today, so I decided to look into it.  It
looks to me like the problem only happens if you profile
with lineevents enabled.  In that case, hotshot uses the
tracer_callback function (in _hotshot.c) to dispatch trace
events.  This function explicitly ignores exception returns
(PyTrace_EXCEPTION), which can lead to an unbalanced stack
of calls/returns when the log is loaded (if an profiled
function exits with an exception).

It seems on the surface that tracer_callback ought to handle
exceptions the same way as normal returns.  This would be
consistent with what happens when profiler_callback is used,
since PyEval_EvalFrame dispatches sends a Py_RETURN to
c_profilefunc when exiting because of an exception.


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-09-27 14:41

Message:
Logged In: YES 
user_id=12800

Could this be related to 1019882?


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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 22:00

Message:
Logged In: YES 
user_id=469548

Hmm, the file was too big, even though it was compressed.
I've uploaded it to
http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2
now.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 21:58

Message:
Logged In: YES 
user_id=469548

While the original report isn't very useful, I've ran into
this problem multiple times as well. I can reproduce it
using the attached profile file (compressed because of the
large size) and the following console session:

Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import hotshot.stats
>>> stats = hotshot.stats.load('roundup.prof')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load
    return StatsLoader(filename).load()
  File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load
    assert not self._stack
AssertionError
>>>

I'm not sure who's baby hotshot really is, so I'm leaving
this unassigned.

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

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

From noreply at sourceforge.net  Fri Feb  9 02:48:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 17:48:41 -0800
Subject: [ python-Bugs-1655683 ] 3.4.1 comparison methods content
Message-ID: <E1HFKsT-0002LO-O6@sc8-sf-web4.sourceforge.net>

Bugs item #1655683, was opened at 2007-02-09 01: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=1655683&group_id=5470

Please note that this 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: Jeffrey Miller (jsmgoogle)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.4.1 comparison methods content

Initial Comment:
From: Jeffrey Miller <jsmiller at google.com>

At this URL and this section of the reference:

http://docs.python.org/ref/customization.html

3.4.1 Basic Customization

The existing text reads, in part:

"""
    There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection.
"""

but is incorrect.  Although __le__ and __ge__ are symmetric, as are __lt__ and __gt__, they are not boolean inverse operations if the arguments are swapped.

Instead the text should pair __lt__ with __ge__, __le__ with __gt__ .

Correcting the given text, it should read:

"""
    There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __ge__() are each other's reflection, __le__() and __gt__() are each other's reflection, and __eq__() and __ne__() are their own reflection.
"""


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

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

From noreply at sourceforge.net  Fri Feb  9 08:54:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Feb 2007 23:54:15 -0800
Subject: [ python-Bugs-1655800 ] email.Generator docs contain a bad off-site
	link
Message-ID: <E1HFQaF-0007UB-8x@sc8-sf-web9.sourceforge.net>

Bugs item #1655800, was opened at 2007-02-08 23: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=1655800&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Forest Wilkinson (forest)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Generator docs contain a bad off-site link

Initial Comment:
The email.Generator module documentation contains this off-site link, entitled "WHY THE CONTENT-LENGTH FORMAT IS BAD":

http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html

That page no longer exists, and hasn't for quite a while, according to archive.org.  Perhaps the python docs should refer to another source for that informative rant from jwz.

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

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

From noreply at sourceforge.net  Fri Feb  9 12:43:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 03:43:36 -0800
Subject: [ python-Bugs-455694 ] bug in list append, or list multiply?
Message-ID: <E1HFUAC-0001f7-7u@sc8-sf-web6.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bug in list append, or list multiply?

Initial Comment:
Python 2.1.1 (Windows NT 4)

&gt;&gt;&gt; x=6*[[]]
&gt;&gt;&gt; x
[[], [], [], [], [], []]
&gt;&gt;&gt; x[3].append(7)
&gt;&gt;&gt; x
[[7], [7], [7], [7], [7], [7]]

But, I was expecting:

[[], [], [], [7], [], []]

So I then tried this:

&gt;&gt;&gt; x=[[],[],[],[],[],[]] # instead of x=6*[[]]
&gt;&gt;&gt; x[3].append(7)
&gt;&gt;&gt; x
[[], [], [], [7], [], []]

And it worked.

----

I imagine what is happening is that 6*[[]] creates 6 pointers to the same empty list?  But, if so, 
the python docs (http://www.python.org/doc/current/lib/typesseq.html) imply otherwise:

s * n , n * s yields n _copies_ of s concatenated

Anyway, I'm confused.

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

Comment By: M.Hampton (hamptonio)
Date: 2007-02-09 05:43

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

This really messed me recently, and I consider it a definite bug.  It is
still present in python 2.5 on multiple platforms.  

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 09:56

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libstdtypes.tex revision 1.68.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-27 16:25

Message:
Logged In: YES 
user_id=31435

Changed to Doc and reassigned to Fred.  The docs may be 
clearer if they said &quot;n shallow copies&quot; instead of &quot;n 
copies&quot;.

&gt;&gt;&gt; s = [[]]
&gt;&gt;&gt; from copy import copy
&gt;&gt;&gt; x = copy(s) + copy(s) + copy(s)
&gt;&gt;&gt; x
[[], [], []]
&gt;&gt;&gt; x[1].append(7)
&gt;&gt;&gt; x
[[7], [7], [7]]
&gt;&gt;&gt;

That is, &quot;s*n is n copies of s concatenated&quot; is correct, 
but only if you have shallow copies in mind.

Anonymous, the effect you *want* can be gotten via

x = []
for i in range(6):
    x.append([])

or, in Python 2.0+ via

x = [[] for i in range(6)]

Doing

[O] * n

creates a list with n repetitions of O, i.e. exactly the 
same object n times, the same as [O, O, O, ...].  In

[[], []]

you create two distinct empty lists, but in

temp = []
[temp, temp]

you get a single empty list twice.  Same thing for

[[]] * n

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

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

From noreply at sourceforge.net  Fri Feb  9 13:20:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 04:20:54 -0800
Subject: [ python-Bugs-1653736 ] Problems in datetime.c and typeobject.c.
Message-ID: <E1HFUkI-00085I-GQ@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems in datetime.c and typeobject.c.

Initial Comment:
This is related to [python-Bugs-1648268], but I think these problems might be important enough to consider fixing prior to any patch being produced for that item.

Modules/datetimemodule.c:time_isoformat() is declared in time_methods[] as METH_KEYWORDS. However, I believe it is better declared as METH_NOARGS (calling it with args and kwargs doesn't raise any exception, but it doesn't accept them).

Objects/typeobject.c:4428 - slot_nb_inplace_power is declared with the SLOT1() macro. I'm not sure I entirely grok what's going on here (not enough to supply a python-level failure case), but it seems to me that it should be declared with the SLOT2() macro (it's a ternary op). FWIW, I changed it from:

SLOT1(slot_nb_inplace_power, "__ipow__", PyObject *, "O")

to:

SLOT2(slot_nb_inplace_power, "__ipow__", PyObject *, PyObject *, "OO")

... and that ran the failing tests OK.

Hopefully someone familiar with this code can determine if this is correct or not.

Thanks, Kev.




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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-09 13:20

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

The second bug should now be fixed in r53689 and r53690.

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

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

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

Thanks for the report. I have fixed the first bug, in r53671 and r53672.

As for the second bug: I think your suggested change is wrong. __ipow__ is
supposed to take only two arguments. I'm unsure why nb_inplace_power is
defined with three arguments; the third argument is set to Py_None in all
places I could find. So it is, at a minimum,
ok if slot_nb_inplace_power discards its third argument; I wonder whether
the API should be changed to drop this argument entirely. This is for
python-dev to discuss.

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

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

From noreply at sourceforge.net  Fri Feb  9 13:21:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 04:21:38 -0800
Subject: [ python-Bugs-1653736 ] Problems in datetime.c and typeobject.c.
Message-ID: <E1HFUl0-0001Br-4c@sc8-sf-web8.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems in datetime.c and typeobject.c.

Initial Comment:
This is related to [python-Bugs-1648268], but I think these problems might be important enough to consider fixing prior to any patch being produced for that item.

Modules/datetimemodule.c:time_isoformat() is declared in time_methods[] as METH_KEYWORDS. However, I believe it is better declared as METH_NOARGS (calling it with args and kwargs doesn't raise any exception, but it doesn't accept them).

Objects/typeobject.c:4428 - slot_nb_inplace_power is declared with the SLOT1() macro. I'm not sure I entirely grok what's going on here (not enough to supply a python-level failure case), but it seems to me that it should be declared with the SLOT2() macro (it's a ternary op). FWIW, I changed it from:

SLOT1(slot_nb_inplace_power, "__ipow__", PyObject *, "O")

to:

SLOT2(slot_nb_inplace_power, "__ipow__", PyObject *, PyObject *, "OO")

... and that ran the failing tests OK.

Hopefully someone familiar with this code can determine if this is correct or not.

Thanks, Kev.




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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-09 13:20

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

The second bug should now be fixed in r53689 and r53690.

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

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

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

Thanks for the report. I have fixed the first bug, in r53671 and r53672.

As for the second bug: I think your suggested change is wrong. __ipow__ is
supposed to take only two arguments. I'm unsure why nb_inplace_power is
defined with three arguments; the third argument is set to Py_None in all
places I could find. So it is, at a minimum,
ok if slot_nb_inplace_power discards its third argument; I wonder whether
the API should be changed to drop this argument entirely. This is for
python-dev to discuss.

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

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

From noreply at sourceforge.net  Fri Feb  9 13:38:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 04:38:04 -0800
Subject: [ python-Bugs-1600860 ] --enable-shared links extensions to libpython
	statically
Message-ID: <E1HFV0u-0001Lt-NZ@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: --enable-shared links extensions to libpython statically

Initial Comment:
python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes.

There is a comment on the referenced bug saying

"""
You can probably rely on libpythonxy.so ending up in
$(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can
retrieve from the installed Makefile (i.e. through
distutils.config).
"""

so I think the patch that got applied does not do what was intended.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-09 13:38

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

Thanks for the patch. Committed as r53691 and r53692.

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

Comment By: Marien Zwart (marienz)
Date: 2006-11-27 02:01

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

Yes, that seems to fix it, thanks!

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

Comment By: Martin v. L?wis (loewis)
Date: 2006-11-25 14:42

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

gustavo: you can only attach a patch if you are team member or creator of
the bug report. I'm attaching your patch.

marienz: can you please confirm whether this patch solves this problem?

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

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-11-25 14:10

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

*sigh* why doesn't SF let me attach patches? :(

You can find a patch to fix this here:
http://www.gnome.org/~gjc/linux-shlib.diff


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

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-11-23 21:47

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

Hmm.. I think I wrongfully assumed $prefix/lib/pythonX.Y/config contained
a shared python library in addition to the static one.  It seems that was
an Ubuntu specific thing :|

I'll take a good look and fix this within a couple of days...

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

Comment By: Marien Zwart (marienz)
Date: 2006-11-22 14:02

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

I can reproduce this by using either gentoo's python 2.5 or one I
installed temporarily with ./configure --enable-shared --prefix
$HOME/tmp/pytem, using a trivial distutils extension (I used
http://dev.gentooexperimental.org/~marienz/ext.c and
http://dev.gentooexperimental.org/~marienz/setup.py for testing). The
relevant command that is run is:

gcc -pthread -shared build/temp.linux-i686-2.5/ext.o
-L/home/marienz/tmp/pytem/lib/python2.5/config -lpython2.5 -o
build/lib.linux-i686-2.5/ext.so

for the manually-configured python and something similar for gentoo's
python. The code doing the adding was added by r45232 in svn. From the diff
(svn di -r45231:45232
http://svn.python.org/projects/python/trunk/Lib/distutils/command/build_ext.py)
with some extra context added:

-        if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos':
+        if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos'
or \
+               (sys.platform.startswith('linux') and
+                sysconfig.get_config_var('Py_ENABLE_SHARED')):
             if string.find(sys.executable, sys.exec_prefix) != -1:
                 # building third party extensions
                 self.library_dirs.append(os.path.join(sys.prefix, "lib",
                                                      "python" +
get_python_version(),
                                                      "config"))

(that is around line 188 of Lib/distutils/command/build_ext.py)

sys.platform on this host is linux2 and as far as I can tell
Py_ENABLE_SHARED is true if --enable-shared is passed to configure.

If you need any more information please ask.

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

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

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

I can't reproduce the problem. Why do you think
-L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT,
it never is.

What operating system are you using?

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

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

From noreply at sourceforge.net  Fri Feb  9 13:46:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 04:46:13 -0800
Subject: [ python-Bugs-1655392 ] thirdparty extensions, --enable-shared,
	static linking
Message-ID: <E1HFV8n-000117-AD@sc8-sf-monitor2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marien Zwart (marienz)
>Assigned to: Georg Brandl (gbrandl)
Summary: thirdparty extensions, --enable-shared, static linking

Initial Comment:
(I'm filing this under the "Build" category which may not be entirely accurate, but couldn't find a closer match. Is there a description of what the categories mean somewhere?).

Python 2.5 built with --enable-shared on linux produces a shared libpython2.5.so in the "normal" libdir and only a static libpython2.5.a in /usr/lib/python2.5/config. Normally when you build extensions you want them to link to the dynamic one. However python-config --ldflags has -L/usr/lib/python2.5/config in its output, causing build processes using it to prefer the static library over the dynamic one.

This is somewhat similar to bug 1600860: distutils does the same thing when compiling extensions in an --enable-shared python 2.5.

I think either python-config should be modified to not mention that "config" dir on an --enable-shared build or the build process should be modified to put a .so file next to the .a file in that directory.


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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-09 13:46

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

The categories aren't described anywhere.

python-config should describe the installed code; we shouldn't change what
gets installed how for 2.5.1.

Georg, with python-config being your code, can you take a look? If not,
please unassign (in which case I'd ask marienz whether he would like to
contribute a patch).

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

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

From noreply at sourceforge.net  Fri Feb  9 13:54:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 04:54:25 -0800
Subject: [ python-Bugs-1655683 ] 3.4.1 comparison methods content
Message-ID: <E1HFVGj-00007I-Eg@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: Jeffrey Miller (jsmgoogle)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.4.1 comparison methods content

Initial Comment:
From: Jeffrey Miller <jsmiller at google.com>

At this URL and this section of the reference:

http://docs.python.org/ref/customization.html

3.4.1 Basic Customization

The existing text reads, in part:

"""
    There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection.
"""

but is incorrect.  Although __le__ and __ge__ are symmetric, as are __lt__ and __gt__, they are not boolean inverse operations if the arguments are swapped.

Instead the text should pair __lt__ with __ge__, __le__ with __gt__ .

Correcting the given text, it should read:

"""
    There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __ge__() are each other's reflection, __le__() and __gt__() are each other's reflection, and __eq__() and __ne__() are their own reflection.
"""


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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-09 13:54

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

I cannot see a bug there.

The text doesn't talk about boolean inverse operations, it talks about
reflected operations, and defines that term as "to be used when the left
argument does not support the operation but the right argument does")

Consider this code:

>>> class A:
...   pass
... 
>>> class B:
...   def __gt__(self, other):
...     print "gt"
...     return True
...   def __ge__(self, other):
...     print "ge"
...     return True
... 
>>> A()<B()
gt
True

According to your "corrected" text, lack of __lt__ in class A should cause
__ge__ of class B to be called. As you can see, it calls __gt__ instead
(just as the documentation predicts). Indeed, x<y should be considered
equal to y>x.

Closing the report as invalid.

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

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

From noreply at sourceforge.net  Fri Feb  9 14:00:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 05:00:49 -0800
Subject: [ python-Bugs-1655800 ] email.Generator docs contain a bad off-site
	link
Message-ID: <E1HFVMv-0003Yu-43@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: Fixed
Priority: 5
Private: No
Submitted By: Forest Wilkinson (forest)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Generator docs contain a bad off-site link

Initial Comment:
The email.Generator module documentation contains this off-site link, entitled "WHY THE CONTENT-LENGTH FORMAT IS BAD":

http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html

That page no longer exists, and hasn't for quite a while, according to archive.org.  Perhaps the python docs should refer to another source for that informative rant from jwz.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-09 14:00

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

Thanks for the report. I updated it to

http://www.jwz.org/doc/content-length.html

in r53693 and r53694. This will hopefully be a bit more permanent.

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

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

From noreply at sourceforge.net  Fri Feb  9 15:03:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 06:03:37 -0800
Subject: [ python-Bugs-1656078 ] Typo in Docs
Message-ID: <E1HFWLh-00007U-Jg@sc8-sf-monitor2.sourceforge.net>

Bugs item #1656078, was opened at 2007-02-09 14: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=1656078&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in Docs

Initial Comment:
http://docs.python.org/dev/lib/module-profile.html

"""
This function takes a single argument that has can be passed to the exec statement,"""

I think the "has" should be deleted.

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

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

From noreply at sourceforge.net  Fri Feb  9 19:15:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 10:15:05 -0800
Subject: [ python-Bugs-900092 ] hotshot.stats.load
Message-ID: <E1HFaH3-0000a7-Cr@sc8-sf-web7.sourceforge.net>

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

Please note that this 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: Simon Dahlbacka (sdahlbac)
>Assigned to: Nobody/Anonymous (nobody)
Summary: hotshot.stats.load

Initial Comment:
trying to do a 

hotshot.stats.load("myprofiling_file.prof")

fails with assertionerror

assert not self._stack


python 2.3.2 on WinXP



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

>Comment By: Brett Cannon (bcannon)
Date: 2007-02-09 10:15

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

I think only OPs and project members can upload.  Email it to me, George
(brett at python.org), mention the bug # and I will upload it.

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

Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 16:08

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

Ok, I reduced the prof file to 38K. Can I upload an attachment here ? I
don't see how.

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

Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 15:37

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

Has this ever been reported again since it was closed ? I just got it
today (python 2.5). The prof file is 11MB, I'll see if I can reproduce the
bug with a smaller one.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-08-15 11:14

Message:
Logged In: YES 
user_id=12800

Patches applied for Python 2.4.2 and 2.5a1


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-08 08:02

Message:
Logged In: YES 
user_id=12800

900092-patch-2.txt fixes the test suite for the extra return
event.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-07 16:26

Message:
Logged In: YES 
user_id=12800

See 900092-patch.txt for a candidate patch against Python
2.4.1.  Props to Justin Campbell for most of the heavily
lifting (but you can blame me for any problems ;).

This fix restore the tracing of a 'return' event for
exceptions that cause a function to exit.

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

Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 15:54

Message:
Logged In: YES 
user_id=86307

Well, the superficial fix doesn't work (sorry for posting
too soon).  It turns out that PyTrace_EXCEPTION is sent for
any exception, not just one causing the function to exit. 
So I guess the best fix may be to have hotshot always
install its profiler_callback to handle CALLS and RETURNS,
and then optionally install the tracer_callback to handle
only LINEs.  Anyway, that works for the one test case I've
been using (a runcall of a function which simply does
"import pickle").

By the way, I'm testing with 2.4b1.

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

Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 15:32

Message:
Logged In: YES 
user_id=86307

I ran into this today, so I decided to look into it.  It
looks to me like the problem only happens if you profile
with lineevents enabled.  In that case, hotshot uses the
tracer_callback function (in _hotshot.c) to dispatch trace
events.  This function explicitly ignores exception returns
(PyTrace_EXCEPTION), which can lead to an unbalanced stack
of calls/returns when the log is loaded (if an profiled
function exits with an exception).

It seems on the surface that tracer_callback ought to handle
exceptions the same way as normal returns.  This would be
consistent with what happens when profiler_callback is used,
since PyEval_EvalFrame dispatches sends a Py_RETURN to
c_profilefunc when exiting because of an exception.


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-09-27 07:41

Message:
Logged In: YES 
user_id=12800

Could this be related to 1019882?


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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 15:00

Message:
Logged In: YES 
user_id=469548

Hmm, the file was too big, even though it was compressed.
I've uploaded it to
http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2
now.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 14:58

Message:
Logged In: YES 
user_id=469548

While the original report isn't very useful, I've ran into
this problem multiple times as well. I can reproduce it
using the attached profile file (compressed because of the
large size) and the following console session:

Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import hotshot.stats
>>> stats = hotshot.stats.load('roundup.prof')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load
    return StatsLoader(filename).load()
  File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load
    assert not self._stack
AssertionError
>>>

I'm not sure who's baby hotshot really is, so I'm leaving
this unassigned.

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

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

From noreply at sourceforge.net  Fri Feb  9 19:35:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 10:35:07 -0800
Subject: [ python-Bugs-1655683 ] 3.4.1 comparison methods content
Message-ID: <E1HFaaR-0002kX-Vw@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: Jeffrey Miller (jsmgoogle)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.4.1 comparison methods content

Initial Comment:
From: Jeffrey Miller <jsmiller at google.com>

At this URL and this section of the reference:

http://docs.python.org/ref/customization.html

3.4.1 Basic Customization

The existing text reads, in part:

"""
    There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection.
"""

but is incorrect.  Although __le__ and __ge__ are symmetric, as are __lt__ and __gt__, they are not boolean inverse operations if the arguments are swapped.

Instead the text should pair __lt__ with __ge__, __le__ with __gt__ .

Correcting the given text, it should read:

"""
    There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __ge__() are each other's reflection, __le__() and __gt__() are each other's reflection, and __eq__() and __ne__() are their own reflection.
"""


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

>Comment By: Jeffrey Miller (jsmgoogle)
Date: 2007-02-09 18:35

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

I stand corrected.  Thank you for taking the time to elucidate. (A <= B is
equivalent to the swapped operation B >= A)

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-09 12:54

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

I cannot see a bug there.

The text doesn't talk about boolean inverse operations, it talks about
reflected operations, and defines that term as "to be used when the left
argument does not support the operation but the right argument does")

Consider this code:

>>> class A:
...   pass
... 
>>> class B:
...   def __gt__(self, other):
...     print "gt"
...     return True
...   def __ge__(self, other):
...     print "ge"
...     return True
... 
>>> A()<B()
gt
True

According to your "corrected" text, lack of __lt__ in class A should cause
__ge__ of class B to be called. As you can see, it calls __gt__ instead
(just as the documentation predicts). Indeed, x<y should be considered
equal to y>x.

Closing the report as invalid.

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

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

From noreply at sourceforge.net  Fri Feb  9 19:49:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 10:49:30 -0800
Subject: [ python-Bugs-1656078 ] Typo in Docs
Message-ID: <E1HFaoM-0000lj-Nj@sc8-sf-web6.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in Docs

Initial Comment:
http://docs.python.org/dev/lib/module-profile.html

"""
This function takes a single argument that has can be passed to the exec statement,"""

I think the "has" should be deleted.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-09 18:49

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

Thanks for reporting, fixed in rev. 53697, 53698 (2.5).

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

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

From noreply at sourceforge.net  Fri Feb  9 19:50:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 10:50:22 -0800
Subject: [ python-Bugs-455694 ] bug in list append, or list multiply?
Message-ID: <E1HFapB-0000rW-SP@sc8-sf-web6.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bug in list append, or list multiply?

Initial Comment:
Python 2.1.1 (Windows NT 4)

&gt;&gt;&gt; x=6*[[]]
&gt;&gt;&gt; x
[[], [], [], [], [], []]
&gt;&gt;&gt; x[3].append(7)
&gt;&gt;&gt; x
[[7], [7], [7], [7], [7], [7]]

But, I was expecting:

[[], [], [], [7], [], []]

So I then tried this:

&gt;&gt;&gt; x=[[],[],[],[],[],[]] # instead of x=6*[[]]
&gt;&gt;&gt; x[3].append(7)
&gt;&gt;&gt; x
[[], [], [], [7], [], []]

And it worked.

----

I imagine what is happening is that 6*[[]] creates 6 pointers to the same empty list?  But, if so, 
the python docs (http://www.python.org/doc/current/lib/typesseq.html) imply otherwise:

s * n , n * s yields n _copies_ of s concatenated

Anyway, I'm confused.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-09 18:50

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

This behavior is not a bug, it is how objects in Python and the '*'
operator for lists work.

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

Comment By: M.Hampton (hamptonio)
Date: 2007-02-09 11:43

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

This really messed me recently, and I consider it a definite bug.  It is
still present in python 2.5 on multiple platforms.  

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 14:56

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libstdtypes.tex revision 1.68.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-27 21:25

Message:
Logged In: YES 
user_id=31435

Changed to Doc and reassigned to Fred.  The docs may be 
clearer if they said &quot;n shallow copies&quot; instead of &quot;n 
copies&quot;.

&gt;&gt;&gt; s = [[]]
&gt;&gt;&gt; from copy import copy
&gt;&gt;&gt; x = copy(s) + copy(s) + copy(s)
&gt;&gt;&gt; x
[[], [], []]
&gt;&gt;&gt; x[1].append(7)
&gt;&gt;&gt; x
[[7], [7], [7]]
&gt;&gt;&gt;

That is, &quot;s*n is n copies of s concatenated&quot; is correct, 
but only if you have shallow copies in mind.

Anonymous, the effect you *want* can be gotten via

x = []
for i in range(6):
    x.append([])

or, in Python 2.0+ via

x = [[] for i in range(6)]

Doing

[O] * n

creates a list with n repetitions of O, i.e. exactly the 
same object n times, the same as [O, O, O, ...].  In

[[], []]

you create two distinct empty lists, but in

temp = []
[temp, temp]

you get a single empty list twice.  Same thing for

[[]] * n

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

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

From noreply at sourceforge.net  Fri Feb  9 19:54:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 10:54:47 -0800
Subject: [ python-Bugs-1653940 ] popen - docs - wrong order on fileobjects in
	tuple returned
Message-ID: <E1HFatT-0001Fq-GE@sc8-sf-web6.sourceforge.net>

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

Please note that this 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
Private: No
Submitted By: Emil Lind (noflux)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen - docs - wrong order on fileobjects in tuple returned

Initial Comment:
http://docs.python.org/lib/module-popen2.html

(child_stdout, child_stdin, child_stderr)
should probably be 
(child_stdin, child_stdout, child_stderr)

and so on.


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-09 18:54

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

No, the current version is correct.

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

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

From noreply at sourceforge.net  Sat Feb 10 00:14:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 15:14:41 -0800
Subject: [ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?
Message-ID: <E1HFewz-0004KY-K1@sc8-sf-web7.sourceforge.net>

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

Please note that this 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: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?

Initial Comment:
When using
  print >> f, "Hello"
on a file f opened for reading, no exception is raised.  Is this normal?

This situation has to be contrasted with
  f.write("Hello")
which raises an exception.

Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:

In [1]: f=open("start.01")
In [2]: f.write("Hello")
<type 'exceptions.IOError'>: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()

NB: file f is not modified, despite the "print" statement yielding no error, above.

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

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

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

There seem to be multiple problems here. AFAICT,

print >>f, 3

fails on both Linux and OSX. This is because this uses fprintf to put out
the number, which, in turn, returns -1. This result is ignored; instead
Python expects ferror() to be set. However, ferror doesn't get set.

For printing strings, fwrite is used. On both Linux and OSX, fwrite will
return 0. On Linux, in addition, ferror gets set; on OSX, it doesn't.

Reading C99, I can't figure out which of these systems is behaving
correctly in what cases. The definition of ferror is that it returns the
"error indicator" of the stream, and only fseek, fputc (+putc), and fflush
are explicitly documented to set the error indicator. However, the error
indicator is also documented to be set that it "records whether a 
read/write error  has  occurred", and write is documented to return a
number smaller than the requested only if an error occurred. Likewise,
fprintf is document to return an negative value "if an  output  or 
encoding error occurred."

Putting these all together, ISTM that both Linux and OSX implement fprintf
incorrectly. To work around, Python could check the result of fprintf and
fwrite in all places; this might become a large change.

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

Comment By: Skip Montanaro (montanaro)
Date: 2007-02-06 19:49

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

I verified this behavior on my Mac with /usr/bin/python, Python 2.5 and
Python 2.6a0, both built from SVN.

Skip


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

Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-06 18:45

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

Interesting point, about Linux.   The incorrect behavior is even seen in
the  default python 2.3 that ships with Mac OS X!


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-06 18:31

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

If this happens, it's a bug. Though it doesn't seem to occur under Linux
here.

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

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

From noreply at sourceforge.net  Sat Feb 10 02:48:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 17:48:43 -0800
Subject: [ python-Bugs-900092 ] hotshot.stats.load
Message-ID: <E1HFhM3-0008Lm-Gn@sc8-sf-web11.sourceforge.net>

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

Please note that this 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: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotshot.stats.load

Initial Comment:
trying to do a 

hotshot.stats.load("myprofiling_file.prof")

fails with assertionerror

assert not self._stack


python 2.3.2 on WinXP



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

>Comment By: Brett Cannon (bcannon)
Date: 2007-02-09 17:48

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

Attaching the file George made.
File Added: bug.prof

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

Comment By: Brett Cannon (bcannon)
Date: 2007-02-09 10:15

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

I think only OPs and project members can upload.  Email it to me, George
(brett at python.org), mention the bug # and I will upload it.

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

Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 16:08

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

Ok, I reduced the prof file to 38K. Can I upload an attachment here ? I
don't see how.

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

Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 15:37

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

Has this ever been reported again since it was closed ? I just got it
today (python 2.5). The prof file is 11MB, I'll see if I can reproduce the
bug with a smaller one.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-08-15 11:14

Message:
Logged In: YES 
user_id=12800

Patches applied for Python 2.4.2 and 2.5a1


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-08 08:02

Message:
Logged In: YES 
user_id=12800

900092-patch-2.txt fixes the test suite for the extra return
event.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-07 16:26

Message:
Logged In: YES 
user_id=12800

See 900092-patch.txt for a candidate patch against Python
2.4.1.  Props to Justin Campbell for most of the heavily
lifting (but you can blame me for any problems ;).

This fix restore the tracing of a 'return' event for
exceptions that cause a function to exit.

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

Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 15:54

Message:
Logged In: YES 
user_id=86307

Well, the superficial fix doesn't work (sorry for posting
too soon).  It turns out that PyTrace_EXCEPTION is sent for
any exception, not just one causing the function to exit. 
So I guess the best fix may be to have hotshot always
install its profiler_callback to handle CALLS and RETURNS,
and then optionally install the tracer_callback to handle
only LINEs.  Anyway, that works for the one test case I've
been using (a runcall of a function which simply does
"import pickle").

By the way, I'm testing with 2.4b1.

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

Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 15:32

Message:
Logged In: YES 
user_id=86307

I ran into this today, so I decided to look into it.  It
looks to me like the problem only happens if you profile
with lineevents enabled.  In that case, hotshot uses the
tracer_callback function (in _hotshot.c) to dispatch trace
events.  This function explicitly ignores exception returns
(PyTrace_EXCEPTION), which can lead to an unbalanced stack
of calls/returns when the log is loaded (if an profiled
function exits with an exception).

It seems on the surface that tracer_callback ought to handle
exceptions the same way as normal returns.  This would be
consistent with what happens when profiler_callback is used,
since PyEval_EvalFrame dispatches sends a Py_RETURN to
c_profilefunc when exiting because of an exception.


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-09-27 07:41

Message:
Logged In: YES 
user_id=12800

Could this be related to 1019882?


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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 15:00

Message:
Logged In: YES 
user_id=469548

Hmm, the file was too big, even though it was compressed.
I've uploaded it to
http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2
now.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 14:58

Message:
Logged In: YES 
user_id=469548

While the original report isn't very useful, I've ran into
this problem multiple times as well. I can reproduce it
using the attached profile file (compressed because of the
large size) and the following console session:

Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import hotshot.stats
>>> stats = hotshot.stats.load('roundup.prof')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load
    return StatsLoader(filename).load()
  File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load
    assert not self._stack
AssertionError
>>>

I'm not sure who's baby hotshot really is, so I'm leaving
this unassigned.

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

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

From noreply at sourceforge.net  Sat Feb 10 03:05:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 18:05:10 -0800
Subject: [ python-Feature Requests-1656538 ] dict(key,values) initializer
Message-ID: <E1HFhby-00040o-2S@sc8-sf-web7.sourceforge.net>

Feature Requests item #1656538, was opened at 2007-02-10 02:05
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=1656538&group_id=5470

Please note that this 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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: George Sakkis (gsakkis)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict(key,values) initializer

Initial Comment:
Far too often I use the idiom dict(zip(keys,values)), or
the same with izip. How does letting dict take two positional arguments sound ?

Pros:
- Pretty obvious semantics, no mental overhead to learn and remember it.
- More concise (especially if one imports itertools just to use izip).
- At least as efficient (and probably more) as the current alternatives.
- Backwards compatible.

George

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

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

From noreply at sourceforge.net  Sat Feb 10 04:41:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 19:41:40 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HFj7M-0005E2-4J@sc8-sf-web3.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
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=1656559&group_id=5470

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



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

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

From noreply at sourceforge.net  Sat Feb 10 06:37:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 21:37:46 -0800
Subject: [ python-Bugs-1656578 ] shutil.copyfileobj description is incomplete
Message-ID: <E1HFkvi-0005DA-Qt@sc8-sf-web11.sourceforge.net>

Bugs item #1656578, was opened at 2007-02-10 00: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=1656578&group_id=5470

Please note that this 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: Witten (herrwitten)
Assigned to: Nobody/Anonymous (nobody)
Summary: shutil.copyfileobj description is incomplete

Initial Comment:
shutil.copyfileobj reads the source's data starting from the source's current file position. Thus, a user must issue seek(0) in order to have all of the source file object's contents read.

This needs to be documented.

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

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

From noreply at sourceforge.net  Sat Feb 10 06:45:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 21:45:49 -0800
Subject: [ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs
	clarification
Message-ID: <E1HFl3V-0005Q2-VN@sc8-sf-web5.sourceforge.net>

Bugs item #1656581, was opened at 2007-02-10 00: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=1656581&group_id=5470

Please note that this 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: Witten (herrwitten)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.TarFile fileobject use needs clarification

Initial Comment:
The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented.

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

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

From noreply at sourceforge.net  Sat Feb 10 06:47:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 21:47:58 -0800
Subject: [ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs
	clarification
Message-ID: <E1HFl5a-0005c4-0G@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: Witten (herrwitten)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.TarFile fileobject use needs clarification

Initial Comment:
The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented.

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

>Comment By: Witten (herrwitten)
Date: 2007-02-10 00:47

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

A clarification: When an existing file object is used to create a TarFile
object, the TarFile object expects the existing file object to have its
file position at 0.

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

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

From noreply at sourceforge.net  Sat Feb 10 08:15:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Feb 2007 23:15:33 -0800
Subject: [ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs
	clarification
Message-ID: <E1HFmSL-0002DD-OW@sc8-sf-web4.sourceforge.net>

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

Please note that this 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: Witten (herrwitten)
>Assigned to: Lars Gust?bel (gustaebel)
Summary: tarfile.TarFile fileobject use needs clarification

Initial Comment:
The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented.

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

Comment By: Witten (herrwitten)
Date: 2007-02-10 05:47

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

A clarification: When an existing file object is used to create a TarFile
object, the TarFile object expects the existing file object to have its
file position at 0.

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

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

From noreply at sourceforge.net  Sat Feb 10 12:36:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 10 Feb 2007 03:36:45 -0800
Subject: [ python-Feature Requests-1656675 ] Drop-Handler for Python files
Message-ID: <E1HFqX7-0008Vt-Kv@sc8-sf-web7.sourceforge.net>

Feature Requests item #1656675, was opened at 2007-02-10 12:36
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=1656675&group_id=5470

Please note that this 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
Private: No
Submitted By: Marek Kubica (leonidasxiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: Drop-Handler for Python files

Initial Comment:
Hi!

We had a dscussion about what happens when one drops a file on a python sourcecode-file in the python-forum [1]. It turned out, that nothing happens at all. So someone brought up a solution. It is not really a problem with Python but it would be nice to add this to the Windows Installer.

The proposed solution was to add the following to the registry (this is the format of the registry editor):

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Python.File\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"

[HKEY_CLASSES_ROOT\Python.NoConFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"

[HKEY_CLASSES_ROOT\Python.CompiledFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"

That should be simple thing to do using the MSI-Installer.

[1] only in german, sorry: http://www.python-forum.de/topic-7493.html

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

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

From noreply at sourceforge.net  Sat Feb 10 12:49:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 10 Feb 2007 03:49:54 -0800
Subject: [ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?
Message-ID: <E1HFqjq-0001kH-MB@sc8-sf-web9.sourceforge.net>

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

Please note that this 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: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?

Initial Comment:
When using
  print >> f, "Hello"
on a file f opened for reading, no exception is raised.  Is this normal?

This situation has to be contrasted with
  f.write("Hello")
which raises an exception.

Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:

In [1]: f=open("start.01")
In [2]: f.write("Hello")
<type 'exceptions.IOError'>: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()

NB: file f is not modified, despite the "print" statement yielding no error, above.

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

>Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-10 12:49

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

Just for reference: with Fink Python 2.5 (r25:51908, Sep 24 2006) on OS X
10.4.8 / darwin 8.8.0 for Intel Macs, "print >>f, 3" is also silently (and
incorrectly) accepted when f is only opened for reading.

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

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

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

There seem to be multiple problems here. AFAICT,

print >>f, 3

fails on both Linux and OSX. This is because this uses fprintf to put out
the number, which, in turn, returns -1. This result is ignored; instead
Python expects ferror() to be set. However, ferror doesn't get set.

For printing strings, fwrite is used. On both Linux and OSX, fwrite will
return 0. On Linux, in addition, ferror gets set; on OSX, it doesn't.

Reading C99, I can't figure out which of these systems is behaving
correctly in what cases. The definition of ferror is that it returns the
"error indicator" of the stream, and only fseek, fputc (+putc), and fflush
are explicitly documented to set the error indicator. However, the error
indicator is also documented to be set that it "records whether a 
read/write error  has  occurred", and write is documented to return a
number smaller than the requested only if an error occurred. Likewise,
fprintf is document to return an negative value "if an  output  or 
encoding error occurred."

Putting these all together, ISTM that both Linux and OSX implement fprintf
incorrectly. To work around, Python could check the result of fprintf and
fwrite in all places; this might become a large change.

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

Comment By: Skip Montanaro (montanaro)
Date: 2007-02-06 19:49

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

I verified this behavior on my Mac with /usr/bin/python, Python 2.5 and
Python 2.6a0, both built from SVN.

Skip


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

Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-06 18:45

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

Interesting point, about Linux.   The incorrect behavior is even seen in
the  default python 2.3 that ships with Mac OS X!


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-06 18:31

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

If this happens, it's a bug. Though it doesn't seem to occur under Linux
here.

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

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

From noreply at sourceforge.net  Sat Feb 10 13:25:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 10 Feb 2007 04:25:49 -0800
Subject: [ python-Feature Requests-1656675 ] Drop-Handler for Python files
Message-ID: <E1HFrIb-00063W-Fi@sc8-sf-web8.sourceforge.net>

Feature Requests item #1656675, was opened at 2007-02-10 11:36
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&group_id=5470

Please note that this 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
Private: No
Submitted By: Marek Kubica (leonidasxiv)
>Assigned to: Martin v. L?wis (loewis)
Summary: Drop-Handler for Python files

Initial Comment:
Hi!

We had a dscussion about what happens when one drops a file on a python sourcecode-file in the python-forum [1]. It turned out, that nothing happens at all. So someone brought up a solution. It is not really a problem with Python but it would be nice to add this to the Windows Installer.

The proposed solution was to add the following to the registry (this is the format of the registry editor):

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Python.File\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"

[HKEY_CLASSES_ROOT\Python.NoConFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"

[HKEY_CLASSES_ROOT\Python.CompiledFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"

That should be simple thing to do using the MSI-Installer.

[1] only in german, sorry: http://www.python-forum.de/topic-7493.html

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

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

From noreply at sourceforge.net  Sat Feb 10 16:06:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 10 Feb 2007 07:06:17 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HFtnt-0004i0-Rf@sc8-sf-web8.sourceforge.net>

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

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

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

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

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

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

From noreply at sourceforge.net  Sat Feb 10 21:16:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 10 Feb 2007 12:16:10 -0800
Subject: [ python-Feature Requests-1654367 ] [PATCH] Debuggers need a way to
	change the locals of a frame
Message-ID: <E1HFydm-0008N1-DR@sc8-sf-monitor2.sourceforge.net>

Feature Requests item #1654367, was opened at 2007-02-07 17:12
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654367&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabio Zadrozny (fabioz)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] Debuggers need a way to change the locals of a frame

Initial Comment:
Debuggers need a way to change the local variables in a given frame... currently, this works only if this change is done in the topmost frame (and under certain circumstances), but it should work for any frame.

Initial discussion at:
http://mail.python.org/pipermail/python-dev/2007-February/070884.html

Apparently, the problem is the order in which PyFrame_LocalsToFast / PyFrame_FastToLocals is called.

The proposed solution to this is having a savelocals() method in the frame object and have it reflect the changes in its returned dict into its locals. It will simply enable users to call PyFrame_LocalsToFast externally after a change, to be sure that it will not be changed (and it must be done before another call to PyFrame_LocalsToFast -- which I don't see as a large problem, because it is of restrict use -- mainly for debuggers).


--------- frameobject.c Patch part 1: -----------------

static PyObject *
PyFrame_SaveLocals(PyFrameObject *f)
{
    PyFrame_LocalsToFast(f, 0);
	Py_INCREF(Py_None);
	return Py_None;
}

static PyMethodDef frame_methodlist[] = {
    {"savelocals", (PyCFunction)PyFrame_SaveLocals, METH_NOARGS,
     "After a change in f_locals, this method should be called to save the changes internally."
    },
    {NULL}  /* Sentinel */
};


---------- frameobject.c Patch part 2: ---------------
Add to PyTypeObject PyFrame_Type:

frame_methodlist,/* tp_methods */

------------------ end patch -------------------------

I'm sorry that this is not in an actual patch format... but as I didn't get it from the cvs, it is easier for me to explain it (as it is a rather small patch).

Attached is a test-case for this patch.

Thanks, 

Fabio

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

>Comment By: Armin Rigo (arigo)
Date: 2007-02-10 20:16

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

A point of detail probably, but I suppose that instead of introducing a
new method on frame objects, we could allow f_locals to be a writeable
attribute.  Setting it to a dictionary would update the value of the local
variables.  It's a bit of a hack, but so is the need for an explicit
savelocals() method.

A cleaner solution is to have f_locals return a dict-like object instead
of a real dict when appropriate, but it takes more efforts to implement.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-08 08:38

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

Why don't you set the clear parameter to 1?

Please do submit a patch, you can use 'diff -ur' to create a recursive
unified diff between source trees. Please also try to come up with a patch
to the documentation.

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

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

From noreply at sourceforge.net  Sun Feb 11 01:35:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 10 Feb 2007 16:35:04 -0800
Subject: [ python-Bugs-1657034 ] 'Ok' key in options dialog does nothing
Message-ID: <E1HG2gK-0000uw-5t@sc8-sf-web1.sourceforge.net>

Bugs item #1657034, was opened at 2007-02-11 01: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=1657034&group_id=5470

Please note that this 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: torhu (torhu)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Ok' key in options dialog does nothing

Initial Comment:
IDLE 1.2, winxp sp2 US.

I get the same results with idlelib from svn rev. 53721.


Steps to reproduce:
1. Open Options -> Configure IDLE...
2. Click on the Ok button.
3. Nothing happens, you have to click Cancel to close the options window.


Here's a way that crashes IDLE on my machine:
1. Open Options -> Configure IDLE...
2. Set Indentation width to 8 (was 4 by default).
3. Click on Apply.
4. Click on Ok (nothing happens).
5. Click on Cancel - IDLE exits.


Workaround:
Replace the Python25/Lib/idlelib directory with the one that comes with python 2.4.3.

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

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

From noreply at sourceforge.net  Sun Feb 11 06:35:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 10 Feb 2007 21:35:59 -0800
Subject: [ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs
	clarification
Message-ID: <E1HG7NX-0005nH-7Z@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Witten (herrwitten)
Assigned to: Lars Gust?bel (gustaebel)
Summary: tarfile.TarFile fileobject use needs clarification

Initial Comment:
The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented.

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

>Comment By: Witten (herrwitten)
Date: 2007-02-11 00:35

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

I suppose I could make this clearer:

The user needs to know that the file object will be used from the current
file position.

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

Comment By: Witten (herrwitten)
Date: 2007-02-10 00:47

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

A clarification: When an existing file object is used to create a TarFile
object, the TarFile object expects the existing file object to have its
file position at 0.

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

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

From noreply at sourceforge.net  Mon Feb 12 00:57:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 11 Feb 2007 15:57:00 -0800
Subject: [ python-Bugs-1614460 ] python-logging compatability with Zope.
Message-ID: <E1HGOZ2-00085f-FB@sc8-sf-web6.sourceforge.net>

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

Please note that this 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: None
Priority: 5
Private: No
Submitted By: Simon Hookway (shookway)
Assigned to: Vinay Sajip (vsajip)
Summary: python-logging compatability with Zope.

Initial Comment:
I'm using Zope2.8.x and python2.4.

On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it.

This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification.

See the included patch.

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

>Comment By: Simon Hookway (shookway)
Date: 2007-02-12 10:57

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

"fixed in 2.5" -- that is the problem, why was this fix not rolled back to
python2.4? I submit this patch for those of us out there still using 2.4
and likely to be using it for a while to come. 

Can we have it fixed in 2.4 please.

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

Comment By: SourceForge Robot (sf-robot)
Date: 2006-12-30 14:20

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

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: Vinay Sajip (vsajip)
Date: 2006-12-16 04:13

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

Yes, a fix was applied a while ago.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-12-15 19:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

I believe this was fixed in 2.5, but I could be mistaken.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 08:40:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 11 Feb 2007 23:40:36 -0800
Subject: [ python-Bugs-1650053 ] decimals compare badly to floats
Message-ID: <E1HGVng-0004x0-EO@sc8-sf-web2.sourceforge.net>

Bugs item #1650053, was opened at 2007-02-01 13:20
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650053&group_id=5470

Please note that this 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
Private: No
Submitted By: Brian Sutherland (jinty_)
>Assigned to: Nobody/Anonymous (nobody)
Summary: decimals compare badly to floats

Initial Comment:
This behaviour is so unexpected that I'm pretty sure it's a bug. If decimals can't be compared to floats, at least it should error.

Found in python2.4 and 2.5 by at least 2 people:

Python 2.5 (release25-maint, Dec  9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> 1172837167.27 > Decimal("1172837136.0800")
False
>>> 1172837167.27 > Decimal("1")
False


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-12 02:40

Message:
Logged In: YES 
user_id=80475
Originator: NO

The __cmp__() method decimal.py is doing the right thing and returning
NotImplemented.

The odd result you're seeing is just Python's normal way of handling
things it doesn't know how to compare.  You get the same results by
comparing floats to strings:

>>> 1172837167.27 > "1172837136.0800"
False
>>> 1172837167.27 > "1"
False

I don't see a way to change this behavior without making deep incompatible
changes to Python.

If someone sees a way out, feel free to re-open this bug.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-01 15:24

Message:
Logged In: YES 
user_id=80475
Originator: NO

It was intended that Decimals not be compared to floats, but I think we
can do better than returning a useless result

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650053&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 10:30:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 01:30:27 -0800
Subject: [ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs
	clarification
Message-ID: <E1HGXVz-00032E-Mp@sc8-sf-web2.sourceforge.net>

Bugs item #1656581, was opened at 2007-02-10 06:45
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&group_id=5470

Please note that this 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: Accepted
Priority: 5
Private: No
Submitted By: Witten (herrwitten)
Assigned to: Lars Gust?bel (gustaebel)
Summary: tarfile.TarFile fileobject use needs clarification

Initial Comment:
The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented.

----------------------------------------------------------------------

>Comment By: Lars Gust?bel (gustaebel)
Date: 2007-02-12 10:30

Message:
Logged In: YES 
user_id=642936
Originator: NO

Both is true: The file object will be used from the current file position
which is supposed to be 0 ;-)
I changed the docs to be clearer on this (cp. rev. 53752 and rev. 53753).

----------------------------------------------------------------------

Comment By: Witten (herrwitten)
Date: 2007-02-11 06:35

Message:
Logged In: YES 
user_id=1595909
Originator: YES

I suppose I could make this clearer:

The user needs to know that the file object will be used from the current
file position.

----------------------------------------------------------------------

Comment By: Witten (herrwitten)
Date: 2007-02-10 06:47

Message:
Logged In: YES 
user_id=1595909
Originator: YES

A clarification: When an existing file object is used to create a TarFile
object, the TarFile object expects the existing file object to have its
file position at 0.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 13:23:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 04:23:30 -0800
Subject: [ python-Bugs-847665 ] XMLGenerator.startElementNS dies on
	EMPTY_NAMESPACE attribut
Message-ID: <E1HGaDS-0006sH-WE@sc8-sf-monitor2.sourceforge.net>

Bugs item #847665, was opened at 2003-11-23 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=847665&group_id=5470

Please note that this 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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut

Initial Comment:
from xml.sax.saxutils import XMLGenerator

g = XMLGenerator(encoding='utf8')
STREAM_NAMESPACE = 'http://etherx.jabber.org/streams'
CLIENT_NAMESPACE = 'jabber:client'
g.startDocument()
g.startPrefixMapping('stream', STREAM_NAMESPACE)
g.startPrefixMapping('client', CLIENT_NAMESPACE)
g.startElementNS( 
    (STREAM_NAMESPACE, 'stream'), 'stream',
    {(None,'xmlns'): CLIENT_NAMESPACE}
    )

Dies with:
Traceback (most recent call last):
  File &quot;tst.py&quot;, line 11, in ?
    g.startElementNS( 
  File &quot;/System/Library/Frameworks/Python.framework/
Versions/2.3/lib/python2.3/xml/sax/saxutils.py&quot;, line 124, in 
startElementNS
    name = self._current_context[name[0]] + &quot;:&quot; + name[1]
KeyError: 'x'


Changing the end of XMLGenerator.startElementNS to the 
following makes it work the way I expect:

        for (name, value) in attrs.items():
            if name[0] is None:
                name = name[1]
            else:
                name = self._current_context[name[0]] + &quot;:&quot; + 
name[1]
            self._out.write(' %s=%s' % (name, 
quoteattr(value)))
        self._out.write('&gt;')


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 13:23

Message:
Logged In: YES 
user_id=21627
Originator: NO

This is now fixed in r53754 and r53755.

----------------------------------------------------------------------

Comment By: Nikolai Grigoriev (ngrig)
Date: 2006-03-26 23:29

Message:
Logged In: YES 
user_id=195108

This issue lasts for 2.5 years already. I feel like it is
somewhat stalled.

The processing of XML namespaces in saxutils.XMLGenerator is
so blatantly broken that I wonder if it ever has been tested
at all. I wrote down a simple smoke test for it:


import sys
from xml import sax
from xml.sax.saxutils import XMLGenerator
from StringIO import StringIO

tests = [
("No namespace, no attributes",     "<a/>"),
("No namespace, with attributes",   "<a b='c'/>"),
("Empty prefix, no attributes",     "<a xmlns='qux'/>"),
("Empty prefix, unprefixed attributes", "<a xmlns='qux'
b='c'/>"),
("Prefixed, no attributes",         "<my:a xmlns:my='qux'/>"),
("Prefixed, unprefixed attributes", "<my:a xmlns:my='qux'
b='c'/>"),               
("Prefixed, prefixed attributes",   "<my:a xmlns:my='qux'
my:b='c'/>"),
]
          
for (caption, testdoc) in tests:
    try:
        parser = sax.make_parser()
        parser.setFeature(sax.handler.feature_namespaces, 1)
        parser.setContentHandler(XMLGenerator(StringIO()))
        parser.parse(StringIO(testdoc))
        print caption, "- OK"
    except StandardError, e:
        print caption, "- FAILED:", e.__class__.__name__


With the current version of saxutils (as of Python 2.4.1), I
get 4 failures out of 7. Stuart Bishop's patch fixes the
issue; could someone commit it please?


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-12-04 21:15

Message:
Logged In: YES 
user_id=11375

Please provide your changes in the form of a patch.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-12-04 21:02

Message:
Logged In: YES 
user_id=11375

Never mind my previous comment; I just noticed the
setContentHandler call.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-12-04 21:01

Message:
Logged In: YES 
user_id=11375

I don't understand your second example; it uses saxutils to
parse a file.  What's it got to do with XMLGenerator?

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-11-24 20:36

Message:
Logged In: YES 
user_id=46639

This method also appears to have trouble emmitting tags without a 
namespace prefix:

import xml.sax
import xml.sax.handler
import xml.sax.saxutils
x = '''&lt;?xml version=&quot;1.0&quot;?&gt;&lt;mechanisms
xmlns='urn:ietf:
params:xml:ns:xmpp-sasl'
&gt;'''
parser = xml.sax.make_parser()
parser.setFeature(xml.sax.handler.feature_namespaces, True)
parser.setContentHandler(xml.sax.saxutils.XMLGenerator())
parser.feed(x)

dies with:
Traceback (most recent call last):
  File &quot;tst.py&quot;, line 30, in ?
    parser.feed(x)
  File &quot;/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/xml/sax/expatreader.py&quot;, line 207, in feed
    self._parser.Parse(data, isFinal)
  File &quot;/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/xml/sax/expatreader.py&quot;, line 337, in 
start_element_ns
    AttributesNSImpl(newattrs, qnames))
  File &quot;/System/Library/Frameworks/Python.framework/Versions/
2.3/lib/python2.3/xml/sax/saxutils.py&quot;, line 116, in startElementNS
    name = self._current_context[name[0]] + &quot;:&quot; + name[1]
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'



I've attached my current replacement startElementNS method 
which appears to fix both this and the previous issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 13:38:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 04:38:49 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGaSG-0000QA-Uh@sc8-sf-web4.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 04:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 13:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 16:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 13:43:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 04:43:48 -0800
Subject: [ python-Bugs-1653757 ] configure does not check/warn/stop for tk/tcl
Message-ID: <E1HGaX6-0000ua-5w@sc8-sf-web4.sourceforge.net>

Bugs item #1653757, was opened at 2007-02-07 03:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653757&group_id=5470

Please note that this 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
Private: No
Submitted By: SAndreason (sandreas41)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure does not check/warn/stop for tk/tcl

Initial Comment:
linux-2.4.33
installing Python-2.5.tar.bz2 9357099 bytes

During the first configure/make process, there were no errors until compilation failed.
Looking back at the configure output, I see:
...[clip]...
checking for UCS-4 tcl... no
...[clip]...

Because during make, it said:
...[clip]...
/usr/src/Python-2.5/Modules/_tkinter.c:80:2: #error "Tk older than 8.2 not supported"
/usr/src/Python-2.5/Modules/_tkinter.c:92:2: #error "unsupported Tcl configuration"
...[clip]...and many pages of:...
/usr/src/Python-2.5/Modules/_tkinter.c:xxxx: errors

Ok, so I upgraded the tk and tcl packages without incident.

Now, Why during the clean re-configuration, do I get the same message, and also an error in the config.log that matches??

make did (appear to) finish ok

Perhaps this may have relevance to the other bug.
[ 1653753 ] crash / abort during install

config.log is attached there.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 13:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Are you sure compilation (of Python) failed? If make finished ok, then the
compilation indeed succeeded. Failure to build an extension module (such as
Tkinter) is not considered a failure of the entire build. Instead, if the
module cannot build (e.g. because the header files are missing), the build
is just skipped (either entirely or partially).

IOW, I cannot see a bug here; closing the report as "won't fix".

If you want to find out why it didn't build _tkinter, you should check the
compiler command line to find out where it found the Tcl header files.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653757&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 16:11:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 07:11:35 -0800
Subject: [ python-Bugs-1653757 ] configure does not check/warn/stop for tk/tcl
Message-ID: <E1HGcq7-0007Jg-BQ@sc8-sf-web2.sourceforge.net>

Bugs item #1653757, was opened at 2007-02-06 18:15
Message generated for change (Comment added) made by sandreas41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653757&group_id=5470

Please note that this 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
Private: No
Submitted By: SAndreason (sandreas41)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure does not check/warn/stop for tk/tcl

Initial Comment:
linux-2.4.33
installing Python-2.5.tar.bz2 9357099 bytes

During the first configure/make process, there were no errors until compilation failed.
Looking back at the configure output, I see:
...[clip]...
checking for UCS-4 tcl... no
...[clip]...

Because during make, it said:
...[clip]...
/usr/src/Python-2.5/Modules/_tkinter.c:80:2: #error "Tk older than 8.2 not supported"
/usr/src/Python-2.5/Modules/_tkinter.c:92:2: #error "unsupported Tcl configuration"
...[clip]...and many pages of:...
/usr/src/Python-2.5/Modules/_tkinter.c:xxxx: errors

Ok, so I upgraded the tk and tcl packages without incident.

Now, Why during the clean re-configuration, do I get the same message, and also an error in the config.log that matches??

make did (appear to) finish ok

Perhaps this may have relevance to the other bug.
[ 1653753 ] crash / abort during install

config.log is attached there.


----------------------------------------------------------------------

>Comment By: SAndreason (sandreas41)
Date: 2007-02-12 07:11

Message:
Logged In: YES 
user_id=1095971
Originator: YES

I am not sure now that compilation failed.
With all the errors generated, and the lack of a familiar 
make[1]: Leaving directory

left me thinking it failed. But you're right, it did not end with 
make: *** [all] Error 1

I don't see any tk/tcl libraries mentioned in the gcc line that started
producing errors:

building '_tkinter' extension
/usr/src/Python-2.5/Modules/_tkinter.c:80:2: #error "Tk older than 8.2 not
supported"
/usr/src/Python-2.5/Modules/_tkinter.c:92:2: #error "unsupported Tcl
configuration"
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -DWITH_APPINIT=1 -I/usr/X11R6/include -I.
-I/usr/src/Python-2.5/./Include -I./Include -I. -I/usr/local/include
-I/usr/src/Python-2.5/Include -I/usr/src/Python-2.5 -c
/usr/src/Python-2.5/Modules/_tkinter.c -o
build/temp.linux-i686-2.5/usr/src/Python-2.5/Modules/_tkinter.o

Can't go back and test it, now that tk/tcl is upgraded.
I agree, close.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 04:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Are you sure compilation (of Python) failed? If make finished ok, then the
compilation indeed succeeded. Failure to build an extension module (such as
Tkinter) is not considered a failure of the entire build. Instead, if the
module cannot build (e.g. because the header files are missing), the build
is just skipped (either entirely or partially).

IOW, I cannot see a bug here; closing the report as "won't fix".

If you want to find out why it didn't build _tkinter, you should check the
compiler command line to find out where it found the Tcl header files.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653757&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 19:59:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 10:59:42 -0800
Subject: [ python-Bugs-1633621 ] curses should reset curses.{COLS,
	LINES} when term. resized
Message-ID: <E1HGgOs-00058C-CV@sc8-sf-web5.sourceforge.net>

Bugs item #1633621, was opened at 2007-01-12 00:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470

Please note that this 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: 3
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses should reset curses.{COLS,LINES} when term. resized

Initial Comment:
[forwarded from http://bugs.debian.org/366698]

The curses module does not reset curses.COLS and curses.LINES when the terminal is resized.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2007-02-12 19:59

Message:
Logged In: YES 
user_id=89016
Originator: NO

Here's a patch that implements the requested changes.
File Added: diff.txt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 22:45:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 13:45:40 -0800
Subject: [ python-Bugs-1658430 ] random.betavariate(-0,5, -0,5) 
Message-ID: <E1HGizU-00047y-Nl@sc8-sf-web2.sourceforge.net>

Bugs item #1658430, was opened at 2007-02-12 21: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=1658430&group_id=5470

Please note that this 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: Alain Spineux (aspineux)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.betavariate(-0,5, -0,5) 

Initial Comment:

I the "Python Library Reference", about random module, I read :

betavariate(alpha, beta)
    Beta distribution. Conditions on the parameters are alpha > -1 and beta > -1. Returned values range between 0 and 1.

But

>>> import random
>>> random.betavariate(-0.5, -0.5)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/random.py", line 575, in betavariate
    y = self.gammavariate(alpha, 1.)
  File "/usr/lib/python2.4/random.py", line 458, in gammavariate
    raise ValueError, 'gammavariate: alpha and beta must be > 0.0'
ValueError: gammavariate: alpha and beta must be > 0.0


The documentation is probably inaccurate, because they are two beta distribution usage in the math world:
one with alpha and beta >0 (the common one)
and the other whit alpha' and beta' > -1 where alpha'=alpha-1 and beta'=beta-1

this could explain the mistake.

Finally, I thing the documentation should specify :

alpha > 0 and beta > 0

The problem exist in Python 2.4.3 and probably in all versions.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658430&group_id=5470

From noreply at sourceforge.net  Mon Feb 12 23:37:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 14:37:20 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGjnU-0004k1-Ms@sc8-sf-monitor2.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 00:09:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 15:09:53 -0800
Subject: [ python-Bugs-1658430 ] random.betavariate(-0,5, -0,5) 
Message-ID: <E1HGkIz-0002cY-7k@sc8-sf-web3.sourceforge.net>

Bugs item #1658430, was opened at 2007-02-12 21:45
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658430&group_id=5470

Please note that this 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: Duplicate
Priority: 5
Private: No
Submitted By: Alain Spineux (aspineux)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.betavariate(-0,5, -0,5) 

Initial Comment:

I the "Python Library Reference", about random module, I read :

betavariate(alpha, beta)
    Beta distribution. Conditions on the parameters are alpha > -1 and beta > -1. Returned values range between 0 and 1.

But

>>> import random
>>> random.betavariate(-0.5, -0.5)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/random.py", line 575, in betavariate
    y = self.gammavariate(alpha, 1.)
  File "/usr/lib/python2.4/random.py", line 458, in gammavariate
    raise ValueError, 'gammavariate: alpha and beta must be > 0.0'
ValueError: gammavariate: alpha and beta must be > 0.0


The documentation is probably inaccurate, because they are two beta distribution usage in the math world:
one with alpha and beta >0 (the common one)
and the other whit alpha' and beta' > -1 where alpha'=alpha-1 and beta'=beta-1

this could explain the mistake.

Finally, I thing the documentation should specify :

alpha > 0 and beta > 0

The problem exist in Python 2.4.3 and probably in all versions.




----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-12 23:09

Message:
Logged In: YES 
user_id=849994
Originator: NO

This is already fixed in the development docs. Thanks for reporting it
anyway!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658430&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 06:57:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Feb 2007 21:57:00 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGqey-0008Ui-9Q@sc8-sf-web4.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 04:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: Works For Me
Priority: 5
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 06:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 23:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 13:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 16:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 11:10:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 02:10:30 -0800
Subject: [ python-Bugs-1514451 ] zipfile "append" mode should create a file if
	not present
Message-ID: <E1HGucI-0000a4-ML@sc8-sf-web4.sourceforge.net>

Bugs item #1514451, was opened at 2006-06-29 18:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514451&group_id=5470

Please note that this 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: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile "append" mode should create a file if not present

Initial Comment:
The line 

filename = zipfile.ZipFile(zip_file_name, "a") 

throws an exception if the given filename is not 
present already.

Shouldn't it create a file (in case one is not there) 
since it is "append" mode ??

It's throwing an OSError Exception stating "No such 
file/directory".

Normal convention has been that when opening a file 
in append mode, if the file is not present a new file 
is created.

Why is this non-standard?

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 11:10

Message:
Logged In: YES 
user_id=21627
Originator: NO

Technically, this is not a bug, as the documentation clearly states that
'a' should open existing files.
For 2.6, the behavior is changed with said patch.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2006-07-08 19:38

Message:
Logged In: YES 
user_id=413

I agree.  append semantics generally mean append or create.

+1 from me on fixing this bug.

if any existing code is depending on the side effect from
opening a zip file in 'a' mode to tell them that it doesn't
already exist this change would break that; but I'd argue
that such code is already broken and should be cleaned up.


----------------------------------------------------------------------

Comment By: Thomas Lee (krumms)
Date: 2006-07-06 04:31

Message:
Logged In: YES 
user_id=315535

Patch #1517891 resolves this. See:

http://sourceforge.net/tracker/index.php?func=detail&aid=1517891&group_id=5470&atid=305470

Waiting for review.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514451&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 11:29:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 02:29:05 -0800
Subject: [ python-Bugs-1658794 ] This shouldn't be there: Note that this code
	that uses...
Message-ID: <E1HGuuH-0002TB-IH@sc8-sf-web4.sourceforge.net>

Bugs item #1658794, was opened at 2007-02-13 11:29
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=1658794&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alf Lerv?g (alfborge)
Assigned to: Nobody/Anonymous (nobody)
Summary: This shouldn't be there: Note that this code that uses...

Initial Comment:
In 21.2.1 Background, details, hints, tips and caveats; we have the following paragraph:

The case conversion functions in the string module are affected by the locale settings. When a call to the setlocale() function changes the LC_CTYPE settings, the variables string.lowercase, string.uppercase and string.letters are recalculated. Note that this code that uses these variable through `from ... import ...', e.g. from string import letters, is not affected by subsequent setlocale() calls.

I can't make sense of the last sentence unless I pretend that "this" shouldn't be there, i.e.  Note that code that uses these variable(s?) through `from ... (...).

-- 
Kind regards,
Alf Lerv?g

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658794&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 12:06:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 03:06:47 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGvUl-0002M7-4c@sc8-sf-web9.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: Works For Me
Priority: 5
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 12:10:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 03:10:02 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGvXu-0002f1-OA@sc8-sf-web9.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Settings changed) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 12:18:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 03:18:29 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGvg5-0005vB-Nh@sc8-sf-web2.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 12:19:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 03:19:48 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGvhM-00061b-RQ@sc8-sf-web2.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 12:28:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 03:28:06 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGvpO-0004lD-Rc@sc8-sf-web7.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is
a bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 13:04:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 04:04:20 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGwOS-0000Gi-Pu@sc8-sf-web6.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 04:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 13:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 06:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 23:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 13:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 16:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 13:04:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 04:04:52 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGwOy-0000HR-7O@sc8-sf-web6.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 04:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 13:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 13:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 06:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 23:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 13:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 16:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 13:07:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 04:07:18 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGwRK-0007XX-VP@sc8-sf-web3.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by cvalente
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07

Message:
Logged In: YES 
user_id=627298
Originator: NO

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.

More info later on.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 13:09:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 04:09:02 -0800
Subject: [ python-Bugs-1658794 ] This shouldn't be there: Note that this code
	that uses...
Message-ID: <E1HGwT0-0000ge-O0@sc8-sf-web6.sourceforge.net>

Bugs item #1658794, was opened at 2007-02-13 11:29
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658794&group_id=5470

Please note that this 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
Private: No
Submitted By: Alf Lerv?g (alfborge)
Assigned to: Nobody/Anonymous (nobody)
Summary: This shouldn't be there: Note that this code that uses...

Initial Comment:
In 21.2.1 Background, details, hints, tips and caveats; we have the following paragraph:

The case conversion functions in the string module are affected by the locale settings. When a call to the setlocale() function changes the LC_CTYPE settings, the variables string.lowercase, string.uppercase and string.letters are recalculated. Note that this code that uses these variable through `from ... import ...', e.g. from string import letters, is not affected by subsequent setlocale() calls.

I can't make sense of the last sentence unless I pretend that "this" shouldn't be there, i.e.  Note that code that uses these variable(s?) through `from ... (...).

-- 
Kind regards,
Alf Lerv?g

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 13:09

Message:
Logged In: YES 
user_id=21627
Originator: NO

Thanks for the report. This is now fixed in r53767 and r53768.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658794&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 13:22:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 04:22:16 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGwfo-0003jd-DS@sc8-sf-web2.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22

Message:
Logged In: YES 
user_id=4882
Originator: YES

timezone :  WET in winter WEST in summer 
I try same with timezone of NEW YORK and 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0


----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07

Message:
Logged In: YES 
user_id=627298
Originator: NO

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.

More info later on.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 13:31:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 04:31:18 -0800
Subject: [ python-Bugs-1448060 ] gettext.py breaks on plural-forms header
	(PATCH)
Message-ID: <E1HGwoY-0006eL-9i@sc8-sf-web4.sourceforge.net>

Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by potorange
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

Please note that this 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: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)

Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256

The problem is a PO file like the following:

test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#\n"

(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)

Any Python program trying to access this breaks:

$ python test.py
Traceback (most recent call last):
  File "test.py", line 7, in ?
    gt = gettext.GNUTranslations(file)
  File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 300, in _parse
    v = v.split(';')
AttributeError: 'list' object has no attribute 'split'


test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
    gt = gettext.GNUTranslations(file)


The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.

The attached simple patch fixes this.


----------------------------------------------------------------------

Comment By: Alexis Deruelle (potorange)
Date: 2007-02-13 13:31

Message:
Logged In: YES 
user_id=1718193
Originator: NO

gettext chokes on empty Plural-Forms ?

#> audit2allow

Traceback (most recent call last):
  File "/usr/bin/audit2allow", line 34, in ?
    gettext.install('policycoreutils')
  File "/usr/lib/python2.4/gettext.py", line 482, in install
    t = translation(domain, localedir, fallback=True, codeset=codeset)
  File "/usr/lib/python2.4/gettexTraceback (most recent call last):
  File "/usr/bin/audit2allow", line 34, in ?
    gettext.install('policycoreutils')
  File "/usr/lib/python2.4/gettext.py", line 482, in install
    t = translation(domain, localedir, fallback=True, codeset=codeset)
  File "/usr/lib/python2.4/gettext.py", line 467, in translation
    t = _translations.setdefault(key, class_(open(mofile, 'rb')))
  File "/usr/lib/python2.4/gettext.py", line 177, in __init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 302, in _parse
    print v[1]
IndexError: list index out of range
t.py", line 467, in translation
    t = _translations.setdefault(key, class_(open(mofile, 'rb')))
  File "/usr/lib/python2.4/gettext.py", line 177, in __init__
    self._parse(fp)
  File "/usr/lib/python2.4/gettext.py", line 302, in _parse
    print v[1]
IndexError: list index out of range

#> msgunfmt /usr/share/locale/fr/LC_MESSAGES/policycoreutils.mo | grep -i
plural
"Plural-Forms: \n"

Bellow is a patch that fixes this for me.

--- /usr/lib/python2.4/gettext.py.orig  2007-02-13 13:25:54.000000000
+0100
+++ /usr/lib/python2.4/gettext.py       2007-02-13 12:36:29.000000000
+0100
@@ -298,8 +298,9 @@
                         self._charset = v.split('charset=')[1]
                     elif k == 'plural-forms':
                         v  = v.split(';')
-                        plural = v[1].split('plural=')[1]
-                               self.plural = c2py(plural)
+                       if len(v) > 1:
+                               plural = v[1].split('plural=')[1]
+                               self.plural = c2py(plural)
             # Note: we unconditionally convert both msgids and msgstrs
to
             # Unicode using the character encoding specified in the
charset
             # parameter of the Content-Type header.  The gettext
documentation


----------------------------------------------------------------------

Comment By: Danilo Segan (dsegan)
Date: 2006-03-22 00:28

Message:
Logged In: YES 
user_id=219596

No.  And based on what Bruno said, it's obviously not
supported (and since it's a GNU thingy, Bruno would probably
know best ;).

[btw, we need no plural forms in documentation at all, at
least not in static content translation; Yelp's
gnome-doc-utils stylesheets provide plural forms for where
they are appropriate]


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-03-20 08:50

Message:
Logged In: YES 
user_id=21627

dsegan: Can you give a real-world (i.e. non-documentation)
example of a PO file with a multi-line plural formula?

----------------------------------------------------------------------

Comment By: Danilo Segan (dsegan)
Date: 2006-03-20 05:07

Message:
Logged In: YES 
user_id=219596

Agreed on all points, except the "summary": multi-line
plural forms are actually supported and widely used.

Anyway, gettext.py should fail gracefully in case of any
problem in the header, instead of running into exception.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-03-19 12:51

Message:
Logged In: YES 
user_id=21627

Several things seem to be going on here:

1. gettext.py is clearly wrong; it shouldn't break on that file.

2. it is trying to process multi-line fields here. So the
patch is also wrong, as it just sets k and v to None.

3. I believe that the PO file presented is also wrong. I
believe the intention of the header is that it should have
the RFC822 style syntax, which doesn't allow for # comment
lines. The tool should use a syntax like

X-Filename: plo.po; package=PACKAGE; version=VERSION;

To summarize, I think the attempt to process multi-line
fields in the header is misguided, and gettext.py should
just fetch the first line of content-type and plural-forms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 13:47:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 04:47:31 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGx4F-0005Hm-6x@sc8-sf-web11.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by cvalente
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:47

Message:
Logged In: YES 
user_id=627298
Originator: NO

OK. This is almost surely NOT a Python bug but most likely a libc bug.

In c:
----------
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]){
        struct tm t1;
        struct tm t2;

        /* midnight 26/SET/1076*/
        t1.tm_sec  = 0;
        t1.tm_min  = 0;
        t1.tm_hour = 0;
        t1.tm_mday = 26;
        t1.tm_mon  = 8;
        t1.tm_year = 76;

        /* midnight 25/SET/1076*/
        t2.tm_sec  = 0;
        t2.tm_min  = 0;
        t2.tm_hour = 0;
        t2.tm_mday = 25;
        t2.tm_mon  = 8;
        t2.tm_year = 76;

        printf("%li\n", mktime(&t1)-mktime(&t2));
        printf("%li\n", mktime(&t1)-mktime(&t2));

        return 0;
}
------
Outputs:

90000
86400


In perl:
-----
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-----

Outputs

90000
86400

-----

My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon

When I changed this to another timezone (Say London) the problem didn't
exist.

Thank you all for your time.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22

Message:
Logged In: YES 
user_id=4882
Originator: YES

timezone :  WET in winter WEST in summer 
I try same with timezone of NEW YORK and 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0


----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07

Message:
Logged In: YES 
user_id=627298
Originator: NO

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.

More info later on.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 14:44:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 05:44:01 -0800
Subject: [ python-Bugs-1658959 ] os.wait child process fail when under stress
Message-ID: <E1HGxwv-00014G-As@sc8-sf-web7.sourceforge.net>

Bugs item #1658959, was opened at 2007-02-13 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=1658959&group_id=5470

Please note that this 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: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: The Groff (thegroff)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.wait child process fail when under stress

Initial Comment:
when having high amount of threads forking, os.wait fails from time to time giving a "No child" error". If you retry, eventually it will work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 15:25:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 06:25:29 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGyb3-00034o-7q@sc8-sf-monitor2.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 14:25

Message:
Logged In: YES 
user_id=4882
Originator: YES

ok bug openned on 
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033

----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:47

Message:
Logged In: YES 
user_id=627298
Originator: NO

OK. This is almost surely NOT a Python bug but most likely a libc bug.

In c:
----------
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]){
        struct tm t1;
        struct tm t2;

        /* midnight 26/SET/1076*/
        t1.tm_sec  = 0;
        t1.tm_min  = 0;
        t1.tm_hour = 0;
        t1.tm_mday = 26;
        t1.tm_mon  = 8;
        t1.tm_year = 76;

        /* midnight 25/SET/1076*/
        t2.tm_sec  = 0;
        t2.tm_min  = 0;
        t2.tm_hour = 0;
        t2.tm_mday = 25;
        t2.tm_mon  = 8;
        t2.tm_year = 76;

        printf("%li\n", mktime(&t1)-mktime(&t2));
        printf("%li\n", mktime(&t1)-mktime(&t2));

        return 0;
}
------
Outputs:

90000
86400


In perl:
-----
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-----

Outputs

90000
86400

-----

My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon

When I changed this to another timezone (Say London) the problem didn't
exist.

Thank you all for your time.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22

Message:
Logged In: YES 
user_id=4882
Originator: YES

timezone :  WET in winter WEST in summer 
I try same with timezone of NEW YORK and 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0


----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07

Message:
Logged In: YES 
user_id=627298
Originator: NO

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.

More info later on.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python,
but in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is
a bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 16:23:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 07:23:17 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGzUz-0004OO-Gm@sc8-sf-web2.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 14:25

Message:
Logged In: YES 
user_id=4882
Originator: YES

ok bug openned on 
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033

----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:47

Message:
Logged In: YES 
user_id=627298
Originator: NO

OK. This is almost surely NOT a Python bug but most likely a libc bug.

In c:
----------
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]){
        struct tm t1;
        struct tm t2;

        /* midnight 26/SET/1076*/
        t1.tm_sec  = 0;
        t1.tm_min  = 0;
        t1.tm_hour = 0;
        t1.tm_mday = 26;
        t1.tm_mon  = 8;
        t1.tm_year = 76;

        /* midnight 25/SET/1076*/
        t2.tm_sec  = 0;
        t2.tm_min  = 0;
        t2.tm_hour = 0;
        t2.tm_mday = 25;
        t2.tm_mon  = 8;
        t2.tm_year = 76;

        printf("%li\n", mktime(&t1)-mktime(&t2));
        printf("%li\n", mktime(&t1)-mktime(&t2));

        return 0;
}
------
Outputs:

90000
86400


In perl:
-----
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-----

Outputs

90000
86400

-----

My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon

When I changed this to another timezone (Say London) the problem didn't
exist.

Thank you all for your time.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22

Message:
Logged In: YES 
user_id=4882
Originator: YES

timezone :  WET in winter WEST in summer 
I try same with timezone of NEW YORK and 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0


----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07

Message:
Logged In: YES 
user_id=627298
Originator: NO

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.

More info later on.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 16:54:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 07:54:05 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HGzyn-0005cD-Rb@sc8-sf-web6.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 04:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 16:54

Message:
Logged In: YES 
user_id=21627
Originator: NO

cvalente, thanks for the research. Making a second attempt at closing this
as third-party bug.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 15:25

Message:
Logged In: YES 
user_id=4882
Originator: YES

ok bug openned on 
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033

----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 13:47

Message:
Logged In: YES 
user_id=627298
Originator: NO

OK. This is almost surely NOT a Python bug but most likely a libc bug.

In c:
----------
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]){
        struct tm t1;
        struct tm t2;

        /* midnight 26/SET/1076*/
        t1.tm_sec  = 0;
        t1.tm_min  = 0;
        t1.tm_hour = 0;
        t1.tm_mday = 26;
        t1.tm_mon  = 8;
        t1.tm_year = 76;

        /* midnight 25/SET/1076*/
        t2.tm_sec  = 0;
        t2.tm_min  = 0;
        t2.tm_hour = 0;
        t2.tm_mday = 25;
        t2.tm_mon  = 8;
        t2.tm_year = 76;

        printf("%li\n", mktime(&t1)-mktime(&t2));
        printf("%li\n", mktime(&t1)-mktime(&t2));

        return 0;
}
------
Outputs:

90000
86400


In perl:
-----
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-----

Outputs

90000
86400

-----

My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon

When I changed this to another timezone (Say London) the problem didn't
exist.

Thank you all for your time.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 13:22

Message:
Logged In: YES 
user_id=4882
Originator: YES

timezone :  WET in winter WEST in summer 
I try same with timezone of NEW YORK and 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0


----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 13:07

Message:
Logged In: YES 
user_id=627298
Originator: NO

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.

More info later on.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 13:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 13:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 06:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 23:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 13:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 16:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 16:57:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 07:57:41 -0800
Subject: [ python-Bugs-1658959 ] os.wait child process fail when under stress
Message-ID: <E1HH02H-0005yw-92@sc8-sf-web6.sourceforge.net>

Bugs item #1658959, was opened at 2007-02-13 14:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470

Please note that this 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: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: The Groff (thegroff)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.wait child process fail when under stress

Initial Comment:
when having high amount of threads forking, os.wait fails from time to time giving a "No child" error". If you retry, eventually it will work.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 16:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

What operating system are you using? 

Why do you think this is a bug in Python and not in your operating
system?

Are you sure there are any unwaited-for children when ECHILD is returned?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 18:27:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 09:27:43 -0800
Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in
	Python 2.4
Message-ID: <E1HH1RP-0002LZ-Vc@sc8-sf-web4.sourceforge.net>

Bugs item #1659171, was opened at 2007-02-13 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=1659171&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.4

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 18:28:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 09:28:34 -0800
Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in
	Python 2.5
Message-ID: <E1HH1SE-00067H-9t@sc8-sf-web7.sourceforge.net>

Bugs item #1659171, was opened at 2007-02-13 18:27
Message generated for change (Settings changed) made by richyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Calling tparm from extension lib fails in Python 2.5

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 18:29:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 09:29:31 -0800
Subject: [ python-Bugs-1659173 ] Calling tparm from extension lib fails in
	Python 2.4
Message-ID: <E1HH1T9-0006PS-4x@sc8-sf-web9.sourceforge.net>

Bugs item #1659173, was opened at 2007-02-13 18:29
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=1659173&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.4

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 18:33:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 09:33:12 -0800
Subject: [ python-Bugs-1659173 ] Calling tparm from extension lib fails in
	Python 2.4
Message-ID: <E1HH1Wi-0008K8-U9@sc8-sf-web1.sourceforge.net>

Bugs item #1659173, was opened at 2007-02-13 18:29
Message generated for change (Comment added) made by richyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.4

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

>Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-13 18:33

Message:
Logged In: YES 
user_id=1718463
Originator: YES

Sorry, I was not aware that changing the subject opens a new bug report.
This is more appropiately tracked in [1659171].

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&group_id=5470

From noreply at sourceforge.net  Tue Feb 13 18:45:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Feb 2007 09:45:05 -0800
Subject: [ python-Bugs-1659173 ] Calling tparm from extension lib fails in
	Python 2.4
Message-ID: <E1HH1iC-0008GC-CP@sc8-sf-web8.sourceforge.net>

Bugs item #1659173, was opened at 2007-02-13 17:29
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&group_id=5470

Please note that this 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: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.4

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-13 17:33

Message:
Logged In: YES 
user_id=1718463
Originator: YES

Sorry, I was not aware that changing the subject opens a new bug report.
This is more appropiately tracked in [1659171].

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&group_id=5470

From noreply at sourceforge.net  Wed Feb 14 09:52:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Feb 2007 00:52:26 -0800
Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in
	Python 2.5
Message-ID: <E1HHFsI-0002GO-23@sc8-sf-web7.sourceforge.net>

Bugs item #1659171, was opened at 2007-02-13 18:27
Message generated for change (Comment added) made by richyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.5

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

>Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-14 09:52

Message:
Logged In: YES 
user_id=1718463
Originator: YES

I suspect that this is a duplicate of Bug [1548092].
Note that, there it is asserted that tparm returns NULL on certain invalid
strings.
That does not seem to be true. It returns NULL for valid trivial strings,
too.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

From noreply at sourceforge.net  Wed Feb 14 13:15:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Feb 2007 04:15:08 -0800
Subject: [ python-Bugs-1659705 ] Python extension problems after re-install
Message-ID: <E1HHJ2S-0006mZ-IT@sc8-sf-web5.sourceforge.net>

Bugs item #1659705, was opened at 2007-02-14 22: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=1659705&group_id=5470

Please note that this 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
Private: No
Submitted By: elf (elfin24fw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python extension problems after re-install

Initial Comment:
This has happened before on another computer at my work:
If you install python, then uninstall it, when you re-install it it stops brining up the 'Edit with Idle' option and the running from python doesnt seem to be working properly. This is extreamly annoying for me as it makes it incredibly difficult to code on, as you must open up the code through idle, and you must also reference "c:\python25\pyton.exe" before using the py file. 

Can this be fixed? is there an easy solution for me to make this work properly on my computer (and on the computer at work)?

Please email me back if you find a solution: elfin24 at gmail.com, thanks :)

Steps to reproduce:
1) Install python 2.5
2) Un-install pyton 2.5
3) Install python 2.4
4) Right click on a '*.py' file
5) Observe no 'Edit with idle' option
6) Run the *.py file (after entering in c:\python24 into the enviromental variables)
7) Observe it not working properly
8) Uninstall 2.4.4
9) Install 2.5
10) Run the *.py file (after entering in c:\python25 into the enviromental variables and removing the 24 version)
11) Observe it not working properly

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659705&group_id=5470

From noreply at sourceforge.net  Wed Feb 14 20:52:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Feb 2007 11:52:34 -0800
Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple
	set-cookie headers
Message-ID: <E1HHQB8-0007MH-S5@sc8-sf-web4.sourceforge.net>

Bugs item #1660009, was opened at 2007-02-14 19: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=1660009&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Margrave (davidma)
Assigned to: Nobody/Anonymous (nobody)
Summary: continuing problem with httplib multiple set-cookie headers

Initial Comment:

This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open.

The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string.

The problem arises when a comma character appears inside the 'expires' field of one of the cookies.  This makes it difficult to split the cookie headers back apart.  The comma character should be escaped, or a different separator character used.

i.e.

expires=Sun, 17-Jan-2038 19:14:07 GMT

For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders()

Python 2.3 has this behavior, and probably later versions.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470

From noreply at sourceforge.net  Wed Feb 14 21:18:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Feb 2007 12:18:21 -0800
Subject: [ python-Bugs-961805 ] Text.edit_modified() fails
Message-ID: <E1HHQa5-0001KH-CD@sc8-sf-web7.sourceforge.net>

Bugs item #961805, was opened at 2004-05-27 21:59
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=961805&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eric P. (ericpett)
Assigned to: Martin v. L?wis (loewis)
Summary: Text.edit_modified() fails

Initial Comment:
Text.edit_modified() fails because it calls _getints() on the 
result of the underlying tk.call().  The tk.call() is returning a 
boolean, not a string, and the _getints() fails.

Here's the last part of an example traceback:

File "/usr/local/src/staff/pett/chimera/devel/Ilabel/
__init__.py", line 53, in textCB
    if not text.edit_modified():
  File "/usr/local/src/staff/chimera-build/IRIX-X11/foreign/
Python-2.3.2/lib/python2.3/lib-tk/Tkinter.py", line 2831, in 
edit_modified
    return self.edit("modified", arg)
  File "/usr/local/src/staff/chimera-build/IRIX-X11/foreign/
Python-2.3.2/lib/python2.3/lib-tk/Tkinter.py", line 2819, in 
edit
    return self._getints(
  File "/usr/local/src/staff/chimera-build/IRIX-X11/foreign/
Python-2.3.2/lib/python2.3/lib-tk/Tkinter.py", line 972, in 
_getints
    return tuple(map(getint, self.tk.splitlist(string)))
TypeError: coercing to Unicode: need string or buffer, bool 
found

----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2007-02-14 21:18

Message:
Logged In: YES 
user_id=60903
Originator: NO

followup from https://bugs.launchpad.net/bugs/84720



As a workaround you can get the status by calling:

print root.tk.call('eval','%s edit modified'%self.textwidget)

where self.textwidget is the variable where the text widget was assigned
to.


----------------------------------------------------------------------

Comment By: Eric P. (ericpett)
Date: 2004-05-27 22:52

Message:
Logged In: YES 
user_id=1051353

I should mention that it's the argless form of edit_modified() that
fails (querying the flag state) -- setting the flag works.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=961805&group_id=5470

From noreply at sourceforge.net  Wed Feb 14 22:11:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Feb 2007 13:11:44 -0800
Subject: [ python-Bugs-1659705 ] Python extension problems after re-install
Message-ID: <E1HHRPk-0001JT-IK@sc8-sf-web9.sourceforge.net>

Bugs item #1659705, was opened at 2007-02-14 13:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659705&group_id=5470

Please note that this 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
Private: No
Submitted By: elf (elfin24fw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python extension problems after re-install

Initial Comment:
This has happened before on another computer at my work:
If you install python, then uninstall it, when you re-install it it stops brining up the 'Edit with Idle' option and the running from python doesnt seem to be working properly. This is extreamly annoying for me as it makes it incredibly difficult to code on, as you must open up the code through idle, and you must also reference "c:\python25\pyton.exe" before using the py file. 

Can this be fixed? is there an easy solution for me to make this work properly on my computer (and on the computer at work)?

Please email me back if you find a solution: elfin24 at gmail.com, thanks :)

Steps to reproduce:
1) Install python 2.5
2) Un-install pyton 2.5
3) Install python 2.4
4) Right click on a '*.py' file
5) Observe no 'Edit with idle' option
6) Run the *.py file (after entering in c:\python24 into the enviromental variables)
7) Observe it not working properly
8) Uninstall 2.4.4
9) Install 2.5
10) Run the *.py file (after entering in c:\python25 into the enviromental variables and removing the 24 version)
11) Observe it not working properly

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-14 22:11

Message:
Logged In: YES 
user_id=21627
Originator: NO

It|s unlikely that I will be able to work on this at all before April

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659705&group_id=5470

From noreply at sourceforge.net  Wed Feb 14 22:24:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Feb 2007 13:24:45 -0800
Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in
	Python 2.5
Message-ID: <E1HHRcL-0004TS-AO@sc8-sf-web11.sourceforge.net>

Bugs item #1659171, was opened at 2007-02-13 18:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.5

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-14 22:24

Message:
Logged In: YES 
user_id=21627
Originator: NO

I fail to see the bug. The exception precisely describes the error in your
code

ImportError: dynamic module does not define init function (inittestlib)

Why do you expect any meaningful behavior in the presence of this error?
Your shared library isn't an extension module.

If you think it is related to #1548092, please try out the subversion
trunk, which has fixed this bug.

----------------------------------------------------------------------

Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-14 09:52

Message:
Logged In: YES 
user_id=1718463
Originator: YES

I suspect that this is a duplicate of Bug [1548092].
Note that, there it is asserted that tparm returns NULL on certain invalid
strings.
That does not seem to be true. It returns NULL for valid trivial strings,
too.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

From noreply at sourceforge.net  Thu Feb 15 19:35:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 15 Feb 2007 10:35:56 -0800
Subject: [ python-Bugs-1519638 ] Unmatched Group issue
Message-ID: <E1HHlSW-00023O-Lm@sc8-sf-web8.sourceforge.net>

Bugs item #1519638, was opened at 2006-07-09 14:34
Message generated for change (Comment added) made by mchaput
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470

Please note that this 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: Bobby Xiao (nneonneo)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Unmatched Group issue

Initial Comment:
Using sre.sub[n], an "unmatched group" error can occur.

The test I used is this pattern:

sre.sub("foo(?:b(ar)|baz)","\\1","foobaz")

This will cause the following backtrace to occur:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "lib/python2.4/sre.py", line 142, in sub
    return _compile(pattern, 0).sub(repl, string, count)
  File "lib/python2.4/sre.py", line 260, in filter
    return sre_parse.expand_template(template, match)
  File "lib/python2.4/sre_parse.py", line 782, in expand_template
    raise error, "unmatched group"
sre_constants.error: unmatched group

Python Version 2.4.3, Mac OS X (behaviour has been verified on 
Windows 2.4.3 as well).

This behaviour, while by design, is unwanted because this type of 
matching usually requests that a blank match be returned (i.e. the 
example should return '')

The example that I was trying resembles the following:

sre.sub("User: (?:Registered User #(\d+)|Guest)","%USERID|\1%",data)

The intended behaviour is that the function returns "" when the user is 
a guest and the user number if the user is a registered member.

However, when this function encounters a Guest, it raises an exception 
and terminates, which is not what is wanted.

Perl and other regex engines behave as I have described, substituting 
empty strings for unmatched groups. The code fix is relatively simple, 
and would really help out for these types of things.

----------------------------------------------------------------------

Comment By: Matt Chaput (mchaput)
Date: 2007-02-15 13:35

Message:
Logged In: YES 
user_id=1249840
Originator: NO

The current behavior also makes the "sub" function useless when you need
to backreference a group that might not capture, since you have no chance
to deal with the exception.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 04:11:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 15 Feb 2007 19:11:23 -0800
Subject: [ python-Bugs-1661108 ] base64.urlsafe_b64encode() shouldn't use the
	= character
Message-ID: <E1HHtVL-0007lU-4P@sc8-sf-web4.sourceforge.net>

Bugs item #1661108, was opened at 2007-02-16 03: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=1661108&group_id=5470

Please note that this 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
Private: No
Submitted By: Ryan Barrett (ryanbarrett)
Assigned to: Nobody/Anonymous (nobody)
Summary: base64.urlsafe_b64encode() shouldn't use the = character

Initial Comment:
base64.urlsafe_b64encode() almost always returns strings that include the = character. this may be ok before the ? in a URL, but it's not OK after.

it would be nice if it substituted another character for =, like it does for + and /. if this is intentional, though, and you don't want to substitute for =, the documentation should probably be changed to note that it's only safe for use before the ?. (it doesn't include that caveat now.)

http://docs.python.org/lib/module-base64.html#l2h-1592

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 16:32:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 07:32:14 -0800
Subject: [ python-Bugs-1661603 ] Misleading behavior for [] and {} default
	arguments
Message-ID: <E1HI54I-0004Rv-DA@sc8-sf-web11.sourceforge.net>

Bugs item #1661603, was opened at 2007-02-16 16:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661603&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthijs (matthijsd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading behavior for [] and {} default arguments

Initial Comment:
Hello

On python 2.3.4 and 2.4.3, 

>>> def a(x=[]):
...   return x
... 
>>> y=a()
>>> y.append(1)
>>> a()
[1]

Hence, the default argument is not recomputed. The same behavior occurs with x={} instead of x=[].

This looks like a bug because it is not coherent with 

>>> def f():
...   return []
... 
>>> y=f()
>>> y.append(5)
>>> f()
[]

So, is it a feature?

Thanks



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661603&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 16:40:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 07:40:17 -0800
Subject: [ python-Bugs-1661603 ] Misleading behavior for [] and {} default
	arguments
Message-ID: <E1HI5C5-0000wO-BW@sc8-sf-web9.sourceforge.net>

Bugs item #1661603, was opened at 2007-02-16 15:32
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661603&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: Matthijs (matthijsd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading behavior for [] and {} default arguments

Initial Comment:
Hello

On python 2.3.4 and 2.4.3, 

>>> def a(x=[]):
...   return x
... 
>>> y=a()
>>> y.append(1)
>>> a()
[1]

Hence, the default argument is not recomputed. The same behavior occurs with x={} instead of x=[].

This looks like a bug because it is not coherent with 

>>> def f():
...   return []
... 
>>> y=f()
>>> y.append(5)
>>> f()
[]

So, is it a feature?

Thanks



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-16 15:40

Message:
Logged In: YES 
user_id=849994
Originator: NO

Yes, it is. (Please post questions about Python semantics to the
comp.lang.python newsgroup, they'll explain them in detail...)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661603&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 17:42:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 08:42:59 -0800
Subject: [ python-Bugs-1648268 ] Parameter list mismatches (portation problem)
Message-ID: <E1HI6Al-00072J-Fp@sc8-sf-web9.sourceforge.net>

Bugs item #1648268, was opened at 2007-01-30 22:15
Message generated for change (Comment added) made by ked-tao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648268&group_id=5470

Please note that this 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: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parameter list mismatches (portation problem)

Initial Comment:
On the system I'm porting to(*), an application will trap if the caller does not pass the exact parameter list that the callee requires. This is causing problems running Python.

One common instance where this appears to be causing problems is where functions are registered as METH_NOARGS methods. For example, in Obejcts/dictobject.c, dict_popitem() is declared:

static PyObject *dict_popitem(dictobject *mp);

However, as it is declared in the method array as METH_NOARGS, it will be called by Objects/methodobject.c:PyCFunction_Call() as "(*meth)(self, NULL)" (i.e., an extra NULL parameter is passed for some reason). This will fail on my target system.

I've no problem submitting a patch for this (dictobject.c is by no means the only place this is happening - it's just the first one encountered because it's used so much - though some places _do_ correctly declare a second, ignored parameter). However, I'd like to get agreement on the correct form it should be changed to before I put the effort in to produce a patch (it's going to be a fairly tedious process to identify and fix all these).

In various modules, the functions are called internally as well as being registered as METH_NOARGS methods.

Therefore, the change can either be:

static PyObject *foo(PyObject *self)
{
  ...
}

static PyObject *foo_noargs(PyObject *self, void *noargs_null)
{
   return foo(self);
}

... where 'foo' is called internally and 'foo_noargs' is registered as a METH_NOARGS method.

or:

static PyObject *foo(PyObject *self, void *noargs_null)
{
  ...
}

... and any internal calls in the module have to pass a second, NULL, argument in each call.

The former favours internal module calls over METH_NOARGS calls, the latter penalises them. Which is preferred? Should this be raised on a different forum? Does anyone care? ;)

Thanks, Kev.

(*) Details on request.

----------------------------------------------------------------------

>Comment By: ked-tao (ked-tao)
Date: 2007-02-16 16:42

Message:
Logged In: YES 
user_id=1703158
Originator: YES

File Added: tested.diff

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 19:49

Message:
Logged In: YES 
user_id=21627
Originator: NO

The current specification says that these should be PyCFunction pointers,
see

http://docs.python.org/api/common-structs.html

My initial implementation of METH_NOARGS had it differently, and nobody
ever bothered fixing them all when this was changed. Please do submit a
patch to correct all such errors, both in code and documentation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648268&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 17:46:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 08:46:49 -0800
Subject: [ python-Bugs-1648268 ] Parameter list mismatches (portation problem)
Message-ID: <E1HI6ET-0007QB-5W@sc8-sf-web9.sourceforge.net>

Bugs item #1648268, was opened at 2007-01-30 22:15
Message generated for change (Comment added) made by ked-tao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648268&group_id=5470

Please note that this 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: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parameter list mismatches (portation problem)

Initial Comment:
On the system I'm porting to(*), an application will trap if the caller does not pass the exact parameter list that the callee requires. This is causing problems running Python.

One common instance where this appears to be causing problems is where functions are registered as METH_NOARGS methods. For example, in Obejcts/dictobject.c, dict_popitem() is declared:

static PyObject *dict_popitem(dictobject *mp);

However, as it is declared in the method array as METH_NOARGS, it will be called by Objects/methodobject.c:PyCFunction_Call() as "(*meth)(self, NULL)" (i.e., an extra NULL parameter is passed for some reason). This will fail on my target system.

I've no problem submitting a patch for this (dictobject.c is by no means the only place this is happening - it's just the first one encountered because it's used so much - though some places _do_ correctly declare a second, ignored parameter). However, I'd like to get agreement on the correct form it should be changed to before I put the effort in to produce a patch (it's going to be a fairly tedious process to identify and fix all these).

In various modules, the functions are called internally as well as being registered as METH_NOARGS methods.

Therefore, the change can either be:

static PyObject *foo(PyObject *self)
{
  ...
}

static PyObject *foo_noargs(PyObject *self, void *noargs_null)
{
   return foo(self);
}

... where 'foo' is called internally and 'foo_noargs' is registered as a METH_NOARGS method.

or:

static PyObject *foo(PyObject *self, void *noargs_null)
{
  ...
}

... and any internal calls in the module have to pass a second, NULL, argument in each call.

The former favours internal module calls over METH_NOARGS calls, the latter penalises them. Which is preferred? Should this be raised on a different forum? Does anyone care? ;)

Thanks, Kev.

(*) Details on request.

----------------------------------------------------------------------

>Comment By: ked-tao (ked-tao)
Date: 2007-02-16 16:46

Message:
Logged In: YES 
user_id=1703158
Originator: YES

Hi,

I am submitting two patches (both against the 2.5 release sources). One
contains a set of changes which have subsequently been compiled by me and
used to run lib/python/test/regrtest.py. If the format of the changes
themselves is acceptable, then I believe this patch can be applied
relatively
confidently. I haven't paid too much attention to conditional compilation
in
those files, but there appears to be little in the areas I've touched.

The second contains a set of changes to source files that are not being
used
at present on my system. Therefore, they _may_ not compile. I have
visually
checked that all functions whose signature I have changed are not called
directly (across all source files) with the old signature and have also
checked
header file prototypes. However, that doesn't mean I didn't miss
something, so
this patch should be applied with a little more care.

The nature of the fixes themselves are discussed below.

-----------------------------------
==== Fixes to common problems across several files:

* Failure to declare second (always NULL) parameter on functions
registered as
  METH_NOARGS methods.

  - These all now have a second parameter declared as "PyObject
*NOARGS_NULL".
  - I have also changed ones that already declared the parameter as
    "void *ignored" etc, as I think the name makes it clear why it's
there.
    If the upper-case name is bad style, feel free to change it to
something
    else - as they are all now consistent, that should be a trivial
process
    to change in the patch file before applying it.

* PyGetSetDef 'getter' and 'setter' functions not declaring the final
'closure'
  parameter.

  - These all now have a final parameter declared as "void *closure".
  - I have also changed ones that already declared the parameter as
    "void *context" or "void *ignored" etc, for consistency.

* The tp_clear type slot is defined as type 'inquiry' but the return value
is
  ignored and in some instances, not returned at all. This is related to
the
  following thread:

  http://mail.python.org/pipermail/python-dev/2003-April/034433.html

  frameobject.c and traceback.c were either missed when those changes
were
  made, or the problems were re-introduced since.

  - I have changed the functions in those files to return zero.

==== Miscellaneous individual fixes:

* Objects/fileobject.c:file_self() is registered both in the "tp_iter"
slot
  and as a METH_NOARGS function. The "tp_iter" slot function is
  called with one parameter (the object) and the METH_NOARGS function is
called
  with two parameters (the object, a NULL pointer).

  - Wrapper function file_self_noargs() created which accepts the
additional
    "PyObject *NOARGS_NULL" parameter and just calls the file_self()
function.
  - All other occurences of tp_iter visually checked and appear to be OK.

* The datetimemodule.c problem with time_isoformat() being registered as
  METH_KEYWORDS instead of METH_NOARGS is also fixed here, though I
believe
  that has already been dealt with.

-----------------------------------

All in all, that was a pretty tedious process! Hopefully these changes can

mostly make it in so I don't have to do it all over again one day ;)

Regards, Kev.

File Added: untested.diff

----------------------------------------------------------------------

Comment By: ked-tao (ked-tao)
Date: 2007-02-16 16:42

Message:
Logged In: YES 
user_id=1703158
Originator: YES

File Added: tested.diff

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-06 19:49

Message:
Logged In: YES 
user_id=21627
Originator: NO

The current specification says that these should be PyCFunction pointers,
see

http://docs.python.org/api/common-structs.html

My initial implementation of METH_NOARGS had it differently, and nobody
ever bothered fixing them all when this was changed. Please do submit a
patch to correct all such errors, both in code and documentation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648268&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 19:10:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 10:10:20 -0800
Subject: [ python-Bugs-1661108 ] base64.urlsafe_b64encode() shouldn't use the
	= character
Message-ID: <E1HI7XI-000837-PK@sc8-sf-web3.sourceforge.net>

Bugs item #1661108, was opened at 2007-02-16 03:11
Message generated for change (Comment added) made by ryanbarrett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&group_id=5470

Please note that this 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
Private: No
Submitted By: Ryan Barrett (ryanbarrett)
Assigned to: Nobody/Anonymous (nobody)
Summary: base64.urlsafe_b64encode() shouldn't use the = character

Initial Comment:
base64.urlsafe_b64encode() almost always returns strings that include the = character. this may be ok before the ? in a URL, but it's not OK after.

it would be nice if it substituted another character for =, like it does for + and /. if this is intentional, though, and you don't want to substitute for =, the documentation should probably be changed to note that it's only safe for use before the ?. (it doesn't include that caveat now.)

http://docs.python.org/lib/module-base64.html#l2h-1592

----------------------------------------------------------------------

>Comment By: Ryan Barrett (ryanbarrett)
Date: 2007-02-16 18:10

Message:
Logged In: YES 
user_id=751286
Originator: YES

after more investigation, RFC3548 does say to use the = character for
padding even in the URL-safe alphabet. weird.

so, it looks like the base64 module is just following the spec, and it's
the spec that (seems) broken. sigh.

i'm off to try to figure out why RFC3548 says = is ok in URLs...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 19:27:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 10:27:51 -0800
Subject: [ python-Bugs-1614460 ] python-logging compatability with Zope.
Message-ID: <E1HI7oF-0003uy-Cz@sc8-sf-web6.sourceforge.net>

Bugs item #1614460, was opened at 2006-12-13 03:02
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470

Please note that this 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: None
Priority: 5
Private: No
Submitted By: Simon Hookway (shookway)
Assigned to: Vinay Sajip (vsajip)
Summary: python-logging compatability with Zope.

Initial Comment:
I'm using Zope2.8.x and python2.4.

On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it.

This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification.

See the included patch.

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2007-02-16 18:27

Message:
Logged In: YES 
user_id=308438
Originator: NO

The change was backported to the release24-maint branch some time ago -
sorry for not making it clear.

----------------------------------------------------------------------

Comment By: Simon Hookway (shookway)
Date: 2007-02-11 23:57

Message:
Logged In: YES 
user_id=1667120
Originator: YES

"fixed in 2.5" -- that is the problem, why was this fix not rolled back to
python2.4? I submit this patch for those of us out there still using 2.4
and likely to be using it for a while to come. 

Can we have it fixed in 2.4 please.

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2006-12-30 03:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

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: Vinay Sajip (vsajip)
Date: 2006-12-15 17:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

Yes, a fix was applied a while ago.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-12-15 08:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

I believe this was fixed in 2.5, but I could be mistaken.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 20:11:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 11:11:18 -0800
Subject: [ python-Bugs-1661745 ] finditer stuck in infinite loop
Message-ID: <E1HI8UI-0005TV-I0@sc8-sf-web7.sourceforge.net>

Bugs item #1661745, was opened at 2007-02-16 20: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=1661745&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Milan (migues)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: finditer stuck in infinite loop

Initial Comment:
Using iterator on Match Object results in infinite unbreakable loop. Attached is sample script and sample file.

My OS: Win XP Pro.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661745&group_id=5470

From noreply at sourceforge.net  Fri Feb 16 23:45:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 14:45:54 -0800
Subject: [ python-Bugs-1652788 ] logging formatter %(lineno)d does not work
Message-ID: <E1HIBpy-00062e-1O@sc8-sf-web11.sourceforge.net>

Bugs item #1652788, was opened at 2007-02-05 23:42
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652788&group_id=5470

Please note that this 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: lx_jakal (alex_petry)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging formatter %(lineno)d does not work

Initial Comment:
The current line number produced by the module is "1072" which is static over all logging calls. It refers to a the denoted line in logging/__init__.py

A possible patch is attached.


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2007-02-16 22:45

Message:
Logged In: YES 
user_id=308438
Originator: NO

Change checked into trunk, and will be shortly checked into
release25-maint and release24-maint.

----------------------------------------------------------------------

Comment By: lx_jakal (alex_petry)
Date: 2007-02-06 01:07

Message:
Logged In: YES 
user_id=1033478
Originator: YES

File Added: python-logging-2.5-fixed.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652788&group_id=5470

From noreply at sourceforge.net  Sat Feb 17 03:55:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 18:55:15 -0800
Subject: [ python-Bugs-1519638 ] Unmatched Group issue
Message-ID: <E1HIFjH-0005cq-3R@sc8-sf-web11.sourceforge.net>

Bugs item #1519638, was opened at 2006-07-09 18:34
Message generated for change (Settings changed) made by nneonneo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bobby Xiao (nneonneo)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Unmatched Group issue

Initial Comment:
Using sre.sub[n], an "unmatched group" error can occur.

The test I used is this pattern:

sre.sub("foo(?:b(ar)|baz)","\\1","foobaz")

This will cause the following backtrace to occur:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "lib/python2.4/sre.py", line 142, in sub
    return _compile(pattern, 0).sub(repl, string, count)
  File "lib/python2.4/sre.py", line 260, in filter
    return sre_parse.expand_template(template, match)
  File "lib/python2.4/sre_parse.py", line 782, in expand_template
    raise error, "unmatched group"
sre_constants.error: unmatched group

Python Version 2.4.3, Mac OS X (behaviour has been verified on 
Windows 2.4.3 as well).

This behaviour, while by design, is unwanted because this type of 
matching usually requests that a blank match be returned (i.e. the 
example should return '')

The example that I was trying resembles the following:

sre.sub("User: (?:Registered User #(\d+)|Guest)","%USERID|\1%",data)

The intended behaviour is that the function returns "" when the user is 
a guest and the user number if the user is a registered member.

However, when this function encounters a Guest, it raises an exception 
and terminates, which is not what is wanted.

Perl and other regex engines behave as I have described, substituting 
empty strings for unmatched groups. The code fix is relatively simple, 
and would really help out for these types of things.

----------------------------------------------------------------------

Comment By: Matt Chaput (mchaput)
Date: 2007-02-15 18:35

Message:
Logged In: YES 
user_id=1249840
Originator: NO

The current behavior also makes the "sub" function useless when you need
to backreference a group that might not capture, since you have no chance
to deal with the exception.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470

From noreply at sourceforge.net  Sat Feb 17 03:56:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 18:56:56 -0800
Subject: [ python-Bugs-1519638 ] Unmatched Group issue
Message-ID: <E1HIFku-0005jW-6a@sc8-sf-web11.sourceforge.net>

Bugs item #1519638, was opened at 2006-07-09 18:34
Message generated for change (Comment added) made by nneonneo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bobby Xiao (nneonneo)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Unmatched Group issue

Initial Comment:
Using sre.sub[n], an "unmatched group" error can occur.

The test I used is this pattern:

sre.sub("foo(?:b(ar)|baz)","\\1","foobaz")

This will cause the following backtrace to occur:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "lib/python2.4/sre.py", line 142, in sub
    return _compile(pattern, 0).sub(repl, string, count)
  File "lib/python2.4/sre.py", line 260, in filter
    return sre_parse.expand_template(template, match)
  File "lib/python2.4/sre_parse.py", line 782, in expand_template
    raise error, "unmatched group"
sre_constants.error: unmatched group

Python Version 2.4.3, Mac OS X (behaviour has been verified on 
Windows 2.4.3 as well).

This behaviour, while by design, is unwanted because this type of 
matching usually requests that a blank match be returned (i.e. the 
example should return '')

The example that I was trying resembles the following:

sre.sub("User: (?:Registered User #(\d+)|Guest)","%USERID|\1%",data)

The intended behaviour is that the function returns "" when the user is 
a guest and the user number if the user is a registered member.

However, when this function encounters a Guest, it raises an exception 
and terminates, which is not what is wanted.

Perl and other regex engines behave as I have described, substituting 
empty strings for unmatched groups. The code fix is relatively simple, 
and would really help out for these types of things.

----------------------------------------------------------------------

>Comment By: Bobby Xiao (nneonneo)
Date: 2007-02-17 02:56

Message:
Logged In: YES 
user_id=393491
Originator: YES

AFAIK the findall function works as desired in this respect: empty matches
will return empty strings.

----------------------------------------------------------------------

Comment By: Matt Chaput (mchaput)
Date: 2007-02-15 18:35

Message:
Logged In: YES 
user_id=1249840
Originator: NO

The current behavior also makes the "sub" function useless when you need
to backreference a group that might not capture, since you have no chance
to deal with the exception.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470

From noreply at sourceforge.net  Sat Feb 17 08:32:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Feb 2007 23:32:16 -0800
Subject: [ python-Bugs-1661108 ] base64.urlsafe_b64encode() shouldn't use the
	= character
Message-ID: <E1HIK3M-0002vi-8q@sc8-sf-web9.sourceforge.net>

Bugs item #1661108, was opened at 2007-02-16 03:11
Message generated for change (Comment added) made by ryanbarrett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&group_id=5470

Please note that this 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
Private: No
Submitted By: Ryan Barrett (ryanbarrett)
Assigned to: Nobody/Anonymous (nobody)
Summary: base64.urlsafe_b64encode() shouldn't use the = character

Initial Comment:
base64.urlsafe_b64encode() almost always returns strings that include the = character. this may be ok before the ? in a URL, but it's not OK after.

it would be nice if it substituted another character for =, like it does for + and /. if this is intentional, though, and you don't want to substitute for =, the documentation should probably be changed to note that it's only safe for use before the ?. (it doesn't include that caveat now.)

http://docs.python.org/lib/module-base64.html#l2h-1592

----------------------------------------------------------------------

>Comment By: Ryan Barrett (ryanbarrett)
Date: 2007-02-17 07:32

Message:
Logged In: YES 
user_id=751286
Originator: YES

i talked to harald alvestrand, and he made the good point that the =
character is only problematic in URL parameter names. it's ok, if unusual,
in parameter values, since the & character is used at the end the value.

apart from that, though, he didn't sound like this would be a priority for
the IETF to address. unfortunate, but understandable. :P

so, the resolution here might just be to update the base64 documentation
to say that urlsafe_b64encode's output may include the = character. another
option would be to change the code to use different character for padding,
which would be nicer, but wouldn't follow the spec. up to you.

----------------------------------------------------------------------

Comment By: Ryan Barrett (ryanbarrett)
Date: 2007-02-16 18:10

Message:
Logged In: YES 
user_id=751286
Originator: YES

after more investigation, RFC3548 does say to use the = character for
padding even in the URL-safe alphabet. weird.

so, it looks like the base64 module is just following the spec, and it's
the spec that (seems) broken. sigh.

i'm off to try to figure out why RFC3548 says = is ok in URLs...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&group_id=5470

From noreply at sourceforge.net  Sat Feb 17 22:38:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 17 Feb 2007 13:38:02 -0800
Subject: [ python-Bugs-1662529 ] [2.5 regression?] failure to import the ORBit
	extension
Message-ID: <E1HIXFq-000557-6R@sc8-sf-web2.sourceforge.net>

Bugs item #1662529, was opened at 2007-02-17 22:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662529&group_id=5470

Please note that this 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: 5
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: [2.5 regression?] failure to import the ORBit extension

Initial Comment:
seen with 2.5 SVN 20070216, with an interpreter built with --enable-pydebug, succeeds with a 2.4.4 interpreter built with --enable-pydebug:

pyorbit is version 2.14.1.

$ python-dbg -c 'import ORBit'
[26750 refs]
Fatal Python error: ../Objects/tupleobject.c:169 object at 0x8186bdc has negative ref count -1
Aborted (core dumped)

(gdb) bt
#0  0xb7f89410 in __kernel_vsyscall ()
#1  0xb7e11df0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e13641 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x081174f8 in Py_FatalError (
    msg=0xbfd0ef78 "../Objects/tupleobject.c:169 object at 0x8186bdc has negative ref count -1")
    at ../Python/pythonrun.c:1555
#4  0x08093305 in _Py_NegativeRefcount (fname=0x816f958 "../Objects/tupleobject.c", lineno=169, op=0x8186bdc)
    at ../Objects/object.c:193
#5  0x080add27 in tupledealloc (op=0xb7a1bd1c) at ../Objects/tupleobject.c:169
#6  0x080973a6 in _Py_Dealloc (op=0xb7a1bd1c) at ../Objects/object.c:1928
#7  0x0814d037 in func_dealloc (op=0xb7a1d1c4) at ../Objects/funcobject.c:451
#8  0x080973a6 in _Py_Dealloc (op=0xb7a1d1c4) at ../Objects/object.c:1928
#9  0x0808eb99 in dict_dealloc (mp=0xb7a1c494) at ../Objects/dictobject.c:819
#10 0x080973a6 in _Py_Dealloc (op=0xb7a1c494) at ../Objects/object.c:1928
#11 0x0806459e in class_dealloc (op=0xb7a0bdb4) at ../Objects/classobject.c:184
#12 0x080973a6 in _Py_Dealloc (op=0xb7a0bdb4) at ../Objects/object.c:1928
#13 0x080add3b in tupledealloc (op=0xb7a22edc) at ../Objects/tupleobject.c:169
#14 0x080973a6 in _Py_Dealloc (op=0xb7a22edc) at ../Objects/object.c:1928
#15 0x08064540 in class_dealloc (op=0xb7a2446c) at ../Objects/classobject.c:183
#16 0x080973a6 in _Py_Dealloc (op=0xb7a2446c) at ../Objects/object.c:1928
#17 0x080add3b in tupledealloc (op=0xb7a243dc) at ../Objects/tupleobject.c:169
#18 0x080b13fe in subtype_dealloc (self=0xb7a243dc) at ../Objects/typeobject.c:709
#19 0x080973a6 in _Py_Dealloc (op=0xb7a243dc) at ../Objects/object.c:1928
#20 0x0808eb99 in dict_dealloc (mp=0xb7dcf214) at ../Objects/dictobject.c:819
#21 0x080973a6 in _Py_Dealloc (op=0xb7dcf214) at ../Objects/object.c:1928
#22 0x08112acb in PyInterpreterState_Clear (interp=0x81b8020) at ../Python/pystate.c:107
#23 0x081145be in Py_Finalize () at ../Python/pythonrun.c:441
#24 0x08059eb0 in Py_Main (argc=3, argv=0xbfd0f5b4) at ../Modules/main.c:545
#25 0x08058da6 in main (argc=Cannot access memory at address 0x155c
) at ../Modules/python.c:23


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662529&group_id=5470

From noreply at sourceforge.net  Sun Feb 18 00:39:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 17 Feb 2007 15:39:24 -0800
Subject: [ python-Bugs-1662581 ] the re module can perform poorly: O(2**n)
	versus O(n**2)
Message-ID: <E1HIZ9I-0006Is-3j@sc8-sf-web8.sourceforge.net>

Bugs item #1662581, was opened at 2007-02-17 15:39
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=1662581&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gregory P. Smith (greg)
Assigned to: Nobody/Anonymous (nobody)
Summary: the re module can perform poorly: O(2**n) versus O(n**2)

Initial Comment:
in short, the re module can degenerate to really really horrid performance.  See this for how and why:

 http://swtch.com/~rsc/regexp/regexp1.html

exponential decline instead of squared.

I don't have a patch so i'm filing this bug as a starting point for future work.  The Modules/_sre.c files implementation could be updated to use the parallel stepping Thompson approach instead of recursive backtracking.

filing this as a bug until me or someone else comes up with a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662581&group_id=5470

From noreply at sourceforge.net  Sun Feb 18 00:48:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 17 Feb 2007 15:48:18 -0800
Subject: [ python-Bugs-1662581 ] the re module can perform poorly: O(2**n)
	versus O(n**2)
Message-ID: <E1HIZHu-0004fc-1b@sc8-sf-web5.sourceforge.net>

Bugs item #1662581, was opened at 2007-02-17 15:39
Message generated for change (Settings changed) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662581&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: None
Status: Open
Resolution: None
>Priority: 4
Private: No
Submitted By: Gregory P. Smith (greg)
Assigned to: Nobody/Anonymous (nobody)
Summary: the re module can perform poorly: O(2**n) versus O(n**2)

Initial Comment:
in short, the re module can degenerate to really really horrid performance.  See this for how and why:

 http://swtch.com/~rsc/regexp/regexp1.html

exponential decline instead of squared.

I don't have a patch so i'm filing this bug as a starting point for future work.  The Modules/_sre.c files implementation could be updated to use the parallel stepping Thompson approach instead of recursive backtracking.

filing this as a bug until me or someone else comes up with a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662581&group_id=5470

From noreply at sourceforge.net  Sun Feb 18 09:51:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 18 Feb 2007 00:51:23 -0800
Subject: [ python-Bugs-1653736 ] Problems in datetime.c and typeobject.c.
Message-ID: <E1HIhlT-00058J-2s@sc8-sf-web2.sourceforge.net>

Bugs item #1653736, was opened at 2007-02-07 02:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653736&group_id=5470

Please note that this 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
Private: No
Submitted By: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems in datetime.c and typeobject.c.

Initial Comment:
This is related to [python-Bugs-1648268], but I think these problems might be important enough to consider fixing prior to any patch being produced for that item.

Modules/datetimemodule.c:time_isoformat() is declared in time_methods[] as METH_KEYWORDS. However, I believe it is better declared as METH_NOARGS (calling it with args and kwargs doesn't raise any exception, but it doesn't accept them).

Objects/typeobject.c:4428 - slot_nb_inplace_power is declared with the SLOT1() macro. I'm not sure I entirely grok what's going on here (not enough to supply a python-level failure case), but it seems to me that it should be declared with the SLOT2() macro (it's a ternary op). FWIW, I changed it from:

SLOT1(slot_nb_inplace_power, "__ipow__", PyObject *, "O")

to:

SLOT2(slot_nb_inplace_power, "__ipow__", PyObject *, PyObject *, "OO")

... and that ran the failing tests OK.

Hopefully someone familiar with this code can determine if this is correct or not.

Thanks, Kev.




----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-18 09:51

Message:
Logged In: YES 
user_id=21627
Originator: NO

I had to revert r53672. New fix is r53816.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-09 13:20

Message:
Logged In: YES 
user_id=21627
Originator: NO

The second bug should now be fixed in r53689 and r53690.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-08 10:18

Message:
Logged In: YES 
user_id=21627
Originator: NO

Thanks for the report. I have fixed the first bug, in r53671 and r53672.

As for the second bug: I think your suggested change is wrong. __ipow__ is
supposed to take only two arguments. I'm unsure why nb_inplace_power is
defined with three arguments; the third argument is set to Py_None in all
places I could find. So it is, at a minimum,
ok if slot_nb_inplace_power discards its third argument; I wonder whether
the API should be changed to drop this argument entirely. This is for
python-dev to discuss.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653736&group_id=5470

From noreply at sourceforge.net  Mon Feb 19 03:38:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 18 Feb 2007 18:38:32 -0800
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1HIyQC-0007co-UI@sc8-sf-web6.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 11:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

Please note that this 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: Fixed
>Priority: 8
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-18 21:38

Message:
Logged In: YES 
user_id=80475
Originator: NO

There are more of these that need to be fixed:

bufferobject.c:236:     if (!_PyArg_NoKeywords("buffer()", kw))
classobject.c:2261:     if (!_PyArg_NoKeywords("instancemethod", kw))
exceptions.c:57:    if (!_PyArg_NoKeywords(self->ob_type->tp_name, kwds))
funcobject.c:653:       if (!_PyArg_NoKeywords("classmethod", kwds))
funcobject.c:810:       if (!_PyArg_NoKeywords("staticmethod", kwds))
rangeobject.c:48:       if (!_PyArg_NoKeywords("xrange()", kw))
sliceobject.c:197:      if (!_PyArg_NoKeywords("slice()", kw))
typeobject.c:5773:      if (!_PyArg_NoKeywords("super", kwds))



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-21 05:29

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed as rev. 53509, 53510 (2.5).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-17 04:13

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll create the testcases and commit the patch (as well as NEWS entries :)
when I find the time.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-17 02:22

Message:
Logged In: YES 
user_id=33168
Originator: NO

Were these changes applied by Raymond?  I don't think there were NEWS
entries though.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 15:43

Message:
Logged In: YES 
user_id=80475
Originator: NO

That looks about right.  Please add test cases that fail without the patch
and succeed with the patch.  Also, put a comment in Misc/NEWS.  If the
whole test suite passes, go ahead and check-in to Py2.5.1 and the head.  

Thanks, 

Raymond

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 14:56

Message:
Logged In: YES 
user_id=849994
Originator: NO

Attaching patch.
File Added: nokeywordchecks.diff

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 13:30

Message:
Logged In: YES 
user_id=80475
Originator: NO

I fixed setobject.c in revisions 53380 and 53381.

Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-10 19:49

Message:
Logged In: YES 
user_id=80475
Originator: NO

My proposed solution:

- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 16:30

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll do that, only in set_init, you have 
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))

Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name

Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 21:26

Message:
Logged In: YES 
user_id=80475
Originator: NO

I prefer the approach used by list().

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 20:19

Message:
Logged In: YES 
user_id=1326842

See patch #1491939

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 15:02

Message:
Logged In: YES 
user_id=1326842

This bug was introduced as part of the fix for bug #1119418.

It also affects collections.deque.

Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?

array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.

The rest of the types changed in that fix should not
be affected, since they are immutable.
 

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 12:23

Message:
Logged In: YES 
user_id=849994

Raymond, what to do in this case?

Note that other built-in types, such as list(), do accept
keyword arguments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Mon Feb 19 09:02:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Feb 2007 00:02:00 -0800
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1HJ3TE-00065J-9G@sc8-sf-web7.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 16:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

Please note that this 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: Fixed
Priority: 8
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-19 08:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

The exceptions.c one is in __init__, so it is not a problem when the
derived class doesn't pass along kwargs to super.__init__.

I deliberately left the others as they were since their type objects lack
the Py_TPFLAGS_BASETYPE flag.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-19 02:38

Message:
Logged In: YES 
user_id=80475
Originator: NO

There are more of these that need to be fixed:

bufferobject.c:236:     if (!_PyArg_NoKeywords("buffer()", kw))
classobject.c:2261:     if (!_PyArg_NoKeywords("instancemethod", kw))
exceptions.c:57:    if (!_PyArg_NoKeywords(self->ob_type->tp_name, kwds))
funcobject.c:653:       if (!_PyArg_NoKeywords("classmethod", kwds))
funcobject.c:810:       if (!_PyArg_NoKeywords("staticmethod", kwds))
rangeobject.c:48:       if (!_PyArg_NoKeywords("xrange()", kw))
sliceobject.c:197:      if (!_PyArg_NoKeywords("slice()", kw))
typeobject.c:5773:      if (!_PyArg_NoKeywords("super", kwds))



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-21 10:29

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed as rev. 53509, 53510 (2.5).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-17 09:13

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll create the testcases and commit the patch (as well as NEWS entries :)
when I find the time.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-17 07:22

Message:
Logged In: YES 
user_id=33168
Originator: NO

Were these changes applied by Raymond?  I don't think there were NEWS
entries though.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 20:43

Message:
Logged In: YES 
user_id=80475
Originator: NO

That looks about right.  Please add test cases that fail without the patch
and succeed with the patch.  Also, put a comment in Misc/NEWS.  If the
whole test suite passes, go ahead and check-in to Py2.5.1 and the head.  

Thanks, 

Raymond

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 19:56

Message:
Logged In: YES 
user_id=849994
Originator: NO

Attaching patch.
File Added: nokeywordchecks.diff

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 18:30

Message:
Logged In: YES 
user_id=80475
Originator: NO

I fixed setobject.c in revisions 53380 and 53381.

Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 00:49

Message:
Logged In: YES 
user_id=80475
Originator: NO

My proposed solution:

- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 21:30

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll do that, only in set_init, you have 
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))

Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name

Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-06 02:26

Message:
Logged In: YES 
user_id=80475
Originator: NO

I prefer the approach used by list().

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-20 01:19

Message:
Logged In: YES 
user_id=1326842

See patch #1491939

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 20:02

Message:
Logged In: YES 
user_id=1326842

This bug was introduced as part of the fix for bug #1119418.

It also affects collections.deque.

Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?

array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.

The rest of the types changed in that fix should not
be affected, since they are immutable.
 

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 17:23

Message:
Logged In: YES 
user_id=849994

Raymond, what to do in this case?

Note that other built-in types, such as list(), do accept
keyword arguments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Mon Feb 19 09:21:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Feb 2007 00:21:52 -0800
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1HJ3mS-0001MP-CW@sc8-sf-web9.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 11:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

Please note that this 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: 8
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-19 03:21

Message:
Logged In: YES 
user_id=80475
Originator: NO

Okay, it looks like this bug was already fixed.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-19 03:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

The exceptions.c one is in __init__, so it is not a problem when the
derived class doesn't pass along kwargs to super.__init__.

I deliberately left the others as they were since their type objects lack
the Py_TPFLAGS_BASETYPE flag.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-18 21:38

Message:
Logged In: YES 
user_id=80475
Originator: NO

There are more of these that need to be fixed:

bufferobject.c:236:     if (!_PyArg_NoKeywords("buffer()", kw))
classobject.c:2261:     if (!_PyArg_NoKeywords("instancemethod", kw))
exceptions.c:57:    if (!_PyArg_NoKeywords(self->ob_type->tp_name, kwds))
funcobject.c:653:       if (!_PyArg_NoKeywords("classmethod", kwds))
funcobject.c:810:       if (!_PyArg_NoKeywords("staticmethod", kwds))
rangeobject.c:48:       if (!_PyArg_NoKeywords("xrange()", kw))
sliceobject.c:197:      if (!_PyArg_NoKeywords("slice()", kw))
typeobject.c:5773:      if (!_PyArg_NoKeywords("super", kwds))



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-21 05:29

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed as rev. 53509, 53510 (2.5).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-17 04:13

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll create the testcases and commit the patch (as well as NEWS entries :)
when I find the time.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-17 02:22

Message:
Logged In: YES 
user_id=33168
Originator: NO

Were these changes applied by Raymond?  I don't think there were NEWS
entries though.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 15:43

Message:
Logged In: YES 
user_id=80475
Originator: NO

That looks about right.  Please add test cases that fail without the patch
and succeed with the patch.  Also, put a comment in Misc/NEWS.  If the
whole test suite passes, go ahead and check-in to Py2.5.1 and the head.  

Thanks, 

Raymond

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 14:56

Message:
Logged In: YES 
user_id=849994
Originator: NO

Attaching patch.
File Added: nokeywordchecks.diff

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 13:30

Message:
Logged In: YES 
user_id=80475
Originator: NO

I fixed setobject.c in revisions 53380 and 53381.

Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-10 19:49

Message:
Logged In: YES 
user_id=80475
Originator: NO

My proposed solution:

- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 16:30

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll do that, only in set_init, you have 
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))

Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name

Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 21:26

Message:
Logged In: YES 
user_id=80475
Originator: NO

I prefer the approach used by list().

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 20:19

Message:
Logged In: YES 
user_id=1326842

See patch #1491939

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 15:02

Message:
Logged In: YES 
user_id=1326842

This bug was introduced as part of the fix for bug #1119418.

It also affects collections.deque.

Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?

array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.

The rest of the types changed in that fix should not
be affected, since they are immutable.
 

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 12:23

Message:
Logged In: YES 
user_id=849994

Raymond, what to do in this case?

Note that other built-in types, such as list(), do accept
keyword arguments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Mon Feb 19 11:17:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Feb 2007 02:17:38 -0800
Subject: [ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if
	SC_OPEN_MAX is hi
Message-ID: <E1HJ5aU-0002Z6-MR@sc8-sf-web6.sourceforge.net>

Bugs item #1663329, was opened at 2007-02-19 11: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=1663329&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: H. von Bargen (hvbargen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi

Initial Comment:
If the value of sysconf("SC_OPEN_MAX") is high
and you try to start a subprocess with subprocess.py or os.popen2 with close_fds=True, then starting the other process is very slow.
This boils down to the following code in subprocess.py:
        def _close_fds(self, but):
            for i in xrange(3, MAXFD):
                if i == but:
                    continue
                try:
                    os.close(i)
                except:
                    pass

resp. the similar code in popen2.py:
    def _run_child(self, cmd):
        if isinstance(cmd, basestring):
            cmd = ['/bin/sh', '-c', cmd]
        for i in xrange(3, MAXFD):
            try:
                os.close(i)
            except OSError:
                pass

There has been an optimization already (range has been replaced by xrange to reduce memory impact), but I think the problem is that for high values of MAXFD, usually a high percentage of the os.close statements will fail, raising an exception (which is an "expensive" operation).
It has been suggested already to add a C implementation called "rclose" or "close_range" that tries to close all FDs in a given range (min, max) without the overhead of Python exception handling.

I'd like emphasize that this is not a theoretical, but a real world problem:
We have a Python application in a production environment on Sun Solaris. Some other software running on the same server needed a high value of 260000 for SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which one).
Suddenly calling any other process with subprocess.Popen (..., close_fds=True) now took 14 seconds (!) instead of some microseconds.
This caused a huge performance degradation, since the subprocess itself only needs only  a few seconds.

See also:
Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value".
This contains a fix, but only for AIX - and I think the patch does not support the "but" argument used in subprocess.py.
The correct solution should be coded in C, and should
do the same as the _close_fds routine in subprocess.py.
It could be optimized to make use of (operating-specific) system calls to close all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in the patch.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

From noreply at sourceforge.net  Mon Feb 19 12:42:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Feb 2007 03:42:58 -0800
Subject: [ python-Bugs-1663392 ] PyType_IsSubtype segfaults
Message-ID: <E1HJ6v4-0003FL-9F@sc8-sf-web2.sourceforge.net>

Bugs item #1663392, was opened at 2007-02-19 17: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=1663392&group_id=5470

Please note that this 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: navtej singh (nsbuttar)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyType_IsSubtype segfaults

Initial Comment:
It seems the issue is similar to bug#560215.  I was not able to reopen the last bug so I have opened a new one. I am using an external python extension which seems to be buggy. I am still investigating the actual cause of the bug in the said extension library.

PyType_IsSubType segfault reason is NULL pointer derefrence @ PyType_IsSubtype (a=0x0, b=0xb7f1ea00)
attaching the gdb bt as attachment.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470

From noreply at sourceforge.net  Mon Feb 19 12:46:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Feb 2007 03:46:17 -0800
Subject: [ python-Bugs-1663392 ] PyType_IsSubtype segfaults
Message-ID: <E1HJ6yH-0003dY-KR@sc8-sf-web2.sourceforge.net>

Bugs item #1663392, was opened at 2007-02-19 17:12
Message generated for change (Comment added) made by nsbuttar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470

Please note that this 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: navtej singh (nsbuttar)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyType_IsSubtype segfaults

Initial Comment:
It seems the issue is similar to bug#560215.  I was not able to reopen the last bug so I have opened a new one. I am using an external python extension which seems to be buggy. I am still investigating the actual cause of the bug in the said extension library.

PyType_IsSubType segfault reason is NULL pointer derefrence @ PyType_IsSubtype (a=0x0, b=0xb7f1ea00)
attaching the gdb bt as attachment.



----------------------------------------------------------------------

>Comment By: navtej singh (nsbuttar)
Date: 2007-02-19 17:16

Message:
Logged In: YES 
user_id=847825
Originator: YES

Additional Information

cat /etc/gentoo-release ; uname -r; python -V
Gentoo Base System release 1.12.9
2.6.19-suspend2-r2
Python 2.4.4


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470

From noreply at sourceforge.net  Mon Feb 19 13:21:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Feb 2007 04:21:09 -0800
Subject: [ python-Bugs-1663392 ] PyType_IsSubtype segfaults
Message-ID: <E1HJ7W1-0007Sv-BF@sc8-sf-web2.sourceforge.net>

Bugs item #1663392, was opened at 2007-02-19 11:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: navtej singh (nsbuttar)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyType_IsSubtype segfaults

Initial Comment:
It seems the issue is similar to bug#560215.  I was not able to reopen the last bug so I have opened a new one. I am using an external python extension which seems to be buggy. I am still investigating the actual cause of the bug in the said extension library.

PyType_IsSubType segfault reason is NULL pointer derefrence @ PyType_IsSubtype (a=0x0, b=0xb7f1ea00)
attaching the gdb bt as attachment.



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-19 12:21

Message:
Logged In: YES 
user_id=849994
Originator: NO

I don't think this is a bug in the core. Most Python API functions may not
be passed NULL pointers;
it is expected that the user of the function checks for that condition.

----------------------------------------------------------------------

Comment By: navtej singh (nsbuttar)
Date: 2007-02-19 11:46

Message:
Logged In: YES 
user_id=847825
Originator: YES

Additional Information

cat /etc/gentoo-release ; uname -r; python -V
Gentoo Base System release 1.12.9
2.6.19-suspend2-r2
Python 2.4.4


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470

From noreply at sourceforge.net  Tue Feb 20 11:36:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Feb 2007 02:36:05 -0800
Subject: [ python-Bugs-1633863 ] AIX: configure ignores $CC
Message-ID: <E1HJSLt-00063N-Ag@sc8-sf-web5.sourceforge.net>

Bugs item #1633863, was opened at 2007-01-12 09:46
Message generated for change (Comment added) made by smudd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johannes Abt (jabt)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX: configure ignores $CC

Initial Comment:
CC=xlc_r ./configure does not work on AIX-5.1, because configure unconditionally sets $CC to "cc_r":

	case $ac_sys_system in
	AIX*)   CC=cc_r
		without_gcc=;;


It would be better to leave $CC and just add "-qthreaded" to $CFLAGS. 

Furthermore, much of the C source code of Python uses C++ /C99 comments. This is an error with the standard AIX compiler. Please add the compiler flag "-qcpluscmt".

An alternative would be to use a default of "xlc_r" for CC on AIX. This calls the compiler in a mode that both accepts C++ comments and generates reentrant code.

Regards,
Johannes

----------------------------------------------------------------------

Comment By: Simon Mudd (smudd)
Date: 2007-02-20 11:36

Message:
Logged In: YES 
user_id=1724042
Originator: NO

This issue also prevents trying to build Python with gcc on AIX which I am
attempting at the moment.
While trying to resolve my own issue I have applied the following dirty
patch to the python-2.5 tar ball.
The patch should allow you to set CC to a non standard value.

# Patch to make Python work with AIX and OpenPKG.
#
# This patch is NOT complete.
# - configure is not automatically recreated from configure.in
# - The correct behaviour for AIX should be to use CC if set and
#   otherwise to look for cc_r, cc and gcc (not sure about the order).
#
Index: configure.in
--- configure.in.orig   2007-02-19 15:19:32.000000000 +0100
+++ configure.in        2007-02-19 15:21:35.000000000 +0100
@@ -346,8 +346,15 @@
                without_gcc=$withval;;
        esac], [
        case $ac_sys_system in
-       AIX*)   CC=cc_r
-               without_gcc=;;
+       AIX*)
+               # set CC if not set already.
+               # - SHOULD enhance check to look for cc or gcc in case it
+               #   is in the PATH.
+               if /usr/bin/test -z "$CC"; then
+                       CC=cc_r
+                       without_gcc=
+               fi
+               ;;
        BeOS*)
                case $BE_HOST_CPU in
                ppc)
Index: configure
*** configure.orig      Tue Feb 20 10:14:18 2007
--- configure           Tue Feb 20 10:15:23 2007
***************
*** 1719,1726 ****
  else

        case $ac_sys_system in
!       AIX*)   CC=cc_r
!               without_gcc=;;
        BeOS*)
                case $BE_HOST_CPU in
                ppc)
--- 1719,1733 ----
  else

        case $ac_sys_system in
!       AIX*)
!               # set CC if not set already.
!               # - SHOULD enhance check to look for cc or gcc in case it
!               #   is in the PATH.
!               if /usr/bin/test -z "$CC"; then
!                       CC=cc_r
!                       without_gcc=
!               fi
!               ;;
        BeOS*)
                case $BE_HOST_CPU in
                ppc)


----------------------------------------------------------------------

Comment By: Johannes Abt (jabt)
Date: 2007-01-30 14:07

Message:
Logged In: YES 
user_id=1563402
Originator: YES

Sorry about the C++ comments... all the C++ comments I have found concern
Windows, PC or Darwin. I must have confused this with another project
I have been compiling.

Though there still the issue with setting $CC.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-19 06:47

Message:
Logged In: YES 
user_id=33168
Originator: NO

There shouldn't be any C++ comments in the Python code.  If there are, it
is a mistake.  I did see some get removed recently.  Could you let me know
where you see the C++ comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 00:45:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Feb 2007 15:45:52 -0800
Subject: [ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if
	SC_OPEN_MAX is hi
Message-ID: <E1HJegC-0004tI-VD@sc8-sf-web1.sourceforge.net>

Bugs item #1663329, was opened at 2007-02-19 11:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: H. von Bargen (hvbargen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi

Initial Comment:
If the value of sysconf("SC_OPEN_MAX") is high
and you try to start a subprocess with subprocess.py or os.popen2 with close_fds=True, then starting the other process is very slow.
This boils down to the following code in subprocess.py:
        def _close_fds(self, but):
            for i in xrange(3, MAXFD):
                if i == but:
                    continue
                try:
                    os.close(i)
                except:
                    pass

resp. the similar code in popen2.py:
    def _run_child(self, cmd):
        if isinstance(cmd, basestring):
            cmd = ['/bin/sh', '-c', cmd]
        for i in xrange(3, MAXFD):
            try:
                os.close(i)
            except OSError:
                pass

There has been an optimization already (range has been replaced by xrange to reduce memory impact), but I think the problem is that for high values of MAXFD, usually a high percentage of the os.close statements will fail, raising an exception (which is an "expensive" operation).
It has been suggested already to add a C implementation called "rclose" or "close_range" that tries to close all FDs in a given range (min, max) without the overhead of Python exception handling.

I'd like emphasize that this is not a theoretical, but a real world problem:
We have a Python application in a production environment on Sun Solaris. Some other software running on the same server needed a high value of 260000 for SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which one).
Suddenly calling any other process with subprocess.Popen (..., close_fds=True) now took 14 seconds (!) instead of some microseconds.
This caused a huge performance degradation, since the subprocess itself only needs only  a few seconds.

See also:
Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value".
This contains a fix, but only for AIX - and I think the patch does not support the "but" argument used in subprocess.py.
The correct solution should be coded in C, and should
do the same as the _close_fds routine in subprocess.py.
It could be optimized to make use of (operating-specific) system calls to close all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in the patch.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-21 00:45

Message:
Logged In: YES 
user_id=21627
Originator: NO

Wouldn't it be simpler for you to just don't pass close_fds=True to popen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 04:20:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Feb 2007 19:20:10 -0800
Subject: [ python-Bugs-1653121 ] Double free/corruption?
Message-ID: <200702210320.l1L3KAuR011593@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1653121, was opened at 2007-02-06 01: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=1653121&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Jarek Zgoda (zgoda)
Assigned to: Nobody/Anonymous (nobody)
Summary: Double free/corruption?

Initial Comment:
Today I encountered a problem with system complaining on double free/corruption, but as I don't know C, I cann't say it's a problem with Python or with MySQLdb.
Attached is a stack trace that I saw in screen session termination window. I am unable to reproduce this error, I tried few times, but it does not happen.

If this is a MySQLdb (or even MySQL) problem, I'll report the bug as appriopriate, just let me know.

The system is pretty standard FC4. Below is as some system information, let me know if I should provide you anything more.

$ python
Python 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2

$ uname -a
Linux localhost 2.6.17-1.2139_FC4smp #1 SMP Fri Jun 23 21:12:13 EDT 2006 i686 i686 i386 GNU/Linux

$ yum list installed glibc
Installed Packages
glibc.i686                               2.3.6-3

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-02-20 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

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: Jarek Zgoda (zgoda)
Date: 2007-02-06 03:24

Message:
Logged In: YES 
user_id=92222
Originator: YES

Thank you, will try my luck with MySQLdb.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2007-02-06 02:31

Message:
Logged In: YES 
user_id=31435
Originator: NO

Since the top 6 or 7 stack entries are all in
/usr/lib/mysql/libmysqlclient_r.so.14, and shows it trying to using its
own free() function (my_no_flags_free()), it's almost certainly a problem
in the extension module (as opposed to in Python).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653121&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 09:31:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Feb 2007 00:31:52 -0800
Subject: [ python-Bugs-1664966 ] crash in exec statement if uncode filename
	cannot be decoded
Message-ID: <E1HJmtE-0003V8-Kx@sc8-sf-web2.sourceforge.net>

Bugs item #1664966, was opened at 2007-02-21 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=1664966&group_id=5470

Please note that this 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: Stefan Schukat (sschukat)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash in exec statement if uncode filename cannot be decoded

Initial Comment:
In case the exec statement gets an open file with a unicode object in f->f_fp the return value of PyString_AsString is not checked for an error and therefore a NULL pointer is given to PyRun_File which then leads to a crash.

in ceval.c:
line 4171 ff 

FILE *fp = PyFile_AsFile(prog);
char *name = PyString_AsString(PyFile_Name(prog));
PyCompilerFlags cf;
cf.cf_flags = 0;
if (PyEval_MergeCompilerFlags(&cf))
    v = PyRun_FileFlags(fp, name, Py_file_input, 
                        globals, locals, &cf);
else
    v = PyRun_File(fp, name, Py_file_input, globals,
				       locals);

Name is NULL after conversion.

Patch would be:

FILE *fp = PyFile_AsFile(prog);
char *name = PyString_AsString(PyFile_Name(prog));
if(name == NULL)
     return -1;
PyCompilerFlags cf;

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 14:24:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Feb 2007 05:24:34 -0800
Subject: [ python-Bugs-1665206 ] Hangup when using cgitb in a thread while
	still in import
Message-ID: <E1HJrSU-0001lG-D6@sc8-sf-web8.sourceforge.net>

Bugs item #1665206, was opened at 2007-02-21 14: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=1665206&group_id=5470

Please note that this 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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: hoffie (hoffie)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hangup when using cgitb in a thread while still in import

Initial Comment:
The problem is best described using example code (also see http://trac.saddi.com/flup/ticket/12#comment:3):

  * file foo.py: see attachment
  * file bar.py:
      import foo

Running foo.py directly produces the expected result (html output from cgitb), running bar.py outputs nothing as it seems to hang internally (only the thread which should print the html).
Moving all non-import into a function in foo.py and calling that function after the import in bar.py leads to the expected result, so it seems to be related to code which is executed while still in import and while using threads.
I don't think it is serious problem as it's only triggered in that unusual case.

I'm running python-2.4.4 on Gentoo Linux.
Linux tux 2.6.20-gentoo #2 PREEMPT Mon Feb 5 19:20:30 CET 2007 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665206&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 15:55:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Feb 2007 06:55:02 -0800
Subject: [ python-Feature Requests-1665292 ] Datetime enhancements
Message-ID: <E1HJss2-00058s-3e@sc8-sf-web1.sourceforge.net>

Feature Requests item #1665292, was opened at 2007-02-21 15:55
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=1665292&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datetime enhancements

Initial Comment:
I'm proposing some small enhancements to the datetime module:

Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method.

Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :]

The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch.

Thx

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 16:40:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Feb 2007 07:40:21 -0800
Subject: [ python-Bugs-1665333 ] Documentation missing for OptionGroup class
	in optparse 
Message-ID: <E1HJtZt-0004Ap-4E@sc8-sf-web4.sourceforge.net>

Bugs item #1665333, was opened at 2007-02-21 16: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=1665333&group_id=5470

Please note that this 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
Private: No
Submitted By: LunarYorn (lunar_yorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Documentation missing for OptionGroup class in optparse 

Initial Comment:
Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul.

In detail documentation of the following classes and methods in optparse is missing:

- OptionGroup
- OptionParser.add_option_group
- OptionParser.get_option_group

These classes and methods also lack docstrings.

I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 16:42:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Feb 2007 07:42:06 -0800
Subject: [ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if
	SC_OPEN_MAX is hi
Message-ID: <E1HJtba-0007SR-KN@sc8-sf-web9.sourceforge.net>

Bugs item #1663329, was opened at 2007-02-19 11:17
Message generated for change (Comment added) made by hvbargen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: H. von Bargen (hvbargen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi

Initial Comment:
If the value of sysconf("SC_OPEN_MAX") is high
and you try to start a subprocess with subprocess.py or os.popen2 with close_fds=True, then starting the other process is very slow.
This boils down to the following code in subprocess.py:
        def _close_fds(self, but):
            for i in xrange(3, MAXFD):
                if i == but:
                    continue
                try:
                    os.close(i)
                except:
                    pass

resp. the similar code in popen2.py:
    def _run_child(self, cmd):
        if isinstance(cmd, basestring):
            cmd = ['/bin/sh', '-c', cmd]
        for i in xrange(3, MAXFD):
            try:
                os.close(i)
            except OSError:
                pass

There has been an optimization already (range has been replaced by xrange to reduce memory impact), but I think the problem is that for high values of MAXFD, usually a high percentage of the os.close statements will fail, raising an exception (which is an "expensive" operation).
It has been suggested already to add a C implementation called "rclose" or "close_range" that tries to close all FDs in a given range (min, max) without the overhead of Python exception handling.

I'd like emphasize that this is not a theoretical, but a real world problem:
We have a Python application in a production environment on Sun Solaris. Some other software running on the same server needed a high value of 260000 for SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which one).
Suddenly calling any other process with subprocess.Popen (..., close_fds=True) now took 14 seconds (!) instead of some microseconds.
This caused a huge performance degradation, since the subprocess itself only needs only  a few seconds.

See also:
Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value".
This contains a fix, but only for AIX - and I think the patch does not support the "but" argument used in subprocess.py.
The correct solution should be coded in C, and should
do the same as the _close_fds routine in subprocess.py.
It could be optimized to make use of (operating-specific) system calls to close all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in the patch.


----------------------------------------------------------------------

>Comment By: H. von Bargen (hvbargen)
Date: 2007-02-21 16:42

Message:
Logged In: YES 
user_id=1008979
Originator: YES

No, I have to use close_fds=True, because I don't want to have the
subprocess to inherit each and every file descriptor.
This is for two reasons:
i) Security - why should the subproces be able to work with all the parent
processes' files?
ii) Sometimes, for whatever reason, the subprocess (Oracle Reports in this
case) seems to hang. And because it inherited all of the parent's log file
handles, the paraent can not close and remove its log files correctly. This
is the reason why I stumbled about close_fds at all. BTW on MS Windows, a
similar (but not equivalent) solution was to create the log files as
non-inheritable.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-21 00:45

Message:
Logged In: YES 
user_id=21627
Originator: NO

Wouldn't it be simpler for you to just don't pass close_fds=True to popen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 17:16:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Feb 2007 08:16:52 -0800
Subject: [ python-Feature Requests-1665292 ] Datetime enhancements
Message-ID: <E1HJu9E-0002Vf-6j@sc8-sf-web9.sourceforge.net>

Feature Requests item #1665292, was opened at 2007-02-21 15:55
Message generated for change (Comment added) made by tiran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datetime enhancements

Initial Comment:
I'm proposing some small enhancements to the datetime module:

Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method.

Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :]

The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch.

Thx

----------------------------------------------------------------------

>Comment By: Christian Heimes (tiran)
Date: 2007-02-21 17:16

Message:
Logged In: YES 
user_id=560817
Originator: YES

File Added: timedelta.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 19:18:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Feb 2007 10:18:21 -0800
Subject: [ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if
	SC_OPEN_MAX is hi
Message-ID: <E1HJw2n-0002Cv-F1@sc8-sf-web11.sourceforge.net>

Bugs item #1663329, was opened at 2007-02-19 11:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: H. von Bargen (hvbargen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi

Initial Comment:
If the value of sysconf("SC_OPEN_MAX") is high
and you try to start a subprocess with subprocess.py or os.popen2 with close_fds=True, then starting the other process is very slow.
This boils down to the following code in subprocess.py:
        def _close_fds(self, but):
            for i in xrange(3, MAXFD):
                if i == but:
                    continue
                try:
                    os.close(i)
                except:
                    pass

resp. the similar code in popen2.py:
    def _run_child(self, cmd):
        if isinstance(cmd, basestring):
            cmd = ['/bin/sh', '-c', cmd]
        for i in xrange(3, MAXFD):
            try:
                os.close(i)
            except OSError:
                pass

There has been an optimization already (range has been replaced by xrange to reduce memory impact), but I think the problem is that for high values of MAXFD, usually a high percentage of the os.close statements will fail, raising an exception (which is an "expensive" operation).
It has been suggested already to add a C implementation called "rclose" or "close_range" that tries to close all FDs in a given range (min, max) without the overhead of Python exception handling.

I'd like emphasize that this is not a theoretical, but a real world problem:
We have a Python application in a production environment on Sun Solaris. Some other software running on the same server needed a high value of 260000 for SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which one).
Suddenly calling any other process with subprocess.Popen (..., close_fds=True) now took 14 seconds (!) instead of some microseconds.
This caused a huge performance degradation, since the subprocess itself only needs only  a few seconds.

See also:
Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value".
This contains a fix, but only for AIX - and I think the patch does not support the "but" argument used in subprocess.py.
The correct solution should be coded in C, and should
do the same as the _close_fds routine in subprocess.py.
It could be optimized to make use of (operating-specific) system calls to close all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in the patch.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-21 19:18

Message:
Logged In: YES 
user_id=21627
Originator: NO

I understand you don't want the subprocess to inherit "incorrect" file
descriptors. However, there are other ways to prevent that from happening:
- you should close file descriptors as soon as you are done with the
files
- you should set the FD_CLOEXEC flag on all file descriptors you don't
want to be inherited, using fnctl(fd, F_SETFD, 1)

I understand that there are cases where neither these strategy is not
practical, but if you follow it, the performance will be much better, as
the closing of unused file descriptor is done in the exec(2) implementation
of the operating system.


----------------------------------------------------------------------

Comment By: H. von Bargen (hvbargen)
Date: 2007-02-21 16:42

Message:
Logged In: YES 
user_id=1008979
Originator: YES

No, I have to use close_fds=True, because I don't want to have the
subprocess to inherit each and every file descriptor.
This is for two reasons:
i) Security - why should the subproces be able to work with all the parent
processes' files?
ii) Sometimes, for whatever reason, the subprocess (Oracle Reports in this
case) seems to hang. And because it inherited all of the parent's log file
handles, the paraent can not close and remove its log files correctly. This
is the reason why I stumbled about close_fds at all. BTW on MS Windows, a
similar (but not equivalent) solution was to create the log files as
non-inheritable.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-21 00:45

Message:
Logged In: YES 
user_id=21627
Originator: NO

Wouldn't it be simpler for you to just don't pass close_fds=True to popen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

From noreply at sourceforge.net  Wed Feb 21 23:34:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Feb 2007 14:34:27 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HK02d-0007ql-2K@sc8-sf-web9.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: 3rd Party
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-21 22:34

Message:
Logged In: YES 
user_id=4882
Originator: YES

well I found the bug is in ./site-packages/_xmlplus/utils/iso8601.py

 gmt = __extract_date(m) + __extract_time(m) + (0, 0, 0) this is wrong 
My sugestion is:  
 gmt = __extract_date(m) + __extract_time(m)
 gmt = datetime(gmt).timetuple()

(0,0,0) zero for week of day, zero for day of the year and zero isdst is
the error here. 

timetuple calculate this last 3 numbers well. 
and my problem is gone !

references http://docs.python.org/lib/module-time.html: 
0  	tm_year  	(for example, 1993)
1 	tm_mon 	        range [1,12]
2 	tm_mday 	range [1,31]
3 	tm_hour 	range [0,23]
4 	tm_min 	        range [0,59]
5 	tm_sec 	        range [0,61]; see (1) in strftime() description
6 	tm_wday 	range [0,6], Monday is 0
7 	tm_yday 	range [1,366]
8 	tm_isdst 	0, 1 or -1; see below


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 15:54

Message:
Logged In: YES 
user_id=21627
Originator: NO

cvalente, thanks for the research. Making a second attempt at closing this
as third-party bug.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 14:25

Message:
Logged In: YES 
user_id=4882
Originator: YES

ok bug openned on 
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033

----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:47

Message:
Logged In: YES 
user_id=627298
Originator: NO

OK. This is almost surely NOT a Python bug but most likely a libc bug.

In c:
----------
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]){
        struct tm t1;
        struct tm t2;

        /* midnight 26/SET/1076*/
        t1.tm_sec  = 0;
        t1.tm_min  = 0;
        t1.tm_hour = 0;
        t1.tm_mday = 26;
        t1.tm_mon  = 8;
        t1.tm_year = 76;

        /* midnight 25/SET/1076*/
        t2.tm_sec  = 0;
        t2.tm_min  = 0;
        t2.tm_hour = 0;
        t2.tm_mday = 25;
        t2.tm_mon  = 8;
        t2.tm_year = 76;

        printf("%li\n", mktime(&t1)-mktime(&t2));
        printf("%li\n", mktime(&t1)-mktime(&t2));

        return 0;
}
------
Outputs:

90000
86400


In perl:
-----
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-----

Outputs

90000
86400

-----

My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon

When I changed this to another timezone (Say London) the problem didn't
exist.

Thank you all for your time.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22

Message:
Logged In: YES 
user_id=4882
Originator: YES

timezone :  WET in winter WEST in summer 
I try same with timezone of NEW YORK and 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0


----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07

Message:
Logged In: YES 
user_id=627298
Originator: NO

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.

More info later on.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 09:51:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 00:51:06 -0800
Subject: [ python-Bugs-1662581 ] the re module can perform poorly: O(2**n)
	versus O(n**2)
Message-ID: <E1HK9fO-0003VP-OZ@sc8-sf-web1.sourceforge.net>

Bugs item #1662581, was opened at 2007-02-17 15:39
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662581&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: None
Status: Open
Resolution: None
Priority: 4
Private: No
Submitted By: Gregory P. Smith (greg)
Assigned to: Nobody/Anonymous (nobody)
Summary: the re module can perform poorly: O(2**n) versus O(n**2)

Initial Comment:
in short, the re module can degenerate to really really horrid performance.  See this for how and why:

 http://swtch.com/~rsc/regexp/regexp1.html

exponential decline instead of squared.

I don't have a patch so i'm filing this bug as a starting point for future work.  The Modules/_sre.c files implementation could be updated to use the parallel stepping Thompson approach instead of recursive backtracking.

filing this as a bug until me or someone else comes up with a patch.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-02-22 00:51

Message:
Logged In: YES 
user_id=341410
Originator: NO

I would file this under "feature request"; the current situation isn't so
much buggy, as slow.  While you can produce a segfault with the current
regular expression engine (due to stack overflow), you can do the same
thing with regular Python on Linux (with sys.setrecursionlimit), ctypes,
etc., and none of those are considered as buggy.

My only concern with such a change is that it may or may not change the
semantics of the repeat operators '*' and '+', which are currently defined
as "greedy".  If I skimmed the article correctly late at night, switching
to a Thompson family regular expression engine may result in those
operators no longer being greedy.  Please correct me if I am wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662581&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 11:44:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 02:44:25 -0800
Subject: [ python-Bugs-1661745 ] finditer stuck in infinite loop
Message-ID: <E1HKBR3-0007RU-DC@sc8-sf-web3.sourceforge.net>

Bugs item #1661745, was opened at 2007-02-16 12:11
Message generated for change (Comment added) made by rhamphoryncus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661745&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Milan (migues)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: finditer stuck in infinite loop

Initial Comment:
Using iterator on Match Object results in infinite unbreakable loop. Attached is sample script and sample file.

My OS: Win XP Pro.



----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-02-22 03:44

Message:
Logged In: YES 
user_id=12364
Originator: NO

I've rewritten the test case.  It's not an infinite loop but rather
exponential runtime based on the length of the string.  Matching on a
string of 'x.x.', increasing the length of the left x or right x by one
doubles the runtime.  Increasing both quadruples it.

 0:         0.0000350475
 1:         0.0000259876
 2:         0.0000669956
 3:         0.0002369881
 4:         0.0009140968
 5:         0.0038359165
 6:         0.0148119926
 7:         0.0732769966
 8:         0.2570281029
 9:         0.9819128513
10:         3.9152498245
11:        16.4304330349
12:        64.8596510887
13:       264.2261950970

I'm not a re guru though, so I don't know if this is a real bug or just
one of those special cases re is prone to.

Now I just need to find out how to attach my file, SF doesn't want to let
me..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661745&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 11:45:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 02:45:35 -0800
Subject: [ python-Bugs-1661745 ] finditer stuck in infinite loop
Message-ID: <E1HKBSB-0007wf-PR@sc8-sf-web11.sourceforge.net>

Bugs item #1661745, was opened at 2007-02-16 12:11
Message generated for change (Comment added) made by rhamphoryncus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661745&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Milan (migues)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: finditer stuck in infinite loop

Initial Comment:
Using iterator on Match Object results in infinite unbreakable loop. Attached is sample script and sample file.

My OS: Win XP Pro.



----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-02-22 03:45

Message:
Logged In: YES 
user_id=12364
Originator: NO

Nope, won't let me attach a file.  Pasted instead:

#!/usr/bin/env python
import re
from timeit import Timer

reexpr = re.compile(r"(.+\n?)+?((\.\n)|(\n\n))")

def test(count):
    text = '%s.%s.' % ('x' * count, 'x' * count)
    for m in reexpr.finditer(text):
        pass

for count in range(21):
    print '%2i: %20.10f' % (count,
        Timer('test(%i)' % count, "from __main__ import
test").timeit(number=1))


----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-02-22 03:44

Message:
Logged In: YES 
user_id=12364
Originator: NO

I've rewritten the test case.  It's not an infinite loop but rather
exponential runtime based on the length of the string.  Matching on a
string of 'x.x.', increasing the length of the left x or right x by one
doubles the runtime.  Increasing both quadruples it.

 0:         0.0000350475
 1:         0.0000259876
 2:         0.0000669956
 3:         0.0002369881
 4:         0.0009140968
 5:         0.0038359165
 6:         0.0148119926
 7:         0.0732769966
 8:         0.2570281029
 9:         0.9819128513
10:         3.9152498245
11:        16.4304330349
12:        64.8596510887
13:       264.2261950970

I'm not a re guru though, so I don't know if this is a real bug or just
one of those special cases re is prone to.

Now I just need to find out how to attach my file, SF doesn't want to let
me..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661745&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 12:59:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 03:59:01 -0800
Subject: [ python-Bugs-1661745 ] finditer stuck in infinite loop
Message-ID: <E1HKCbF-0000Ul-LW@sc8-sf-web7.sourceforge.net>

Bugs item #1661745, was opened at 2007-02-16 19:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661745&group_id=5470

Please note that this 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.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Milan (migues)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: finditer stuck in infinite loop

Initial Comment:
Using iterator on Match Object results in infinite unbreakable loop. Attached is sample script and sample file.

My OS: Win XP Pro.



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-22 11:59

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'd say this is a duplicate of #1662581.

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-02-22 10:45

Message:
Logged In: YES 
user_id=12364
Originator: NO

Nope, won't let me attach a file.  Pasted instead:

#!/usr/bin/env python
import re
from timeit import Timer

reexpr = re.compile(r"(.+\n?)+?((\.\n)|(\n\n))")

def test(count):
    text = '%s.%s.' % ('x' * count, 'x' * count)
    for m in reexpr.finditer(text):
        pass

for count in range(21):
    print '%2i: %20.10f' % (count,
        Timer('test(%i)' % count, "from __main__ import
test").timeit(number=1))


----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-02-22 10:44

Message:
Logged In: YES 
user_id=12364
Originator: NO

I've rewritten the test case.  It's not an infinite loop but rather
exponential runtime based on the length of the string.  Matching on a
string of 'x.x.', increasing the length of the left x or right x by one
doubles the runtime.  Increasing both quadruples it.

 0:         0.0000350475
 1:         0.0000259876
 2:         0.0000669956
 3:         0.0002369881
 4:         0.0009140968
 5:         0.0038359165
 6:         0.0148119926
 7:         0.0732769966
 8:         0.2570281029
 9:         0.9819128513
10:         3.9152498245
11:        16.4304330349
12:        64.8596510887
13:       264.2261950970

I'm not a re guru though, so I don't know if this is a real bug or just
one of those special cases re is prone to.

Now I just need to find out how to attach my file, SF doesn't want to let
me..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661745&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 13:00:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 04:00:30 -0800
Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in
	Python 2.5
Message-ID: <E1HKCcg-0000gh-D4@sc8-sf-web7.sourceforge.net>

Bugs item #1659171, was opened at 2007-02-13 17:27
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

Please note that this 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: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.5

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-14 21:24

Message:
Logged In: YES 
user_id=21627
Originator: NO

I fail to see the bug. The exception precisely describes the error in your
code

ImportError: dynamic module does not define init function (inittestlib)

Why do you expect any meaningful behavior in the presence of this error?
Your shared library isn't an extension module.

If you think it is related to #1548092, please try out the subversion
trunk, which has fixed this bug.

----------------------------------------------------------------------

Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-14 08:52

Message:
Logged In: YES 
user_id=1718463
Originator: YES

I suspect that this is a duplicate of Bug [1548092].
Note that, there it is asserted that tparm returns NULL on certain invalid
strings.
That does not seem to be true. It returns NULL for valid trivial strings,
too.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 13:25:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 04:25:09 -0800
Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in
	Python 2.5
Message-ID: <E1HKD0X-0006M9-0X@sc8-sf-web9.sourceforge.net>

Bugs item #1659171, was opened at 2007-02-13 18:27
Message generated for change (Comment added) made by richyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

Please note that this 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: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.5

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

>Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-22 13:25

Message:
Logged In: YES 
user_id=1718463
Originator: YES

The error message about the undefined init function is a red herring. The
example is actually a stripped-down testcase from a much larger
Boost.Python module, which of course does have an init function. The point
here is the NULL pointer returned by tparm.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-14 22:24

Message:
Logged In: YES 
user_id=21627
Originator: NO

I fail to see the bug. The exception precisely describes the error in your
code

ImportError: dynamic module does not define init function (inittestlib)

Why do you expect any meaningful behavior in the presence of this error?
Your shared library isn't an extension module.

If you think it is related to #1548092, please try out the subversion
trunk, which has fixed this bug.

----------------------------------------------------------------------

Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-14 09:52

Message:
Logged In: YES 
user_id=1718463
Originator: YES

I suspect that this is a duplicate of Bug [1548092].
Note that, there it is asserted that tparm returns NULL on certain invalid
strings.
That does not seem to be true. It returns NULL for valid trivial strings,
too.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 17:13:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 08:13:28 -0800
Subject: [ python-Bugs-1656559 ] I think,
	I have found this bug on time.mktime()
Message-ID: <E1HKGZU-0003xY-PP@sc8-sf-web9.sourceforge.net>

Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

Please note that this 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: 3rd Party
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: S?rgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()

Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
S?rgio M. B. 



----------------------------------------------------------------------

>Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-22 16:13

Message:
Logged In: YES 
user_id=4882
Originator: YES

please forget my last comment, it is all wrong 

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-21 22:34

Message:
Logged In: YES 
user_id=4882
Originator: YES

well I found the bug is in ./site-packages/_xmlplus/utils/iso8601.py

 gmt = __extract_date(m) + __extract_time(m) + (0, 0, 0) this is wrong 
My sugestion is:  
 gmt = __extract_date(m) + __extract_time(m)
 gmt = datetime(gmt).timetuple()

(0,0,0) zero for week of day, zero for day of the year and zero isdst is
the error here. 

timetuple calculate this last 3 numbers well. 
and my problem is gone !

references http://docs.python.org/lib/module-time.html: 
0  	tm_year  	(for example, 1993)
1 	tm_mon 	        range [1,12]
2 	tm_mday 	range [1,31]
3 	tm_hour 	range [0,23]
4 	tm_min 	        range [0,59]
5 	tm_sec 	        range [0,61]; see (1) in strftime() description
6 	tm_wday 	range [0,6], Monday is 0
7 	tm_yday 	range [1,366]
8 	tm_isdst 	0, 1 or -1; see below


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 15:54

Message:
Logged In: YES 
user_id=21627
Originator: NO

cvalente, thanks for the research. Making a second attempt at closing this
as third-party bug.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 14:25

Message:
Logged In: YES 
user_id=4882
Originator: YES

ok bug openned on 
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033

----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:47

Message:
Logged In: YES 
user_id=627298
Originator: NO

OK. This is almost surely NOT a Python bug but most likely a libc bug.

In c:
----------
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]){
        struct tm t1;
        struct tm t2;

        /* midnight 26/SET/1076*/
        t1.tm_sec  = 0;
        t1.tm_min  = 0;
        t1.tm_hour = 0;
        t1.tm_mday = 26;
        t1.tm_mon  = 8;
        t1.tm_year = 76;

        /* midnight 25/SET/1076*/
        t2.tm_sec  = 0;
        t2.tm_min  = 0;
        t2.tm_hour = 0;
        t2.tm_mday = 25;
        t2.tm_mon  = 8;
        t2.tm_year = 76;

        printf("%li\n", mktime(&t1)-mktime(&t2));
        printf("%li\n", mktime(&t1)-mktime(&t2));

        return 0;
}
------
Outputs:

90000
86400


In perl:
-----
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-----

Outputs

90000
86400

-----

My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon

When I changed this to another timezone (Say London) the problem didn't
exist.

Thank you all for your time.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22

Message:
Logged In: YES 
user_id=4882
Originator: YES

timezone :  WET in winter WEST in summer 
I try same with timezone of NEW YORK and 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0


----------------------------------------------------------------------

Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07

Message:
Logged In: YES 
user_id=627298
Originator: NO

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.

More info later on.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Also, don't change the priority of bugs.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 12:04

Message:
Logged In: YES 
user_id=21627
Originator: NO

Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.

Also please respond to the question what timezone you are in.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28

Message:
Logged In: YES 
user_id=4882
Originator: YES

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0


----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:19

Message:
Logged In: YES 
user_id=4882
Originator: YES

on my FC6 same 
first time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:18

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:06

Message:
Logged In: YES 
user_id=4882
Originator: YES

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 05:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

Looks like an FC6 bug to me (either in their C library, or in their Python
port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this
to Redhat; I'm closing this as "works for me". If you stil think there is a
bug in Python, please point to the exact source that you think is
erroneous, and the change that should be made.

----------------------------------------------------------------------

Comment By: S?rgio Monteiro Basto (sergiomb)
Date: 2007-02-12 22:37

Message:
Logged In: YES 
user_id=4882
Originator: YES

python-2.4.4-1.fc6
>>> import time
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-12 12:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

I can't reproduce this problem. On my system (OSX), I get

>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-10 15:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European
Union.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 17:22:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 08:22:09 -0800
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1HKGht-0006dR-RF@sc8-sf-web1.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 15:58
Message generated for change (Comment added) made by bwooster47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

Please note that this 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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 16:22

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.

>From Python docs at http://docs.python.org/lib/module-time.html  :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."

Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+0000 for EST.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 21:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 16:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 17:26:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 08:26:37 -0800
Subject: [ python-Bugs-1666318 ] shutil.copytree doesn't preserve directory
	permissions
Message-ID: <E1HKGmD-0001yF-5S@sc8-sf-web7.sourceforge.net>

Bugs item #1666318, was opened at 2007-02-22 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=1666318&group_id=5470

Please note that this 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: Jeff McNeil (j_mcneil)
Assigned to: Nobody/Anonymous (nobody)
Summary: shutil.copytree doesn't preserve directory permissions

Initial Comment:
I am using shutil.copytree to setup new user home directories within an automated system.  The copy2 function is called in order to copy individual files and preserve stat data. 

However, copytree simply calls os.mkdir and leaves directory creation at the mercy of my current umask (in my case, that's daemon context - 0).

I've got to then iterate through the newly copied tree and set permissions on each individual subdirectory. 

Adding a simple copystat(src, dst) on line 112 of shutil.py fixes the problem. 

The result should be uniform; either preserve permissions across the board, or leave it to the mercy of the caller.  I know there's an enhancement request already open to supply a 'func=' kw argument to copytree.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666318&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 17:28:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 08:28:17 -0800
Subject: [ python-Bugs-1666318 ] shutil.copytree doesn't preserve directory
	permissions
Message-ID: <E1HKGnp-0007IM-MP@sc8-sf-web1.sourceforge.net>

Bugs item #1666318, was opened at 2007-02-22 11:26
Message generated for change (Comment added) made by j_mcneil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666318&group_id=5470

Please note that this 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: Jeff McNeil (j_mcneil)
Assigned to: Nobody/Anonymous (nobody)
Summary: shutil.copytree doesn't preserve directory permissions

Initial Comment:
I am using shutil.copytree to setup new user home directories within an automated system.  The copy2 function is called in order to copy individual files and preserve stat data. 

However, copytree simply calls os.mkdir and leaves directory creation at the mercy of my current umask (in my case, that's daemon context - 0).

I've got to then iterate through the newly copied tree and set permissions on each individual subdirectory. 

Adding a simple copystat(src, dst) on line 112 of shutil.py fixes the problem. 

The result should be uniform; either preserve permissions across the board, or leave it to the mercy of the caller.  I know there's an enhancement request already open to supply a 'func=' kw argument to copytree.



----------------------------------------------------------------------

>Comment By: Jeff McNeil (j_mcneil)
Date: 2007-02-22 11:28

Message:
Logged In: YES 
user_id=1726175
Originator: YES

python -V
Python 2.4.3

on 

Linux marvin 2.6.18-1.2257.fc5smp #1 SMP Fri Dec 15 16:33:51 EST 2006 i686
i686 i386 GNU/Linux


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666318&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 21:16:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 12:16:25 -0800
Subject: [ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if
	SC_OPEN_MAX is hi
Message-ID: <E1HKKMb-00035x-4U@sc8-sf-web9.sourceforge.net>

Bugs item #1663329, was opened at 2007-02-19 11:17
Message generated for change (Comment added) made by hvbargen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: H. von Bargen (hvbargen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi

Initial Comment:
If the value of sysconf("SC_OPEN_MAX") is high
and you try to start a subprocess with subprocess.py or os.popen2 with close_fds=True, then starting the other process is very slow.
This boils down to the following code in subprocess.py:
        def _close_fds(self, but):
            for i in xrange(3, MAXFD):
                if i == but:
                    continue
                try:
                    os.close(i)
                except:
                    pass

resp. the similar code in popen2.py:
    def _run_child(self, cmd):
        if isinstance(cmd, basestring):
            cmd = ['/bin/sh', '-c', cmd]
        for i in xrange(3, MAXFD):
            try:
                os.close(i)
            except OSError:
                pass

There has been an optimization already (range has been replaced by xrange to reduce memory impact), but I think the problem is that for high values of MAXFD, usually a high percentage of the os.close statements will fail, raising an exception (which is an "expensive" operation).
It has been suggested already to add a C implementation called "rclose" or "close_range" that tries to close all FDs in a given range (min, max) without the overhead of Python exception handling.

I'd like emphasize that this is not a theoretical, but a real world problem:
We have a Python application in a production environment on Sun Solaris. Some other software running on the same server needed a high value of 260000 for SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which one).
Suddenly calling any other process with subprocess.Popen (..., close_fds=True) now took 14 seconds (!) instead of some microseconds.
This caused a huge performance degradation, since the subprocess itself only needs only  a few seconds.

See also:
Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value".
This contains a fix, but only for AIX - and I think the patch does not support the "but" argument used in subprocess.py.
The correct solution should be coded in C, and should
do the same as the _close_fds routine in subprocess.py.
It could be optimized to make use of (operating-specific) system calls to close all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in the patch.


----------------------------------------------------------------------

>Comment By: H. von Bargen (hvbargen)
Date: 2007-02-22 21:16

Message:
Logged In: YES 
user_id=1008979
Originator: YES

Of course I am already closing any files as soon as possible.

I know that I could use FD_CLOEXEC. But this would require that I do it
explicitly for each descriptor that I use in my program. But this would be
a tedious work and require platform-specific coding all around the program.
And the whole bunch of python library functions (i.e. the logging module)
do not use FD_CLOEXEC as well.
Right now, more or less the only platform specific code in the program is
where I call subprocesses, and I like to keep it that way.
The same is true for the socket module. All sockets are by default
inherited to child processes.
So, the only way to prevent unwanted handles from inheriting to child
processes, is in fact to specify close_fds=True in subprocess.py.
If you think that a performance patch similar to the patch #16078087 makes
no sense, then the close_fds argument should either be marked as deprecated
or at least the documentation should mention that the implementation is
slow for large values of SC_OPEN_MAX.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-21 19:18

Message:
Logged In: YES 
user_id=21627
Originator: NO

I understand you don't want the subprocess to inherit "incorrect" file
descriptors. However, there are other ways to prevent that from happening:
- you should close file descriptors as soon as you are done with the
files
- you should set the FD_CLOEXEC flag on all file descriptors you don't
want to be inherited, using fnctl(fd, F_SETFD, 1)

I understand that there are cases where neither these strategy is not
practical, but if you follow it, the performance will be much better, as
the closing of unused file descriptor is done in the exec(2) implementation
of the operating system.


----------------------------------------------------------------------

Comment By: H. von Bargen (hvbargen)
Date: 2007-02-21 16:42

Message:
Logged In: YES 
user_id=1008979
Originator: YES

No, I have to use close_fds=True, because I don't want to have the
subprocess to inherit each and every file descriptor.
This is for two reasons:
i) Security - why should the subproces be able to work with all the parent
processes' files?
ii) Sometimes, for whatever reason, the subprocess (Oracle Reports in this
case) seems to hang. And because it inherited all of the parent's log file
handles, the paraent can not close and remove its log files correctly. This
is the reason why I stumbled about close_fds at all. BTW on MS Windows, a
similar (but not equivalent) solution was to create the log files as
non-inheritable.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-21 00:45

Message:
Logged In: YES 
user_id=21627
Originator: NO

Wouldn't it be simpler for you to just don't pass close_fds=True to popen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470

From noreply at sourceforge.net  Thu Feb 22 23:30:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 14:30:49 -0800
Subject: [ python-Bugs-1662581 ] the re module can perform poorly: O(2**n)
	versus O(n**2)
Message-ID: <E1HKMSf-0008GA-JZ@sc8-sf-web11.sourceforge.net>

Bugs item #1662581, was opened at 2007-02-17 15:39
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662581&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
>Group: Feature Request
Status: Open
Resolution: None
>Priority: 3
Private: No
Submitted By: Gregory P. Smith (greg)
Assigned to: Nobody/Anonymous (nobody)
Summary: the re module can perform poorly: O(2**n) versus O(n**2)

Initial Comment:
in short, the re module can degenerate to really really horrid performance.  See this for how and why:

 http://swtch.com/~rsc/regexp/regexp1.html

exponential decline instead of squared.

I don't have a patch so i'm filing this bug as a starting point for future work.  The Modules/_sre.c files implementation could be updated to use the parallel stepping Thompson approach instead of recursive backtracking.

filing this as a bug until me or someone else comes up with a patch.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2007-02-22 14:30

Message:
Logged In: YES 
user_id=413
Originator: YES

yeah this is better as a feature request.  certianly low priority either
way.

-nothing- I propose doing would change the syntax or behaviour of existing
regular expressions at all.  Doing so would be a disaster.  thompson nfa
does not imply changing the behaviour.

anyways its a lot more than a simple "patch" to change the re module to
not use backtracking so i expect this to languish unless someone has a of
free time and motivation all at once. :)


----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-02-22 00:51

Message:
Logged In: YES 
user_id=341410
Originator: NO

I would file this under "feature request"; the current situation isn't so
much buggy, as slow.  While you can produce a segfault with the current
regular expression engine (due to stack overflow), you can do the same
thing with regular Python on Linux (with sys.setrecursionlimit), ctypes,
etc., and none of those are considered as buggy.

My only concern with such a change is that it may or may not change the
semantics of the repeat operators '*' and '+', which are currently defined
as "greedy".  If I skimmed the article correctly late at night, switching
to a Thompson family regular expression engine may result in those
operators no longer being greedy.  Please correct me if I am wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662581&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 08:08:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Feb 2007 23:08:51 -0800
Subject: [ python-Bugs-1666807 ] Incorrect file path reported by
	inspect.getabsfile()
Message-ID: <E1HKUXz-0002BC-Ax@sc8-sf-web8.sourceforge.net>

Bugs item #1666807, was opened at 2007-02-23 07: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=1666807&group_id=5470

Please note that this 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: Fernando P?rez (fer_perez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect file path reported by inspect.getabsfile()

Initial Comment:
The following code demonstrates the problem succinctly:

###
import inspect,sys

print 'Version info:',sys.version_info
print

f1 = inspect.getabsfile(inspect)
f2 = inspect.getabsfile(inspect.iscode)
print 'File for `inspect`       :',f1
print 'File for `inspect.iscode`:',f2
print 'Do these match?',f1==f2
if f1==f2:
    print 'OK'
else:
    print 'BUG - this is a bug in this version of Python'

###  EOF

Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py
Version info: (2, 3, 6, 'final', 0)

File for `inspect`       : /home/fperez/tmp/local/lib/python2.3/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py
Do these match? True
OK
tlon[bin]> python2.4 ~/code/python/inspect_bug.py
Version info: (2, 4, 4, 'candidate', 1)

File for `inspect`       : /usr/lib/python2.4/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python
tlon[bin]> python2.5 ~/code/python/inspect_bug.py
Version info: (2, 5, 0, 'final', 0)

File for `inspect`       : /usr/lib/python2.5/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python


###

The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path.  This changed between 2.3 and 2.4, but the inspect module was never updated.  This code:

###
import inspect,sys

print 'Python version info:',sys.version_info
print 'File info for `inspect.iscode function`:'
print ' ',inspect.iscode.func_code.co_filename
print
### EOF

shows the problem:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py
Python version info: (2, 3, 6, 'final', 0)
File info for `inspect.iscode function`:
  /home/fperez/tmp/local//lib/python2.3/inspect.py

tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py
Python version info: (2, 5, 0, 'final', 0)
File info for `inspect.iscode function`:
  inspect.py

###

(2.4 has the same issue).

Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 11:30:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 02:30:00 -0800
Subject: [ python-Bugs-1666952 ] terminalcommand doesn't work under Darwin
Message-ID: <E1HKXge-0007Vx-5V@sc8-sf-web7.sourceforge.net>

Bugs item #1666952, was opened at 2007-02-23 11:29
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=1666952&group_id=5470

Please note that this 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: Jurjen N.E. Bos (jneb)
Assigned to: Nobody/Anonymous (nobody)
Summary: terminalcommand doesn't work under Darwin

Initial Comment:
The "terminalcommand" library doesn't work under Darwin. It raises an obscure AppleScript error that I can't figure out.
I made a tiny library that gives roughly the same API, but starts applications fine under Darwin (10.2 and up). It works using the osascript command, but Jack can probably get it too work using OSA directly :-)
Quotes, spaces and backslashes are handled properly.
I would recommend to extend terminalcommand to incorporate this code in the Darwin case, assuming that you still want to support OS9.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 11:31:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 02:31:52 -0800
Subject: [ python-Bugs-1666952 ] terminalcommand doesn't work under Darwin
Message-ID: <E1HKXiS-0004cI-5u@sc8-sf-web9.sourceforge.net>

Bugs item #1666952, was opened at 2007-02-23 11:29
Message generated for change (Comment added) made by jneb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470

Please note that this 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: Jurjen N.E. Bos (jneb)
Assigned to: Nobody/Anonymous (nobody)
Summary: terminalcommand doesn't work under Darwin

Initial Comment:
The "terminalcommand" library doesn't work under Darwin. It raises an obscure AppleScript error that I can't figure out.
I made a tiny library that gives roughly the same API, but starts applications fine under Darwin (10.2 and up). It works using the osascript command, but Jack can probably get it too work using OSA directly :-)
Quotes, spaces and backslashes are handled properly.
I would recommend to extend terminalcommand to incorporate this code in the Darwin case, assuming that you still want to support OS9.


----------------------------------------------------------------------

>Comment By: Jurjen N.E. Bos (jneb)
Date: 2007-02-23 11:31

Message:
Logged In: YES 
user_id=446428
Originator: YES

O yes: forgot to mention:
The bug is for Mac only, any version of Python, OS X and up.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 15:25:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 06:25:48 -0800
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1HKbMq-0004h2-V5@sc8-sf-web2.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 08:58
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

Please note that this 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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 06:25

Message:
Logged In: YES 
user_id=357491
Originator: NO

It is not a Python issue.  strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.

You can write a patch if you want to cause it to blank out if it is not
supported and submit it.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 08:22

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.

>From Python docs at http://docs.python.org/lib/module-time.html  :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."

Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+0000 for EST.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 14:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 09:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 16:20:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 07:20:45 -0800
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1HKcE1-0004Ls-5h@sc8-sf-web4.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 15:58
Message generated for change (Comment added) made by bwooster47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

Please note that this 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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:20

Message:
Logged In: YES 
user_id=1209659
Originator: NO

But the C library does support it (and ones that don't will start - +nnnn
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).

The question is different - as the original post shows:

>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.

Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 14:25

Message:
Logged In: YES 
user_id=357491
Originator: NO

It is not a Python issue.  strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.

You can write a patch if you want to cause it to blank out if it is not
supported and submit it.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 16:22

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.

>From Python docs at http://docs.python.org/lib/module-time.html  :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."

Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+0000 for EST.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 21:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 16:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 16:36:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 07:36:28 -0800
Subject: [ python-Bugs-803610 ] os.close(3) raises OSError: [Errno 9] Bad file
	descriptor
Message-ID: <E1HKcTE-0003ni-0r@sc8-sf-web11.sourceforge.net>

Bugs item #803610, was opened at 2003-09-10 08:18
Message generated for change (Comment added) made by rhn_mk1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&group_id=5470

Please note that this 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.3
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on
FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 
Python 2.3 on Gentoo Linux 1.4 is not affected.

Interestingly, if you call os.fstat(3) first, a
subsequent call to os.close(3) succeeds.

And yes, you do need to set up fd #3.

Here is a demonstration (on FreeBSD):

[syrah at ripple filter]$ cat test.py
import os
os.close (3)

[syrah at ripple filter]$ python test.py 3&gt; file
Traceback (most recent call last):
  File &quot;test.py&quot;, line 2, in ?
    os.close (3)
OSError: [Errno 9] Bad file descriptor

[syrah at ripple filter]$ cat test2.py
import os
os.fstat (3)
os.close (3)

[syrah at ripple filter]$ python test2.py 3&gt; file

[syrah at ripple filter]$   (success!)


----------------------------------------------------------------------

Comment By: rhn (rhn_mk1)
Date: 2007-02-23 16:36

Message:
Logged In: YES 
user_id=1727118
Originator: NO

I have a similar problem on Ubuntu 6.06 and Python 2.5:

>>> import os, struct, fcntl
>>> lpt = open('/dev/lp0', 'rw')
>>> fcntl.lockf(lpt, fcntl.LOCK_EX)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor


But calling os.fstat doesn't do much.

>>> lpt.fileno()
3
>>> os.fstat(3)
(8630, 8123L, 13L, 1, 0, 7, 0L, 1172241640, 1172241640, 1172241878)
>>> fcntl.lockf(lpt, fcntl.LOCK_EX)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor


It's definitely some Python error in this, because it 3 is not a valid
file descriptore, Python shouldn't use it with open() call.

The same happens whe I try os.open().

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-12 07:44

Message:
Logged In: YES 
user_id=21627

Ok, closing it.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-12 03:13

Message:
Logged In: YES 
user_id=827529

Well... I just got a FreeBSD 4.8 machine running.  (FreeBSD
5.1 is billed as experimental.)

The problem does NOT manifest on FreeBSD 4.8.  They are both
running Python 2.3.  (Although the 5.1 machine has
portrevision 1, whereas the 4.8 machine has portrevision 0.
 But they use the same sourcecode tarball.)

So... I'm willing to close out the bug report and assume
that the bug is in FreeBSD 5.1 somewhere.  If in the future
I determine otherwise, I'll reopen the bug then.

Let me know what you think.  Many thanks for all your help.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-12 02:55

Message:
Logged In: YES 
user_id=827529

I think fd6 is created in the pipe call.  But why is pipe
returning 4?  It should return 0 or -1, shouldn't it?

Do I need to recomiple python (so that debug info is added
to the executable) to attach the debugger to it?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-12 00:06

Message:
Logged In: YES 
user_id=21627

I think you are misinterpreting the ktrace output. fd 6 is
the source code file, test.py, which can be seen by looking
at the read result for fd 6. Unfortunately, there is no
corresponding open call opening the file... (there is a
second open call for test.py, when Python opens the file to
print the backtrace, but there should be an earlier call).

If this ktrace output can be trusted, it appears that Python
does not call os.open(3) at all, but immediately decides on
an error - which could happen if errno was somehow
overwritten. However, I doubt that ktrace output, since it
fails to report the first open of test.py, which I know must
be there.

I recommend to run this under a debugger, and break at
posix_open.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-11 18:50

Message:
Logged In: YES 
user_id=827529

Okay.  I think I have attached a tgz file with 3 programs, 3
binary ktraces, and the ktraces converted to text files.

In all cases, the programs were run as follows:

[bash]$ program 3&gt; file

Many thanks for your continued interest.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 08:01

Message:
Logged In: YES 
user_id=21627

Was that the complete ktrace? I'm missing the point where it
outputs &quot;Traceback (most recent call last):&quot;. If you have
stripped it down, can you please attach the entire thing
(please don't paste it)?

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-11 00:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be
directly calling the operating systems close function.  It
is very puzzling that there is an error.

I did include in my initial post a parent that sets up fd 3.
 I used bash.  I was able to test successfully with bash.  I
wrote a C program:

-------- test.c --------
#include &lt;stdio.h&gt;

int main () {
  int i = close (3);
  printf (&quot;close: %i\n&quot;, i); }
--------

Using bash, I tested test.py, test2.py, and test.c (gcc
test.c -o test).  test.c behaved properly.  When I set up fd
3 with bash, test.c printed &quot;close: 0&quot;.  When I did not set
up fd 3, test.c printed &quot;close: -1&quot;.

I therefore have bash working properly, C working properly
and test2.py working properly.  The only thing that is not
working properly is test.py.  To me, it seems that I have
isolated the problem.

However, this problem only manifests on FreeBSD.  test.py
runs fine on Gentoo Linux.  At present, those are the only
two OSes I have easy access to.

So... if you really want a test program that sets up fd3,
I'll write one - let me know.  Would you prefer me to write
it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is
most direct.  But bash seems sufficient: &quot;[bash]$ python
test.py 3&gt; file&quot; sets up file descriptor 3 so it writes into
a file named &quot;file&quot;.

To look at it from another angle... is it possible that
Python, during its startup and initialization stuff messes
with file descriptor 3?  Is it possible it does this in some
really non-standard way?  Perhaps it does it indirectly by
calling some OS function that, as a side effect on FreeBSD
touches fd 3?  Something is going on with file descriptions
0-4 _every_ time python runs.  [Based on the ktrace's below,
it looks like

[syrah at ripple]$ python
Python 2.3 (#1, Sep  9 2003, 22:47:18) 
[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or
&quot;license&quot; for more
information.
&gt;&gt;&gt; import os 
&gt;&gt;&gt; os.fstat (0)
(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,
1063206044, 1063206044)
&gt;&gt;&gt; os.fstat (1)
(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,
1063206046, 1063206046)
&gt;&gt;&gt; os.fstat (2)
(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,
1063206048, 1063206048)
&gt;&gt;&gt; os.fstat (3)
(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,
1063206027)
&gt;&gt;&gt; os.fstat (4)
(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,
1063206027)
&gt;&gt;&gt; os.fstat (5)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
OSError: [Errno 9] Bad file descriptor
&gt;&gt;&gt; 

Also, it is very strange that after calling os.fstat(3),
os.close(3) works.  This says to me that fd 3 is fine, but
Python thinks fd 3 is bogus, but
calling os.fstat (3) forces Python to check fd 3's real status.

I considered the possibility that os.fstat(x) will the next
os.close(x) to succeed, but that is not the case:

[bash]$ cat test3.py
import os
os.fstat (3)
os.close (3)
os.fstat (3)
os.close (3)

[bash]$ python test3.py 3&gt; file
(an the error is raised on the second os.fstat(3) call, just
as you would expect)

Okay, here is your ktrace:

26520 python   GIO   fd 6 read 23 bytes
       &quot;import os
        os.close (3)
       &quot;
 26520 python   RET   read 23/0x17
 26520 python   CALL  write(0x2,0x80e6708,0x4)
 26520 python   GIO   fd 2 wrote 4 bytes
       &quot;    &quot;
 26520 python   RET   write 4
 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)
 26520 python   GIO   fd 2 wrote 13 bytes
       &quot;os.close (3)
       &quot;
 26520 python   RET   write 13/0xd
 26520 python   CALL  fstat(0x6,0xbfbfe670)
 26520 python   RET   fstat 0
 26520 python   CALL  fcntl(0x6,0x3,0)
 26520 python   RET   fcntl 4
 26520 python   CALL  fcntl(0x6,0x4,0)
 26520 python   RET   fcntl 0
 26520 python   CALL  close(0x6)
 26520 python   RET   close 0
 26520 python   CALL  write(0x2,0x813a3b4,0x7)
 26520 python   GIO   fd 2 wrote 7 bytes
       &quot;OSError&quot;
 26520 python   RET   write 7
 26520 python   CALL  write(0x2,0x80dbe5f,0x2)
 26520 python   GIO   fd 2 wrote 2 bytes
       &quot;: &quot;
 26520 python   RET   write 2
 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)
 26520 python   GIO   fd 2 wrote 29 bytes
       &quot;[Errno 9] Bad file descriptor&quot;
 26520 python   RET   write 29/0x1d
 26520 python   CALL  write(0x2,0x80e4d42,0x1)
 26520 python   GIO   fd 2 wrote 1 byte
       &quot;
       &quot;

Note that when I call os.close (3), python calls close(0x6),
so it looks like python is &quot;mapping&quot; the file description
numbers.  There are many other close calls the ktrace, but
_none_ of them close (0x3).  This says to me that (possibly)
python is doing lots of fd manipulation, but fd 3 is already
open, so python never uses it.

Here is a ktrace of test2.py.  It's very interesting.  6 is
fstated, closed, then 3 is fstated, fnctled, and closed
successfully.

 26498 python   GIO   fd 6 read 36 bytes
       &quot;import os
        os.fstat (3)
        os.close (3)
       &quot;
 26498 python   RET   read 36/0x24
 26498 python   CALL  lseek(0x6,0,0,0,0x1)
 26498 python   RET   lseek 36/0x24
 26498 python   CALL  read(0x6,0x8203000,0x4000)
 26498 python   GIO   fd 6 read 0 bytes
       &quot;&quot;
 26498 python   RET   read 0
 26498 python   CALL  fstat(0x6,0xbfbff450)
 26498 python   RET   fstat 0
 26498 python   CALL  fcntl(0x6,0x3,0)
 26498 python   RET   fcntl 4
 26498 python   CALL  fcntl(0x6,0x4,0)
 26498 python   RET   fcntl 0
 26498 python   CALL  close(0x6)
 26498 python   RET   close 0
 26498 python   CALL  fcntl(0x3,0x3,0)
 26498 python   RET   fcntl 1
 26498 python   CALL  fcntl(0x3,0x4,0x5)
 26498 python   RET   fcntl 0
 26498 python   CALL  fstat(0x3,0xbfbff290)
 26498 python   RET   fstat 0
 26498 python   CALL  fstat(0x3,0xbfbff260)
 26498 python   RET   fstat 0
 26498 python   CALL  fcntl(0x3,0x3,0)
 26498 python   RET   fcntl 5
 26498 python   CALL  fcntl(0x3,0x4,0x1)
 26498 python   RET   fcntl 0
 26498 python   CALL  close(0x3)
 26498 python   RET   close 0
 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)
 26498 python   RET   sigaction 0
 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)
 26498 python   RET   setitimer 0
 26498 python   CALL  close(0x4)
 26498 python   RET   close 0
 26498 python   CALL  close(0x5)
 26498 python   RET   close 0
 26498 python   CALL  fcntl(0,0x3,0)
 26498 python   RET   fcntl 6
 26498 python   CALL  fcntl(0,0x4,0x2)
 26498 python   RET   fcntl 0
 26498 python   CALL  fcntl(0x1,0x3,0)
 26498 python   RET   fcntl 2
 26498 python   CALL  fcntl(0x1,0x4,0x2)
 26498 python   RET   fcntl 0
 26498 python   CALL  fcntl(0x2,0x3,0)
 26498 python   RET   fcntl 2
 26498 python   CALL  fcntl(0x2,0x4,0x2)
 26498 python   RET   fcntl 0
 26498 python   CALL  exit(0)

Does fd 3 have some special significance on FreeBSD?  Or on
other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.
 But I didn't know that 3 was anything special.  And 3 is
what courier uses to communicate with its filters.

Okay... I just searched through the whole ktrace of test.py.
 As far as I can tell, nothing touches fd 3 in the whole
ktrace.  fcntl takes 0x3 as the second argument many times,
but that is a command, not a file descriptor.

So... this means that with test.py, Python decides (based on
an fstat (0x6)?) that os.close(3) will fail without ever
calling close(3) to see what will happen.

This could be a bug in FreeBSD.  But then why did my C
program work as expected?  Or perhaps there is a library
inbetween Python and the OS, a library that my c program
does not use.

Any suggestions for further diagnosis?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 22:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),
and reports an error if and only if the operating system
reports an error. So there is absolutely zero possibility
that the operatin system lets close(2) succeeed, yet python
returns OSError(9). As a consequence, if python raises
OSError(9), it was the operating system that has returned an
error before.

If you doubt this statement, please use ktrace/strace to
diagnose this further.

Also, if you *know* that a parent process has set up fd 3,
your test case is irrelevant. Your test case is only
meaningful in a context where a parent process has set up fd
3, however, you have not reported the code of that parent
process. Providing a minimal test case would be appreciated.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-10 19:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.

Before courier forks the filter, courier sets up fd 3 to
communicate with the filter.  When the filter has finished
initialization and is ready for work, the filter is supposed
to close fd 3.  Courier detects the closure of fd 3 and
knows that the filter is ready to work.

In general, before a call to fork/exec, the parent process
can set up any number of file descriptors for the child to
inherit.  If you are writing such a child in C, it is easy
to use these &quot;extra&quot; file descriptors.  It would nice to be
able to write in Python instead.

Saying that &quot;3 *is* a bad file descriptor&quot; assumes that
every program will be run from the command line, and the the
command line will only set up fd's 0, 1 and 2.  This is not
the case.  In fact it is very easy to set up other file
descriptors on the command line using bash.  See my example
above.

Another example of using more than 0, 1 and 2.  The openssl
program can use arbitrary file descriptors (referenced by
number on the command line) to recieve passwords.  This
allows you to cleanly pass in multiple passwords in a
reasonably secure manner.  (Arguably more secure than
writing the passwords to a file, and definitely more secure
that specifying them on the command line.)

The problem manifest on FreeBSD.  3 is not always a bad fd
on FreeBSD.  I've got a C program that has no problem
closing fd 3 (when fd 3 is properly set up).

Moreover, as I pointed out above, if I call os.fstat (3)
first, then I can os.close (3) without problem.  If 3 was a
bad fd, the call to os.fstat (3) should generate an error. 
It does not.

Please let me know if you have further questions.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 18:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the
systems which report it to be a bad file descriptor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 16:38:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 07:38:28 -0800
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1HKcVA-0005cN-8d@sc8-sf-web7.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 15:58
Message generated for change (Comment added) made by bwooster47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

Please note that this 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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:38

Message:
Logged In: YES 
user_id=1209659
Originator: NO

To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":

As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:

1. In Modules/timemodule.c, the time_strftime function calls gettmarg.

2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).

3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.

4. Thus, the strftime system call fails to find or make use of time
zone information.

So it looks like no call to strftime with a supplied argument will
produce time zone information. 


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:20

Message:
Logged In: YES 
user_id=1209659
Originator: NO

But the C library does support it (and ones that don't will start - +nnnn
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).

The question is different - as the original post shows:

>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.

Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 14:25

Message:
Logged In: YES 
user_id=357491
Originator: NO

It is not a Python issue.  strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.

You can write a patch if you want to cause it to blank out if it is not
supported and submit it.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 16:22

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.

>From Python docs at http://docs.python.org/lib/module-time.html  :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."

Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+0000 for EST.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 21:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 16:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 17:57:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 08:57:22 -0800
Subject: [ python-Bugs-1666807 ] Incorrect file path reported by
	inspect.getabsfile()
Message-ID: <E1HKdjW-0007io-R5@sc8-sf-monitor2.sourceforge.net>

Bugs item #1666807, was opened at 2007-02-23 07:08
Message generated for change (Comment added) made by fer_perez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470

Please note that this 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: Fernando P?rez (fer_perez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect file path reported by inspect.getabsfile()

Initial Comment:
The following code demonstrates the problem succinctly:

###
import inspect,sys

print 'Version info:',sys.version_info
print

f1 = inspect.getabsfile(inspect)
f2 = inspect.getabsfile(inspect.iscode)
print 'File for `inspect`       :',f1
print 'File for `inspect.iscode`:',f2
print 'Do these match?',f1==f2
if f1==f2:
    print 'OK'
else:
    print 'BUG - this is a bug in this version of Python'

###  EOF

Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py
Version info: (2, 3, 6, 'final', 0)

File for `inspect`       : /home/fperez/tmp/local/lib/python2.3/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py
Do these match? True
OK
tlon[bin]> python2.4 ~/code/python/inspect_bug.py
Version info: (2, 4, 4, 'candidate', 1)

File for `inspect`       : /usr/lib/python2.4/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python
tlon[bin]> python2.5 ~/code/python/inspect_bug.py
Version info: (2, 5, 0, 'final', 0)

File for `inspect`       : /usr/lib/python2.5/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python


###

The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path.  This changed between 2.3 and 2.4, but the inspect module was never updated.  This code:

###
import inspect,sys

print 'Python version info:',sys.version_info
print 'File info for `inspect.iscode function`:'
print ' ',inspect.iscode.func_code.co_filename
print
### EOF

shows the problem:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py
Python version info: (2, 3, 6, 'final', 0)
File info for `inspect.iscode function`:
  /home/fperez/tmp/local//lib/python2.3/inspect.py

tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py
Python version info: (2, 5, 0, 'final', 0)
File info for `inspect.iscode function`:
  inspect.py

###

(2.4 has the same issue).

Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days.

----------------------------------------------------------------------

>Comment By: Fernando P?rez (fer_perez)
Date: 2007-02-23 16:57

Message:
Logged In: YES 
user_id=395388
Originator: YES

Note: a colleague just tested this under Python 2.4 for Mac OSX (intel),
and the problem didn't show up there:

import inspect
print 'File for `code`         :',inspect.getabsfile(code)
print 'File for `code.interact`:',inspect.getabsfile(code.interact)

Gives:

File for `code`         :
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py
File for `code.interact`:
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py

My original tests were done under Ubuntu Edgy Eft, using the
Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source
download at python.org.

HTH,

f

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 18:23:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 09:23:15 -0800
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1HKe8Z-0000Zg-9l@sc8-sf-web6.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 08:58
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

Please note that this 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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 09:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

OK, but that is an issue of how much information is stored in the time
tuple.  There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not.  That is just an inherit shortcoming of
the time tuple.  You can't fix that without adding a new field to the time
tuple itself.

I am personally not about to do that, but if someone wants to write a
patch it might be considered.  But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 07:38

Message:
Logged In: YES 
user_id=1209659
Originator: NO

To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":

As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:

1. In Modules/timemodule.c, the time_strftime function calls gettmarg.

2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).

3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.

4. Thus, the strftime system call fails to find or make use of time
zone information.

So it looks like no call to strftime with a supplied argument will
produce time zone information. 


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 07:20

Message:
Logged In: YES 
user_id=1209659
Originator: NO

But the C library does support it (and ones that don't will start - +nnnn
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).

The question is different - as the original post shows:

>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.

Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 06:25

Message:
Logged In: YES 
user_id=357491
Originator: NO

It is not a Python issue.  strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.

You can write a patch if you want to cause it to blank out if it is not
supported and submit it.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 08:22

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.

>From Python docs at http://docs.python.org/lib/module-time.html  :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."

Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+0000 for EST.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 14:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 09:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 19:33:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 10:33:17 -0800
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1HKfEL-0005Pg-HJ@sc8-sf-web9.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 15:58
Message generated for change (Comment added) made by bwooster47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

Please note that this 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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 18:33

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Thanks, I'll let this go. (datetime is even worse - it does not handle any
timezone data, and requires users to create their own timezone info).

So right now Python has no support for the functions that are readily
available to GNU C-lib users of time, that's that, and I won't argue about
it, will just assume Python cannot produce RFC 822 conformant dates with
standard libraries. (Perl, PHP, all work fine (but they are not Python)).

(C-lib strftime has no problems printing %z with the time-tuple - with
just dst info - because it is supposed to be the local time zone as set on
the computer. No data needed in the tuple.
>From the man page:
       %z     The  time-zone  as  hour  offset  from  GMT.   Required  to
emit
              RFC 822-conformant dates (using "%a, %d  %b  %Y  %H:%M:%S 
%z").
              (GNU)
)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 17:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

OK, but that is an issue of how much information is stored in the time
tuple.  There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not.  That is just an inherit shortcoming of
the time tuple.  You can't fix that without adding a new field to the time
tuple itself.

I am personally not about to do that, but if someone wants to write a
patch it might be considered.  But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:38

Message:
Logged In: YES 
user_id=1209659
Originator: NO

To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":

As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:

1. In Modules/timemodule.c, the time_strftime function calls gettmarg.

2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).

3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.

4. Thus, the strftime system call fails to find or make use of time
zone information.

So it looks like no call to strftime with a supplied argument will
produce time zone information. 


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:20

Message:
Logged In: YES 
user_id=1209659
Originator: NO

But the C library does support it (and ones that don't will start - +nnnn
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).

The question is different - as the original post shows:

>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.

Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 14:25

Message:
Logged In: YES 
user_id=357491
Originator: NO

It is not a Python issue.  strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.

You can write a patch if you want to cause it to blank out if it is not
supported and submit it.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 16:22

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.

>From Python docs at http://docs.python.org/lib/module-time.html  :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."

Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+0000 for EST.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 21:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 16:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Fri Feb 23 20:52:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 11:52:56 -0800
Subject: [ python-Bugs-803610 ] os.close(3) raises OSError: [Errno 9] Bad file
	descriptor
Message-ID: <E1HKgTQ-0006uB-5c@sc8-sf-web6.sourceforge.net>

Bugs item #803610, was opened at 2003-09-10 08:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&group_id=5470

Please note that this 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.3
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on
FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 
Python 2.3 on Gentoo Linux 1.4 is not affected.

Interestingly, if you call os.fstat(3) first, a
subsequent call to os.close(3) succeeds.

And yes, you do need to set up fd #3.

Here is a demonstration (on FreeBSD):

[syrah at ripple filter]$ cat test.py
import os
os.close (3)

[syrah at ripple filter]$ python test.py 3&gt; file
Traceback (most recent call last):
  File &quot;test.py&quot;, line 2, in ?
    os.close (3)
OSError: [Errno 9] Bad file descriptor

[syrah at ripple filter]$ cat test2.py
import os
os.fstat (3)
os.close (3)

[syrah at ripple filter]$ python test2.py 3&gt; file

[syrah at ripple filter]$   (success!)


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-23 20:52

Message:
Logged In: YES 
user_id=21627
Originator: NO

rhn_mk1: I doubt it is a similar problem (entirely different operating
system). If you want to report a bug in Python, please submit a new bug
report.

However, I fail to see the bug at all. You somehow seem to believe that 3
could not be a valid file descriptor, but I cannot understand why you think
so. File descriptors 0, 1, 2 are in use for stdin, stdout, stderr, and then
the next call to open() will give you a the next file descriptor.

Python doesn't use the 3 *with* open, in fact, the file descriptor is not
a parameter to open at all. It is a *result* *from* open, i.e. a value that
the operating system returns. Please read some Unix book to understand the
concept of file descriptors better.

----------------------------------------------------------------------

Comment By: rhn (rhn_mk1)
Date: 2007-02-23 16:36

Message:
Logged In: YES 
user_id=1727118
Originator: NO

I have a similar problem on Ubuntu 6.06 and Python 2.5:

>>> import os, struct, fcntl
>>> lpt = open('/dev/lp0', 'rw')
>>> fcntl.lockf(lpt, fcntl.LOCK_EX)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor


But calling os.fstat doesn't do much.

>>> lpt.fileno()
3
>>> os.fstat(3)
(8630, 8123L, 13L, 1, 0, 7, 0L, 1172241640, 1172241640, 1172241878)
>>> fcntl.lockf(lpt, fcntl.LOCK_EX)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor


It's definitely some Python error in this, because it 3 is not a valid
file descriptore, Python shouldn't use it with open() call.

The same happens whe I try os.open().

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-12 07:44

Message:
Logged In: YES 
user_id=21627

Ok, closing it.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-12 03:13

Message:
Logged In: YES 
user_id=827529

Well... I just got a FreeBSD 4.8 machine running.  (FreeBSD
5.1 is billed as experimental.)

The problem does NOT manifest on FreeBSD 4.8.  They are both
running Python 2.3.  (Although the 5.1 machine has
portrevision 1, whereas the 4.8 machine has portrevision 0.
 But they use the same sourcecode tarball.)

So... I'm willing to close out the bug report and assume
that the bug is in FreeBSD 5.1 somewhere.  If in the future
I determine otherwise, I'll reopen the bug then.

Let me know what you think.  Many thanks for all your help.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-12 02:55

Message:
Logged In: YES 
user_id=827529

I think fd6 is created in the pipe call.  But why is pipe
returning 4?  It should return 0 or -1, shouldn't it?

Do I need to recomiple python (so that debug info is added
to the executable) to attach the debugger to it?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-12 00:06

Message:
Logged In: YES 
user_id=21627

I think you are misinterpreting the ktrace output. fd 6 is
the source code file, test.py, which can be seen by looking
at the read result for fd 6. Unfortunately, there is no
corresponding open call opening the file... (there is a
second open call for test.py, when Python opens the file to
print the backtrace, but there should be an earlier call).

If this ktrace output can be trusted, it appears that Python
does not call os.open(3) at all, but immediately decides on
an error - which could happen if errno was somehow
overwritten. However, I doubt that ktrace output, since it
fails to report the first open of test.py, which I know must
be there.

I recommend to run this under a debugger, and break at
posix_open.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-11 18:50

Message:
Logged In: YES 
user_id=827529

Okay.  I think I have attached a tgz file with 3 programs, 3
binary ktraces, and the ktraces converted to text files.

In all cases, the programs were run as follows:

[bash]$ program 3&gt; file

Many thanks for your continued interest.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-11 08:01

Message:
Logged In: YES 
user_id=21627

Was that the complete ktrace? I'm missing the point where it
outputs &quot;Traceback (most recent call last):&quot;. If you have
stripped it down, can you please attach the entire thing
(please don't paste it)?

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-11 00:45

Message:
Logged In: YES 
user_id=827529

I agree that this is a very strange error.  Python should be
directly calling the operating systems close function.  It
is very puzzling that there is an error.

I did include in my initial post a parent that sets up fd 3.
 I used bash.  I was able to test successfully with bash.  I
wrote a C program:

-------- test.c --------
#include &lt;stdio.h&gt;

int main () {
  int i = close (3);
  printf (&quot;close: %i\n&quot;, i); }
--------

Using bash, I tested test.py, test2.py, and test.c (gcc
test.c -o test).  test.c behaved properly.  When I set up fd
3 with bash, test.c printed &quot;close: 0&quot;.  When I did not set
up fd 3, test.c printed &quot;close: -1&quot;.

I therefore have bash working properly, C working properly
and test2.py working properly.  The only thing that is not
working properly is test.py.  To me, it seems that I have
isolated the problem.

However, this problem only manifests on FreeBSD.  test.py
runs fine on Gentoo Linux.  At present, those are the only
two OSes I have easy access to.

So... if you really want a test program that sets up fd3,
I'll write one - let me know.  Would you prefer me to write
it in Python, C, PHP, Ruby, Perl?  I'd prefer C as it is
most direct.  But bash seems sufficient: &quot;[bash]$ python
test.py 3&gt; file&quot; sets up file descriptor 3 so it writes into
a file named &quot;file&quot;.

To look at it from another angle... is it possible that
Python, during its startup and initialization stuff messes
with file descriptor 3?  Is it possible it does this in some
really non-standard way?  Perhaps it does it indirectly by
calling some OS function that, as a side effect on FreeBSD
touches fd 3?  Something is going on with file descriptions
0-4 _every_ time python runs.  [Based on the ktrace's below,
it looks like

[syrah at ripple]$ python
Python 2.3 (#1, Sep  9 2003, 22:47:18) 
[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or
&quot;license&quot; for more
information.
&gt;&gt;&gt; import os 
&gt;&gt;&gt; os.fstat (0)
(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206044,
1063206044, 1063206044)
&gt;&gt;&gt; os.fstat (1)
(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206046,
1063206046, 1063206046)
&gt;&gt;&gt; os.fstat (2)
(8592, 113L, 67174144L, 1, 1001, 4, 0L, 1063206048,
1063206048, 1063206048)
&gt;&gt;&gt; os.fstat (3)
(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,
1063206027)
&gt;&gt;&gt; os.fstat (4)
(4096, 0L, 0L, 0, 1001, 1001, 0L, 1063206027, 1063206027,
1063206027)
&gt;&gt;&gt; os.fstat (5)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
OSError: [Errno 9] Bad file descriptor
&gt;&gt;&gt; 

Also, it is very strange that after calling os.fstat(3),
os.close(3) works.  This says to me that fd 3 is fine, but
Python thinks fd 3 is bogus, but
calling os.fstat (3) forces Python to check fd 3's real status.

I considered the possibility that os.fstat(x) will the next
os.close(x) to succeed, but that is not the case:

[bash]$ cat test3.py
import os
os.fstat (3)
os.close (3)
os.fstat (3)
os.close (3)

[bash]$ python test3.py 3&gt; file
(an the error is raised on the second os.fstat(3) call, just
as you would expect)

Okay, here is your ktrace:

26520 python   GIO   fd 6 read 23 bytes
       &quot;import os
        os.close (3)
       &quot;
 26520 python   RET   read 23/0x17
 26520 python   CALL  write(0x2,0x80e6708,0x4)
 26520 python   GIO   fd 2 wrote 4 bytes
       &quot;    &quot;
 26520 python   RET   write 4
 26520 python   CALL  write(0x2,0xbfbfeb70,0xd)
 26520 python   GIO   fd 2 wrote 13 bytes
       &quot;os.close (3)
       &quot;
 26520 python   RET   write 13/0xd
 26520 python   CALL  fstat(0x6,0xbfbfe670)
 26520 python   RET   fstat 0
 26520 python   CALL  fcntl(0x6,0x3,0)
 26520 python   RET   fcntl 4
 26520 python   CALL  fcntl(0x6,0x4,0)
 26520 python   RET   fcntl 0
 26520 python   CALL  close(0x6)
 26520 python   RET   close 0
 26520 python   CALL  write(0x2,0x813a3b4,0x7)
 26520 python   GIO   fd 2 wrote 7 bytes
       &quot;OSError&quot;
 26520 python   RET   write 7
 26520 python   CALL  write(0x2,0x80dbe5f,0x2)
 26520 python   GIO   fd 2 wrote 2 bytes
       &quot;: &quot;
 26520 python   RET   write 2
 26520 python   CALL  write(0x2,0x81c5dfc,0x1d)
 26520 python   GIO   fd 2 wrote 29 bytes
       &quot;[Errno 9] Bad file descriptor&quot;
 26520 python   RET   write 29/0x1d
 26520 python   CALL  write(0x2,0x80e4d42,0x1)
 26520 python   GIO   fd 2 wrote 1 byte
       &quot;
       &quot;

Note that when I call os.close (3), python calls close(0x6),
so it looks like python is &quot;mapping&quot; the file description
numbers.  There are many other close calls the ktrace, but
_none_ of them close (0x3).  This says to me that (possibly)
python is doing lots of fd manipulation, but fd 3 is already
open, so python never uses it.

Here is a ktrace of test2.py.  It's very interesting.  6 is
fstated, closed, then 3 is fstated, fnctled, and closed
successfully.

 26498 python   GIO   fd 6 read 36 bytes
       &quot;import os
        os.fstat (3)
        os.close (3)
       &quot;
 26498 python   RET   read 36/0x24
 26498 python   CALL  lseek(0x6,0,0,0,0x1)
 26498 python   RET   lseek 36/0x24
 26498 python   CALL  read(0x6,0x8203000,0x4000)
 26498 python   GIO   fd 6 read 0 bytes
       &quot;&quot;
 26498 python   RET   read 0
 26498 python   CALL  fstat(0x6,0xbfbff450)
 26498 python   RET   fstat 0
 26498 python   CALL  fcntl(0x6,0x3,0)
 26498 python   RET   fcntl 4
 26498 python   CALL  fcntl(0x6,0x4,0)
 26498 python   RET   fcntl 0
 26498 python   CALL  close(0x6)
 26498 python   RET   close 0
 26498 python   CALL  fcntl(0x3,0x3,0)
 26498 python   RET   fcntl 1
 26498 python   CALL  fcntl(0x3,0x4,0x5)
 26498 python   RET   fcntl 0
 26498 python   CALL  fstat(0x3,0xbfbff290)
 26498 python   RET   fstat 0
 26498 python   CALL  fstat(0x3,0xbfbff260)
 26498 python   RET   fstat 0
 26498 python   CALL  fcntl(0x3,0x3,0)
 26498 python   RET   fcntl 5
 26498 python   CALL  fcntl(0x3,0x4,0x1)
 26498 python   RET   fcntl 0
 26498 python   CALL  close(0x3)
 26498 python   RET   close 0
 26498 python   CALL  sigaction(0x2,0xbfbff4b0,0)
 26498 python   RET   sigaction 0
 26498 python   CALL  setitimer(0x2,0xbfbff5f0,0)
 26498 python   RET   setitimer 0
 26498 python   CALL  close(0x4)
 26498 python   RET   close 0
 26498 python   CALL  close(0x5)
 26498 python   RET   close 0
 26498 python   CALL  fcntl(0,0x3,0)
 26498 python   RET   fcntl 6
 26498 python   CALL  fcntl(0,0x4,0x2)
 26498 python   RET   fcntl 0
 26498 python   CALL  fcntl(0x1,0x3,0)
 26498 python   RET   fcntl 2
 26498 python   CALL  fcntl(0x1,0x4,0x2)
 26498 python   RET   fcntl 0
 26498 python   CALL  fcntl(0x2,0x3,0)
 26498 python   RET   fcntl 2
 26498 python   CALL  fcntl(0x2,0x4,0x2)
 26498 python   RET   fcntl 0
 26498 python   CALL  exit(0)

Does fd 3 have some special significance on FreeBSD?  Or on
other OSes?  I'm aware of 0, 1 and 2 being stdin, out, err.
 But I didn't know that 3 was anything special.  And 3 is
what courier uses to communicate with its filters.

Okay... I just searched through the whole ktrace of test.py.
 As far as I can tell, nothing touches fd 3 in the whole
ktrace.  fcntl takes 0x3 as the second argument many times,
but that is a command, not a file descriptor.

So... this means that with test.py, Python decides (based on
an fstat (0x6)?) that os.close(3) will fail without ever
calling close(3) to see what will happen.

This could be a bug in FreeBSD.  But then why did my C
program work as expected?  Or perhaps there is a library
inbetween Python and the OS, a library that my c program
does not use.

Any suggestions for further diagnosis?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 22:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),
and reports an error if and only if the operating system
reports an error. So there is absolutely zero possibility
that the operatin system lets close(2) succeeed, yet python
returns OSError(9). As a consequence, if python raises
OSError(9), it was the operating system that has returned an
error before.

If you doubt this statement, please use ktrace/strace to
diagnose this further.

Also, if you *know* that a parent process has set up fd 3,
your test case is irrelevant. Your test case is only
meaningful in a context where a parent process has set up fd
3, however, you have not reported the code of that parent
process. Providing a minimal test case would be appreciated.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-10 19:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.

Before courier forks the filter, courier sets up fd 3 to
communicate with the filter.  When the filter has finished
initialization and is ready for work, the filter is supposed
to close fd 3.  Courier detects the closure of fd 3 and
knows that the filter is ready to work.

In general, before a call to fork/exec, the parent process
can set up any number of file descriptors for the child to
inherit.  If you are writing such a child in C, it is easy
to use these &quot;extra&quot; file descriptors.  It would nice to be
able to write in Python instead.

Saying that &quot;3 *is* a bad file descriptor&quot; assumes that
every program will be run from the command line, and the the
command line will only set up fd's 0, 1 and 2.  This is not
the case.  In fact it is very easy to set up other file
descriptors on the command line using bash.  See my example
above.

Another example of using more than 0, 1 and 2.  The openssl
program can use arbitrary file descriptors (referenced by
number on the command line) to recieve passwords.  This
allows you to cleanly pass in multiple passwords in a
reasonably secure manner.  (Arguably more secure than
writing the passwords to a file, and definitely more secure
that specifying them on the command line.)

The problem manifest on FreeBSD.  3 is not always a bad fd
on FreeBSD.  I've got a C program that has no problem
closing fd 3 (when fd 3 is properly set up).

Moreover, as I pointed out above, if I call os.fstat (3)
first, then I can os.close (3) without problem.  If 3 was a
bad fd, the call to os.fstat (3) should generate an error. 
It does not.

Please let me know if you have further questions.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-10 18:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the
systems which report it to be a bad file descriptor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 00:13:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 15:13:44 -0800
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1HKjbk-00006N-JP@sc8-sf-web5.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 17:58
Message generated for change (Comment added) made by pboddie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

Please note that this 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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 00:13

Message:
Logged In: YES 
user_id=226443
Originator: NO

It's probably too late to change details of the time tuple (far too much
code now depends on it), but I have patches against 2.4.4 which provide an
additional function called localtime_tz, which itself returns a localtime
tuple containing the additional "GMT offset" field. With some modifications
to various internal functions, the "struct tm" data can be populated and
strftime can then produce the desired result.

With regard to datetime, it does support time zones, but there's a
relatively large of work required to get "aware" datetime objects. I noted
this situation in the referenced newsgroup message on this topic.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 19:33

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Thanks, I'll let this go. (datetime is even worse - it does not handle any
timezone data, and requires users to create their own timezone info).

So right now Python has no support for the functions that are readily
available to GNU C-lib users of time, that's that, and I won't argue about
it, will just assume Python cannot produce RFC 822 conformant dates with
standard libraries. (Perl, PHP, all work fine (but they are not Python)).

(C-lib strftime has no problems printing %z with the time-tuple - with
just dst info - because it is supposed to be the local time zone as set on
the computer. No data needed in the tuple.
>From the man page:
       %z     The  time-zone  as  hour  offset  from  GMT.   Required  to
emit
              RFC 822-conformant dates (using "%a, %d  %b  %Y  %H:%M:%S 
%z").
              (GNU)
)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 18:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

OK, but that is an issue of how much information is stored in the time
tuple.  There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not.  That is just an inherit shortcoming of
the time tuple.  You can't fix that without adding a new field to the time
tuple itself.

I am personally not about to do that, but if someone wants to write a
patch it might be considered.  But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 16:38

Message:
Logged In: YES 
user_id=1209659
Originator: NO

To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":

As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:

1. In Modules/timemodule.c, the time_strftime function calls gettmarg.

2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).

3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.

4. Thus, the strftime system call fails to find or make use of time
zone information.

So it looks like no call to strftime with a supplied argument will
produce time zone information. 


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 16:20

Message:
Logged In: YES 
user_id=1209659
Originator: NO

But the C library does support it (and ones that don't will start - +nnnn
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).

The question is different - as the original post shows:

>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.

Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 15:25

Message:
Logged In: YES 
user_id=357491
Originator: NO

It is not a Python issue.  strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.

You can write a patch if you want to cause it to blank out if it is not
supported and submit it.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 17:22

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.

>From Python docs at http://docs.python.org/lib/module-time.html  :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."

Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+0000 for EST.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 23:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 18:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 00:26:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 15:26:29 -0800
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1HKjo5-0005Rq-Pv@sc8-sf-monitor2.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 17:58
Message generated for change (Comment added) made by pboddie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

Please note that this 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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 00:26

Message:
Logged In: YES 
user_id=226443
Originator: NO

See patch #1667546 for a somewhat tested implementation of the changes
mentioned below.

----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 00:13

Message:
Logged In: YES 
user_id=226443
Originator: NO

It's probably too late to change details of the time tuple (far too much
code now depends on it), but I have patches against 2.4.4 which provide an
additional function called localtime_tz, which itself returns a localtime
tuple containing the additional "GMT offset" field. With some
modifications to various internal functions, the "struct tm" data can be
populated and strftime can then produce the desired result.

With regard to datetime, it does support time zones, but there's a
relatively large of work required to get "aware" datetime objects. I noted
this situation in the referenced newsgroup message on this topic.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 19:33

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Thanks, I'll let this go. (datetime is even worse - it does not handle any
timezone data, and requires users to create their own timezone info).

So right now Python has no support for the functions that are readily
available to GNU C-lib users of time, that's that, and I won't argue about
it, will just assume Python cannot produce RFC 822 conformant dates with
standard libraries. (Perl, PHP, all work fine (but they are not Python)).

(C-lib strftime has no problems printing %z with the time-tuple - with
just dst info - because it is supposed to be the local time zone as set on
the computer. No data needed in the tuple.
>From the man page:
       %z     The  time-zone  as  hour  offset  from  GMT.   Required  to
emit
              RFC 822-conformant dates (using "%a, %d  %b  %Y  %H:%M:%S 
%z").
              (GNU)
)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 18:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

OK, but that is an issue of how much information is stored in the time
tuple.  There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not.  That is just an inherit shortcoming of
the time tuple.  You can't fix that without adding a new field to the time
tuple itself.

I am personally not about to do that, but if someone wants to write a
patch it might be considered.  But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 16:38

Message:
Logged In: YES 
user_id=1209659
Originator: NO

To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":

As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:

1. In Modules/timemodule.c, the time_strftime function calls gettmarg.

2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).

3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.

4. Thus, the strftime system call fails to find or make use of time
zone information.

So it looks like no call to strftime with a supplied argument will
produce time zone information. 


----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 16:20

Message:
Logged In: YES 
user_id=1209659
Originator: NO

But the C library does support it (and ones that don't will start - +nnnn
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).

The question is different - as the original post shows:

>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.

Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 15:25

Message:
Logged In: YES 
user_id=357491
Originator: NO

It is not a Python issue.  strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.

You can write a patch if you want to cause it to blank out if it is not
supported and submit it.

----------------------------------------------------------------------

Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 17:22

Message:
Logged In: YES 
user_id=1209659
Originator: NO

Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.

>From Python docs at http://docs.python.org/lib/module-time.html  :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."

Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+0000 for EST.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 23:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 18:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 01:31:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 16:31:54 -0800
Subject: [ python-Bugs-1647654 ] No obvious and correct way to get the time
	zone offset
Message-ID: <E1HKkpO-0007rH-Ag@sc8-sf-web5.sourceforge.net>

Bugs item #1647654, was opened at 2007-01-30 06:48
Message generated for change (Comment added) made by pboddie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470

Please note that this 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: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: No obvious and correct way to get the time zone offset

Initial Comment:
It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp.  The existing constants included in the module are not sufficient to correctly determine this value.

As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit.

The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this:

    if time.localtime(t).tm_isdst and time.daylight:
        return -time.altzone
    else:
        return -time.timezone

This worked most of the time, but would occasionally give incorrect results.

On Linux, the local time system can handle different daylight saving rules for different spans of years.  For years where the rules change, these constants can provide incorrect data.  Furthermore, they may be incorrect for time stamps in the past.

I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007.

Having a function in the standard library to calculate this offset would solve the problem.  The implementation we ended up with for Bazaar was:

    offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t)
    return offset.days * 86400 + offset.seconds

Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field).

----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 01:31

Message:
Logged In: YES 
user_id=226443
Originator: NO

See patch #1667546 for a time module function returning extended time
tuples. The datetime-based solution you provide is quite a clever
workaround using "naive" datetime objects, but I'm inclined to think that
some more convenient way of getting "aware" datetime objects would be
nicer.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 01:33:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 16:33:49 -0800
Subject: [ python-Bugs-1560794 ] strftime('%z') behaving differently
	with/without time arg.
Message-ID: <E1HKkrF-0007ml-HD@sc8-sf-web9.sourceforge.net>

Bugs item #1560794, was opened at 2006-09-18 16:53
Message generated for change (Comment added) made by pboddie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560794&group_id=5470

Please note that this 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: Knut Aksel R?ysland (knutroy)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime('%z') behaving differently with/without time arg.

Initial Comment:
According to the documentation, time.strftime will use
time.localtime, when no time tuple is provided as
argument. So, I wonder if it is desired behavior that
%z returns different values in the following two cases:

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.
>>> import time
>>> time.strftime('%Y-%m-%dT%H:%M:%S%z')
'2006-09-18T16:12:05+0200'
>>> time.strftime('%Y-%m-%dT%H:%M:%S%z', time.localtime())
'2006-09-18T16:12:05+0000'

The first behavior is what I am looking for.

I realize that %z is not documented, so maybe it should
be rejected instead of giving surprising results, like
above.

This behavior is observed on different Linux systems
under different versions of Python, e.g. on Ubuntu
Dapper Drake running Python 2.4.3.


----------------------------------------------------------------------

Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 01:33

Message:
Logged In: YES 
user_id=226443
Originator: NO

See patch #1667546 and related bug #1493676 (with discussion).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560794&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 07:51:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 22:51:54 -0800
Subject: [ python-Bugs-1666807 ] Incorrect file path reported by
	inspect.getabsfile()
Message-ID: <E1HKql8-0007hU-PJ@sc8-sf-monitor2.sourceforge.net>

Bugs item #1666807, was opened at 2007-02-23 00:08
Message generated for change (Comment added) made by jseutter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470

Please note that this 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: Fernando P?rez (fer_perez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect file path reported by inspect.getabsfile()

Initial Comment:
The following code demonstrates the problem succinctly:

###
import inspect,sys

print 'Version info:',sys.version_info
print

f1 = inspect.getabsfile(inspect)
f2 = inspect.getabsfile(inspect.iscode)
print 'File for `inspect`       :',f1
print 'File for `inspect.iscode`:',f2
print 'Do these match?',f1==f2
if f1==f2:
    print 'OK'
else:
    print 'BUG - this is a bug in this version of Python'

###  EOF

Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py
Version info: (2, 3, 6, 'final', 0)

File for `inspect`       : /home/fperez/tmp/local/lib/python2.3/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py
Do these match? True
OK
tlon[bin]> python2.4 ~/code/python/inspect_bug.py
Version info: (2, 4, 4, 'candidate', 1)

File for `inspect`       : /usr/lib/python2.4/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python
tlon[bin]> python2.5 ~/code/python/inspect_bug.py
Version info: (2, 5, 0, 'final', 0)

File for `inspect`       : /usr/lib/python2.5/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python


###

The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path.  This changed between 2.3 and 2.4, but the inspect module was never updated.  This code:

###
import inspect,sys

print 'Python version info:',sys.version_info
print 'File info for `inspect.iscode function`:'
print ' ',inspect.iscode.func_code.co_filename
print
### EOF

shows the problem:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py
Python version info: (2, 3, 6, 'final', 0)
File info for `inspect.iscode function`:
  /home/fperez/tmp/local//lib/python2.3/inspect.py

tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py
Python version info: (2, 5, 0, 'final', 0)
File info for `inspect.iscode function`:
  inspect.py

###

(2.4 has the same issue).

Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days.

----------------------------------------------------------------------

Comment By: Jerry Seutter (jseutter)
Date: 2007-02-23 23:51

Message:
Logged In: YES 
user_id=1727609
Originator: NO

Hi,

On a custom-compiled Python 2.5 on Ubuntu Dapper, I get:
yello at outback:~/code/python $ python bug_1666807.py
Version info: (2, 5, 0, 'final', 0)

File for `inspect` : /usr/local/lib/python2.5/inspect.py
File for `inspect.iscode`: /usr/local/lib/python2.5/inspect.py
Do these match? True
OK


On a system python 2.4.3 on another Ubuntu Dapper system, I get:
yello at adelaide:~/code/python $ python bug_1666807.py
Version info: (2, 4, 3, 'final', 0)

File for `inspect` : /usr/lib/python2.4/inspect.py
File for `inspect.iscode`: /usr/lib/python2.4/inspect.py
Do these match? True
OK

However, I can recreate this issue on another system (CentOS4) with a
custom install where a symlink is involved.  I get: 
[prompt goes here python]$ python bug_1666807.py
Version info: (2, 2, 3, 'final', 0)

File for `inspect` : /xxx/yyyy/PythonHome/lib/python2.2/inspect.py
File for `inspect.iscode`: /xxx/yyyy/Python-2.2/lib/python2.2/inspect.py
Do these match? 0
BUG - this is a bug in this version of Python

Is a symlink involved on the system where you saw this behaviour?

----------------------------------------------------------------------

Comment By: Fernando P?rez (fer_perez)
Date: 2007-02-23 09:57

Message:
Logged In: YES 
user_id=395388
Originator: YES

Note: a colleague just tested this under Python 2.4 for Mac OSX (intel),
and the problem didn't show up there:

import inspect
print 'File for `code`         :',inspect.getabsfile(code)
print 'File for `code.interact`:',inspect.getabsfile(code.interact)

Gives:

File for `code`         :
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py
File for `code.interact`:
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py

My original tests were done under Ubuntu Edgy Eft, using the
Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source
download at python.org.

HTH,

f

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 08:22:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Feb 2007 23:22:19 -0800
Subject: [ python-Bugs-1666807 ] Incorrect file path reported by
	inspect.getabsfile()
Message-ID: <E1HKrEZ-0006xk-7e@sc8-sf-web8.sourceforge.net>

Bugs item #1666807, was opened at 2007-02-23 07:08
Message generated for change (Comment added) made by fer_perez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470

Please note that this 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: Fernando P?rez (fer_perez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect file path reported by inspect.getabsfile()

Initial Comment:
The following code demonstrates the problem succinctly:

###
import inspect,sys

print 'Version info:',sys.version_info
print

f1 = inspect.getabsfile(inspect)
f2 = inspect.getabsfile(inspect.iscode)
print 'File for `inspect`       :',f1
print 'File for `inspect.iscode`:',f2
print 'Do these match?',f1==f2
if f1==f2:
    print 'OK'
else:
    print 'BUG - this is a bug in this version of Python'

###  EOF

Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py
Version info: (2, 3, 6, 'final', 0)

File for `inspect`       : /home/fperez/tmp/local/lib/python2.3/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py
Do these match? True
OK
tlon[bin]> python2.4 ~/code/python/inspect_bug.py
Version info: (2, 4, 4, 'candidate', 1)

File for `inspect`       : /usr/lib/python2.4/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python
tlon[bin]> python2.5 ~/code/python/inspect_bug.py
Version info: (2, 5, 0, 'final', 0)

File for `inspect`       : /usr/lib/python2.5/inspect.py
File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python


###

The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path.  This changed between 2.3 and 2.4, but the inspect module was never updated.  This code:

###
import inspect,sys

print 'Python version info:',sys.version_info
print 'File info for `inspect.iscode function`:'
print ' ',inspect.iscode.func_code.co_filename
print
### EOF

shows the problem:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py
Python version info: (2, 3, 6, 'final', 0)
File info for `inspect.iscode function`:
  /home/fperez/tmp/local//lib/python2.3/inspect.py

tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py
Python version info: (2, 5, 0, 'final', 0)
File info for `inspect.iscode function`:
  inspect.py

###

(2.4 has the same issue).

Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days.

----------------------------------------------------------------------

>Comment By: Fernando P?rez (fer_perez)
Date: 2007-02-24 07:22

Message:
Logged In: YES 
user_id=395388
Originator: YES

No, in my case the original tests with 2.4 and 2.5 were done with the
Ubuntu-provided (Edgy) versions, unmodified from their apt-get install
state.  But your comments are interesting.  I just rebuilt 2.5 by hand
from source on the same system, and this is what I get:

tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py
Version info: (2, 5, 0, 'final', 0)

File for `inspect`       :
/home/fperez/tmp/local/lib/python2.5/inspect.py
File for `inspect.iscode`:
/home/fperez/tmp/local/lib/python2.5/inspect.py
Do these match? True
OK


tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py
Python version info: (2, 5, 0, 'final', 0)
File info for `inspect.iscode function`:
  /home/fperez/tmp/local//lib/python2.5/inspect.py

So basically it seems that there's a difference in the value of the
func_code.co_filename object attribute depending on how the build was
made.

At this point I'm not really sure if this should be considered a Python
bug or an Ubuntu one...  Perhaps the Python build process can be made more
robust, I simply don't know.

But the end-user behavior /is/ a bug, so it would be nice to know how to
fix it.


Thanks for your info!

----------------------------------------------------------------------

Comment By: Jerry Seutter (jseutter)
Date: 2007-02-24 06:51

Message:
Logged In: YES 
user_id=1727609
Originator: NO

Hi,

On a custom-compiled Python 2.5 on Ubuntu Dapper, I get:
yello at outback:~/code/python $ python bug_1666807.py
Version info: (2, 5, 0, 'final', 0)

File for `inspect` : /usr/local/lib/python2.5/inspect.py
File for `inspect.iscode`: /usr/local/lib/python2.5/inspect.py
Do these match? True
OK


On a system python 2.4.3 on another Ubuntu Dapper system, I get:
yello at adelaide:~/code/python $ python bug_1666807.py
Version info: (2, 4, 3, 'final', 0)

File for `inspect` : /usr/lib/python2.4/inspect.py
File for `inspect.iscode`: /usr/lib/python2.4/inspect.py
Do these match? True
OK

However, I can recreate this issue on another system (CentOS4) with a
custom install where a symlink is involved.  I get: 
[prompt goes here python]$ python bug_1666807.py
Version info: (2, 2, 3, 'final', 0)

File for `inspect` : /xxx/yyyy/PythonHome/lib/python2.2/inspect.py
File for `inspect.iscode`: /xxx/yyyy/Python-2.2/lib/python2.2/inspect.py
Do these match? 0
BUG - this is a bug in this version of Python

Is a symlink involved on the system where you saw this behaviour?

----------------------------------------------------------------------

Comment By: Fernando P?rez (fer_perez)
Date: 2007-02-23 16:57

Message:
Logged In: YES 
user_id=395388
Originator: YES

Note: a colleague just tested this under Python 2.4 for Mac OSX (intel),
and the problem didn't show up there:

import inspect
print 'File for `code`         :',inspect.getabsfile(code)
print 'File for `code.interact`:',inspect.getabsfile(code.interact)

Gives:

File for `code`         :
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py
File for `code.interact`:
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py

My original tests were done under Ubuntu Edgy Eft, using the
Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source
download at python.org.

HTH,

f

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 17:10:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 24 Feb 2007 08:10:43 -0800
Subject: [ python-Bugs-1667877 ] Install fails with no error
Message-ID: <E1HKzTv-0000By-3B@sc8-sf-web5.sourceforge.net>

Bugs item #1667877, was opened at 2007-02-24 10: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=1667877&group_id=5470

Please note that this 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
Private: No
Submitted By: larry (widgeteye)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install fails with no error

Initial Comment:
When I built python 2.5 for linux I did the normal: 
configure 
make 
make install 

Everything went fine til the "make install" part. It dies with no 
error. 
just says "install failed" after this: 

Compiling /usr/local/lib/python2.5/zipfile.py 

That part built fine but the next part failed. 
So what I did being the industrious fellow that I am I did: 

make -n install > out 

Took the out file and did: 

sh out 

That installed python without failure. 

Now if I do "make install" everything works fine. 

Weird eh?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 22:01:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 24 Feb 2007 13:01:20 -0800
Subject: [ python-Bugs-1668032 ] PyMem_Realloc docs don't specifiy out-of-mem
	behavior
Message-ID: <E1HL41A-0002UH-9b@sc8-sf-web3.sourceforge.net>

Bugs item #1668032, was opened at 2007-02-24 13: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=1668032&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Stutzbach (agthorr)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyMem_Realloc docs don't specifiy out-of-mem behavior

Initial Comment:
I suggest adding the following text to the documentation for PyMem_Realloc:

"If the request fails, PyMem_Realloc returns NULL and p remains a valid allocated pointer."

I dug into obmalloc.c to figure out the behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668032&group_id=5470

From noreply at sourceforge.net  Sat Feb 24 22:09:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 24 Feb 2007 13:09:20 -0800
Subject: [ python-Bugs-1668036 ] PyMem_Resize docs don't specify that it
	modifies an argument
Message-ID: <E1HL48u-0006nM-DA@sc8-sf-web1.sourceforge.net>

Bugs item #1668036, was opened at 2007-02-24 13:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668036&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Stutzbach (agthorr)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyMem_Resize docs don't specify that it modifies an argument

Initial Comment:
PyMem_Resize is defined as follows:

#define PyMem_Resize(p, type, n) \
	( (p) = (type *) PyMem_Realloc((p), (n) * sizeof(type)) )

The docs for PyMem_Resize don't specify that it modifies p.  I suggest adding the following sentence:

"On return, p will point to the new memory area, or NULL in the event of failure."


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668036&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 00:23:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 24 Feb 2007 15:23:29 -0800
Subject: [ python-Bugs-1591774 ] Urllib2.urlopen() raises OSError w/bad HTTP
	Location header
Message-ID: <E1HL6Ej-0003mX-9O@sc8-sf-web4.sourceforge.net>

Bugs item #1591774, was opened at 2006-11-06 20:08
Message generated for change (Comment added) made by jseutter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591774&group_id=5470

Please note that this 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
Private: No
Submitted By: nikitathespider (nikitathespider)
Assigned to: Nobody/Anonymous (nobody)
Summary: Urllib2.urlopen() raises OSError w/bad HTTP Location header

Initial Comment:
The documentation for urllib2.urlopen() says that it
"[r]aises URLError on errors". But if urllib2 requests
a resource from a (misconfigured) Web server and that
server returns 302 response with the Location header
set to "file:", urlopen raises "OSError: [Errno 2] No
such file or directory: ''". I have seen such a
misconfiguration in the wild; I've also created a URL
on my server that reproduces the problem in case the
real-world URL disappears or is fixed. Both URLs are in
the attachment with code to reproduce the problem.

I can recreate this under Python 2.3 - 2.5 under Mac OS
X, FreeBSD and Win2k.

I would be satisfied if the module simply followed the
documentation and actually returned URLError.


----------------------------------------------------------------------

Comment By: Jerry Seutter (jseutter)
Date: 2007-02-24 16:23

Message:
Logged In: YES 
user_id=1727609
Originator: NO

Fix submitted in patch 1668100 - urllib2.urlopen() raises OSError instead
of URLError

http://sourceforge.net/tracker/index.php?func=detail&aid=1668100&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591774&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 01:58:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 24 Feb 2007 16:58:42 -0800
Subject: [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http
Message-ID: <E1HL7is-0007Ma-Ns@sc8-sf-web11.sourceforge.net>

Bugs item #767111, was opened at 2003-07-07 12:52
Message generated for change (Comment added) made by varmaa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: AttributeError thrown by urllib.open_http

Initial Comment:
In 2.3b2, looks like an error condition isn't being picked up 
on line 300 or 301 of urllib.py.

The code that triggered this traceback was simply:
        url = urllib.urlopen(action, data)


Traceback (most recent call last):
  File &quot;autospamrep.py&quot;, line 170, in ?
    current_page = handle_spamcop_page(current_page)
  File &quot;autospamrep.py&quot;, line 140, in handle_spamcop_page
    url = urllib.urlopen(action, data)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py&quot;, line 78, in urlopen
    return opener.open(url, data)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py&quot;, line 183, in open
    return getattr(self, name)(url, data)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py&quot;, line 308, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers, 
data)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py&quot;, line 323, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py&quot;, line 551, in http_error_default
    return addinfourl(fp, headers, &quot;http:&quot; + url)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py&quot;, line 837, in __init__
    addbase.__init__(self, fp)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py&quot;, line 787, in __init__
    self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

----------------------------------------------------------------------

Comment By: Atul Varma (varmaa)
Date: 2007-02-25 00:58

Message:
Logged In: YES 
user_id=863202
Originator: NO

I have attempted to fix this bug in patch 1668132:

http://sourceforge.net/tracker/index.php?func=detail&aid=1668132&group_id=5470&atid=305470


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 22:11

Message:
Logged In: YES 
user_id=1188172

Further information can be found in #1163401 which has been
closed as a duplicate.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-01-07 12:39

Message:
Logged In: YES 
user_id=11375

No, not at this point in time.  Unassigning (or, if this bug
is on the radar for 2.3.5/2.4.1, I can find time to work on it).
-

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-01-07 12:39

Message:
Logged In: YES 
user_id=11375

No, not at this point in time.  Unassigning (or, if this bug
is on the radar for 2.3.5/2.4.1, I can find time to work on it).
-

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-07 01:37

Message:
Logged In: YES 
user_id=80475

Andrew, are you still working on this one?

----------------------------------------------------------------------

Comment By: Rob Probin (robzed)
Date: 2004-03-18 23:43

Message:
Logged In: YES 
user_id=1000470

The file pointer (fp) is None (inside urllib) from httplib. This appears
to 
be caused by a BadStatusLine exception in getreply() (line1016 httplib). 

This sets self.file to self._conn.sock.makefile('rb', 0) then does a 
self.close() which sets self.file to None. 

Being new to this peice of code, I'm not sure whether it's urllib assuming

the file isn't going to be closed, or the BadStatusLine exception clearing

the file. Certainly it looks like the error -1 is not being trapped by 
open_http() in urllib upon calling h.getreply() and assuming that the file

still exists even in an error condition?

It maybe a coincidence but it appears to occur more when a web browser 
on the same machine is refreshing. 

Regards
Rob


----------------------------------------------------------------------

Comment By: Rob Probin (robzed)
Date: 2004-03-17 22:24

Message:
Logged In: YES 
user_id=1000470

""" 
This comment is program to reproduce the problem. Sorry it's not an 
attachment - as a relative Sourceforge newbie I have no idea how to 
attach to an existing bug. More notes available via email if required - 
including all local variables for each function from post mortem.

As said before, seems to be fp = None. Although the exception is caused 
by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside

open_http()

This is repeatable, but you may have to run this more than once. 
(Apologies to noaa.gov).

*** PLEASE: Run only where absolutely necessary for reproduction of 
bug!!! ***

"""

""" Attribute Error test case  - Python 2.3 """

import urllib

url = "http://adds.aviationweather.noaa.gov/metars/index.php"

params = urllib.urlencode({ "station_ids" : "KJFK", 
				"hoursStr" : "most recent only", 
				"std_trans" : "standard", 
				"chk_metars" : "on",
				"submit":"Submit"})

print "test"

for i in range(1, 1000):
	x = urllib.urlopen(url, params)
	string = x.read()
	print i

"""
Local variables for middle level routine...

	classURLopener
	open_http(self, url, data=None)
		args	('User-agent', 'Python-urllib/1.15')
		auth	None
		data	
'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub
mit=Submit&chk_metars=on'
		errcode	-1
		errmsg	''
		fp	None
		h	<httplib.HTTP instance at 0x507df30>
		headers	None
		host	'adds.aviationweather.noaa.gov'
		httplib	<module 'httplib' from '/System/Library/Frameworks/
Python.framework/Versions/2.3/lib/python2.3/httplib.pyc'>
		realhost	'adds.aviationweather.noaa.gov'
		selector	'/metars/index.php'
		self	<urllib.FancyURLopener instance at 0x465f3c8>
		url	'//adds.aviationweather.noaa.gov/metars/index.php'
		user_passwd	None
"""


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-07-29 03:23

Message:
Logged In: YES 
user_id=12800

Please provide a self-contained, complete example that we
can use to reproduce this problem.  Without enough
information, I can't see us fixing this for Python 2.3, and
time for that is rapidly running out.

Lowering to priority 6.

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-07-17 04:34

Message:
Logged In: YES 
user_id=46639

I've finally managed to get another traceback with some more 
information, using an assert I inserted into urllib.py a while ago to 
catch .fp == None:

Traceback (most recent call last):
  File &quot;/Users/zen/bin/autospamrep.py&quot;, line 168, in ?
    current_page = urllib.urlopen(start_url).read()
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py&quot;, line 76, in urlopen
    return opener.open(url)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py&quot;, line 181, in open
    return getattr(self, name)(url)
  File &quot;/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py&quot;, line 305, in open_http
    assert fp is not None, 'errcode %r, errmsg %r, headers %r' % 
(errcode, errmsg, headers)
AssertionError: errcode -1, errmsg '', headers None


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-07-12 13:14

Message:
Logged In: YES 
user_id=261020

HTTPResponse.read returns '' if its .fp is None, but the 
backwards-compat HTTP class' .getfile() just returns self.file, 
which it previously grabbed from HTTPResponse in .getreply(). 
 
Wild guess: maybe HTTP.getreply should just do 
 
self.file = response 
 
rather than 
 
self.file = response.fp 
 
The object returned by HTTP.getfile() was documented as 
returning an object supporting .readline() and .readlines(), 
while HTTPResponse only supports .read(), so that's obviously 
not the whole solution. 
 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 05:50

Message:
Logged In: YES 
user_id=80475

What were the values of 'action' and 'data' when the call was 
made?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 02:03:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 24 Feb 2007 17:03:14 -0800
Subject: [ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension
	doesn't build
Message-ID: <E1HL7nG-0006Zi-Ra@sc8-sf-web9.sourceforge.net>

Bugs item #1668133, was opened at 2007-02-25 01: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=1668133&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: clemens fischer (inow)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build

Initial Comment:
'uname -rms'
FreeBSD 6.2-STABLE i386

'cc --version'
cc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

trying to build python-2.4.4 from ports/lang/python24, i get the
following messages, where earlier versions have been compiled and
installed w/o problems:

"./configure" stage:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for curses.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the preprocessor's result
configure: WARNING: ncurses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for ncurses.h... yes

the 'readline' extension builds fine, though:

building 'readline' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o
cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so

I also tried this command after noticing that freebsd needs some special
define for wchars:

$ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES'
===>  Building for python24-2.4.4
case $MAKEFLAGS in  *-s*)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;;  *)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;;  esac
running build
running build_ext
db.h: found (4, 3) in /usr/local/include/db43
db.h: found (4, 4) in /usr/local/include/db44
db lib: using (4, 4) db-4.4
INFO: Can't locate Tcl/Tk libs and/or headers
building 'nis' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat':
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type
cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o -L/usr/local/lib -o build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so
*** WARNING: renaming "nis" since importing it failed: build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so: Undefined symbol "yperr_string"
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/lang/python24/work/Python-2.4.4.
*** Error code 1


regards, clemens


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 02:49:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 24 Feb 2007 17:49:37 -0800
Subject: [ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension
	doesn't build
Message-ID: <E1HL8W9-0008Vn-Mo@sc8-sf-web6.sourceforge.net>

Bugs item #1668133, was opened at 2007-02-25 10:03
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: clemens fischer (inow)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build

Initial Comment:
'uname -rms'
FreeBSD 6.2-STABLE i386

'cc --version'
cc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

trying to build python-2.4.4 from ports/lang/python24, i get the
following messages, where earlier versions have been compiled and
installed w/o problems:

"./configure" stage:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for curses.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the preprocessor's result
configure: WARNING: ncurses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for ncurses.h... yes

the 'readline' extension builds fine, though:

building 'readline' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o
cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so

I also tried this command after noticing that freebsd needs some special
define for wchars:

$ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES'
===>  Building for python24-2.4.4
case $MAKEFLAGS in  *-s*)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;;  *)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;;  esac
running build
running build_ext
db.h: found (4, 3) in /usr/local/include/db43
db.h: found (4, 4) in /usr/local/include/db44
db lib: using (4, 4) db-4.4
INFO: Can't locate Tcl/Tk libs and/or headers
building 'nis' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat':
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type
cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o -L/usr/local/lib -o build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so
*** WARNING: renaming "nis" since importing it failed: build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so: Undefined symbol "yperr_string"
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/lang/python24/work/Python-2.4.4.
*** Error code 1


regards, clemens


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2007-02-25 10:49

Message:
Logged In: YES 
user_id=55188
Originator: NO

The ncurses problem is already known and proven as a problem of FreeBSD. 
And its ports have a workaround applied. (-D__wchar_t=wchar_t as you
used.)

The nis compilation error can be raised when your base system was built
with NO_NIS=yes option.  But build process shouldn't segfault even after
nis warning.

So, can you provide a backtrace of the core dumped for more investigation?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 12:10:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 03:10:54 -0800
Subject: [ python-Bugs-1668295 ] Strange unicode behaviour
Message-ID: <E1HLHHK-0004bk-0X@sc8-sf-web3.sourceforge.net>

Bugs item #1668295, was opened at 2007-02-25 12: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=1668295&group_id=5470

Please note that this 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: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour

Initial Comment:

I know that python is very funny WRT unicode processing, but this defies all my knowledge.

I use the es_ES.UTF-8 encoding on linux. The script:


python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line.

However, if I redirect it to less or to a file, like

python -c "print unicode('? %s' % '??','utf8') " >test
Traceback (most recent call last):
  File "<string>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128)


Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 12:17:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 03:17:35 -0800
Subject: [ python-Bugs-1668295 ] Strange unicode behaviour
Message-ID: <E1HLHNn-0008Rp-Go@sc8-sf-web9.sourceforge.net>

Bugs item #1668295, was opened at 2007-02-25 12:10
Message generated for change (Comment added) made by sgala
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

Please note that this 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: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour

Initial Comment:

I know that python is very funny WRT unicode processing, but this defies all my knowledge.

I use the es_ES.UTF-8 encoding on linux. The script:


python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line.

However, if I redirect it to less or to a file, like

python -c "print unicode('? %s' % '??','utf8') " >test
Traceback (most recent call last):
  File "<string>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128)


Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases?

----------------------------------------------------------------------

>Comment By: Santiago Gala (sgala)
Date: 2007-02-25 12:17

Message:
Logged In: YES 
user_id=178886
Originator: YES

Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn
trunk

Also, some people asks for repr of strings (I guess to reproduce if they
can't read the caracters). Those are printed in utf-8:

$python -c "print repr('? %s')"
'\xc3\xa1 %s'
$ python -c "print repr('?i')"
'\xc3\xa9i'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 16:26:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 07:26:31 -0800
Subject: [ python-Bugs-1664966 ] crash in exec statement if uncode filename
	cannot be decoded
Message-ID: <E1HLLGh-00042E-Ff@sc8-sf-web3.sourceforge.net>

Bugs item #1664966, was opened at 2007-02-21 08:31
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470

Please note that this 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: Stefan Schukat (sschukat)
>Assigned to: Jeremy Hylton (jhylton)
Summary: crash in exec statement if uncode filename cannot be decoded

Initial Comment:
In case the exec statement gets an open file with a unicode object in f->f_fp the return value of PyString_AsString is not checked for an error and therefore a NULL pointer is given to PyRun_File which then leads to a crash.

in ceval.c:
line 4171 ff 

FILE *fp = PyFile_AsFile(prog);
char *name = PyString_AsString(PyFile_Name(prog));
PyCompilerFlags cf;
cf.cf_flags = 0;
if (PyEval_MergeCompilerFlags(&cf))
    v = PyRun_FileFlags(fp, name, Py_file_input, 
                        globals, locals, &cf);
else
    v = PyRun_File(fp, name, Py_file_input, globals,
				       locals);

Name is NULL after conversion.

Patch would be:

FILE *fp = PyFile_AsFile(prog);
char *name = PyString_AsString(PyFile_Name(prog));
if(name == NULL)
     return -1;
PyCompilerFlags cf;

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 16:58:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 07:58:15 -0800
Subject: [ python-Bugs-1664966 ] crash in exec statement if uncode filename
	cannot be decoded
Message-ID: <E1HLLlP-0007iV-QN@sc8-sf-web5.sourceforge.net>

Bugs item #1664966, was opened at 2007-02-21 08:31
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470

Please note that this 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: Stefan Schukat (sschukat)
Assigned to: Jeremy Hylton (jhylton)
Summary: crash in exec statement if uncode filename cannot be decoded

Initial Comment:
In case the exec statement gets an open file with a unicode object in f->f_fp the return value of PyString_AsString is not checked for an error and therefore a NULL pointer is given to PyRun_File which then leads to a crash.

in ceval.c:
line 4171 ff 

FILE *fp = PyFile_AsFile(prog);
char *name = PyString_AsString(PyFile_Name(prog));
PyCompilerFlags cf;
cf.cf_flags = 0;
if (PyEval_MergeCompilerFlags(&cf))
    v = PyRun_FileFlags(fp, name, Py_file_input, 
                        globals, locals, &cf);
else
    v = PyRun_File(fp, name, Py_file_input, globals,
				       locals);

Name is NULL after conversion.

Patch would be:

FILE *fp = PyFile_AsFile(prog);
char *name = PyString_AsString(PyFile_Name(prog));
if(name == NULL)
     return -1;
PyCompilerFlags cf;

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 15:58

Message:
Logged In: YES 
user_id=31392
Originator: NO

Committed revision 53901.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1664966&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 17:22:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 08:22:34 -0800
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda bodies
	correctly
Message-ID: <E1HLM8w-0005j2-JW@sc8-sf-web7.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 16:48
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 16:22

Message:
Logged In: YES 
user_id=31392
Originator: NO

I guess I should get back to this bug report at least once a year.  I'm
trying to understand how Scheme handles eval.  If I look at R5RS or R6RS,
I see that the eval procedure takes an environment as an argument.  The
procedures that create environment all seem to create variants of the
top-level environment (an empty environment, the interactive environment,
etc.).  I don't see any way to create an environment that contains the
bindings visible in a particular region of code.  Am I missing something?


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2006-04-03 17:36

Message:
Logged In: YES 
user_id=432579

Lest my last comment be interpreted as overly arrogant,
please  be assured that it was not meant as anything other
than an explanation of why I reported this as a bug in the
first place. I do understand that Python works the way it
does; I just want it to be even better. :-)


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2006-04-03 17:12

Message:
Logged In: YES 
user_id=432579

>The source of the problem is that scoping decisions are made
>statically.

No, because other languages with lexical scope and
permitting evaluation at runtime have no problem whatsoever
with this. They just answer the question:

Q: In what environment is the eval() argument evaluated?

typically in one of three ways:

A1. In an empty environment with no bindings at all, or just
the language-defined standard bindings.
A2. In the (or a) top-level environment; local, lexically
bound variables where the eval() takes place are not visible
to the argument expression.
A3. In the same lexical environment as the eval() call itself.

Perl and Ruby both say A3. Scheme (R5RS) lets the user
specify A1 or A2. Common Lisp answers A2.

Observe that none of the answers depend on what the
expression looks like.

Now, let's be crystal clear about this: The rules of where x
is looked up in the expressions

1) x

and

2) lambda: x

should reasonably be the same - after all, this is
fundamentally how lexical scoping works. And Python does
indeed work this way, to everybody's satisfaction.

In case 2), the evaluation of x is delayed, but that is
irrelevant; the decision of what x means is taken at the
same time in both cases, and the decision will be the same.

Most people would expect Python to answer question Q above
with one of the answers A1-3, but it does not, and it does
not document what the answer is. The Python answer is rather:

A4. A mixed hybrid environment of some kind: The identifiers
representing variables that are to be evaluated immediately
are looked up in the lexical environment of the eval
expression; identifiers representing variables in
delayed-evaluation positions use the global environment.

This answer is not very satisfactory and I'm inclined to
consider a design bug; it is different from what everyone
else does and not very intuitive. However, I can accept that
it is hard to change now for compatibility reasons. But this
answer A4 should be documented.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 15:44

Message:
Logged In: YES 
user_id=31392

The source of the problem is that scoping decisions are made
statically.  If a variable is determined to be local at
compile time, it can't be access as a free variable in
dynamically compiled code.  The compiler has already
determined that the variable is *not* free in the containing
function.  If a variable is free in a nested function, the
compiler treats it differently than if it is merely local to
the function.

In the most recent cases considered,
def f(x): eval('x') -- works because x is a local variable in f.
def f(g): eval('lambda x: g(x)') -- does not work because
the compiler has determined that g is not used a free
variable in f.  It isn't possible to change that static
analysis at runtime using eval or exec.

I agree that the documentation could be clearer here.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 03:46

Message:
Logged In: YES 
user_id=593130

"   def f(x): eval('x') works as expected and
    def f(g): eval('lambda x: g(x)') does not. Why?"

For the same reason
  def f(g,s): return eval(s)
 f(lambda x: x, 'lambda x: g(x)')(1)
and
  def g(x): return lambda: eval('x')
do not 'work'.  eval is a builtin C function whose behavior 
depends on its arguments (including the somewhat magical 
defaulting to globals(), local()) and not on its lexical position.

" Both are evaluated at the same time and use
the same environment to look up their variables."

No, the lambda in your second example introduces a new local 
namespace that is different from the one passed in.

" The fact that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping"

The delay and change of scoping are correlated. Evaluation is 
delayed because g is inside a lambda function def which 
introduces a new local scope which does not contain g, even 
though the original one did. 


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 02:55

Message:
Logged In: YES 
user_id=593130

After more carefully reading the eval doc in Lib Ref 2.1, I agree 
that it needs improvement.  My suggestions (assuming that my 
experiment-based inferences are correct):

In 
"The expression argument is parsed and evaluated as a Python 
expression (technically speaking, a condition list) using the 
globals and locals dictionaries as global and local name space."
insert "in a new top-level environment" before 'using'. This says 
right-off, even if indirectly, that lexical scoping does not work 
across the eval call.

In
"If the locals dictionary is omitted it defaults to the globals 
dictionary."
insert "only" after "If'.  If both are omitted, it does not so default.  
Add a comma after 'omitted', as in the next sentence.

In
"If both dictionaries are omitted, the expression is executed in 
the environment where eval is called."
replace  "the expression ... is called", which I believe to be 
incorrect as well as misleading, with something like "they default 
to current globals() and locals()."  This parallels the previous 
sentence and is, I believe, more correct.  Within a function, 
locals() is not the current local namespace, and the following 
shows that the difference can make a visible difference:

>>> def g1(): return op.setitem(locals(), 'x', 1), x
...
>>> g1()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in g1
NameError: global name 'x' is not defined
>>> def h1(): return eval("op.setitem(locals(), 'x', 1), x")
...
>>> h1()
(None, 1)

After
"The return value is the result of the evaluated expression. "
add something like
It does not depend on the lexical position of the eval call and 
hence the expression should not contain names that require 
lexical scoping reaching outside the eval call to be valid."

Note that eval scope blocking, the OP's pseudobug, does not 
require a lambda within the eval-ed expression:
>>> def f(x): return lambda: x
...
>>> f(1)()
1
>>> def g(x): return lambda: eval('x')
...
>>> g(1)()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined

This might be another example for the PEP.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-03 15:29

Message:
Logged In: YES 
user_id=80475

Jeremy, would you update the pep and docs to cover the OP's
examples.



----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-03 11:16

Message:
Logged In: YES 
user_id=432579

>No, this issue is not specific to either eval or lambda:

Right, so let me rephrase: The bug occurs when explicitly
evaluating a lambda expression or function definition
statement using eval or exec. (This is an artifact of
Python's strong separation of statements and expressions.)

If this is done "by design", why cannot I find anything
anywhere describing this? If this is just a documentation
oversight, please say so, but then I would also like to have
an explanation of the behaviour.

The fact remains that

    def f(x): eval('x')

works as expected and

    def f(g): eval('lambda x: g(x)')

does not. Why? Both are evaluated at the same time and use
the same environment to look up their variables. The fact
that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping, because that is how
lambda expressions work.

>If you want Python to work 
>differently, write a PEP or a patch, or raise the question in
>the newsgroup/mailing list.

www.python.org told me that this is the place to report bugs
in Python. If that is wrong, we should change the web site.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-02 22:59

Message:
Logged In: YES 
user_id=593130

No, this issue is not specific to either eval or lambda:

>>> def f(g):
...   exec 'def h(x): return g(x)'
...   return h
...
>>> f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in h
NameError: global name 'g' is not defined

It is specific to creating a function at top-level in a separate 
execution environment, as done, by design, by both eval and 
exec, and with either a def statement or lambda abbreviation 
thereof.

In Python, lexical scoping works because nested functions are 
compiled along with the outer function, so that scoped variables 
can be identified and both functions adjusted so that the coupling 
works.  In particular, the scoped variable has to not be deleted 
when the outer function returns.  Eval/exec compile their string 
only later, when the function is called.

"it works that way because it is the way it works".
Those are your words, not mine.  If you want Python to work 
differently, write a PEP or a patch, or raise the question in the 
newsgroup/mailing list. I'm done discussing it here.

----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-02 16:42

Message:
Logged In: YES 
user_id=432579

No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 00:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 00:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 18:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 17:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 09:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 05:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 17:29:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 08:29:06 -0800
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1HLMFG-0006Mh-44@sc8-sf-web7.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Settings changed) made by jhylton
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: Jeremy Hylton (jhylton)
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  Sun Feb 25 19:20:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 10:20:42 -0800
Subject: [ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension
	doesn't build
Message-ID: <E1HLNzG-0002m3-P4@sc8-sf-monitor2.sourceforge.net>

Bugs item #1668133, was opened at 2007-02-25 01:03
Message generated for change (Comment added) made by inow
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: clemens fischer (inow)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build

Initial Comment:
'uname -rms'
FreeBSD 6.2-STABLE i386

'cc --version'
cc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

trying to build python-2.4.4 from ports/lang/python24, i get the
following messages, where earlier versions have been compiled and
installed w/o problems:

"./configure" stage:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for curses.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the preprocessor's result
configure: WARNING: ncurses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for ncurses.h... yes

the 'readline' extension builds fine, though:

building 'readline' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o
cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so

I also tried this command after noticing that freebsd needs some special
define for wchars:

$ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES'
===>  Building for python24-2.4.4
case $MAKEFLAGS in  *-s*)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;;  *)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;;  esac
running build
running build_ext
db.h: found (4, 3) in /usr/local/include/db43
db.h: found (4, 4) in /usr/local/include/db44
db lib: using (4, 4) db-4.4
INFO: Can't locate Tcl/Tk libs and/or headers
building 'nis' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat':
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type
cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o -L/usr/local/lib -o build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so
*** WARNING: renaming "nis" since importing it failed: build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so: Undefined symbol "yperr_string"
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/lang/python24/work/Python-2.4.4.
*** Error code 1


regards, clemens


----------------------------------------------------------------------

>Comment By: clemens fischer (inow)
Date: 2007-02-25 18:20

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 perky writes:

> The ncurses problem is already known and proven as a
> problem of FreeBSD.  And its ports have a workaround
> applied. (-D__wchar_t=wchar_t as you used.)

it may well be a problem of the port that the CFLAGS setting including
this define doesn't cary over into the built.

> The nis compilation error can be raised when your base system was
> built with NO_NIS=yes option.  But build process shouldn't segfault
> even after nis warning.

i noticed that the ports Makefile checks for the existance of
usr/bin/ypcat to decide if NIS support should be included.  i rebuilt
the fbsd world numerous times after the initial install from CD.  NIS
support is disabled on the machine in question, but the yp-programs were
never removed.  after deleting them, the NIS extension still gets built,
but the process doesn't segfault anymore.  the warnings do persist,
though.

> So, can you provide a backtrace of the core dumped for more
> investigation?

for this i would have to have a debug version of the fbsd base systems
gcc, as this is the program segfaulting.  this isn't feasable ATM.

i got another email from Rong-En Fan responding to my freebsd problem
report (1).  he advises to try building python24 after deleting the
development version of ncurses.  i just tried this:  it is the
workaround needed to make python-2.4.4 on fbsd-6.2.

thanks Rong-En Fan and perky!


regards, clemens


(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=109505


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2007-02-25 01:49

Message:
Logged In: YES 
user_id=55188
Originator: NO

The ncurses problem is already known and proven as a problem of FreeBSD. 
And its ports have a workaround applied. (-D__wchar_t=wchar_t as you
used.)

The nis compilation error can be raised when your base system was built
with NO_NIS=yes option.  But build process shouldn't segfault even after
nis warning.

So, can you provide a backtrace of the core dumped for more investigation?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 19:21:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 10:21:21 -0800
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1HLNzt-00009O-Li@sc8-sf-web9.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by kuran
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: Jeremy Hylton (jhylton)
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: Jp Calderone (kuran)
Date: 2007-02-25 13:21

Message:
Logged In: YES 
user_id=366566
Originator: NO

Code coverage tools run afoul

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2006-10-30 11: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 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  Sun Feb 25 19:23:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 10:23:12 -0800
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1HLO1g-0002h7-Js@sc8-sf-web1.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by kuran
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: Jeremy Hylton (jhylton)
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: Jp Calderone (kuran)
Date: 2007-02-25 13:23

Message:
Logged In: YES 
user_id=366566
Originator: NO

Ahem.

Code coverage tools run afoul of this bug as well.  A common case is to
run coverage tools using a test suite.  If this bug is triggered, then the
resulting coverage data isn't valid.


----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2007-02-25 13:21

Message:
Logged In: YES 
user_id=366566
Originator: NO

Code coverage tools run afoul

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2006-10-30 11: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 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  Sun Feb 25 20:43:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 11:43:47 -0800
Subject: [ python-Bugs-1668295 ] Strange unicode behaviour
Message-ID: <E1HLPHf-0000Ma-Os@sc8-sf-web11.sourceforge.net>

Bugs item #1668295, was opened at 2007-02-25 11:10
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

Please note that this 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
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour

Initial Comment:

I know that python is very funny WRT unicode processing, but this defies all my knowledge.

I use the es_ES.UTF-8 encoding on linux. The script:


python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line.

However, if I redirect it to less or to a file, like

python -c "print unicode('? %s' % '??','utf8') " >test
Traceback (most recent call last):
  File "<string>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128)


Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases?

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-25 19:43

Message:
Logged In: YES 
user_id=849994
Originator: NO

First of all: Python's Unicode handling is very consistent and
straightforward, if you know the basics. Sadly, most people don't know the
difference between Unicode and encoded strings.

What you're seeing is not a bug, it is due to the fact that if you print
Unicode to the console, and Python could correctly find out your terminal
encoding, the Unicode string is automatically encoded in that encoding.

If you output to a file, Python does not know which encoding you want to
have, so all Unicode strings are converted to ascii only.

Please direct further questions to the Python mailing list or newsgroup.

The basic rule when handling Unicode is: use Unicode everywhere inside the
program, and byte strings for input and output.
So, your code is exactly the other way round: it takes a byte string,
decodes it to unicode and *then* prints it.

You should do it the other way: use Unicode literals in your code, and
when you write something to a file, *encode* them in utf-8.

----------------------------------------------------------------------

Comment By: Santiago Gala (sgala)
Date: 2007-02-25 11:17

Message:
Logged In: YES 
user_id=178886
Originator: YES

Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn
trunk

Also, some people asks for repr of strings (I guess to reproduce if they
can't read the caracters). Those are printed in utf-8:

$python -c "print repr('? %s')"
'\xc3\xa1 %s'
$ python -c "print repr('?i')"
'\xc3\xa9i'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 21:06:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 12:06:23 -0800
Subject: [ python-Bugs-1668540 ] I can't change attribute __op__ in new-style
	classes
Message-ID: <E1HLPdX-0003Sf-CM@sc8-sf-web2.sourceforge.net>

Bugs item #1668540, was opened at 2007-02-25 23: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=1668540&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: netimen (netimen)
Assigned to: Nobody/Anonymous (nobody)
Summary: I can't change attribute __op__ in new-style classes

Initial Comment:
I tried to use multimethod module from peers package available at http://viral.media.mit.edu/peers/peers-0.20050929.tar.gz to create several __mul__ operators in a new-style class and experienced this problem.

In new-style class I can't change the attribute __op__. Even if I change it with setattr, genuine __op__ will be called.

For instance, if I set __mul__ operator to method object new_mul and write

setattr(obj, '__mul__', new_mul)
obj *= 1 # __mul__ will be called.
# But
obj.__mul__(1) # new_mul will be called.

With common methods and with old-style classes all works properly.

P.S. Sorry for my English

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 21:10:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 12:10:05 -0800
Subject: [ python-Bugs-1668540 ] I can't change attribute __op__ in new-style
	classes
Message-ID: <E1HLPh7-0002bK-Lg@sc8-sf-web9.sourceforge.net>

Bugs item #1668540, was opened at 2007-02-25 20:06
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470

Please note that this 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.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: netimen (netimen)
Assigned to: Nobody/Anonymous (nobody)
Summary: I can't change attribute __op__ in new-style classes

Initial Comment:
I tried to use multimethod module from peers package available at http://viral.media.mit.edu/peers/peers-0.20050929.tar.gz to create several __mul__ operators in a new-style class and experienced this problem.

In new-style class I can't change the attribute __op__. Even if I change it with setattr, genuine __op__ will be called.

For instance, if I set __mul__ operator to method object new_mul and write

setattr(obj, '__mul__', new_mul)
obj *= 1 # __mul__ will be called.
# But
obj.__mul__(1) # new_mul will be called.

With common methods and with old-style classes all works properly.

P.S. Sorry for my English

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-25 20:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

These special methods are looked up upon the type for new-style classes.
This won't change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 21:35:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 12:35:18 -0800
Subject: [ python-Bugs-810714 ] nested variables in 'class:' statements
Message-ID: <E1HLQ5W-0007KB-LY@sc8-sf-web4.sourceforge.net>

Bugs item #810714, was opened at 2003-09-22 17:05
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: nested variables in 'class:' statements

Initial Comment:
from the user's point of view, variables originating
from nested scopes could erratically become bound in
the 'class' statement.

The 'class:' statements works by capturing all locals()
after executing the body; however, this is not exactly
the same as what an explicit call to locals() would
return because of the missing PyFrame_FastToLocals()
call in the implementation of LOAD_LOCALS in ceval.c.
It was thought that PyFrame_FastToLocals() was
unnecessary at that point because the class body
bytecode only uses LOAD_NAME/STORE_NAME and not fast
locals -- but this is no longer true with nested
scopes. See attached examples.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 20:35

Message:
Logged In: YES 
user_id=31392
Originator: NO

I'm not sure I understand all the implications of nested variables,
either.  The current behavior of locals() is to return the names of all
free variables that are being passed through the class body so that they
can be used by methods.  Is the behavior correct?  I see that IronPython
implements locals() that way, but does not bind them as class variables
(good).  Should we change the "spec" of locals() and cause IronPython to be
incompatible, or should we fix CPython and PyPy to behave the same way? 
The fix for CPython will be somewhat involved.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-01-08 17:13

Message:
Logged In: YES 
user_id=4771

Attached is a draft.  I am not sure that I understand all the implications
of nested variables in the presence of class bodies, so please don't check
in this patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-09-24 12:47

Message:
Logged In: YES 
user_id=4771

I'm not sure how to solve this. I could make a patch to
LOAD_LOCALS to prevent free variables from showing up in the
class.__dict__. For the 2nd problem I'm not familiar enough
with compile.c to know how to make the binding 'b=&quot;foo&quot;'
sufficient to prevent 'b' from also being considered free in
the class definition (which is what occurs).

Note also that bare 'exec' statements should then be
forbidden in class definitions in the presence of free
variables, for the same reason as it is forbidden in
functions: you cannot tell whether a variable is free or
local.

As an example of this, if in the attached example we replace
b=&quot;foo&quot; with exec 'b=&quot;foo&quot;' then the last print
correctly
outputs 'foo' instead of 6 but what actually occurs is that
the value of the argument b in f(a,b) was modified by the
class definition -- it is a way to change the binding of a
variable in an enclosing frame, which should not be
possible.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 19:16

Message:
Logged In: YES 
user_id=80475

Do you have a proposed patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 21:36:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 12:36:19 -0800
Subject: [ python-Bugs-810714 ] nested variables in 'class:' statements
Message-ID: <E1HLQ6V-0007QT-Lm@sc8-sf-web4.sourceforge.net>

Bugs item #810714, was opened at 2003-09-22 17:05
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
>Assigned to: Jeremy Hylton (jhylton)
Summary: nested variables in 'class:' statements

Initial Comment:
from the user's point of view, variables originating
from nested scopes could erratically become bound in
the 'class' statement.

The 'class:' statements works by capturing all locals()
after executing the body; however, this is not exactly
the same as what an explicit call to locals() would
return because of the missing PyFrame_FastToLocals()
call in the implementation of LOAD_LOCALS in ceval.c.
It was thought that PyFrame_FastToLocals() was
unnecessary at that point because the class body
bytecode only uses LOAD_NAME/STORE_NAME and not fast
locals -- but this is no longer true with nested
scopes. See attached examples.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 20:36

Message:
Logged In: YES 
user_id=31392
Originator: NO

I'm not sure I understand all the implications of nested variables,
either.  The current behavior of locals() is to return the names of all
free variables that are being passed through the class body so that they
can be used by methods.  Is the behavior correct?  I see that IronPython
implements locals() that way, but does not bind them as class variables
(good).  Should we change the "spec" of locals() and cause IronPython to be
incompatible, or should we fix CPython and PyPy to behave the same way? 
The fix for CPython will be somewhat involved.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 20:35

Message:
Logged In: YES 
user_id=31392
Originator: NO

I'm not sure I understand all the implications of nested variables,
either.  The current behavior of locals() is to return the names of all
free variables that are being passed through the class body so that they
can be used by methods.  Is the behavior correct?  I see that IronPython
implements locals() that way, but does not bind them as class variables
(good).  Should we change the "spec" of locals() and cause IronPython to be
incompatible, or should we fix CPython and PyPy to behave the same way? 
The fix for CPython will be somewhat involved.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-01-08 17:13

Message:
Logged In: YES 
user_id=4771

Attached is a draft.  I am not sure that I understand all the implications
of nested variables in the presence of class bodies, so please don't check
in this patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-09-24 12:47

Message:
Logged In: YES 
user_id=4771

I'm not sure how to solve this. I could make a patch to
LOAD_LOCALS to prevent free variables from showing up in the
class.__dict__. For the 2nd problem I'm not familiar enough
with compile.c to know how to make the binding 'b=&quot;foo&quot;'
sufficient to prevent 'b' from also being considered free in
the class definition (which is what occurs).

Note also that bare 'exec' statements should then be
forbidden in class definitions in the presence of free
variables, for the same reason as it is forbidden in
functions: you cannot tell whether a variable is free or
local.

As an example of this, if in the attached example we replace
b=&quot;foo&quot; with exec 'b=&quot;foo&quot;' then the last print
correctly
outputs 'foo' instead of 6 but what actually occurs is that
the value of the argument b in f(a,b) was modified by the
class definition -- it is a way to change the binding of a
variable in an enclosing frame, which should not be
possible.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 19:16

Message:
Logged In: YES 
user_id=80475

Do you have a proposed patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 22:12:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 13:12:12 -0800
Subject: [ python-Bugs-1668565 ] inspect.getargspec() fails with keyword-only
	arguments
Message-ID: <E1HLQfE-00005X-BP@sc8-sf-web8.sourceforge.net>

Bugs item #1668565, was opened at 2007-02-25 13:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668565&group_id=5470

Please note that this 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 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getargspec() fails with keyword-only arguments

Initial Comment:
If a function's signature includes both keyword-only arguments and *args or **kwargs then inspect.getargspec() assigns the name for the * and ** arguments to the first one or two keyword-only arguments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668565&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 22:57:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 13:57:45 -0800
Subject: [ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension
	doesn't build
Message-ID: <E1HLRNJ-0004bT-PN@sc8-sf-web8.sourceforge.net>

Bugs item #1668133, was opened at 2007-02-25 02:03
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: clemens fischer (inow)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build

Initial Comment:
'uname -rms'
FreeBSD 6.2-STABLE i386

'cc --version'
cc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

trying to build python-2.4.4 from ports/lang/python24, i get the
following messages, where earlier versions have been compiled and
installed w/o problems:

"./configure" stage:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for curses.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the preprocessor's result
configure: WARNING: ncurses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for ncurses.h... yes

the 'readline' extension builds fine, though:

building 'readline' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o
cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so

I also tried this command after noticing that freebsd needs some special
define for wchars:

$ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES'
===>  Building for python24-2.4.4
case $MAKEFLAGS in  *-s*)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;;  *)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;;  esac
running build
running build_ext
db.h: found (4, 3) in /usr/local/include/db43
db.h: found (4, 4) in /usr/local/include/db44
db lib: using (4, 4) db-4.4
INFO: Can't locate Tcl/Tk libs and/or headers
building 'nis' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat':
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type
cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o -L/usr/local/lib -o build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so
*** WARNING: renaming "nis" since importing it failed: build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so: Undefined symbol "yperr_string"
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/lang/python24/work/Python-2.4.4.
*** Error code 1


regards, clemens


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-25 22:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

So should this be closed as 3rd-party bug, then?

----------------------------------------------------------------------

Comment By: clemens fischer (inow)
Date: 2007-02-25 19:20

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 perky writes:

> The ncurses problem is already known and proven as a
> problem of FreeBSD.  And its ports have a workaround
> applied. (-D__wchar_t=wchar_t as you used.)

it may well be a problem of the port that the CFLAGS setting including
this define doesn't cary over into the built.

> The nis compilation error can be raised when your base system was
> built with NO_NIS=yes option.  But build process shouldn't segfault
> even after nis warning.

i noticed that the ports Makefile checks for the existance of
usr/bin/ypcat to decide if NIS support should be included.  i rebuilt
the fbsd world numerous times after the initial install from CD.  NIS
support is disabled on the machine in question, but the yp-programs were
never removed.  after deleting them, the NIS extension still gets built,
but the process doesn't segfault anymore.  the warnings do persist,
though.

> So, can you provide a backtrace of the core dumped for more
> investigation?

for this i would have to have a debug version of the fbsd base systems
gcc, as this is the program segfaulting.  this isn't feasable ATM.

i got another email from Rong-En Fan responding to my freebsd problem
report (1).  he advises to try building python24 after deleting the
development version of ncurses.  i just tried this:  it is the
workaround needed to make python-2.4.4 on fbsd-6.2.

thanks Rong-En Fan and perky!


regards, clemens


(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=109505


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2007-02-25 02:49

Message:
Logged In: YES 
user_id=55188
Originator: NO

The ncurses problem is already known and proven as a problem of FreeBSD. 
And its ports have a workaround applied. (-D__wchar_t=wchar_t as you
used.)

The nis compilation error can be raised when your base system was built
with NO_NIS=yes option.  But build process shouldn't segfault even after
nis warning.

So, can you provide a backtrace of the core dumped for more investigation?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:01:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:01:47 -0800
Subject: [ python-Bugs-1667877 ] Install fails with no error
Message-ID: <E1HLRRD-0005Hr-RQ@sc8-sf-web9.sourceforge.net>

Bugs item #1667877, was opened at 2007-02-24 17:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

Please note that this 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: Wont Fix
Priority: 5
Private: No
Submitted By: larry (widgeteye)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install fails with no error

Initial Comment:
When I built python 2.5 for linux I did the normal: 
configure 
make 
make install 

Everything went fine til the "make install" part. It dies with no 
error. 
just says "install failed" after this: 

Compiling /usr/local/lib/python2.5/zipfile.py 

That part built fine but the next part failed. 
So what I did being the industrious fellow that I am I did: 

make -n install > out 

Took the out file and did: 

sh out 

That installed python without failure. 

Now if I do "make install" everything works fine. 

Weird eh?

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-25 23:01

Message:
Logged In: YES 
user_id=21627
Originator: NO

I'm not finding it weird that the shell script completed. I doubt it
"works fine", though. Instead, some command in it failed, but the shell
doesn't abort in this case - make would abort.

Typically, when byte-compilation fails, it is because you have a file
byte-compiled that has a syntax error in it. Scroll through the entire
compileall output to see what the actual problem is.

Tentatively closing this as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:02:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:02:21 -0800
Subject: [ python-Bugs-1668540 ] I can't change attribute __op__ in new-style
	classes
Message-ID: <E1HLRRl-0006NJ-3F@sc8-sf-web7.sourceforge.net>

Bugs item #1668540, was opened at 2007-02-25 23:06
Message generated for change (Comment added) made by netimen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470

Please note that this 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.5
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: netimen (netimen)
Assigned to: Nobody/Anonymous (nobody)
Summary: I can't change attribute __op__ in new-style classes

Initial Comment:
I tried to use multimethod module from peers package available at http://viral.media.mit.edu/peers/peers-0.20050929.tar.gz to create several __mul__ operators in a new-style class and experienced this problem.

In new-style class I can't change the attribute __op__. Even if I change it with setattr, genuine __op__ will be called.

For instance, if I set __mul__ operator to method object new_mul and write

setattr(obj, '__mul__', new_mul)
obj *= 1 # __mul__ will be called.
# But
obj.__mul__(1) # new_mul will be called.

With common methods and with old-style classes all works properly.

P.S. Sorry for my English

----------------------------------------------------------------------

>Comment By: netimen (netimen)
Date: 2007-02-26 01:02

Message:
Logged In: YES 
user_id=1728694
Originator: YES

But.. then how to overload operators&

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-25 23:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

These special methods are looked up upon the type for new-style classes.
This won't change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668540&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:15:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:15:20 -0800
Subject: [ python-Bugs-1668596 ] distutils chops the first character of
	filenames
Message-ID: <E1HLReK-0000sV-U5@sc8-sf-web9.sourceforge.net>

Bugs item #1668596, was opened at 2007-02-25 22: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=1668596&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sam Pointon (freecondiments)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils chops the first character of filenames

Initial Comment:
Python 2.5c1, Windows XP SP2.

distutils chops the first character from some filenames if the package_data key is ''.

Minimal example:
The setup.py attached, and a directory named 'doc' in the same directory as setup.py with files in it. Running "python setup.py bdist" triggers the error.

On my box, this fails with:
running bdist
running bdist_dumb
running build
running build_py
error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file

http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html 
describes the same problem, and http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a commentary on the code in distutils/commands/build_py.py which causes the error.

On lines 117-122, it tries to chop the directory path from the files it has found, using len() and slicing. This job is better done by os.path.split (and is probably more portable, too).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:16:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:16:18 -0800
Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in
	Python 2.5
Message-ID: <E1HLRfG-0002lQ-82@sc8-sf-web11.sourceforge.net>

Bugs item #1659171, was opened at 2007-02-13 09:27
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard B. Kreckel (richyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling tparm from extension lib fails in Python 2.5

Initial Comment:
Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-25 14:16

Message:
Logged In: YES 
user_id=33168
Originator: NO

Can you test with 2.5 from SVN and confirm your program works in the
complete context?

----------------------------------------------------------------------

Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-22 04:25

Message:
Logged In: YES 
user_id=1718463
Originator: YES

The error message about the undefined init function is a red herring. The
example is actually a stripped-down testcase from a much larger
Boost.Python module, which of course does have an init function. The point
here is the NULL pointer returned by tparm.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-14 13:24

Message:
Logged In: YES 
user_id=21627
Originator: NO

I fail to see the bug. The exception precisely describes the error in your
code

ImportError: dynamic module does not define init function (inittestlib)

Why do you expect any meaningful behavior in the presence of this error?
Your shared library isn't an extension module.

If you think it is related to #1548092, please try out the subversion
trunk, which has fixed this bug.

----------------------------------------------------------------------

Comment By: Richard B. Kreckel (richyk)
Date: 2007-02-14 00:52

Message:
Logged In: YES 
user_id=1718463
Originator: YES

I suspect that this is a duplicate of Bug [1548092].
Note that, there it is asserted that tparm returns NULL on certain invalid
strings.
That does not seem to be true. It returns NULL for valid trivial strings,
too.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:19:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:19:29 -0800
Subject: [ python-Bugs-1658959 ] os.wait child process fail when under stress
Message-ID: <E1HLRiL-0005Li-AQ@sc8-sf-web3.sourceforge.net>

Bugs item #1658959, was opened at 2007-02-13 05:44
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470

Please note that this 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: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: The Groff (thegroff)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.wait child process fail when under stress

Initial Comment:
when having high amount of threads forking, os.wait fails from time to time giving a "No child" error". If you retry, eventually it will work.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-25 14:19

Message:
Logged In: YES 
user_id=33168
Originator: NO

Note that on some versions of Linux 2.4, calling wait() can return ECHILD
even when there is a child.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 07:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

What operating system are you using? 

Why do you think this is a bug in Python and not in your operating
system?

Are you sure there are any unwaited-for children when ECHILD is returned?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:23:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:23:07 -0800
Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Message-ID: <E1HLRlr-0005At-P9@sc8-sf-monitor2.sourceforge.net>

Bugs item #1303614, was opened at 2005-09-24 23:40
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

Please note that this 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: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bypassing __dict__ readonlyness

Initial Comment:
The __dict__ attribute of some objects is read-only,
e.g. for type objects.  However, there is a generic
way to still access and modify it (without hacking with
gc.get_referrents(), that is).  This can lead to
obscure crashes.  Attached is an example that shows
a potential "problem" involving putting strange keys
in the __dict__ of a type.

This is probably very minor anyway.  If we wanted to
fix this, we would need a __dict__ descriptor that
looks more cleverly at the object to which it is
applied.

BTW the first person who understand why the attached
program crashes gets a free coffee.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:23

Message:
Logged In: YES 
user_id=31392
Originator: NO

I tried test67.py in IronPython.  It reports that x.hello has the value
456.  Is that the correct behavior?  It seems incorrect to me.  If the
__eq__ method is called, then the object should no longer have either the
Strange() or hello attributes.  They are cleared by reseting __dict__.  Is
that right?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-06-30 07:05

Message:
Logged In: YES 
user_id=4771

Well, try making an "empty" class Foo(object): pass, and see
what magically shows up in Foo.__dict__.keys().  Here is the
__dict__ descriptor used for instances of Foo.  This
descriptor is connected to subtype_dict() and
subtype_setdict() in typeobject.c.

INCREF/DECREFs are in theory missing around every use of the
dictionary returned by _PyObject_GetDictPtr(), because more
or less any such use could remove the dict from the object
from which _PyObject_GetDictPtr() returned from, and so
decref the dict - while it's used.  This might require some
timing, to check the performance impact.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 01:14

Message:
Logged In: YES 
user_id=357491

OK, then I am going to need a little guidance to dive into
this more since this is going into some murky waters for me.  =)

For the normal, non-evil case of an empty Python class
(``class Foo(object): pass``), I would think that accessing
__dict__ would fall through to the tp_getset for object, and
then fall to the same slot for type.  Now that is obviously
not happening since you get a straight dict back for that
attribute access and not a dict proxy as would be suggested
based on my logic listed above.

So, my question is, where is the code that handles fetching
Foo().__dict__?  And if you have an inkling of where I
should be looking in terms of possible refcounting additions
that would be great as well.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-06-29 21:19

Message:
Logged In: YES 
user_id=4771

Brett: I think you're approaching the problem from the wrong
angle.  The problem is being allowed to freely tamper with
the dict stored in objects.  Getting NULL errors here and
there is only a symptom.  As I explain, the '__dict__'
descriptor object needs to do some more checks, and to be
fully safe some Py_INCREF/Py_DECREF are needed in some
critical places.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:45

Message:
Logged In: YES 
user_id=357491

For the deldict.py crasher, if you look at the traceback
there is no good place to do a check that tp_dict is sane
except in type_module() or PyDict_GetItem().  Now adding the
NULL check in type_module() will fix this specific problem,
but that seems like an ad-hoc patch.

Why don't we check for NULL in PyDict_GetItem() and return
NULL just like the PyDict_Check() test?  I am sure the
answer is "performance", but this is not PyDict_GETITEM()and
thus already is not the performance-critical version anyway.
 So why shouldn't we check for NULL there and possibly catch
other errors?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:41

Message:
Logged In: YES 
user_id=357491

Simple patch for the loosing_dict_ref.py crasher is
attached.  Just checked for possible NULL values in what is
needed by _Py_ForgetReference().  Let me know what you
think, Armin.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-12-14 15:36

Message:
Logged In: YES 
user_id=6656

Yikes!

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 15:32

Message:
Logged In: YES 
user_id=4771

A proposed fix for the later crash: the __dict__ descriptor of
user-defined classes should verify if there is another __dict__ descriptor
along the solid path of the type (i.e. following "tp_base" pointers).  If
so, it should delegate to it.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 14:49

Message:
Logged In: YES 
user_id=4771

Uh oh.  There is a much simpler crash.  The technique outlined in
deldict.py can be used to rebind or even delete the __dict__ attribute of
instances where it should normally not be allowed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-09-25 08:55

Message:
Logged In: YES 
user_id=4771

The bug is related to code like PyObject_GenericGetAttribute and
_PyType_Lookup which are not careful about the reference counters of the
objects they operate on.  This allows a much simpler crash (test67.py):
the __dict__ of an object can be decrefed away while lookdict() is looking
at it.  This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in
core routines like PyObject_GenericGetAttr.  We probably need to measure if
it has a performance impact, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:24:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:24:02 -0800
Subject: [ python-Bugs-1649098 ] non-standard: array[0]
Message-ID: <E1HLRmk-0003bj-2v@sc8-sf-web4.sourceforge.net>

Bugs item #1649098, was opened at 2007-01-31 10:25
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470

Please note that this 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
Private: No
Submitted By: Johannes Abt (jabt)
>Assigned to: Thomas Heller (theller)
Summary: non-standard: array[0]

Initial Comment:
in Modules/_ctypes/ctypes.h:

typedef struct {
[..]
        ffi_type *atypes[0];
} ffi_info;

AFAIK, arrays must be of size > 0.
_Most_ compilers accepts this, but not all
(especially my HP-UX compiler).

Please change *atypes[0] to *atypes[1]!

Bye,
Johannes


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-25 14:24

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas, could you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:25:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:25:24 -0800
Subject: [ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension
	doesn't build
Message-ID: <E1HLRo4-000200-Ci@sc8-sf-web2.sourceforge.net>

Bugs item #1668133, was opened at 2007-02-25 01:03
Message generated for change (Comment added) made by inow
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: clemens fischer (inow)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build

Initial Comment:
'uname -rms'
FreeBSD 6.2-STABLE i386

'cc --version'
cc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

trying to build python-2.4.4 from ports/lang/python24, i get the
following messages, where earlier versions have been compiled and
installed w/o problems:

"./configure" stage:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for curses.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the preprocessor's result
configure: WARNING: ncurses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for ncurses.h... yes

the 'readline' extension builds fine, though:

building 'readline' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o
cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so

I also tried this command after noticing that freebsd needs some special
define for wchars:

$ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES'
===>  Building for python24-2.4.4
case $MAKEFLAGS in  *-s*)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;;  *)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;;  esac
running build
running build_ext
db.h: found (4, 3) in /usr/local/include/db43
db.h: found (4, 4) in /usr/local/include/db44
db lib: using (4, 4) db-4.4
INFO: Can't locate Tcl/Tk libs and/or headers
building 'nis' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat':
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type
cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o -L/usr/local/lib -o build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so
*** WARNING: renaming "nis" since importing it failed: build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so: Undefined symbol "yperr_string"
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/lang/python24/work/Python-2.4.4.
*** Error code 1


regards, clemens


----------------------------------------------------------------------

>Comment By: clemens fischer (inow)
Date: 2007-02-25 22:25

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 loewis said:

> So should this be closed as 3rd-party bug, then?

that'll be a "roger" (beep).  3rd-party bug is the shortest precise
term. the problem had been discussed several times before. it doesn't
show up with the libncurses.* in the base system. as soon as another
package pulls in the "wrong" dependency, later builds can break.

regards, clemens


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-25 21:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

So should this be closed as 3rd-party bug, then?

----------------------------------------------------------------------

Comment By: clemens fischer (inow)
Date: 2007-02-25 18:20

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 perky writes:

> The ncurses problem is already known and proven as a
> problem of FreeBSD.  And its ports have a workaround
> applied. (-D__wchar_t=wchar_t as you used.)

it may well be a problem of the port that the CFLAGS setting including
this define doesn't cary over into the built.

> The nis compilation error can be raised when your base system was
> built with NO_NIS=yes option.  But build process shouldn't segfault
> even after nis warning.

i noticed that the ports Makefile checks for the existance of
usr/bin/ypcat to decide if NIS support should be included.  i rebuilt
the fbsd world numerous times after the initial install from CD.  NIS
support is disabled on the machine in question, but the yp-programs were
never removed.  after deleting them, the NIS extension still gets built,
but the process doesn't segfault anymore.  the warnings do persist,
though.

> So, can you provide a backtrace of the core dumped for more
> investigation?

for this i would have to have a debug version of the fbsd base systems
gcc, as this is the program segfaulting.  this isn't feasable ATM.

i got another email from Rong-En Fan responding to my freebsd problem
report (1).  he advises to try building python24 after deleting the
development version of ncurses.  i just tried this:  it is the
workaround needed to make python-2.4.4 on fbsd-6.2.

thanks Rong-En Fan and perky!


regards, clemens


(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=109505


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2007-02-25 01:49

Message:
Logged In: YES 
user_id=55188
Originator: NO

The ncurses problem is already known and proven as a problem of FreeBSD. 
And its ports have a workaround applied. (-D__wchar_t=wchar_t as you
used.)

The nis compilation error can be raised when your base system was built
with NO_NIS=yes option.  But build process shouldn't segfault even after
nis warning.

So, can you provide a backtrace of the core dumped for more investigation?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:25:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:25:32 -0800
Subject: [ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension
	doesn't build
Message-ID: <E1HLRoC-00020C-Jw@sc8-sf-web2.sourceforge.net>

Bugs item #1668133, was opened at 2007-02-25 01:03
Message generated for change (Comment added) made by inow
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

Please note that this 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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: clemens fischer (inow)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build

Initial Comment:
'uname -rms'
FreeBSD 6.2-STABLE i386

'cc --version'
cc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

trying to build python-2.4.4 from ports/lang/python24, i get the
following messages, where earlier versions have been compiled and
installed w/o problems:

"./configure" stage:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for curses.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the preprocessor's result
configure: WARNING: ncurses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for ncurses.h... yes

the 'readline' extension builds fine, though:

building 'readline' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o
cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so

I also tried this command after noticing that freebsd needs some special
define for wchars:

$ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES'
===>  Building for python24-2.4.4
case $MAKEFLAGS in  *-s*)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;;  *)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;;  esac
running build
running build_ext
db.h: found (4, 3) in /usr/local/include/db43
db.h: found (4, 4) in /usr/local/include/db44
db lib: using (4, 4) db-4.4
INFO: Can't locate Tcl/Tk libs and/or headers
building 'nis' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat':
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type
cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o -L/usr/local/lib -o build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so
*** WARNING: renaming "nis" since importing it failed: build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so: Undefined symbol "yperr_string"
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/lang/python24/work/Python-2.4.4.
*** Error code 1


regards, clemens


----------------------------------------------------------------------

>Comment By: clemens fischer (inow)
Date: 2007-02-25 22:25

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 loewis said:

> So should this be closed as 3rd-party bug, then?

that'll be a "roger" (beep).  3rd-party bug is the shortest precise
term. the problem had been discussed several times before. it doesn't
show up with the libncurses.* in the base system. as soon as another
package pulls in the "wrong" dependency, later builds can break.

regards, clemens


----------------------------------------------------------------------

Comment By: clemens fischer (inow)
Date: 2007-02-25 22:25

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 loewis said:

> So should this be closed as 3rd-party bug, then?

that'll be a "roger" (beep).  3rd-party bug is the shortest precise
term. the problem had been discussed several times before. it doesn't
show up with the libncurses.* in the base system. as soon as another
package pulls in the "wrong" dependency, later builds can break.

regards, clemens


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-25 21:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

So should this be closed as 3rd-party bug, then?

----------------------------------------------------------------------

Comment By: clemens fischer (inow)
Date: 2007-02-25 18:20

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 perky writes:

> The ncurses problem is already known and proven as a
> problem of FreeBSD.  And its ports have a workaround
> applied. (-D__wchar_t=wchar_t as you used.)

it may well be a problem of the port that the CFLAGS setting including
this define doesn't cary over into the built.

> The nis compilation error can be raised when your base system was
> built with NO_NIS=yes option.  But build process shouldn't segfault
> even after nis warning.

i noticed that the ports Makefile checks for the existance of
usr/bin/ypcat to decide if NIS support should be included.  i rebuilt
the fbsd world numerous times after the initial install from CD.  NIS
support is disabled on the machine in question, but the yp-programs were
never removed.  after deleting them, the NIS extension still gets built,
but the process doesn't segfault anymore.  the warnings do persist,
though.

> So, can you provide a backtrace of the core dumped for more
> investigation?

for this i would have to have a debug version of the fbsd base systems
gcc, as this is the program segfaulting.  this isn't feasable ATM.

i got another email from Rong-En Fan responding to my freebsd problem
report (1).  he advises to try building python24 after deleting the
development version of ncurses.  i just tried this:  it is the
workaround needed to make python-2.4.4 on fbsd-6.2.

thanks Rong-En Fan and perky!


regards, clemens


(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=109505


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2007-02-25 01:49

Message:
Logged In: YES 
user_id=55188
Originator: NO

The ncurses problem is already known and proven as a problem of FreeBSD. 
And its ports have a workaround applied. (-D__wchar_t=wchar_t as you
used.)

The nis compilation error can be raised when your base system was built
with NO_NIS=yes option.  But build process shouldn't segfault even after
nis warning.

So, can you provide a backtrace of the core dumped for more investigation?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:27:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:27:40 -0800
Subject: [ python-Bugs-1668295 ] Strange unicode behaviour
Message-ID: <E1HLRqG-0003VJ-UU@sc8-sf-web9.sourceforge.net>

Bugs item #1668295, was opened at 2007-02-25 12:10
Message generated for change (Comment added) made by sgala
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

Please note that this 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: Invalid
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour

Initial Comment:

I know that python is very funny WRT unicode processing, but this defies all my knowledge.

I use the es_ES.UTF-8 encoding on linux. The script:


python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line.

However, if I redirect it to less or to a file, like

python -c "print unicode('? %s' % '??','utf8') " >test
Traceback (most recent call last):
  File "<string>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128)


Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases?

----------------------------------------------------------------------

>Comment By: Santiago Gala (sgala)
Date: 2007-02-25 23:27

Message:
Logged In: YES 
user_id=178886
Originator: YES

re: consistent, my experience it is that python unicode handling is
consistently stupid, doing almost always the wrong thing. It remembers me
of the defaults of WordPerfect, that were always exactly the opposite of
what the user wanted 99% of time. I hope python 3000 comes fast and stops
that real pain.

I love the language, but the way it handles unicode provokes hundreds of
bugs.

>Python could correctly find out your terminal
>encoding, the Unicode string is automatically encoded in that encoding.
>
>If you output to a file, Python does not know which encoding you want to
>have, so all Unicode strings are converted to ascii only.

>>> sys.getfilesystemencoding()
'UTF-8'

so python is really dumb if print does not know my filesystemencoding, but
knows my terminal encoding.

I though breaking the least surprising behaviour was not considered
pythonic, and now you tell me that having a program running on console but
issuing an exception when redirected is intended. I would prefer an
exception in both cases. Or, even better, using
sys.getfilesystemencoding(), or allowing me to set defaultencoding()

>Please direct further questions to the Python mailing list or newsgroup.

I would if I didn't consider this behaviour a bug, and a serious one. 

>The basic rule when handling Unicode is: use Unicode everywhere inside
the
>program, and byte strings for input and output.
>So, your code is exactly the other way round: it takes a byte string,
>decodes it to unicode and *then* prints it.
>
>You should do it the other way: use Unicode literals in your code, and
>when y(ou write something to a file, *encode* them in utf-8.

Do you mean that I need to say print unicode(whatever).encode('utf8'),
like:

>>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and
understand, even in files encoded as utf8. Assume this is a literal or
input
...
>>> print unicode(a).encode('utf8') # because a could be a number, or a
different object

every time, instead of "a='?'; print a"

Cool, I'm starting to really love it. Concise and pythonic

Are you seriously meaning that there is no way to tell print to use a
default encoding, and it will magically try to find it and fail for
everything not being a terminal?


Are you seriously telling me that this is not a bug? Even worse, that it
is "intended behaviour". BTW, jython acts differently about this, in all
the versions I tried.

And with -S I am allowed to change the encoding, which is crippled in site
for no known good reason. 

python -S -c "import sys; sys.setdefaultencoding('utf8'); print
unicode('\xc3\xa1','utf8')" >test
(works, test contains an accented a as intended


>use Unicode everywhere inside the
>program, and byte strings for input and output.

Have you ever wondered that to use unicode everywhere inside the program,
one needs to decode literals (or input) to unicode (the next sentence you
complain about)?

>So, your code is exactly the other way round: it takes a byte string,
>decodes it to unicode and *then* prints it.

I follow this principle in my programming since about 6 years ago, so I'm
not a novice. I'm playing by the rules:
a) "decodes it to unicode" is the first step to get it into processing.
This is just a test case, so processing is zero.
b) I refuse to believe that the only way to ensure something to be printed
right is wrapping every item into unicode(var).encode('utf8') [The
redundant unicode call is because the var could be a number, or a different
object]
c) or making my code non portable by patching site.py to get a real
encoding instead of ascii.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-25 20:43

Message:
Logged In: YES 
user_id=849994
Originator: NO

First of all: Python's Unicode handling is very consistent and
straightforward, if you know the basics. Sadly, most people don't know the
difference between Unicode and encoded strings.

What you're seeing is not a bug, it is due to the fact that if you print
Unicode to the console, and Python could correctly find out your terminal
encoding, the Unicode string is automatically encoded in that encoding.

If you output to a file, Python does not know which encoding you want to
have, so all Unicode strings are converted to ascii only.

Please direct further questions to the Python mailing list or newsgroup.

The basic rule when handling Unicode is: use Unicode everywhere inside the
program, and byte strings for input and output.
So, your code is exactly the other way round: it takes a byte string,
decodes it to unicode and *then* prints it.

You should do it the other way: use Unicode literals in your code, and
when you write something to a file, *encode* them in utf-8.

----------------------------------------------------------------------

Comment By: Santiago Gala (sgala)
Date: 2007-02-25 12:17

Message:
Logged In: YES 
user_id=178886
Originator: YES

Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn
trunk

Also, some people asks for repr of strings (I guess to reproduce if they
can't read the caracters). Those are printed in utf-8:

$python -c "print repr('? %s')"
'\xc3\xa1 %s'
$ python -c "print repr('?i')"
'\xc3\xa9i'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:36:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:36:21 -0800
Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Message-ID: <E1HLRyf-0003B3-DB@sc8-sf-web7.sourceforge.net>

Bugs item #1303614, was opened at 2005-09-24 23:40
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

Please note that this 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: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bypassing __dict__ readonlyness

Initial Comment:
The __dict__ attribute of some objects is read-only,
e.g. for type objects.  However, there is a generic
way to still access and modify it (without hacking with
gc.get_referrents(), that is).  This can lead to
obscure crashes.  Attached is an example that shows
a potential "problem" involving putting strange keys
in the __dict__ of a type.

This is probably very minor anyway.  If we wanted to
fix this, we would need a __dict__ descriptor that
looks more cleverly at the object to which it is
applied.

BTW the first person who understand why the attached
program crashes gets a free coffee.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:36

Message:
Logged In: YES 
user_id=31392
Originator: NO

I tried test67.py in IronPython.  It reports that x.hello has the value
456.  Is that the correct behavior?  It seems incorrect to me.  If the
__eq__ method is called, then the object should no longer have either the
Strange() or hello attributes.  They are cleared by reseting __dict__.  Is
that right?

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:23

Message:
Logged In: YES 
user_id=31392
Originator: NO

I tried test67.py in IronPython.  It reports that x.hello has the value
456.  Is that the correct behavior?  It seems incorrect to me.  If the
__eq__ method is called, then the object should no longer have either the
Strange() or hello attributes.  They are cleared by reseting __dict__.  Is
that right?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-06-30 07:05

Message:
Logged In: YES 
user_id=4771

Well, try making an "empty" class Foo(object): pass, and see
what magically shows up in Foo.__dict__.keys().  Here is the
__dict__ descriptor used for instances of Foo.  This
descriptor is connected to subtype_dict() and
subtype_setdict() in typeobject.c.

INCREF/DECREFs are in theory missing around every use of the
dictionary returned by _PyObject_GetDictPtr(), because more
or less any such use could remove the dict from the object
from which _PyObject_GetDictPtr() returned from, and so
decref the dict - while it's used.  This might require some
timing, to check the performance impact.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 01:14

Message:
Logged In: YES 
user_id=357491

OK, then I am going to need a little guidance to dive into
this more since this is going into some murky waters for me.  =)

For the normal, non-evil case of an empty Python class
(``class Foo(object): pass``), I would think that accessing
__dict__ would fall through to the tp_getset for object, and
then fall to the same slot for type.  Now that is obviously
not happening since you get a straight dict back for that
attribute access and not a dict proxy as would be suggested
based on my logic listed above.

So, my question is, where is the code that handles fetching
Foo().__dict__?  And if you have an inkling of where I
should be looking in terms of possible refcounting additions
that would be great as well.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-06-29 21:19

Message:
Logged In: YES 
user_id=4771

Brett: I think you're approaching the problem from the wrong
angle.  The problem is being allowed to freely tamper with
the dict stored in objects.  Getting NULL errors here and
there is only a symptom.  As I explain, the '__dict__'
descriptor object needs to do some more checks, and to be
fully safe some Py_INCREF/Py_DECREF are needed in some
critical places.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:45

Message:
Logged In: YES 
user_id=357491

For the deldict.py crasher, if you look at the traceback
there is no good place to do a check that tp_dict is sane
except in type_module() or PyDict_GetItem().  Now adding the
NULL check in type_module() will fix this specific problem,
but that seems like an ad-hoc patch.

Why don't we check for NULL in PyDict_GetItem() and return
NULL just like the PyDict_Check() test?  I am sure the
answer is "performance", but this is not PyDict_GETITEM()and
thus already is not the performance-critical version anyway.
 So why shouldn't we check for NULL there and possibly catch
other errors?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:41

Message:
Logged In: YES 
user_id=357491

Simple patch for the loosing_dict_ref.py crasher is
attached.  Just checked for possible NULL values in what is
needed by _Py_ForgetReference().  Let me know what you
think, Armin.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-12-14 15:36

Message:
Logged In: YES 
user_id=6656

Yikes!

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 15:32

Message:
Logged In: YES 
user_id=4771

A proposed fix for the later crash: the __dict__ descriptor of
user-defined classes should verify if there is another __dict__ descriptor
along the solid path of the type (i.e. following "tp_base" pointers).  If
so, it should delegate to it.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 14:49

Message:
Logged In: YES 
user_id=4771

Uh oh.  There is a much simpler crash.  The technique outlined in
deldict.py can be used to rebind or even delete the __dict__ attribute of
instances where it should normally not be allowed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-09-25 08:55

Message:
Logged In: YES 
user_id=4771

The bug is related to code like PyObject_GenericGetAttribute and
_PyType_Lookup which are not careful about the reference counters of the
objects they operate on.  This allows a much simpler crash (test67.py):
the __dict__ of an object can be decrefed away while lookdict() is looking
at it.  This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in
core routines like PyObject_GenericGetAttr.  We probably need to measure if
it has a performance impact, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:40:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:40:47 -0800
Subject: [ python-Bugs-1627039 ] mention side-lists from python-dev description
Message-ID: <E1HLS2x-0003Zf-6n@sc8-sf-web7.sourceforge.net>

Bugs item #1627039, was opened at 2007-01-03 15:06
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627039&group_id=5470

Please note that this 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
Private: No
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: mention side-lists from python-dev description

Initial Comment:
http://www.python.org/community/lists/ describes mailing lists for python, including python-dev.

Change:
"""
Note: python-dev is for work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems writing a Python program, please post to comp.lang.python.
"""

to

"""
Note: python-dev is for work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems writing a Python program, please post to comp.lang.python.  

If you want to discuss larger changes, please use python-ideas instead. http://mail.python.org/mailman/listinfo/python-ideas
"""

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:40

Message:
Logged In: YES 
user_id=31392
Originator: NO

http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets

It would be better to file a web site bug report.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627039&group_id=5470

From noreply at sourceforge.net  Sun Feb 25 23:48:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 14:48:10 -0800
Subject: [ python-Bugs-1620945 ] minor inconsistency in socket.close
Message-ID: <E1HLSA6-0008MZ-9T@sc8-sf-web5.sourceforge.net>

Bugs item #1620945, was opened at 2006-12-22 18:05
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1620945&group_id=5470

Please note that this 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
Private: No
Submitted By: Jonathan Ellis (ellisj)
Assigned to: Nobody/Anonymous (nobody)
Summary: minor inconsistency in socket.close

Initial Comment:
In python 2.5 socket.close, all methods are delegated to _dummy, which raises an error.  It would be more consistent to delegate each method to its counterpart in _closedsocket; in particular re-closing a closed socket is not intended to raise:

    def close(self):
        self._sock.close()
        self._sock = _closedsocket()
        for method in _delegate_methods:
            setattr(self, method, getattr(self._sock, method))


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:48

Message:
Logged In: YES 
user_id=31392
Originator: NO

Re-closing a socket does not raise an exception.  If there is something
else in your bug report that I am missing, please re-open it.


----------------------------------------------------------------------

Comment By: Mark Roberts (mark-roberts)
Date: 2007-01-20 01:51

Message:
Logged In: YES 
user_id=1591633
Originator: NO

On trunk:

>>> import socket
>>> s=socket.socket()
>>> s.close()
>>> s.close()
>>> 

It also seems that the following line will make even that remapping not
useful?  Isn't it better just to avoid the layer of indirection and
directly proceed with assigning to _dummy?

line 145: send = recv = recv_into = sendto = recvfrom = recvfrom_into =
_dummy

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1620945&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 00:27:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 15:27:36 -0800
Subject: [ python-Bugs-1668295 ] Strange unicode behaviour
Message-ID: <E1HLSmG-0001ot-3x@sc8-sf-web4.sourceforge.net>

Bugs item #1668295, was opened at 2007-02-25 11:10
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

Please note that this 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
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour

Initial Comment:

I know that python is very funny WRT unicode processing, but this defies all my knowledge.

I use the es_ES.UTF-8 encoding on linux. The script:


python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line.

However, if I redirect it to less or to a file, like

python -c "print unicode('? %s' % '??','utf8') " >test
Traceback (most recent call last):
  File "<string>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128)


Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases?

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-25 23:27

Message:
Logged In: YES 
user_id=849994
Originator: NO

> >>> sys.getfilesystemencoding()
> 'UTF-8'
>
> so python is really dumb if print does not know my filesystemencoding,
but
> knows my terminal encoding.

the file system encoding is the encoding of file names, not of file
content.

> I though breaking the least surprising behaviour was not considered
> pythonic, and now you tell me that having a program running on console
but
> issuing an exception when redirected is intended. I would prefer an
> exception in both cases. Or, even better, using
> sys.getfilesystemencoding(), or allowing me to set defaultencoding()

I agree that using the terminal encoding is perhaps a bit too DWIMish, but
you
can always get consistent results if you *do not write Unicode strings
anywhere*.

> Do you mean that I need to say print unicode(whatever).encode('utf8'),
> like:
> 
> >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and
> understand, even in files encoded as utf8. Assume this is a literal or
> input

No. You can directly put Unicode literals in your files, with u'...'.
For that to work, you need to tell Python the encoding your file has,
using the coding cookie (see the docs).

> ...
> >>> print unicode(a).encode('utf8') # because a could be a number, or a
> different object
> 
> every time, instead of "a='?'; print a"

> Cool, I'm starting to really love it. Concise and pythonic

> Are you seriously meaning that there is no way to tell print to use a
> default encoding, and it will magically try to find it and fail for
> everything not being a terminal?

This is not magic. "print" looks for an "encoding" attribute on the file
it is printing to. This is the terminal encoding for sys.stdout and None
for
other files.

> Are you seriously telling me that this is not a bug? Even worse, that
it
> is "intended behaviour". BTW, jython acts differently about this, in
all
> the versions I tried.

It *is* not a bug. This was implemented as a simplification for terminal
output.

> And with -S I am allowed to change the encoding, which is crippled in
site
> for no known good reason. 

> python -S -c "import sys; sys.setdefaultencoding('utf8'); print
> unicode('\xc3\xa1','utf8')" >test
> (works, test contains an accented a as intended

Because setdefaultencoding() affects *every* conversion from unicode to
string
and from string to unicode, which can be very confusing if you have to
handle
different encodings.


>>use Unicode everywhere inside the
>>program, and byte strings for input and output.

> Have you ever wondered that to use unicode everywhere inside the
program,
> one needs to decode literals (or input) to unicode (the next sentence
you
> complain about)?

Yes, you have to decode input (for files, you can do this automatically if
you
use codecs.open(), not builtin open()). No, you don't have to decode
literals as
Unicode literals exist.

> I follow this principle in my programming since about 6 years ago, so
I'm
> not a novice. I'm playing by the rules:
> a) "decodes it to unicode" is the first step to get it into processing.
> This is just a test case, so processing is zero.
> b) I refuse to believe that the only way to ensure something to be
printed
> right is wrapping every item into unicode(var).encode('utf8') [The
> redundant unicode call is because the var could be a number, or a
different
> object]

No, that is of course not the only way. An alternative is to use an
encoded file,
as the codecs module offers.

If you e.g. set

sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8')

you can print Unicode strings to stdout, and they will automatically be
converted
using utf-8. This is clear and explicit.

> c) or making my code non portable by patching site.py to get a real
> encoding instead of ascii.

If you still cannot live without setdefaultencoding(), you can do
reload(sys) to get
a sys module with this method.

Closing again.

----------------------------------------------------------------------

Comment By: Santiago Gala (sgala)
Date: 2007-02-25 22:27

Message:
Logged In: YES 
user_id=178886
Originator: YES

re: consistent, my experience it is that python unicode handling is
consistently stupid, doing almost always the wrong thing. It remembers me
of the defaults of WordPerfect, that were always exactly the opposite of
what the user wanted 99% of time. I hope python 3000 comes fast and stops
that real pain.

I love the language, but the way it handles unicode provokes hundreds of
bugs.

>Python could correctly find out your terminal
>encoding, the Unicode string is automatically encoded in that encoding.
>
>If you output to a file, Python does not know which encoding you want to
>have, so all Unicode strings are converted to ascii only.

>>> sys.getfilesystemencoding()
'UTF-8'

so python is really dumb if print does not know my filesystemencoding, but
knows my terminal encoding.

I though breaking the least surprising behaviour was not considered
pythonic, and now you tell me that having a program running on console but
issuing an exception when redirected is intended. I would prefer an
exception in both cases. Or, even better, using
sys.getfilesystemencoding(), or allowing me to set defaultencoding()

>Please direct further questions to the Python mailing list or newsgroup.

I would if I didn't consider this behaviour a bug, and a serious one. 

>The basic rule when handling Unicode is: use Unicode everywhere inside
the
>program, and byte strings for input and output.
>So, your code is exactly the other way round: it takes a byte string,
>decodes it to unicode and *then* prints it.
>
>You should do it the other way: use Unicode literals in your code, and
>when y(ou write something to a file, *encode* them in utf-8.

Do you mean that I need to say print unicode(whatever).encode('utf8'),
like:

>>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and
understand, even in files encoded as utf8. Assume this is a literal or
input
...
>>> print unicode(a).encode('utf8') # because a could be a number, or a
different object

every time, instead of "a='?'; print a"

Cool, I'm starting to really love it. Concise and pythonic

Are you seriously meaning that there is no way to tell print to use a
default encoding, and it will magically try to find it and fail for
everything not being a terminal?


Are you seriously telling me that this is not a bug? Even worse, that it
is "intended behaviour". BTW, jython acts differently about this, in all
the versions I tried.

And with -S I am allowed to change the encoding, which is crippled in site
for no known good reason. 

python -S -c "import sys; sys.setdefaultencoding('utf8'); print
unicode('\xc3\xa1','utf8')" >test
(works, test contains an accented a as intended


>use Unicode everywhere inside the
>program, and byte strings for input and output.

Have you ever wondered that to use unicode everywhere inside the program,
one needs to decode literals (or input) to unicode (the next sentence you
complain about)?

>So, your code is exactly the other way round: it takes a byte string,
>decodes it to unicode and *then* prints it.

I follow this principle in my programming since about 6 years ago, so I'm
not a novice. I'm playing by the rules:
a) "decodes it to unicode" is the first step to get it into processing.
This is just a test case, so processing is zero.
b) I refuse to believe that the only way to ensure something to be printed
right is wrapping every item into unicode(var).encode('utf8') [The
redundant unicode call is because the var could be a number, or a different
object]
c) or making my code non portable by patching site.py to get a real
encoding instead of ascii.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-25 19:43

Message:
Logged In: YES 
user_id=849994
Originator: NO

First of all: Python's Unicode handling is very consistent and
straightforward, if you know the basics. Sadly, most people don't know the
difference between Unicode and encoded strings.

What you're seeing is not a bug, it is due to the fact that if you print
Unicode to the console, and Python could correctly find out your terminal
encoding, the Unicode string is automatically encoded in that encoding.

If you output to a file, Python does not know which encoding you want to
have, so all Unicode strings are converted to ascii only.

Please direct further questions to the Python mailing list or newsgroup.

The basic rule when handling Unicode is: use Unicode everywhere inside the
program, and byte strings for input and output.
So, your code is exactly the other way round: it takes a byte string,
decodes it to unicode and *then* prints it.

You should do it the other way: use Unicode literals in your code, and
when you write something to a file, *encode* them in utf-8.

----------------------------------------------------------------------

Comment By: Santiago Gala (sgala)
Date: 2007-02-25 11:17

Message:
Logged In: YES 
user_id=178886
Originator: YES

Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn
trunk

Also, some people asks for repr of strings (I guess to reproduce if they
can't read the caracters). Those are printed in utf-8:

$python -c "print repr('? %s')"
'\xc3\xa1 %s'
$ python -c "print repr('?i')"
'\xc3\xa9i'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 07:10:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 22:10:45 -0800
Subject: [ python-Bugs-1667877 ] Install fails with no error
Message-ID: <E1HLZ4P-0000oJ-F8@sc8-sf-web1.sourceforge.net>

Bugs item #1667877, was opened at 2007-02-24 10:10
Message generated for change (Comment added) made by widgeteye
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

Please note that this 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: Wont Fix
Priority: 5
Private: No
Submitted By: larry (widgeteye)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install fails with no error

Initial Comment:
When I built python 2.5 for linux I did the normal: 
configure 
make 
make install 

Everything went fine til the "make install" part. It dies with no 
error. 
just says "install failed" after this: 

Compiling /usr/local/lib/python2.5/zipfile.py 

That part built fine but the next part failed. 
So what I did being the industrious fellow that I am I did: 

make -n install > out 

Took the out file and did: 

sh out 

That installed python without failure. 

Now if I do "make install" everything works fine. 

Weird eh?

----------------------------------------------------------------------

>Comment By: larry (widgeteye)
Date: 2007-02-26 00:10

Message:
Logged In: YES 
user_id=402539
Originator: YES

I think you missed the point I was trying to make. When I say "works fine"
I mean
that after I installed python using the shell script, then I could run
"make install" 
and it would complete the install using make without failure. 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-25 16:01

Message:
Logged In: YES 
user_id=21627
Originator: NO

I'm not finding it weird that the shell script completed. I doubt it
"works fine", though. Instead, some command in it failed, but the shell
doesn't abort in this case - make would abort.

Typically, when byte-compilation fails, it is because you have a file
byte-compiled that has a syntax error in it. Scroll through the entire
compileall output to see what the actual problem is.

Tentatively closing this as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 07:11:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 22:11:42 -0800
Subject: [ python-Bugs-1667877 ] Install fails with no error
Message-ID: <E1HLZ5K-0000uR-Ti@sc8-sf-web1.sourceforge.net>

Bugs item #1667877, was opened at 2007-02-24 10:10
Message generated for change (Comment added) made by widgeteye
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

Please note that this 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: Wont Fix
Priority: 5
Private: No
Submitted By: larry (widgeteye)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install fails with no error

Initial Comment:
When I built python 2.5 for linux I did the normal: 
configure 
make 
make install 

Everything went fine til the "make install" part. It dies with no 
error. 
just says "install failed" after this: 

Compiling /usr/local/lib/python2.5/zipfile.py 

That part built fine but the next part failed. 
So what I did being the industrious fellow that I am I did: 

make -n install > out 

Took the out file and did: 

sh out 

That installed python without failure. 

Now if I do "make install" everything works fine. 

Weird eh?

----------------------------------------------------------------------

>Comment By: larry (widgeteye)
Date: 2007-02-26 00:11

Message:
Logged In: YES 
user_id=402539
Originator: YES

I think you missed the point I was trying to make. When I say "works fine"
I mean
that after I installed python using the shell script, then I could run
"make install" 
and it would complete the install using make without failure. 

----------------------------------------------------------------------

Comment By: larry (widgeteye)
Date: 2007-02-26 00:10

Message:
Logged In: YES 
user_id=402539
Originator: YES

I think you missed the point I was trying to make. When I say "works fine"
I mean
that after I installed python using the shell script, then I could run
"make install" 
and it would complete the install using make without failure. 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-25 16:01

Message:
Logged In: YES 
user_id=21627
Originator: NO

I'm not finding it weird that the shell script completed. I doubt it
"works fine", though. Instead, some command in it failed, but the shell
doesn't abort in this case - make would abort.

Typically, when byte-compilation fails, it is because you have a file
byte-compiled that has a syntax error in it. Scroll through the entire
compileall output to see what the actual problem is.

Tentatively closing this as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 07:15:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 22:15:16 -0800
Subject: [ python-Bugs-1668133 ] python-2.4.4 on freebsd-6: _curses extension
	doesn't build
Message-ID: <E1HLZ8m-0006yV-Fv@sc8-sf-web2.sourceforge.net>

Bugs item #1668133, was opened at 2007-02-25 02:03
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

Please note that this 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: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: clemens fischer (inow)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.4 on freebsd-6: _curses extension doesn't build

Initial Comment:
'uname -rms'
FreeBSD 6.2-STABLE i386

'cc --version'
cc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

trying to build python-2.4.4 from ports/lang/python24, i get the
following messages, where earlier versions have been compiled and
installed w/o problems:

"./configure" stage:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the preprocessor's result
configure: WARNING: curses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for curses.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
checking ncurses.h usability... no
checking ncurses.h presence... yes
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h:     check for missing prerequisite headers?
configure: WARNING: ncurses.h: see the Autoconf documentation
configure: WARNING: ncurses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: ncurses.h: proceeding with the preprocessor's result
configure: WARNING: ncurses.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to http://www.python.org/python-bugs ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for ncurses.h... yes

the 'readline' extension builds fine, though:

building 'readline' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/readline.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o
cc -shared -pthread -O build/temp.freebsd-6.2-STABLE-i386-2.4/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.freebsd-6.2-STABLE-i386-2.4/readline.so

I also tried this command after noticing that freebsd needs some special
define for wchars:

$ make 'CFLAGS=-O -D__wchar_t=wchar_t' 'WITH_THREADS=YES' 'WITHOUT_IPV6=YES'
===>  Building for python24-2.4.4
case $MAKEFLAGS in  *-s*)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;;  *)  CC='cc' LDSHARED='cc -shared -pthread' OPT='-DNDEBUG -O' ./python -E ./setup.py build;;  esac
running build
running build_ext
db.h: found (4, 3) in /usr/local/include/db43
db.h: found (4, 4) in /usr/local/include/db44
db lib: using (4, 4) db-4.4
INFO: Can't locate Tcl/Tk libs and/or headers
building 'nis' extension
cc -DNDEBUG -O -fPIC -fno-strict-aliasing -I. -I/usr/ports/lang/python24/work/Python-2.4.4/./Include -I/usr/local/include -I/usr/ports/lang/python24/work/Python-2.4.4/Include -I/usr/ports/lang/python24/work/Python-2.4.4 -c /usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c -o build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c: In function `nis_cat':
/usr/ports/lang/python24/work/Python-2.4.4/Modules/nismodule.c:165: warning: assignment from incompatible pointer type
cc -shared -pthread -O -D__wchar_t=wchar_t build/temp.freebsd-6.2-STABLE-i386-2.4/nismodule.o -L/usr/local/lib -o build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so
*** WARNING: renaming "nis" since importing it failed: build/lib.freebsd-6.2-STABLE-i386-2.4/nis.so: Undefined symbol "yperr_string"
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/lang/python24/work/Python-2.4.4.
*** Error code 1


regards, clemens


----------------------------------------------------------------------

Comment By: clemens fischer (inow)
Date: 2007-02-25 23:25

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 loewis said:

> So should this be closed as 3rd-party bug, then?

that'll be a "roger" (beep).  3rd-party bug is the shortest precise
term. the problem had been discussed several times before. it doesn't
show up with the libncurses.* in the base system. as soon as another
package pulls in the "wrong" dependency, later builds can break.

regards, clemens


----------------------------------------------------------------------

Comment By: clemens fischer (inow)
Date: 2007-02-25 23:25

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 loewis said:

> So should this be closed as 3rd-party bug, then?

that'll be a "roger" (beep).  3rd-party bug is the shortest precise
term. the problem had been discussed several times before. it doesn't
show up with the libncurses.* in the base system. as soon as another
package pulls in the "wrong" dependency, later builds can break.

regards, clemens


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-25 22:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

So should this be closed as 3rd-party bug, then?

----------------------------------------------------------------------

Comment By: clemens fischer (inow)
Date: 2007-02-25 19:20

Message:
Logged In: YES 
user_id=71514
Originator: YES

on 2007-02-25 perky writes:

> The ncurses problem is already known and proven as a
> problem of FreeBSD.  And its ports have a workaround
> applied. (-D__wchar_t=wchar_t as you used.)

it may well be a problem of the port that the CFLAGS setting including
this define doesn't cary over into the built.

> The nis compilation error can be raised when your base system was
> built with NO_NIS=yes option.  But build process shouldn't segfault
> even after nis warning.

i noticed that the ports Makefile checks for the existance of
usr/bin/ypcat to decide if NIS support should be included.  i rebuilt
the fbsd world numerous times after the initial install from CD.  NIS
support is disabled on the machine in question, but the yp-programs were
never removed.  after deleting them, the NIS extension still gets built,
but the process doesn't segfault anymore.  the warnings do persist,
though.

> So, can you provide a backtrace of the core dumped for more
> investigation?

for this i would have to have a debug version of the fbsd base systems
gcc, as this is the program segfaulting.  this isn't feasable ATM.

i got another email from Rong-En Fan responding to my freebsd problem
report (1).  he advises to try building python24 after deleting the
development version of ncurses.  i just tried this:  it is the
workaround needed to make python-2.4.4 on fbsd-6.2.

thanks Rong-En Fan and perky!


regards, clemens


(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=109505


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2007-02-25 02:49

Message:
Logged In: YES 
user_id=55188
Originator: NO

The ncurses problem is already known and proven as a problem of FreeBSD. 
And its ports have a workaround applied. (-D__wchar_t=wchar_t as you
used.)

The nis compilation error can be raised when your base system was built
with NO_NIS=yes option.  But build process shouldn't segfault even after
nis warning.

So, can you provide a backtrace of the core dumped for more investigation?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668133&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 07:21:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Feb 2007 22:21:33 -0800
Subject: [ python-Bugs-1667877 ] Install fails with no error
Message-ID: <E1HLZEr-0007aY-Nv@sc8-sf-web2.sourceforge.net>

Bugs item #1667877, was opened at 2007-02-24 17:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

Please note that this 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: Wont Fix
Priority: 5
Private: No
Submitted By: larry (widgeteye)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install fails with no error

Initial Comment:
When I built python 2.5 for linux I did the normal: 
configure 
make 
make install 

Everything went fine til the "make install" part. It dies with no 
error. 
just says "install failed" after this: 

Compiling /usr/local/lib/python2.5/zipfile.py 

That part built fine but the next part failed. 
So what I did being the industrious fellow that I am I did: 

make -n install > out 

Took the out file and did: 

sh out 

That installed python without failure. 

Now if I do "make install" everything works fine. 

Weird eh?

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-02-26 07:21

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you reproduce the problem on your system? Can you give instructions on
how to reproduce it on another system? If not, I see little chance to
resolve this problem.

----------------------------------------------------------------------

Comment By: larry (widgeteye)
Date: 2007-02-26 07:11

Message:
Logged In: YES 
user_id=402539
Originator: YES

I think you missed the point I was trying to make. When I say "works fine"
I mean
that after I installed python using the shell script, then I could run
"make install" 
and it would complete the install using make without failure. 

----------------------------------------------------------------------

Comment By: larry (widgeteye)
Date: 2007-02-26 07:10

Message:
Logged In: YES 
user_id=402539
Originator: YES

I think you missed the point I was trying to make. When I say "works fine"
I mean
that after I installed python using the shell script, then I could run
"make install" 
and it would complete the install using make without failure. 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-25 23:01

Message:
Logged In: YES 
user_id=21627
Originator: NO

I'm not finding it weird that the shell script completed. I doubt it
"works fine", though. Instead, some command in it failed, but the shell
doesn't abort in this case - make would abort.

Typically, when byte-compilation fails, it is because you have a file
byte-compiled that has a syntax error in it. Scroll through the entire
compileall output to see what the actual problem is.

Tentatively closing this as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 09:23:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 00:23:04 -0800
Subject: [ python-Bugs-1658959 ] os.wait child process fail when under stress
Message-ID: <E1HLb8S-00085J-Ak@sc8-sf-web3.sourceforge.net>

Bugs item #1658959, was opened at 2007-02-13 14:44
Message generated for change (Comment added) made by thegroff
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470

Please note that this 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: Python 2.6
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: The Groff (thegroff)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.wait child process fail when under stress

Initial Comment:
when having high amount of threads forking, os.wait fails from time to time giving a "No child" error". If you retry, eventually it will work.

----------------------------------------------------------------------

>Comment By: The Groff (thegroff)
Date: 2007-02-26 09:23

Message:
Logged In: YES 
user_id=770948
Originator: YES

We were using linux kernel 2.4.21-37. I can then be a bug in the os. I'll
try to look deeper into it. 
Thanks

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-25 23:19

Message:
Logged In: YES 
user_id=33168
Originator: NO

Note that on some versions of Linux 2.4, calling wait() can return ECHILD
even when there is a child.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-13 16:57

Message:
Logged In: YES 
user_id=21627
Originator: NO

What operating system are you using? 

Why do you think this is a bug in Python and not in your operating
system?

Are you sure there are any unwaited-for children when ECHILD is returned?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 09:23:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 00:23:03 -0800
Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Message-ID: <E1HLb8R-0005cd-E1@sc8-sf-web1.sourceforge.net>

Bugs item #1303614, was opened at 2005-09-24 23:40
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

Please note that this 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: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bypassing __dict__ readonlyness

Initial Comment:
The __dict__ attribute of some objects is read-only,
e.g. for type objects.  However, there is a generic
way to still access and modify it (without hacking with
gc.get_referrents(), that is).  This can lead to
obscure crashes.  Attached is an example that shows
a potential "problem" involving putting strange keys
in the __dict__ of a type.

This is probably very minor anyway.  If we wanted to
fix this, we would need a __dict__ descriptor that
looks more cleverly at the object to which it is
applied.

BTW the first person who understand why the attached
program crashes gets a free coffee.

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2007-02-26 08:23

Message:
Logged In: YES 
user_id=4771
Originator: YES

456?  Now that's interesting.  Not 579?

I'm not sure if I ever thought about what the
expected answer should be, but I'd say that
you are correct: 'x.__dict__' should be empty
in the end.  Actually I don't really see how
it manages *not* to be empty in IronPython;
looks like either a very minor detail or a
deeper bug...

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:36

Message:
Logged In: YES 
user_id=31392
Originator: NO

I tried test67.py in IronPython.  It reports that x.hello has the value
456.  Is that the correct behavior?  It seems incorrect to me.  If the
__eq__ method is called, then the object should no longer have either the
Strange() or hello attributes.  They are cleared by reseting __dict__.  Is
that right?

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 22:23

Message:
Logged In: YES 
user_id=31392
Originator: NO

I tried test67.py in IronPython.  It reports that x.hello has the value
456.  Is that the correct behavior?  It seems incorrect to me.  If the
__eq__ method is called, then the object should no longer have either the
Strange() or hello attributes.  They are cleared by reseting __dict__.  Is
that right?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-06-30 07:05

Message:
Logged In: YES 
user_id=4771

Well, try making an "empty" class Foo(object): pass, and see
what magically shows up in Foo.__dict__.keys().  Here is the
__dict__ descriptor used for instances of Foo.  This
descriptor is connected to subtype_dict() and
subtype_setdict() in typeobject.c.

INCREF/DECREFs are in theory missing around every use of the
dictionary returned by _PyObject_GetDictPtr(), because more
or less any such use could remove the dict from the object
from which _PyObject_GetDictPtr() returned from, and so
decref the dict - while it's used.  This might require some
timing, to check the performance impact.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 01:14

Message:
Logged In: YES 
user_id=357491

OK, then I am going to need a little guidance to dive into
this more since this is going into some murky waters for me.  =)

For the normal, non-evil case of an empty Python class
(``class Foo(object): pass``), I would think that accessing
__dict__ would fall through to the tp_getset for object, and
then fall to the same slot for type.  Now that is obviously
not happening since you get a straight dict back for that
attribute access and not a dict proxy as would be suggested
based on my logic listed above.

So, my question is, where is the code that handles fetching
Foo().__dict__?  And if you have an inkling of where I
should be looking in terms of possible refcounting additions
that would be great as well.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-06-29 21:19

Message:
Logged In: YES 
user_id=4771

Brett: I think you're approaching the problem from the wrong
angle.  The problem is being allowed to freely tamper with
the dict stored in objects.  Getting NULL errors here and
there is only a symptom.  As I explain, the '__dict__'
descriptor object needs to do some more checks, and to be
fully safe some Py_INCREF/Py_DECREF are needed in some
critical places.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:45

Message:
Logged In: YES 
user_id=357491

For the deldict.py crasher, if you look at the traceback
there is no good place to do a check that tp_dict is sane
except in type_module() or PyDict_GetItem().  Now adding the
NULL check in type_module() will fix this specific problem,
but that seems like an ad-hoc patch.

Why don't we check for NULL in PyDict_GetItem() and return
NULL just like the PyDict_Check() test?  I am sure the
answer is "performance", but this is not PyDict_GETITEM()and
thus already is not the performance-critical version anyway.
 So why shouldn't we check for NULL there and possibly catch
other errors?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:41

Message:
Logged In: YES 
user_id=357491

Simple patch for the loosing_dict_ref.py crasher is
attached.  Just checked for possible NULL values in what is
needed by _Py_ForgetReference().  Let me know what you
think, Armin.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-12-14 15:36

Message:
Logged In: YES 
user_id=6656

Yikes!

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 15:32

Message:
Logged In: YES 
user_id=4771

A proposed fix for the later crash: the __dict__ descriptor of
user-defined classes should verify if there is another __dict__ descriptor
along the solid path of the type (i.e. following "tp_base" pointers).  If
so, it should delegate to it.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 14:49

Message:
Logged In: YES 
user_id=4771

Uh oh.  There is a much simpler crash.  The technique outlined in
deldict.py can be used to rebind or even delete the __dict__ attribute of
instances where it should normally not be allowed.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-09-25 08:55

Message:
Logged In: YES 
user_id=4771

The bug is related to code like PyObject_GenericGetAttribute and
_PyType_Lookup which are not careful about the reference counters of the
objects they operate on.  This allows a much simpler crash (test67.py): the
__dict__ of an object can be decrefed away while lookdict() is looking at
it.  This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in
core routines like PyObject_GenericGetAttr.  We probably need to measure if
it has a performance impact, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 13:15:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 04:15:07 -0800
Subject: [ python-Bugs-1068268 ] subprocess is not EINTR-safe
Message-ID: <E1HLel1-0005Ob-LN@sc8-sf-monitor2.sourceforge.net>

Bugs item #1068268, was opened at 2004-11-17 22:07
Message generated for change (Comment added) made by mpitt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470

Please note that this 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
Private: No
Submitted By: Peter ?strand (astrand)
Assigned to: Peter ?strand (astrand)
Summary: subprocess is not EINTR-safe

Initial Comment:
The subprocess module is not safe for use with signals,
because it doesn't retry the system calls upon EINTR.
However, as far as I understand it, this is true for
most other Python modules as well, so it isn't obvious
that the subprocess needs to be fixed. 

The problem was first noticed by John P Speno. 

----------------------------------------------------------------------

Comment By: Martin Pitt (mpitt)
Date: 2007-02-26 13:15

Message:
Logged In: YES 
user_id=80975
Originator: NO

I just got two different Ubuntu bug reports about this problem as well,
and I'm unsure how to circumvent this at the application level.

  http://librarian.launchpad.net/6514580/Traceback.txt
  http://librarian.launchpad.net/6527195/Traceback.txt

(from https://launchpad.net/bugs/87292 and its duplicate)

----------------------------------------------------------------------

Comment By: Matt Johnston (mattjohnston)
Date: 2004-12-22 08:07

Message:
Logged In: YES 
user_id=785805

I've hit this on a Solaris 9 box without explicitly using
signals. Using the DCOracle module, a seperate Oracle
process is executed. When this terminates, a SIGCHLD is sent
to the calling python process, which may be in the middle of
a select() in the communicate() call, causing EINTR. From
the output of truss (like strace), a sigchld handler doesn't
appear to be getting explicitly installed by the Oracle module.

SunOS 5.9 Generic_112233-01 sun4u sparc SUNW,Sun-Fire-280R

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2004-11-17 22:15

Message:
Logged In: YES 
user_id=344921

One way of testing subprocess for signal-safeness is to
insert these lines just after _cleanup():

import signal
signal.signal(signal.SIGALRM, lambda x,y: 1)
signal.alarm(1)
import time
time.sleep(0.99)

Then run test_subprocess.py. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 16:00:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 07:00:22 -0800
Subject: [ python-Bugs-1669182 ] PyErr_WriteUnraisable lacks exception type
	check
Message-ID: <E1HLhKw-00049r-Rj@sc8-sf-web5.sourceforge.net>

Bugs item #1669182, was opened at 2007-02-26 12: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=1669182&group_id=5470

Please note that this 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: Gabriel Becedillas (gbeced)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyErr_WriteUnraisable lacks exception type check

Initial Comment:
I'd hit an access violation inside PyErr_WriteUnraisable when a non-exception instance was raised. The call to PyExceptionClass_Name with a non-exception instance is yielding an invalid pointer.
I'd hit the bug embedding Python 2.5 and raising a string instance via PyThreadState_SetAsyncExc but I could also reproduce the crash with this sample code:

class Foo:
    def __del__(self):
        raise "pum"

a = Foo()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669182&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 16:28:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 07:28:07 -0800
Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda bodies
	correctly
Message-ID: <E1HLhln-0006rQ-Gy@sc8-sf-web5.sourceforge.net>

Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Comment added) made by yorick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

Please note that this 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: 6
Private: No
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly

Initial Comment:
eval() does not bind variables in lambda expressions
correctly:

>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in <lambda>
NameError: global name 'g' is not defined

The docs say this about eval():

# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.

and using plain local variables work as expected:

>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20

Also, if locals() is presented as the global dict to
eval(), it works:

>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34

but this does not allow the expression to reference
global variables of course.


----------------------------------------------------------------------

>Comment By: Mattias Engdeg?rd (yorick)
Date: 2007-02-26 16:28

Message:
Logged In: YES 
user_id=432579
Originator: YES

That is quite correct; standard Scheme does not have the ability to eval
expressions in a lexical environment. There are of course good performance
reasons for that (we don't want to keep all lexical environments around in
symbolic form, just in case someone would EVAL an expression referring to a
name inside one of them).

It would be fine for Python to have a similar rule, but now it's just
weirdly inconsistent.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 17:22

Message:
Logged In: YES 
user_id=31392
Originator: NO

I guess I should get back to this bug report at least once a year.  I'm
trying to understand how Scheme handles eval.  If I look at R5RS or R6RS, I
see that the eval procedure takes an environment as an argument.  The
procedures that create environment all seem to create variants of the
top-level environment (an empty environment, the interactive environment,
etc.).  I don't see any way to create an environment that contains the
bindings visible in a particular region of code.  Am I missing something?


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2006-04-03 19:36

Message:
Logged In: YES 
user_id=432579

Lest my last comment be interpreted as overly arrogant,
please  be assured that it was not meant as anything other
than an explanation of why I reported this as a bug in the
first place. I do understand that Python works the way it
does; I just want it to be even better. :-)


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2006-04-03 19:12

Message:
Logged In: YES 
user_id=432579

>The source of the problem is that scoping decisions are made
>statically.

No, because other languages with lexical scope and
permitting evaluation at runtime have no problem whatsoever
with this. They just answer the question:

Q: In what environment is the eval() argument evaluated?

typically in one of three ways:

A1. In an empty environment with no bindings at all, or just
the language-defined standard bindings.
A2. In the (or a) top-level environment; local, lexically
bound variables where the eval() takes place are not visible
to the argument expression.
A3. In the same lexical environment as the eval() call itself.

Perl and Ruby both say A3. Scheme (R5RS) lets the user
specify A1 or A2. Common Lisp answers A2.

Observe that none of the answers depend on what the
expression looks like.

Now, let's be crystal clear about this: The rules of where x
is looked up in the expressions

1) x

and

2) lambda: x

should reasonably be the same - after all, this is
fundamentally how lexical scoping works. And Python does
indeed work this way, to everybody's satisfaction.

In case 2), the evaluation of x is delayed, but that is
irrelevant; the decision of what x means is taken at the
same time in both cases, and the decision will be the same.

Most people would expect Python to answer question Q above
with one of the answers A1-3, but it does not, and it does
not document what the answer is. The Python answer is rather:

A4. A mixed hybrid environment of some kind: The identifiers
representing variables that are to be evaluated immediately
are looked up in the lexical environment of the eval
expression; identifiers representing variables in
delayed-evaluation positions use the global environment.

This answer is not very satisfactory and I'm inclined to
consider a design bug; it is different from what everyone
else does and not very intuitive. However, I can accept that
it is hard to change now for compatibility reasons. But this
answer A4 should be documented.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 17:44

Message:
Logged In: YES 
user_id=31392

The source of the problem is that scoping decisions are made
statically.  If a variable is determined to be local at
compile time, it can't be access as a free variable in
dynamically compiled code.  The compiler has already
determined that the variable is *not* free in the containing
function.  If a variable is free in a nested function, the
compiler treats it differently than if it is merely local to
the function.

In the most recent cases considered,
def f(x): eval('x') -- works because x is a local variable in f.
def f(g): eval('lambda x: g(x)') -- does not work because
the compiler has determined that g is not used a free
variable in f.  It isn't possible to change that static
analysis at runtime using eval or exec.

I agree that the documentation could be clearer here.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 04:46

Message:
Logged In: YES 
user_id=593130

"   def f(x): eval('x') works as expected and
    def f(g): eval('lambda x: g(x)') does not. Why?"

For the same reason
  def f(g,s): return eval(s)
 f(lambda x: x, 'lambda x: g(x)')(1)
and
  def g(x): return lambda: eval('x')
do not 'work'.  eval is a builtin C function whose behavior 
depends on its arguments (including the somewhat magical 
defaulting to globals(), local()) and not on its lexical position.

" Both are evaluated at the same time and use
the same environment to look up their variables."

No, the lambda in your second example introduces a new local 
namespace that is different from the one passed in.

" The fact that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping"

The delay and change of scoping are correlated. Evaluation is 
delayed because g is inside a lambda function def which 
introduces a new local scope which does not contain g, even 
though the original one did. 


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 03:55

Message:
Logged In: YES 
user_id=593130

After more carefully reading the eval doc in Lib Ref 2.1, I agree 
that it needs improvement.  My suggestions (assuming that my 
experiment-based inferences are correct):

In 
"The expression argument is parsed and evaluated as a Python 
expression (technically speaking, a condition list) using the 
globals and locals dictionaries as global and local name space."
insert "in a new top-level environment" before 'using'. This says 
right-off, even if indirectly, that lexical scoping does not work 
across the eval call.

In
"If the locals dictionary is omitted it defaults to the globals 
dictionary."
insert "only" after "If'.  If both are omitted, it does not so default.  
Add a comma after 'omitted', as in the next sentence.

In
"If both dictionaries are omitted, the expression is executed in 
the environment where eval is called."
replace  "the expression ... is called", which I believe to be 
incorrect as well as misleading, with something like "they default 
to current globals() and locals()."  This parallels the previous 
sentence and is, I believe, more correct.  Within a function, 
locals() is not the current local namespace, and the following 
shows that the difference can make a visible difference:

>>> def g1(): return op.setitem(locals(), 'x', 1), x
...
>>> g1()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in g1
NameError: global name 'x' is not defined
>>> def h1(): return eval("op.setitem(locals(), 'x', 1), x")
...
>>> h1()
(None, 1)

After
"The return value is the result of the evaluated expression. "
add something like
It does not depend on the lexical position of the eval call and 
hence the expression should not contain names that require 
lexical scoping reaching outside the eval call to be valid."

Note that eval scope blocking, the OP's pseudobug, does not 
require a lambda within the eval-ed expression:
>>> def f(x): return lambda: x
...
>>> f(1)()
1
>>> def g(x): return lambda: eval('x')
...
>>> g(1)()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined

This might be another example for the PEP.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-03 16:29

Message:
Logged In: YES 
user_id=80475

Jeremy, would you update the pep and docs to cover the OP's
examples.



----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-03 12:16

Message:
Logged In: YES 
user_id=432579

>No, this issue is not specific to either eval or lambda:

Right, so let me rephrase: The bug occurs when explicitly
evaluating a lambda expression or function definition
statement using eval or exec. (This is an artifact of
Python's strong separation of statements and expressions.)

If this is done "by design", why cannot I find anything
anywhere describing this? If this is just a documentation
oversight, please say so, but then I would also like to have
an explanation of the behaviour.

The fact remains that

    def f(x): eval('x')

works as expected and

    def f(g): eval('lambda x: g(x)')

does not. Why? Both are evaluated at the same time and use
the same environment to look up their variables. The fact
that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping, because that is how
lambda expressions work.

>If you want Python to work 
>differently, write a PEP or a patch, or raise the question in
>the newsgroup/mailing list.

www.python.org told me that this is the place to report bugs
in Python. If that is wrong, we should change the web site.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-02 23:59

Message:
Logged In: YES 
user_id=593130

No, this issue is not specific to either eval or lambda:

>>> def f(g):
...   exec 'def h(x): return g(x)'
...   return h
...
>>> f(lambda y: y * 2)(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in h
NameError: global name 'g' is not defined

It is specific to creating a function at top-level in a separate 
execution environment, as done, by design, by both eval and 
exec, and with either a def statement or lambda abbreviation 
thereof.

In Python, lexical scoping works because nested functions are 
compiled along with the outer function, so that scoped variables 
can be identified and both functions adjusted so that the coupling 
works.  In particular, the scoped variable has to not be deleted 
when the outer function returns.  Eval/exec compile their string 
only later, when the function is called.

"it works that way because it is the way it works".
Those are your words, not mine.  If you want Python to work 
differently, write a PEP or a patch, or raise the question in the 
newsgroup/mailing list. I'm done discussing it here.

----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-02 17:42

Message:
Logged In: YES 
user_id=432579

No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 01:20

Message:
Logged In: YES 
user_id=1230541

Obviously I forgot a statement in my previous comment's 
code example. So here's the complete version:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your 
expected implementation?


----------------------------------------------------------------------

Comment By: Branko (bbange)
Date: 2005-03-02 01:15

Message:
Logged In: YES 
user_id=1230541

I think this issue is not special for eval and can be also 
reproduced with a def statement. The point is that at function 
definition time Python does not do any variable binding 
concerning variables not local to the function. Instead Python 
looks for that variable in the namespace of the module in 
which the function was created at the time the function is 
executed. Python determines that module by evaluating the 
variable __module__ at function definition time and 
remembers it by setting the function attribute with the same 
name. That's why only the variable __module__ is relevant at 
function definition time. Simply put, Python does only do a 
module level variable binding at function definition time. This 
is simple and sensible. If you don't agree consider this:

n=2
def f(x): return n*x
del n
f(2) 
# the Python implementation will result in a name error here. 
But what should happen if Python had bound variable n at the 
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your 
expected implementation?

As you see, changing the implementation would either make 
Pythons semantics more complicated or would remove much 
of Pythons dynanism.




----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 19:26

Message:
Logged In: YES 
user_id=432579

What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if  I have missed something.

All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.

I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.

>#  From your comments, I suspect you expect 0.

Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.

None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 18:29

Message:
Logged In: YES 
user_id=593130

Whoops.  eval('x') ==  x as code snippets has an exception, 
which is the one tripping you up.  When the eval is within a 
function definition (and lambda expressions are abbreviated 
simple function definitions) and 'x' contains a function definition, 
then the body of the contained function definition does not have 
access, when it is run, to the locals of the containing function 
(the lexical scope), whereas it will when x is compiled directly *as 
part of the containing function body*.  eval('x') removes x from 
that part of its context.  eval only has the simple two-level 
globals/locals environment, which can be anything the caller 
passes in, so it compiles x as if it were top-level code.  Hence 
free variables in contained functions are looked up in the global 
passed to  eval when the evaled function is called.

This issue has been discussed on the Python newsgroup/mailing 
list more than once.  If my explanation is not clear, you might be 
able to find others in Google c.l.p archives.  Do consider that 
core functions which have been debugged for over a decade are 
unlike to have many bugs left, although the docs are still being 
improved.

While Python's scoping is lexical, its free variable binding is late.
Consider
>>> def f():
...   x = 0
...   def g(): print x
...   x = 1
...   return g
...
>>> f()()
# What gets printed? 0 or 1?
#  From your comments, I suspect you expect 0.
#  Irregardless, it is
1

Similarly
>>> f()()
1
>>> d={'x': 0}
>>> h=eval('lambda: x', d, d)
>>> h()
0
>>> d['x'] = 1
>>> h()
# now what gets printed?
1


----------------------------------------------------------------------

Comment By: Mattias Engdeg?rd (yorick)
Date: 2005-03-01 10:11

Message:
Logged In: YES 
user_id=432579

>Variables in Python functions are resolved 
>when the function is *called*, not when it is defined.

I'm not sure what you mean by that, since Python obeys
lexical scoping, not dynamic.Consider:

def f(x): lambda y: x + y

When the inner lambda expression above is evaluated, x
inside the lambda body is bound to the parameter of the call
of f, even if x+y is not evaluated until that function is
called.
So since

def f(x): return eval('x')

fetches its definition of x from the lexical variable x, why
shouldn't

def f(g): return eval('lambda x: g(x)')

fetch its definition of g from the lexical variable g? A
lambda expression is just a way of delaying evaluation,
*not* delaying how variables are bound --- this is done
immediately.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 06:30

Message:
Logged In: YES 
user_id=593130

I am 99.5% sure that this is 'invalid' (a Resolution category) and 
should be closed.  With the default environment, eval('x') is the 
same as unquoted x.  Variables in Python functions are resolved 
when the function is *called*, not when it is defined.  There is no 
resolution for g in the default globals.  Eval does not change this.  
The NameError is exactly correct.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 18:26:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 09:26:14 -0800
Subject: [ python-Bugs-1669304 ] Clarify PyMem_Realloc and PyMem_Resize docs
Message-ID: <E1HLjc6-0001ma-Gx@sc8-sf-web5.sourceforge.net>

Bugs item #1669304, was opened at 2007-02-26 10: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=1669304&group_id=5470

Please note that this 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: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clarify PyMem_Realloc and PyMem_Resize docs

Initial Comment:
This should close 1668036 and 1668032 which both looked like valid doc patch requests. The pymem_resize patch indicates the PyMem_Resize assigns to p (its first argument), and the pymem_realloc patch indicates that PyMem_Realloc will not modify the pointer if the realloc fails.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 18:26:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 09:26:36 -0800
Subject: [ python-Bugs-1669304 ] Clarify PyMem_Realloc and PyMem_Resize docs
Message-ID: <E1HLjcS-0002tu-2b@sc8-sf-web6.sourceforge.net>

Bugs item #1669304, was opened at 2007-02-26 10:26
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470

Please note that this 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: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clarify PyMem_Realloc and PyMem_Resize docs

Initial Comment:
This should close 1668036 and 1668032 which both looked like valid doc patch requests. The pymem_resize patch indicates the PyMem_Resize assigns to p (its first argument), and the pymem_realloc patch indicates that PyMem_Realloc will not modify the pointer if the realloc fails.

----------------------------------------------------------------------

>Comment By: Steven Bethard (bediviere)
Date: 2007-02-26 10:26

Message:
Logged In: YES 
user_id=945502
Originator: YES

File Added: pymem_realloc.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 18:37:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 09:37:03 -0800
Subject: [ python-Bugs-1665333 ] Documentation missing for OptionGroup class
	in optparse 
Message-ID: <E1HLjmZ-0003uj-7F@sc8-sf-web6.sourceforge.net>

Bugs item #1665333, was opened at 2007-02-21 08:40
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470

Please note that this 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
Private: No
Submitted By: LunarYorn (lunar_yorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Documentation missing for OptionGroup class in optparse 

Initial Comment:
Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul.

In detail documentation of the following classes and methods in optparse is missing:

- OptionGroup
- OptionParser.add_option_group
- OptionParser.get_option_group

These classes and methods also lack docstrings.

I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2007-02-26 10:37

Message:
Logged In: YES 
user_id=945502
Originator: NO

The docstrings need to be modified in the Optik package (from which the
stdlib optparse module is derived). I've filed you an appropriate patch
there:
http://sourceforge.net/tracker/index.php?func=detail&aid=1669315&group_id=38019&atid=421097.
I'll see what I can do about adding some documentation. My preference is
only to document OptionParser.add_option_group -- I think making the
OptionGroup API public is a mistake (like making the STORE_ACTIONS, etc.
APIs public was).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 18:39:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 09:39:35 -0800
Subject: [ python-Bugs-1665333 ] Documentation missing for OptionGroup class
	in optparse 
Message-ID: <E1HLjp1-0004Mb-K7@sc8-sf-monitor2.sourceforge.net>

Bugs item #1665333, was opened at 2007-02-21 08:40
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470

Please note that this 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
Private: No
Submitted By: LunarYorn (lunar_yorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Documentation missing for OptionGroup class in optparse 

Initial Comment:
Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul.

In detail documentation of the following classes and methods in optparse is missing:

- OptionGroup
- OptionParser.add_option_group
- OptionParser.get_option_group

These classes and methods also lack docstrings.

I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2007-02-26 10:39

Message:
Logged In: YES 
user_id=945502
Originator: NO

Looks like the optparse docs are also auto-generated from optik. Here's
the first line of liboptparse.tex:

% THIS FILE IS AUTO-GENERATED!  DO NOT EDIT!

So I guess this needs to be handled in the optparse bugs.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2007-02-26 10:37

Message:
Logged In: YES 
user_id=945502
Originator: NO

The docstrings need to be modified in the Optik package (from which the
stdlib optparse module is derived). I've filed you an appropriate patch
there:
http://sourceforge.net/tracker/index.php?func=detail&aid=1669315&group_id=38019&atid=421097.
I'll see what I can do about adding some documentation. My preference is
only to document OptionParser.add_option_group -- I think making the
OptionGroup API public is a mistake (like making the STORE_ACTIONS, etc.
APIs public was).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 18:46:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 09:46:00 -0800
Subject: [ python-Bugs-1665333 ] Documentation missing for OptionGroup class
	in optparse 
Message-ID: <E1HLjvE-0004v6-5b@sc8-sf-web11.sourceforge.net>

Bugs item #1665333, was opened at 2007-02-21 16:40
Message generated for change (Comment added) made by lunar_yorn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470

Please note that this 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
Private: No
Submitted By: LunarYorn (lunar_yorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Documentation missing for OptionGroup class in optparse 

Initial Comment:
Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul.

In detail documentation of the following classes and methods in optparse is missing:

- OptionGroup
- OptionParser.add_option_group
- OptionParser.get_option_group

These classes and methods also lack docstrings.

I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug.

----------------------------------------------------------------------

>Comment By: LunarYorn (lunar_yorn)
Date: 2007-02-26 18:45

Message:
Logged In: YES 
user_id=1485244
Originator: YES

Thanks for filing the patch there!  I didn't know, that optparse is
developt outside of Python...

Anyway I think you're right not to comment the whole api.  I did not
intend that.  I would be content with a little note in the docs quickly
explains OptionGroups and how to create them.  More shouldn't be told,
since they are only useful for formatting help output.

I just needed such a thing for my recent project and was short of
overwriting the OptionParser and HelpFormatter classes.  For that purpose I
looked into the sources, where I found the OptionGroup capabilities.  A
little note would have shortened the development of the option parsing code
quite a bit... ;)

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2007-02-26 18:39

Message:
Logged In: YES 
user_id=945502
Originator: NO

Looks like the optparse docs are also auto-generated from optik. Here's
the first line of liboptparse.tex:

% THIS FILE IS AUTO-GENERATED!  DO NOT EDIT!

So I guess this needs to be handled in the optparse bugs.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2007-02-26 18:37

Message:
Logged In: YES 
user_id=945502
Originator: NO

The docstrings need to be modified in the Optik package (from which the
stdlib optparse module is derived). I've filed you an appropriate patch
there:
http://sourceforge.net/tracker/index.php?func=detail&aid=1669315&group_id=38019&atid=421097.
I'll see what I can do about adding some documentation. My preference is
only to document OptionParser.add_option_group -- I think making the
OptionGroup API public is a mistake (like making the STORE_ACTIONS, etc.
APIs public was).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 18:53:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 09:53:26 -0800
Subject: [ python-Bugs-1669331 ] document that shutil.copyfileobj does not
	seek()
Message-ID: <E1HLk2Q-0002cY-9N@sc8-sf-web9.sourceforge.net>

Bugs item #1669331, was opened at 2007-02-26 10:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470

Please note that this 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: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: document that shutil.copyfileobj does not seek()

Initial Comment:
This should close bug 1656578 which asks for documentation that shutil.copyfileobj() copies only from the current file position to the end of the file. While this is standard behavior for pretty much any function that accepts a file-like object, the phrase "the contents of the file-like object" could be confusing. The patch adds a little clarification text.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 18:54:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 09:54:41 -0800
Subject: [ python-Bugs-1669331 ] document that shutil.copyfileobj does not
	seek()
Message-ID: <E1HLk3d-0004W1-8Q@sc8-sf-web5.sourceforge.net>

Bugs item #1669331, was opened at 2007-02-26 10:53
Message generated for change (Settings changed) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470

Please note that this 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: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: document that shutil.copyfileobj does not seek()

Initial Comment:
This should close bug 1656578 which asks for documentation that shutil.copyfileobj() copies only from the current file position to the end of the file. While this is standard behavior for pretty much any function that accepts a file-like object, the phrase "the contents of the file-like object" could be confusing. The patch adds a little clarification text.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 19:22:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 10:22:02 -0800
Subject: [ python-Bugs-1669349 ] make install fails if no previous Python
	installation
Message-ID: <E1HLkU6-0000G3-A9@sc8-sf-web4.sourceforge.net>

Bugs item #1669349, was opened at 2007-02-26 19: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=1669349&group_id=5470

Please note that this 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
Private: No
Submitted By: Matthias S. Benkmann (mbenkmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails if no previous Python installation

Initial Comment:
When installing Python 2.5 on a completely Python-less system 'make install' failed. The error that caused the failure was

Compiling /usr/lib/python2.5/test/test_multibytecodec.py ...
Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",)
[snip]
Compiling /usr/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1

'find -name unicodedata.so' showed me that the library did not exist in the build tree. However, after a 'make -i install' to force make to continue despite the error, unicodedata.so was there. So apparently the library is not built until a later stage of make install. And indeed, subsequent 'make install' calls without -i were successful. 

It is important to note that if you have a previous Python installation (at least of the same version), 'make install' will go through, because it'll load the library from there. So if you want to reproduce the issue you will have to install from a freshly unpacked tarball on a system with no Python installation.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 19:41:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 10:41:48 -0800
Subject: [ python-Bugs-1569356 ] sys.settrace cause curried parms to show up
	as attributes
Message-ID: <E1HLknE-0007So-4y@sc8-sf-web9.sourceforge.net>

Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Comment added) made by jhylton
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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: applebucks (scott_marks)
Assigned to: Jeremy Hylton (jhylton)
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: Jeremy Hylton (jhylton)
Date: 2007-02-26 18:41

Message:
Logged In: YES 
user_id=31392
Originator: NO

Fixed in rev. 53954.  Not sure if this should be backported.


----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2007-02-25 18:23

Message:
Logged In: YES 
user_id=366566
Originator: NO

Ahem.

Code coverage tools run afoul of this bug as well.  A common case is to
run coverage tools using a test suite.  If this bug is triggered, then the
resulting coverage data isn't valid.


----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2007-02-25 18:21

Message:
Logged In: YES 
user_id=366566
Originator: NO

Code coverage tools run afoul

----------------------------------------------------------------------

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  Mon Feb 26 19:45:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 10:45:25 -0800
Subject: [ python-Bugs-810714 ] nested variables in 'class:' statements
Message-ID: <E1HLkqj-00018t-Fa@sc8-sf-web5.sourceforge.net>

Bugs item #810714, was opened at 2003-09-22 17:05
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

Please note that this 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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: nested variables in 'class:' statements

Initial Comment:
from the user's point of view, variables originating
from nested scopes could erratically become bound in
the 'class' statement.

The 'class:' statements works by capturing all locals()
after executing the body; however, this is not exactly
the same as what an explicit call to locals() would
return because of the missing PyFrame_FastToLocals()
call in the implementation of LOAD_LOCALS in ceval.c.
It was thought that PyFrame_FastToLocals() was
unnecessary at that point because the class body
bytecode only uses LOAD_NAME/STORE_NAME and not fast
locals -- but this is no longer true with nested
scopes. See attached examples.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-26 18:45

Message:
Logged In: YES 
user_id=31392
Originator: NO

Committed revision 53954.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 20:36

Message:
Logged In: YES 
user_id=31392
Originator: NO

I'm not sure I understand all the implications of nested variables,
either.  The current behavior of locals() is to return the names of all
free variables that are being passed through the class body so that they
can be used by methods.  Is the behavior correct?  I see that IronPython
implements locals() that way, but does not bind them as class variables
(good).  Should we change the "spec" of locals() and cause IronPython to be
incompatible, or should we fix CPython and PyPy to behave the same way? 
The fix for CPython will be somewhat involved.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 20:35

Message:
Logged In: YES 
user_id=31392
Originator: NO

I'm not sure I understand all the implications of nested variables,
either.  The current behavior of locals() is to return the names of all
free variables that are being passed through the class body so that they
can be used by methods.  Is the behavior correct?  I see that IronPython
implements locals() that way, but does not bind them as class variables
(good).  Should we change the "spec" of locals() and cause IronPython to be
incompatible, or should we fix CPython and PyPy to behave the same way? 
The fix for CPython will be somewhat involved.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-01-08 17:13

Message:
Logged In: YES 
user_id=4771

Attached is a draft.  I am not sure that I understand all the implications
of nested variables in the presence of class bodies, so please don't check
in this patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-09-24 12:47

Message:
Logged In: YES 
user_id=4771

I'm not sure how to solve this. I could make a patch to
LOAD_LOCALS to prevent free variables from showing up in the
class.__dict__. For the 2nd problem I'm not familiar enough
with compile.c to know how to make the binding 'b=&quot;foo&quot;'
sufficient to prevent 'b' from also being considered free in
the class definition (which is what occurs).

Note also that bare 'exec' statements should then be
forbidden in class definitions in the presence of free
variables, for the same reason as it is forbidden in
functions: you cannot tell whether a variable is free or
local.

As an example of this, if in the attached example we replace
b=&quot;foo&quot; with exec 'b=&quot;foo&quot;' then the last print
correctly
outputs 'foo' instead of 6 but what actually occurs is that
the value of the argument b in f(a,b) was modified by the
class definition -- it is a way to change the binding of a
variable in an enclosing frame, which should not be
possible.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 19:16

Message:
Logged In: YES 
user_id=80475

Do you have a proposed patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

From noreply at sourceforge.net  Mon Feb 26 23:18:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 14:18:17 -0800
Subject: [ python-Bugs-1669498 ] 2.4.4 Logging LogRecord attributes broken
Message-ID: <E1HLoAj-0006Tj-5r@sc8-sf-web6.sourceforge.net>

Bugs item #1669498, was opened at 2007-02-26 15: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=1669498&group_id=5470

Please note that this 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: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken

Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.) 

#!/usr/bin/env python
import logging

logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)

logger.info("Yo")


On 2.4.3 I get
INFO     tmplogger 11 Yo

On 2.4.4 I get
INFO     __init__ 1072 Yo


The versions are 

Python 2.4.3 (#2, Oct  6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

and

Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 00:50:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 15:50:53 -0800
Subject: [ python-Bugs-1669182 ] PyErr_WriteUnraisable lacks exception type
	check
Message-ID: <E1HLpcL-00080I-Jh@sc8-sf-web11.sourceforge.net>

Bugs item #1669182, was opened at 2007-02-26 07:00
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669182&group_id=5470

Please note that this 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: Gabriel Becedillas (gbeced)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: PyErr_WriteUnraisable lacks exception type check

Initial Comment:
I'd hit an access violation inside PyErr_WriteUnraisable when a non-exception instance was raised. The call to PyExceptionClass_Name with a non-exception instance is yielding an invalid pointer.
I'd hit the bug embedding Python 2.5 and raising a string instance via PyThreadState_SetAsyncExc but I could also reproduce the crash with this sample code:

class Foo:
    def __del__(self):
        raise "pum"

a = Foo()


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-26 15:50

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the report.  The print is kinda crappy, but it shouldn't
crash.

Committed revision 53974. (2.5)
Committed revision 53975. (2.6)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669182&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 00:57:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 15:57:25 -0800
Subject: [ python-Bugs-1669578 ] 2.4.4 Logging LogRecord attributes broken
Message-ID: <E1HLpif-0006qu-4b@sc8-sf-web5.sourceforge.net>

Bugs item #1669578, was opened at 2007-02-26 16:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669578&group_id=5470

Please note that this 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: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken

Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.) 

#!/usr/bin/env python
import logging

logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)

logger.info("Yo")


On 2.4.3 I get
INFO     tmplogger 11 Yo

On 2.4.4 I get
INFO     __init__ 1072 Yo


The versions are 

Python 2.4.3 (#2, Oct  6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

and

Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669578&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 04:14:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 19:14:20 -0800
Subject: [ python-Bugs-1669637 ] Some Compiler Warnings on VC6
Message-ID: <E1HLsnE-0007EK-IE@sc8-sf-web3.sourceforge.net>

Bugs item #1669637, was opened at 2007-02-27 12: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=1669637&group_id=5470

Please note that this 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
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Some Compiler Warnings on VC6

Initial Comment:
I got some warnings on VC6. Probably these are not so
problematic, but anyway I reported.

C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\winbase.h(53) : warning C4005: 'Yield' : macro was redefined.
        ..\..\Include\Python-ast.h(449) : Please check previous definition of 'Yield'

E:\python-dev\release-maint25\Objects\intobject.c(994) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer.

E:\python-dev\release-maint25\Objects\stringobject.c(859) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer.

E:\python-dev\release-maint25\Modules\audioop.c(1263) : warning C4761: The base types of the actual and formal parameters of a function were different.
The compiler converted the actual parameter to the type of the formal parameter.

E:\python-dev\release-maint25\Modules\audioop.c(1331) : warning C4761: The base types of the actual and formal parameters of a function were different.
The compiler converted the actual parameter to the type of the formal parameter.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 04:15:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 19:15:03 -0800
Subject: [ python-Bugs-1669637 ] Some Compiler Warnings on VC6
Message-ID: <E1HLsnv-0001be-Fu@sc8-sf-web8.sourceforge.net>

Bugs item #1669637, was opened at 2007-02-27 12:14
Message generated for change (Settings changed) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470

Please note that this 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: 2
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Some Compiler Warnings on VC6

Initial Comment:
I got some warnings on VC6. Probably these are not so
problematic, but anyway I reported.

C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\winbase.h(53) : warning C4005: 'Yield' : macro was redefined.
        ..\..\Include\Python-ast.h(449) : Please check previous definition of 'Yield'

E:\python-dev\release-maint25\Objects\intobject.c(994) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer.

E:\python-dev\release-maint25\Objects\stringobject.c(859) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer.

E:\python-dev\release-maint25\Modules\audioop.c(1263) : warning C4761: The base types of the actual and formal parameters of a function were different.
The compiler converted the actual parameter to the type of the formal parameter.

E:\python-dev\release-maint25\Modules\audioop.c(1331) : warning C4761: The base types of the actual and formal parameters of a function were different.
The compiler converted the actual parameter to the type of the formal parameter.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 04:28:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 19:28:48 -0800
Subject: [ python-Bugs-1669646 ] 2.4.4 Logging LogRecord attributes broken
Message-ID: <E1HLt1E-0001HT-Lm@sc8-sf-web7.sourceforge.net>

Bugs item #1669646, was opened at 2007-02-26 20:28
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=1669646&group_id=5470

Please note that this 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: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken

Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.) 

#!/usr/bin/env python
import logging

logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)

logger.info("Yo")


On 2.4.3 I get
INFO     tmplogger 11 Yo

On 2.4.4 I get
INFO     __init__ 1072 Yo


The versions are 

Python 2.4.3 (#2, Oct  6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

and

Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669646&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 06:41:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 21:41:52 -0800
Subject: [ python-Bugs-1669646 ] 2.4.4 Logging LogRecord attributes broken
Message-ID: <E1HLv60-0003y1-Ao@sc8-sf-monitor2.sourceforge.net>

Bugs item #1669646, was opened at 2007-02-26 19:28
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669646&group_id=5470

Please note that this 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: Duplicate
Priority: 5
Private: No
Submitted By: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken

Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.) 

#!/usr/bin/env python
import logging

logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)

logger.info("Yo")


On 2.4.3 I get
INFO     tmplogger 11 Yo

On 2.4.4 I get
INFO     __init__ 1072 Yo


The versions are 

Python 2.4.3 (#2, Oct  6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

and

Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-26 21:41

Message:
Logged In: YES 
user_id=33168
Originator: NO

Dupe of 1669498.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669646&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 06:42:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 21:42:19 -0800
Subject: [ python-Bugs-1669578 ] 2.4.4 Logging LogRecord attributes broken
Message-ID: <E1HLv6R-0002CN-O1@sc8-sf-web4.sourceforge.net>

Bugs item #1669578, was opened at 2007-02-26 15:57
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669578&group_id=5470

Please note that this 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: Duplicate
Priority: 5
Private: No
Submitted By: Glenn Murray (murrayg)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.4 Logging LogRecord attributes broken

Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.) 

#!/usr/bin/env python
import logging

logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)

logger.info("Yo")


On 2.4.3 I get
INFO     tmplogger 11 Yo

On 2.4.4 I get
INFO     __init__ 1072 Yo


The versions are 

Python 2.4.3 (#2, Oct  6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

and

Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-26 21:42

Message:
Logged In: YES 
user_id=33168
Originator: NO

Dupe of 1669498.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669578&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 08:23:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 23:23:58 -0800
Subject: [ python-Bugs-810714 ] nested variables in 'class:' statements
Message-ID: <E1HLwgo-0001uT-07@sc8-sf-web5.sourceforge.net>

Bugs item #810714, was opened at 2003-09-22 17:05
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

Please note that this 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.3
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: nested variables in 'class:' statements

Initial Comment:
from the user's point of view, variables originating
from nested scopes could erratically become bound in
the 'class' statement.

The 'class:' statements works by capturing all locals()
after executing the body; however, this is not exactly
the same as what an explicit call to locals() would
return because of the missing PyFrame_FastToLocals()
call in the implementation of LOAD_LOCALS in ceval.c.
It was thought that PyFrame_FastToLocals() was
unnecessary at that point because the class body
bytecode only uses LOAD_NAME/STORE_NAME and not fast
locals -- but this is no longer true with nested
scopes. See attached examples.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2007-02-27 07:23

Message:
Logged In: YES 
user_id=4771
Originator: YES

Jeremy, you inserted many spaces instead of tabs
in frameobject.c.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-26 18:45

Message:
Logged In: YES 
user_id=31392
Originator: NO

Committed revision 53954.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 20:36

Message:
Logged In: YES 
user_id=31392
Originator: NO

I'm not sure I understand all the implications of nested variables,
either.  The current behavior of locals() is to return the names of all
free variables that are being passed through the class body so that they
can be used by methods.  Is the behavior correct?  I see that IronPython
implements locals() that way, but does not bind them as class variables
(good).  Should we change the "spec" of locals() and cause IronPython to be
incompatible, or should we fix CPython and PyPy to behave the same way? 
The fix for CPython will be somewhat involved.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-25 20:35

Message:
Logged In: YES 
user_id=31392
Originator: NO

I'm not sure I understand all the implications of nested variables,
either.  The current behavior of locals() is to return the names of all
free variables that are being passed through the class body so that they
can be used by methods.  Is the behavior correct?  I see that IronPython
implements locals() that way, but does not bind them as class variables
(good).  Should we change the "spec" of locals() and cause IronPython to be
incompatible, or should we fix CPython and PyPy to behave the same way? 
The fix for CPython will be somewhat involved.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-01-08 17:13

Message:
Logged In: YES 
user_id=4771

Attached is a draft.  I am not sure that I understand all the implications
of nested variables in the presence of class bodies, so please don't check
in this patch.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-09-24 12:47

Message:
Logged In: YES 
user_id=4771

I'm not sure how to solve this. I could make a patch to
LOAD_LOCALS to prevent free variables from showing up in the
class.__dict__. For the 2nd problem I'm not familiar enough
with compile.c to know how to make the binding 'b=&quot;foo&quot;'
sufficient to prevent 'b' from also being considered free in
the class definition (which is what occurs).

Note also that bare 'exec' statements should then be
forbidden in class definitions in the presence of free
variables, for the same reason as it is forbidden in
functions: you cannot tell whether a variable is free or
local.

As an example of this, if in the attached example we replace
b=&quot;foo&quot; with exec 'b=&quot;foo&quot;' then the last print
correctly
outputs 'foo' instead of 6 but what actually occurs is that
the value of the argument b in f(a,b) was modified by the
class definition -- it is a way to change the binding of a
variable in an enclosing frame, which should not be
possible.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-22 19:16

Message:
Logged In: YES 
user_id=80475

Do you have a proposed patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 08:32:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Feb 2007 23:32:52 -0800
Subject: [ python-Bugs-1669743 ] Python needs a way to detect implementation
Message-ID: <E1HLwpQ-0000iK-2F@sc8-sf-web4.sourceforge.net>

Bugs item #1669743, was opened at 2007-02-27 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=1669743&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kay Hayen (kayhayen2)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python needs a way to detect implementation

Initial Comment:
Hello,

I am currently writing an application that will run under both CPython and PyPy. In this I encountered the need to discover the implementation of the current interpreter.

For example, with PyPy the use of StringIO may offer benefits due to the possibility of more complete analysis of data flows during compilation or JIT execution. I want to take advantage of this. (Granted, currently pypy will run on top of CPython most of the time, so it's not the real solution to my problem until PyPy-c is at comparable performance). This is only example, a lot of different performance behaviors exist, that at times, will make sense to be abstracted.

I have checked module sys of both implementations (plus Jython) and found in CPython only the property "subversion", which contains a tuple with CPython being the first element. My suspect is though that this is related to the detail of using svn in CPython development, and as such, would not be a good standard. 

So, what I believe with more and more Python versions existing (e.g. IronPython), it is needed to have sys.implementation that puts sys.version into context. My proposal is that CPython leads the effort to aid this, and the other Python variants can then adopt the standard property.

Thank you in advance,
Kay Hayen

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 09:26:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Feb 2007 00:26:22 -0800
Subject: [ python-Bugs-1669637 ] Some Compiler Warnings on VC6
Message-ID: <E1HLxfC-0005fp-CW@sc8-sf-web2.sourceforge.net>

Bugs item #1669637, was opened at 2007-02-27 03:14
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470

Please note that this 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: 2
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Some Compiler Warnings on VC6

Initial Comment:
I got some warnings on VC6. Probably these are not so
problematic, but anyway I reported.

C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\winbase.h(53) : warning C4005: 'Yield' : macro was redefined.
        ..\..\Include\Python-ast.h(449) : Please check previous definition of 'Yield'

E:\python-dev\release-maint25\Objects\intobject.c(994) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer.

E:\python-dev\release-maint25\Objects\stringobject.c(859) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer.

E:\python-dev\release-maint25\Modules\audioop.c(1263) : warning C4761: The base types of the actual and formal parameters of a function were different.
The compiler converted the actual parameter to the type of the formal parameter.

E:\python-dev\release-maint25\Modules\audioop.c(1331) : warning C4761: The base types of the actual and formal parameters of a function were different.
The compiler converted the actual parameter to the type of the formal parameter.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-27 08:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

I assume this is from the 2.5 maintenance branch. Which revision is it?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 14:30:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Feb 2007 05:30:33 -0800
Subject: [ python-Bugs-1669637 ] Some Compiler Warnings on VC6
Message-ID: <E1HM2PZ-0007Hx-3O@sc8-sf-web4.sourceforge.net>

Bugs item #1669637, was opened at 2007-02-27 12:14
Message generated for change (Comment added) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470

Please note that this 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: 2
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Some Compiler Warnings on VC6

Initial Comment:
I got some warnings on VC6. Probably these are not so
problematic, but anyway I reported.

C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\winbase.h(53) : warning C4005: 'Yield' : macro was redefined.
        ..\..\Include\Python-ast.h(449) : Please check previous definition of 'Yield'

E:\python-dev\release-maint25\Objects\intobject.c(994) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer.

E:\python-dev\release-maint25\Objects\stringobject.c(859) : warning C4018: '!=' : Tried to compare signed integer and unsigned integer.

E:\python-dev\release-maint25\Modules\audioop.c(1263) : warning C4761: The base types of the actual and formal parameters of a function were different.
The compiler converted the actual parameter to the type of the formal parameter.

E:\python-dev\release-maint25\Modules\audioop.c(1331) : warning C4761: The base types of the actual and formal parameters of a function were different.
The compiler converted the actual parameter to the type of the formal parameter.


----------------------------------------------------------------------

>Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2007-02-27 22:30

Message:
Logged In: YES 
user_id=1200846
Originator: YES

Yes, Revision 53990 (Latest)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-27 17:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

I assume this is from the 2.5 maintenance branch. Which revision is it?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669637&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 17:54:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Feb 2007 08:54:56 -0800
Subject: [ python-Bugs-1590864 ] import deadlocks when using PyObjC threads
Message-ID: <E1HM5bM-00078k-7J@sc8-sf-web11.sourceforge.net>

Bugs item #1590864, was opened at 2006-11-05 18:06
Message generated for change (Comment added) made by kosuha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470

Please note that this 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: Michael Tsai (michaeltsai)
Assigned to: Nobody/Anonymous (nobody)
Summary: import deadlocks when using PyObjC threads

Initial Comment:
When I use subprocess.py from a child thread, sometimes it deadlocks. I 
determined that the new process is blocked during an import:

#0  0x90024427 in semaphore_wait_signal_trap ()
#1  0x90028414 in pthread_cond_wait ()
#2  0x004c77bf in PyThread_acquire_lock (lock=0x3189a0, waitflag=1)  
at Python/thread_pthread.h:452
#3  0x004ae2a6 in lock_import () at Python/import.c:266
#4  0x004b24be in PyImport_ImportModuleLevel (name=0xaad74 "errno",  
globals=0xbaed0, locals=0x502aa0, fromlist=0xc1378, level=-1) at  
Python/import.c:2054
#5  0x0048d2e2 in builtin___import__ (self=0x0, args=0x53724c90,  
kwds=0x0) at Python/bltinmodule.c:47
#6  0x0040decb in PyObject_Call (func=0xa94b8, arg=0x53724c90,  
kw=0x0) at Objects/abstract.c:1860

and that the code in question is in os.py:

def _execvpe(file, args, env=None):
     from errno import ENOENT, ENOTDIR

I think the problem is that since exec (the C function) hasn't yet been 
called in the new process, it's inherited from the fork a lock that's already 
held. The main process will eventually release its copy of the lock, but this 
will not unlock it in the new process, so it deadlocks.

If I change os.py so that it imports the constants outside of  
_execvpe, the new process no longer blocks in this way.

This is on Mac OS X 10.4.8.

----------------------------------------------------------------------

Comment By: Kosuha (kosuha)
Date: 2007-02-27 18:54

Message:
Logged In: YES 
user_id=1684258
Originator: NO

I confirm that problem with deadlock on execution of
PyImport_ImportModuleLevel exists. Here is a working example:

1) Python was embbeded with C++ application using Python for scripting
support:

------------------------------------------------------------------
PyThreadState * InitThreadScripting()
{
	ASSERT_KOBOLD( g_pyMainThreadState );

	// get the global lock
	PyEval_AcquireLock();
	// get a reference to the PyInterpreterState
	PyInterpreterState * mainInterpreterState = g_pyMainThreadState->interp;
	ASSERT_KOBOLD( mainInterpreterState );
	// create a thread state object for this thread
	PyThreadState * myThreadState = PyThreadState_New(mainInterpreterState);
	// free the lock
	PyEval_ReleaseLock();

	return myThreadState;
}

---------------------------------------------------------------------
void DeadLock()
{
Py_Initialize();
PyEval_InitThreads();
g_AiGlobals     = new Py::Dict();
g_pyInterpState = PyInterpreterState_New();

// save a pointer to the main PyThreadState object
g_pyMainThreadState = PyThreadState_Get();
ASSERT_KOBOLD( g_pyMainThreadState );

// release the lock
PyEval_ReleaseLock();

g_pyWorldThreadState = InitThreadScripting();

// import sys
// sys.path.append ("./scripts")
// 
PyObject	*p = PyImport_ImportModuleEx ("sys", **g_AiGlobals, NULL, NULL);
Py::Module	mod_sys (p);
Py::List	path = mod_sys.getAttr ("path");
path.append (Py::String ("scripts"));
path.append (Py::String ("scripts/sys"));
path.append (Py::String ("../../scripts"));
path.append (Py::String ("../../scripts/sys"));
Py_XDECREF (p);

// HERE IT OCCURS //
Log.ScriptsSrc("Python", "Running startup python scripts...");
PyObject *p = PyImport_ImportModuleEx ("startup", **g_AiGlobals, NULL,
NULL); // <<< Here
if (reload) PyImport_ReloadModule (p);
Py::Module	module (p);
Py_XDECREF (p);
}

Execution locks right on PyImport_ImportModuleEx. 

Code from sturtup.py:
------------------------------------------------------------------------------------
# This module is sturtup script.
# Here we are redirecting output and checking for server version.
################################################################################

import sys
from consts import *   # Import of constants
import config as cfg   # Import of configuration constants
reload(cfg)  

################################################################################

#
----------------------------------------------------------------------------------------------------------------------------------------------------------------
class OurLogStdErr:
    def write (self, txt):
        printLog (txt, PRINT_ERROR)
        
#
----------------------------------------------------------------------------------------------------------------------------------------------------------------
class OurLogStdOut:
    def write (self, txt):
        printLog (txt)

#
----------------------------------------------------------------------------------------------------------------------------------------------------------------
def CheckServerVersion():
    # Checking for server build
    if GetServerBuild() < MIN_SERVER_BUILD:
        printLog( "YOU ARE TRYING TO RUN PYTHON SCRIPTS ON OUTDATED SERVER
BUILD!\
\nREQUIRED SERVER BUILD: %s\
\nPlease Update your server core before running server!\
\nScripting Engine will be Shut Down!"\
        % (MIN_SERVER_BUILD), PRINT_ERROR )

        killScripting()
        
#
----------------------------------------------------------------------------------------------------------------------------------------------------------------
def GetScriptsVersion():
	return SCRIPTS_VERSION

################################################################################
# Startup code here:

# Redirecting errors:
sys.stderr = OurLogStdErr()

# Redirecting output:
sys.stdout = OurLogStdOut()

---------------------------------------------------------------------------------------



----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2007-01-14 00:42

Message:
Logged In: YES 
user_id=344921
Originator: NO

Since both the reporter and I believes that this is not a bug in the
subprocess module, I'm stepping back. 

----------------------------------------------------------------------

Comment By: Michael Tsai (michaeltsai)
Date: 2007-01-07 19:09

Message:
Logged In: YES 
user_id=817528
Originator: YES

I don't have time at the moment to write sample code that reproduces this.
But, FYI, I was using PyObjC to create the threads. It might not happen
with "threading" threads. And second, I think it's a bug in os.py, not in
subprocess.py. Sorry for the confusion.

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2007-01-07 16:10

Message:
Logged In: YES 
user_id=344921
Originator: NO

Can you provide a test case or sample code that demonstrates this problem?


I'm a bit unsure of if this really is a subprocess bug or a more general
Python bug. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470

From noreply at sourceforge.net  Tue Feb 27 18:26:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Feb 2007 09:26:34 -0800
Subject: [ python-Feature Requests-1670167 ] isinstance.__doc__ is somewhat
	irritating
Message-ID: <E1HM65y-0005vr-Fv@sc8-sf-web2.sourceforge.net>

Feature Requests item #1670167, was opened at 2007-02-27 18: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=1670167&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ren? Fleschenberg (refl)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance.__doc__ is somewhat irritating

Initial Comment:
"With a type as second argument, return whether that is the object's type."

That sentence does not really make sense, at least not for new-style classes. After reading that, one could expect that isinstance(1, object) would return False. I think the best thing would be to just drop that sentence from the doc string.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1670167&group_id=5470

From noreply at sourceforge.net  Wed Feb 28 13:07:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Feb 2007 04:07:31 -0800
Subject: [ python-Bugs-968430 ] error flattening complex smime signed message
Message-ID: <E1HMNal-0008K2-7X@sc8-sf-web6.sourceforge.net>

Bugs item #968430, was opened at 2004-06-07 22:34
Message generated for change (Comment added) made by gagern
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470

Please note that this 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: Ludovico Magnocavallo (ludo)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: error flattening complex smime signed message

Initial Comment:
Python 2.3.3 [GCC 3.2.2] on linux2
email version 2.5.5

Complex SMIME signed messages parsed and flattened
again do not pass SMIME verification. I have noticed
this with messages that have as message/rfc822
attachment another SMIME signed message.

A diff between an "original" SMIME signed messaged
passign openssl smime -verify verification and the same
message parsed (message_from_file) and flattened
(as_string(False)) by the email library:
diff -bB bugmsg_signed.eml bugmsg_signed_parsed.eml
2c2,3
< Content-Type: multipart/signed;
protocol="application/x-pkcs7-signature"; micalg=sha1;
boundary="----381546B4549948B9F93D885A82884C49"
---
> Content-Type: multipart/signed;
protocol="application/x-pkcs7-signature";
>       micalg=sha1;
boundary="----381546B4549948B9F93D885A82884C49"

The email-parsed message splits the signature header
into two lines, thus rendering the message non-valid.

Attached to this bug a .zip archive with:

- msg #1: the non-signed message (with a signed message
as attachment)
- msg #2: message #1 signed by openssl
- msg #3: message #2 parsed and flattened as described
above
- the CA certificate file used for smime verification

openssl command used to verify #2 and #3:

openssl smime -verify -in bugmsg_signed.eml -CAfile
cacert.pem

openssl smime -verify -in bugmsg_signed_parsed.eml
-CAfile cacert.pem



----------------------------------------------------------------------

Comment By: Martin von Gagern (gagern)
Date: 2007-02-28 13:07

Message:
Logged In: YES 
user_id=733620
Originator: NO

At least for the header wrapping issue, adding a new handler to the
default Generator implementation should provide an easy solution. I just
created patch 968430 http://tinyurl.com/2chhz6 for this.

>From mailman bug report 815297 http://tinyurl.com/2a8dta I understand that
there is a fix in mailman for this issue as well, but I believe this patch
would be a fix any python program would want, not just mailman.

There remains an issue about leading space in headers, mentioned in that
mailman problem report as well. The cause is an lstrip call in FeedParser.
However removing that would probably break a lot of existing programs. And
modifying all methods accessing the headers to remove or add leading space
would be somewhat ugly. Right now I'm trying to figure out how to save the
unmodified body for every multipart/signed message, so that it can be
stored with the message and used without any modifications during
generation.

----------------------------------------------------------------------

Comment By: Harald Tveit Alvestrand (hta)
Date: 2005-09-08 08:16

Message:
Logged In: YES 
user_id=12193

Adding my voice that the bug is important. 
This is now the chief culprit in breaking signed messages in my usage of 
signed email on the net; that "signtures are so often broken" is one 
argument people often use against using signed email. 
 

----------------------------------------------------------------------

Comment By: Bas Wijnen (shevek)
Date: 2005-01-25 10:37

Message:
Logged In: YES 
user_id=42389

In case it is any help, I tried to find the problem in the
source.  I don't speak python, so I can't fix anything, but
I do speak C, so it's quite readable. :-)

It seems to me that the problem is in Lib/email/Message.py,
in particular in _parseparam and _get_params_preserve.  Both
these functions call strip() on the object several times
(which seems a bit overdone anyway ;-) ), which I presume
removes all whitespace around them.

I think the whitespace should somehow be saved (not
stripping will probably break many programs, so that's not a
good idea), so it can be used again when the header is
written.  set_param should of course also fill this value,
so new params get a defined separation (although the empty
string is quite acceptable).

How this should be implemented I gladly leave to someone who
actually speaks Python. :-)

----------------------------------------------------------------------

Comment By: Bas Wijnen (shevek)
Date: 2005-01-24 12:43

Message:
Logged In: YES 
user_id=42389

I would like to add that I think this bug is quite
important, as mailman uses python.  This means that many
mailing lists invalidate signatures when signed e-mails with
attachments are sent through them.  As attachments are often
code patches, it is quite important that the signatures are
working correctly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470

From noreply at sourceforge.net  Wed Feb 28 19:58:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Feb 2007 10:58:39 -0800
Subject: [ python-Bugs-1671137 ] slice obj with no start index is 0 instead of
	None sometimes
Message-ID: <E1HMU0d-0007Zt-83@sc8-sf-monitor2.sourceforge.net>

Bugs item #1671137, was opened at 2007-02-28 11: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=1671137&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Verdone (jyzude)
Assigned to: Nobody/Anonymous (nobody)
Summary: slice obj with no start index is 0 instead of None sometimes

Initial Comment:
Slice objects returned by the slice ":42" return different slice objects depending on whether the entire slice operation is simple or extended. This bit of code explains it best:

class SliceBug:
    def __getitem__(self, sliceArg):
        print sliceArg

s = SliceBug()

s[:42]
s[:42,]


s[:42] produces slice(0, 42, None)
s[:42,] produces (slice(None, 42, None),)

Note that this bug only occurs on classes that do no inherit from object ("old style" classes). If you change the class to make it inherit from "object" both slices have None as their start index. Oddly enough in Python 3000 it still only happens on "old style" classes even though supposedly they are the same as new style classes. I have also reproduced the bug in Python 2.6, 2.4, 2.3, and 2.2. Seems to be a long standing bug/feature.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470

From noreply at sourceforge.net  Wed Feb 28 20:04:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Feb 2007 11:04:47 -0800
Subject: [ python-Bugs-1671137 ] slice obj with no start index is 0 instead of
	None sometimes
Message-ID: <E1HMU6Z-0000UF-3D@sc8-sf-web6.sourceforge.net>

Bugs item #1671137, was opened at 2007-02-28 11:58
Message generated for change (Comment added) made by jyzude
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Verdone (jyzude)
Assigned to: Nobody/Anonymous (nobody)
Summary: slice obj with no start index is 0 instead of None sometimes

Initial Comment:
Slice objects returned by the slice ":42" return different slice objects depending on whether the entire slice operation is simple or extended. This bit of code explains it best:

class SliceBug:
    def __getitem__(self, sliceArg):
        print sliceArg

s = SliceBug()

s[:42]
s[:42,]


s[:42] produces slice(0, 42, None)
s[:42,] produces (slice(None, 42, None),)

Note that this bug only occurs on classes that do no inherit from object ("old style" classes). If you change the class to make it inherit from "object" both slices have None as their start index. Oddly enough in Python 3000 it still only happens on "old style" classes even though supposedly they are the same as new style classes. I have also reproduced the bug in Python 2.6, 2.4, 2.3, and 2.2. Seems to be a long standing bug/feature.

----------------------------------------------------------------------

>Comment By: Mike Verdone (jyzude)
Date: 2007-02-28 12:04

Message:
Logged In: YES 
user_id=584997
Originator: YES

Correction! This is fixed in Python 3000. I just have too many windows
open and too many branches checked out.
File Added: slicebug.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470

From noreply at sourceforge.net  Wed Feb 28 21:43:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Feb 2007 12:43:29 -0800
Subject: [ python-Bugs-1649098 ] non-standard: array[0]
Message-ID: <E1HMVe5-0004de-4k@sc8-sf-web8.sourceforge.net>

Bugs item #1649098, was opened at 2007-01-31 19:25
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470

Please note that this 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
Private: No
Submitted By: Johannes Abt (jabt)
Assigned to: Thomas Heller (theller)
Summary: non-standard: array[0]

Initial Comment:
in Modules/_ctypes/ctypes.h:

typedef struct {
[..]
        ffi_type *atypes[0];
} ffi_info;

AFAIK, arrays must be of size > 0.
_Most_ compilers accepts this, but not all
(especially my HP-UX compiler).

Please change *atypes[0] to *atypes[1]!

Bye,
Johannes


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2007-02-28 21:43

Message:
Logged In: YES 
user_id=11105
Originator: NO

I can, and probably will, change this in Modules/_ctypes/ctypes.h. 
However, I'm afraid it will not help the OP too much because it seems he
cannot sucessfully compile the libffi sources with this HP-UX compiler
anyway because of at least *some* other problems.

I have the impression that libffi is GCC-specific, and unless someone
provides a complete patch for the HP-UX (or other) compilers it will
probably stay this way.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-25 23:24

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas, could you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470

From noreply at sourceforge.net  Wed Feb 28 22:15:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Feb 2007 13:15:19 -0800
Subject: [ python-Bugs-1669498 ] 2.4.4 Logging LogRecord attributes broken
Message-ID: <E1HMW8t-00081t-SR@sc8-sf-web9.sourceforge.net>

Bugs item #1669498, was opened at 2007-02-26 22:18
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470

Please note that this 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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Glenn Murray (murrayg)
>Assigned to: Vinay Sajip (vsajip)
Summary: 2.4.4 Logging LogRecord attributes broken

Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.) 

#!/usr/bin/env python
import logging

logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)

logger.info("Yo")


On 2.4.3 I get
INFO     tmplogger 11 Yo

On 2.4.4 I get
INFO     __init__ 1072 Yo


The versions are 

Python 2.4.3 (#2, Oct  6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

and

Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2007-02-28 21:15

Message:
Logged In: YES 
user_id=308438
Originator: NO

Can you please delete all logging .pyc files before running the test
script? The problem appears to be caused by the __file__ value stored
inside a .pyc being different (possibly due to symlink changes) from the
source file it was originally compiled from.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470

From john at pyrologistics.com.au  Sun Feb  4 17:12:07 2007
From: john at pyrologistics.com.au (John Collins)
Date: Sun, 04 Feb 2007 16:12:07 -0000
Subject: Python 2.5, missing KERNEL32.DLL, Win95B
Message-ID: <3.0.6.32.20070205031032.0085b8a0@netcore.com.au>

Hello all,
Total newbie: Installed Python 2.5 onto a Win 95
4.00.950B O/S. (BTW, fixed CTL3D32.DLL, it was
the wrong one!) I'm getting this error message
every time I attempt to start Python:

"The PYTHON25.DLL file is linked to missing export
 KERNEL32.DLL:GetFileAttributesExA."

Helup! Many thanks, John.


From john at pyrologistics.com.au  Tue Feb 20 16:13:16 2007
From: john at pyrologistics.com.au (John Collins)
Date: Tue, 20 Feb 2007 15:13:16 -0000
Subject: GetFileAttributesExA and Win95
Message-ID: <3.0.6.32.20070221021120.007a9580@netcore.com.au>

Hi all,
Just installed Python 2.5 on my Win95B machine, tried to run
it, but immediately got this error message;
"The PYTHON25.DLL file is
 linked to missing export KERNELL32.DLL :GetFileAttributedExA"
In FAQ, I noted this has been asked before[1], but I cannot find
the solution? Can anyone please help? Perhaps, Martin v. L?wis? 
Thank you all&
Best Regards,
John Collins.
[1] -----Copy of Previous Q&A on this problem-------------------------
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.


----------------------------------------------------------------------