From noreply at sourceforge.net  Wed Feb  1 12:35:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 03:35:46 -0800
Subject: [ python-Bugs-1367183 ] inspect.getdoc fails on objs that use
	property for __doc__
Message-ID: <E1F4GH4-000102-Ss@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Drew Perttula (drewp)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getdoc fails on objs that use property for __doc__

Initial Comment:
inspect.getdoc has these lines:

     if not isinstance(doc, types.StringTypes):
         return None

which interfere with the case where __doc__ is some
other thing that has a good __str__. I wanted to make a
lazy __doc__ that did an expensive lookup of some
external documentation only when it was str()'d, but
since doc displayers often (correctly) use
inspect.getdoc, they were getting None.

I think the intention of the test in getdoc() is to
avoid trying string operations on a __doc__ that is
None. I think that a more lenient version would allow
me to do my fancy docstrings but still solve the
'__doc__ is None' problem. Please consider the
following patch:

if doc is None:
     return None
doc = str(doc)



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

Comment By: Collin Winter (collinwinter)
Date: 2006-02-01 06:35

Message:
Logged In: YES 
user_id=1344176

It's not a good idea to use properties for __doc__:

"""
>>> class Foo(object):
...    def _get(self):
...        return 'the docstring'
...    __doc__ = property(_get)
...
>>> print Foo().__doc__
the docstring
>>> print Foo.__doc__
<property object at 0xb7b3a234>
>>>
"""

In this light, I don't view inspect.getdoc's lack of support
for __doc__-as-property as a bug.

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

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

From noreply at sourceforge.net  Wed Feb  1 15:48:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 06:48:45 -0800
Subject: [ python-Bugs-1421513 ] IMPORT PROBLEM: Local submodule shadows
	global module
Message-ID: <E1F4JHp-0002bP-Mg@sc8-sf-web5.sourceforge.net>

Bugs item #1421513, was opened at 2006-02-01 14: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=1421513&group_id=5470

Please note that this message 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
Submitted By: Jens Engel (jens_engel)
Assigned to: Nobody/Anonymous (nobody)
Summary: IMPORT PROBLEM: Local submodule shadows global module

Initial Comment:
PYTHON: 2.3, 2.4
PLATFORMS: Solaris, Linux, Cygwin, Win32

Local sister modules seem to hide global ones (of the 
standard Python library) when import occurs in a 
submodule. This statement even holds for indirect 
imports from the standard Python library.


FILE STRUCTURE for EXAMPLES:
  - my/
      +-- __init__.py
      +-- main.py
      +-- main2.py
      +-- symbol.py
      \-- types.py

EXAMPLE 1: Local submodule shadows global one.
# -- file:my.main.py
# COMMAND-LINE: python my/main.py
# MY INTENTION: Import standard module "types".
import types  #< FAILURE: Imports my.types

if __name__ == "__main__":
    print types.StringTypes  #< EXCEPTION: StringTypes 
are not known.
# -- FILE-END


EXAMPLE 2: Indirect import uses "my.symbol" instead.
# -- file:my.main2.py
# COMMAND-LINE: python my/main2.py
# MY INTENTION: Import standard module "compiler".
# NOTE: Module "compiler" imports module "symbol"
import compiler  #< FAILURE: Imports my.symbol instead

if __name__ == "__main__":
    pass
# -- FILE-END
  
NOTE: Module import problems can be better checked 
with "python -v".

I have not found a work-around that let me decide if I 
want to import the global module or the local one. The 
only solution seens to be to relocate the module 
where "__main__" is used to another place where no 
such import conflict occurs.

If my analysis is correct, the "main" module provides 
another ROOT filesystem for Python libraries that is 
normally preferred over the PYTHONHOME filesystem.
If this is true, module names at this level must be 
UNIQUE in a GLOBAL namespace (that is only partly 
under my control) which I consider BAD.

NOTE: In C++ if have the "::" prefix to indicate that 
I want to use the global/default namespace (=module) 
and not a sub-namespace. I am not aware of such a idom 
in Python.


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

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

From noreply at sourceforge.net  Wed Feb  1 18:25:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 09:25:29 -0800
Subject: [ python-Bugs-1421664 ] [win32] stderr atty encoding not set
Message-ID: <E1F4LjV-0002Vt-ET@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Snaury (snaury)
Assigned to: Nobody/Anonymous (nobody)
Summary: [win32] stderr atty encoding not set

Initial Comment:
When starting python console application under windows,
output of unicode strings to console fails because of
ansi encoding. I found that in file
Python-2.4.2/Python/sysmodule, _PySys_Init functions,
setting encoding on stderr was forgotten:

#ifdef MS_WINDOWS
	if(isatty(_fileno(stdin))){
		sprintf(buf, "cp%d", GetConsoleCP());
		if (!PyFile_SetEncoding(sysin, buf))
			return NULL;
	}
	if(isatty(_fileno(stdout))) {
		sprintf(buf, "cp%d", GetConsoleOutputCP());
		if (!PyFile_SetEncoding(sysout, buf))
			return NULL;
	}
#endif

I think the following lines should be added:

	if(isatty(_fileno(stderr))) {
		sprintf(buf, "cp%d", GetConsoleOutputCP());
		if (!PyFile_SetEncoding(syserr, buf))
			return NULL;
	}

Otherwise it's inconsistant, as if we set it to sysout,
why not on syserr? And, for example, this code will not
work properly:

    #!/usr/bin/env python
    # -*- encoding: mbcs -*-
    import sys
    reload(sys) # bring setdefaultencoding back!
    sys.setdefaultencoding("mbcs")
    sys.stderr.write(u"<native text>\n")

Instead of native text garbage will be printed (if you
change it to sys.stdout, proper text displayed), and
there is no way I know to properly determine and set
encoding just for stderr (file.encoding is read-only,
after all).

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

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

From noreply at sourceforge.net  Wed Feb  1 18:29:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 09:29:50 -0800
Subject: [ python-Bugs-1421664 ] [win32] stderr atty encoding not set
Message-ID: <E1F4Lni-0004QF-P2@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Snaury (snaury)
Assigned to: Nobody/Anonymous (nobody)
Summary: [win32] stderr atty encoding not set

Initial Comment:
When starting python console application under windows,
output of unicode strings to console fails because of
ansi encoding. I found that in file
Python-2.4.2/Python/sysmodule, _PySys_Init functions,
setting encoding on stderr was forgotten:

#ifdef MS_WINDOWS
	if(isatty(_fileno(stdin))){
		sprintf(buf, "cp%d", GetConsoleCP());
		if (!PyFile_SetEncoding(sysin, buf))
			return NULL;
	}
	if(isatty(_fileno(stdout))) {
		sprintf(buf, "cp%d", GetConsoleOutputCP());
		if (!PyFile_SetEncoding(sysout, buf))
			return NULL;
	}
#endif

I think the following lines should be added:

	if(isatty(_fileno(stderr))) {
		sprintf(buf, "cp%d", GetConsoleOutputCP());
		if (!PyFile_SetEncoding(syserr, buf))
			return NULL;
	}

Otherwise it's inconsistant, as if we set it to sysout,
why not on syserr? And, for example, this code will not
work properly:

    #!/usr/bin/env python
    # -*- encoding: mbcs -*-
    import sys
    reload(sys) # bring setdefaultencoding back!
    sys.setdefaultencoding("mbcs")
    sys.stderr.write(u"<native text>\n")

Instead of native text garbage will be printed (if you
change it to sys.stdout, proper text displayed), and
there is no way I know to properly determine and set
encoding just for stderr (file.encoding is read-only,
after all).

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

>Comment By: Snaury (snaury)
Date: 2006-02-01 20:29

Message:
Logged In: YES 
user_id=1197042

Ooops, sorry, in the example it should be:

print >>sys.stderr, u"<native text>"

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

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

From noreply at sourceforge.net  Wed Feb  1 18:56:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 09:56:01 -0800
Subject: [ python-Bugs-1421696 ] http response dictionary incomplete
Message-ID: <E1F4MD3-0005Nv-GV@sc8-sf-web6.sourceforge.net>

Bugs item #1421696, was opened at 2006-02-01 12: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=1421696&group_id=5470

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

Initial Comment:
httplib and BaseHTTPServer each maintain their own copy 
of possible response codes.

They don't agree.

It looks like the one in httplib is a superset of the 
one in BaseHTTPServer.BaseHTTPRequestHandler.responses, 
and httplib is the logical place for it, but

(1)  They map in opposite directions.

(2)  The httplib version is just a bunch of names at 
the module toplevel, with no particular grouping that 
separates them from random classes, or makes them easy 
to import as a group.

(3)  The httplib names are explicitly not exported.



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

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

From noreply at sourceforge.net  Wed Feb  1 20:38:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 11:38:48 -0800
Subject: [ python-Bugs-882297 ] socket's makefile file object doesn't work
	with timeouts.
Message-ID: <E1F4NoW-0004RK-2r@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket's makefile file object doesn't work with timeouts.

Initial Comment:
Ok, here's what I did:

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('', 9009))
>>> s.listen(5)
>>> s.accept()

Now, I opened a second Python interpreter in which I
typed this:

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 9009))

In the first interpreter I did this:

>>> s.accept()
(<socket._socketobject object at 0x40163e14>,
('127.0.0.1', 33059))
>>> s1 = _[0]
>>> s1.settimeout(3)
>>> fd = s1.makefile()

Then I tested that the timeout worked correctly.  Still
in the first interpreter:

>>> fd.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
    data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()

Now, while that was blocking, I did this in the second
interpreter:

>>> s.send('foo')
3

Which caused this in the first interpreter (as
expected, since I didn't send a newline):

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
    data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()

While that was blocking, I did this in the second
interpreter:

>>> s.send('bar\n')
4

Finally sending a newline.  But lo and behold!  In the
first interpreter I got this:

>>> fd.readline()
'bar\n'

Alas, my 'foo' has been lost!

Anyway, the documentation does explicitly state that
the socket should be in blocking mode, *implying* that
it does no buffering, but it doesn't say anything about
timeouts.  Ideally, the file object would buffer enough
data until the readline could return meaningfully, but
failing that, the documentation should probably be
updated to mention that timeouts shouldn't be used with
readline on the returned file object.


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

Comment By: John J Lee (jjlee)
Date: 2006-02-01 19:38

Message:
Logged In: YES 
user_id=261020

I believe this was fixed in socket.py in rev 32056, closing
bug 707074.

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

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

From noreply at sourceforge.net  Wed Feb  1 21:06:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 12:06:41 -0800
Subject: [ python-Bugs-1421811 ] CVS (not SVN) mentioned in Python FAQ
Message-ID: <E1F4OFV-0003aA-AV@sc8-sf-web2.sourceforge.net>

Bugs item #1421811, was opened at 2006-02-01 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=1421811&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS (not SVN) mentioned in Python FAQ

Initial Comment:
http://python.org/doc/faq/general.html

1.1.11   How do I get a beta test version of Python?

All releases, including alphas, betas and release
candidates, are announced on the comp.lang.python and
comp.lang.python.announce newsgroups. All announcements
also appear on the Python home page, at
http://www.python.org/; an RSS feed of news is available.

You can also access the development version of Python
through CVS. See
http://sourceforge.net/cvs/?group_id=5470 for details.
If you're not familiar with CVS, documents such as
http://linux.oreillynet.com/pub/a/linux/2002/01/03/cvs_intro.html
provide an introduction.




last paragraph should be about SVN, not CVS

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

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

From noreply at sourceforge.net  Wed Feb  1 21:09:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 12:09:57 -0800
Subject: [ python-Bugs-1421814 ] 2.4.1 mentioned in Python FAQ as most stable
	version
Message-ID: <E1F4OIf-0005zk-Fd@sc8-sf-web3.sourceforge.net>

Bugs item #1421814, was opened at 2006-02-01 23: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=1421814&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 mentioned in Python FAQ as most stable version

Initial Comment:
http://python.org/doc/faq/general.html

1.2.1   How stable is Python?

Very stable. 

...

The 2.4.1 release is the most stable version at this
point in time.



Is this info outdated?


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

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

From noreply at sourceforge.net  Wed Feb  1 21:28:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 12:28:33 -0800
Subject: [ python-Bugs-1353433 ] Http redirection error in urllib2.py
Message-ID: <E1F4Oaf-0006DQ-R1@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Dehn (dehn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Http redirection error in urllib2.py

Initial Comment:
A url request returns a redirect that contains a space '  ' 
character. Python urllib2.py does not replace this 
character with '%20' and fails.

Entering a line after line 507 of:
            newurl=re.sub(' ','%20',newurl)
         
Corrects my problem.

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

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

Message:
Logged In: YES 
user_id=261020

The problem is more general, so perhaps:

URLQUOTE_SAFE_URL_CHARS = "!*'();:@&=+$,/?%#[]~"
newurl = urllib.quote(url, URLQUOTE_SAFE_URL_CHARS)


Caveat: I still haven't read RFCs 3986/3987...

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

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

From noreply at sourceforge.net  Wed Feb  1 21:31:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 12:31:13 -0800
Subject: [ python-Bugs-626543 ] urllib2 doesn't do HTTP-EQUIV &amp; Refresh
Message-ID: <E1F4OdF-00074Z-Ig@sc8-sf-web3.sourceforge.net>

Bugs item #626543, was opened at 2002-10-21 21:57
Message generated for change (Settings changed) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470

Please note that this message 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: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 doesn't do HTTP-EQUIV &amp; Refresh

Initial Comment:
I just added support for HTML's META HTTP-EQUIV and
zero-time Refresh HTTP headers to my 'ClientCookie'
package (which exports essentially a clone of the
urllib2 interface that knows about cookies, making use
of urllib2 in the implementation).  I didn't make a
patch for urllib2 itself but it would be easy to do so.
I don't plan to do this immediately, but will
eventually (assuming Jeremy thinks it's advisible) -- I
just wanted to register this fact to prevent
duplication of effort.

[BTW, this version of ClientCookie isn't on my web page
yet -- my motherboard just died.]

I'm sure you know this already, but: HTTP-EQUIV is just
a way of putting headers in the HEAD section of an HTML
document; Refresh is a Netscape 1.1 header that
indicates that a browser should redirect after a
specified time.  Refresh headers with zero time act
like redirections.

The net result of the code I just wrote is that if you
urlopen a URL that points to an HTML document like
this:

&lt;HTML&gt;&lt;HEAD&gt;
&lt;META HTTP-EQUIV=&quot;Refresh&quot; CONTENT=&quot;0; 
URL=http://acme.com/new_url.htm&quot;&gt;
&lt;/HEAD&gt;&lt;/HTML&gt;

you're automatically redirected to
&quot;http://acme.com/new_url.htm&quot;.  Same thing happens if
the Refresh is in the HTTP headers, because all the
HTTP-EQUIV headers are treated like real HTTP headers.
Refresh with non-zero delay time is ignored (the
urlopen returns the document body unchanged and does
not redirect, but does still add the Refresh header to
the HTTP headers).

A few issues:

0) AFAIK, the Refresh header is not specified in any
RFC, but only here:

http://wp.netscape.com/assist/net_sites/pushpull.html

(HTTP-EQUIV seems to be in the HTML 4.0 standard, maybe
earlier ones too)

1) Infinite loops should be detected, as for HTTP 30x?
   Presumably yes.

2) Should add HTTP-EQUIV headers to response object, or
   just treat them like headers internally?  Perhaps it
   should be possible to get both behaviours?

3) Bug in my implementation: is greedy with reading
   body data from httplib's file object.


John


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

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

Message:
Logged In: YES 
user_id=261020

Closing since I no longer intend to contribute this.

(I don't want to get involved with HTML parsing in the stdlib!)

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

Comment By: John J Lee (jjlee)
Date: 2003-10-29 23:27

Message:
Logged In: YES 
user_id=261020

Just an update: 
 
- this could now be implemented as a handler (and already is, 
in my ClientCookie package) using RFE 759792, rather than 
having to be mixed in with HTTPHandler 
 
- the issues I listed in my initial comment, and the 
backwards-compatibility issue raised by MvL are now 
resolved 
 
- it needs reimplementing using HTMLParser (currently uses 
htmllib) if it's to go in the standard library; I plan to do this in 
time for 2.4 

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

Comment By: Martin v. L??wis (loewis)
Date: 2002-10-26 14:30

Message:
Logged In: YES 
user_id=21627

I would try to subclass HTTPHandler, and then provide a
build_opener wrapper that installs this handler instead of
the normal http handler (the latter is optional, since the
user could just do build_opener(HTTPRefreshHandler)).

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

Comment By: John J Lee (jjlee)
Date: 2002-10-24 00:20

Message:
Logged In: YES 
user_id=261020

What do you think the solution to the backwards-
compatibility problem is?  Leave urllib2 as-is?  Add a
switch to turn it on?  Something else?

At the moment, I just deal with it in AbstractHTTPHandler.
It would be nice to treat it like the other redirections, by
writing a RefreshHandler -- this would solve the backwards-
compatibility issue.  However, OpenerDirector.error always
calls http_error_xxx ATM (where xxx is the HTTP error code),
so without changing that, I don't think a RefreshHandler is
really possible.  I suppose the sensible solution is just to
make a new HTTPHandler and HTTPSHandler?

Can you think of any way in which supporting HTTP-EQUIV
would mess up backwards compatibility, assuming the body is
unchanged but the headers do have the HTTP-EQUIV headers
added?


John


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

Comment By: Martin v. L??wis (loewis)
Date: 2002-10-23 14:54

Message:
Logged In: YES 
user_id=21627

In addition to the issues you have mentioned, there is also 
the backwards compatibility issue: Some applications might 
expect to get a meta-refresh document from urllib, then parse 
it and retry themselves. Those applications would break with 
such a change.

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

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

From noreply at sourceforge.net  Wed Feb  1 21:34:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 12:34:53 -0800
Subject: [ python-Bugs-1152723 ] urllib2 dont respect debuglevel in httplib
Message-ID: <E1F4Ogn-00077d-Fh@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: abbatini (abbatini)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 dont respect debuglevel in httplib

Initial Comment:
It is common habit to see http headers:

>>> import httplib
>>> httplib.HTTPConnection.debuglevel = 1
>>> import urllib
>>> feeddata =
urllib.urlopen('http://diveintomark.org/xml/atom.xml').read()

but this dont work with import urllib2 with python 2.4
In rev 1.57 was intoduced code to AbstractHTTPHandler class
that prevent above mentioned construction.
Init method always set debuglevel=0 then do_open method
always do:

h.set_debuglevel(self._debuglevel)

after instantiating HTTPConnection class.

Regards

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

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

Message:
Logged In: YES 
user_id=261020

Can somebody close this?

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

Comment By: John J Lee (jjlee)
Date: 2005-05-19 20:40

Message:
Logged In: YES 
user_id=261020

The .set_debuglevel() method allows debugging
per-HTTPConnection when using urllib2 (instead of turning on
debug prints for *all* HTTPConnection instances).

Since this is just turns on some debug prints, I don't see
any great need to contort the code and/or confuse people
further by attempting to "fix" this.


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

Comment By: abbatini (abbatini)
Date: 2005-02-27 02:57

Message:
Logged In: YES 
user_id=1227778

of course:

# h.set_debuglevel(self._debuglevel)

work very well, but i dont know reason
this code was introduced,
maybe forgotten code since development


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

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

From noreply at sourceforge.net  Wed Feb  1 21:38:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 12:38:55 -0800
Subject: [ python-Bugs-1123695 ] attempting to use urllib2 on some URLs fails
	starting on 2.4
Message-ID: <E1F4Okh-0007AG-AP@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan Sokolow (ssokolow)
Assigned to: Nobody/Anonymous (nobody)
Summary: attempting to use urllib2 on some URLs fails starting on 2.4

Initial Comment:
The following will work correctly on Python 2.3.3 but fails 
on Python 2.4 
 
Python 2.4 (#1, Dec  4 2004, 01:33:42) 
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> import urllib2 
>>> 
urllib2.urlopen('http://www.fanfiction.net/s/636805/10/').read() 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "/usr/local/lib/python2.4/socket.py", line 285, in read 
    data = self._sock.recv(recv_size) 
  File "/usr/local/lib/python2.4/httplib.py", line 456, in read 
    return self._read_chunked(amt) 
  File "/usr/local/lib/python2.4/httplib.py", line 495, in 
_read_chunked 
    chunk_left = int(line, 16) 
ValueError: invalid literal for int(): 

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

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

Message:
Logged In: YES 
user_id=261020

I can't reproduce this.

1. On what OS did you observe the failure?

2. Anybody have another example that does still trigger the bug?

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

Comment By: Wummel (calvin)
Date: 2005-02-16 16:38

Message:
Logged In: YES 
user_id=9205

This bug is in httplib.py, and I already submitted patch
900744. I wonder why on Python 2.3 it seems to work though,
it should fail the same way since this bug is also present
in Python 2.3. But it might be some change in urllib2 that
triggers this in Python 2.4 and not in Python 2.3.

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

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

From noreply at sourceforge.net  Wed Feb  1 21:41:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 12:41:05 -0800
Subject: [ python-Bugs-1421839 ] Inconsistency in Programming FAQ
Message-ID: <E1F4Omn-0006SX-Cw@sc8-sf-web6.sourceforge.net>

Bugs item #1421839, was opened at 2006-02-01 23: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=1421839&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistency in Programming FAQ

Initial Comment:
http://python.org/doc/faq/programming.html

1.6.8   How do I create static class data and static
class methods?
...
Static methods are possible when you're using new-style
classes:

class C:
    def static(arg1, arg2, arg3):
        # No 'self' parameter!
        ...
    static = staticmethod(static)

- Shouldn't it look like class C(object)?
- it would be nice to mention decorators here


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

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

From noreply at sourceforge.net  Wed Feb  1 23:18:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 14:18:40 -0800
Subject: [ python-Bugs-1123695 ] attempting to use urllib2 on some URLs fails
	starting on 2.4
Message-ID: <E1F4QJE-0005HJ-CX@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan Sokolow (ssokolow)
Assigned to: Nobody/Anonymous (nobody)
Summary: attempting to use urllib2 on some URLs fails starting on 2.4

Initial Comment:
The following will work correctly on Python 2.3.3 but fails 
on Python 2.4 
 
Python 2.4 (#1, Dec  4 2004, 01:33:42) 
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> import urllib2 
>>> 
urllib2.urlopen('http://www.fanfiction.net/s/636805/10/').read() 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "/usr/local/lib/python2.4/socket.py", line 285, in read 
    data = self._sock.recv(recv_size) 
  File "/usr/local/lib/python2.4/httplib.py", line 456, in read 
    return self._read_chunked(amt) 
  File "/usr/local/lib/python2.4/httplib.py", line 495, in 
_read_chunked 
    chunk_left = int(line, 16) 
ValueError: invalid literal for int(): 

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

Comment By: Wummel (calvin)
Date: 2006-02-01 23:18

Message:
Logged In: YES 
user_id=9205

I added a testcase mockup attachment at patch #900744:

https://sourceforge.net/support/tracker.php?aid=900744

To reproduce with urllib2, start server.py and then execute:

import urllib2
urllib2.urlopen("http://localhost:8000/").read()

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

Comment By: John J Lee (jjlee)
Date: 2006-02-01 21:38

Message:
Logged In: YES 
user_id=261020

I can't reproduce this.

1. On what OS did you observe the failure?

2. Anybody have another example that does still trigger the bug?

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

Comment By: Wummel (calvin)
Date: 2005-02-16 17:38

Message:
Logged In: YES 
user_id=9205

This bug is in httplib.py, and I already submitted patch
900744. I wonder why on Python 2.3 it seems to work though,
it should fail the same way since this bug is also present
in Python 2.3. But it might be some change in urllib2 that
triggers this in Python 2.4 and not in Python 2.3.

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

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

From noreply at sourceforge.net  Wed Feb  1 23:50:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 14:50:10 -0800
Subject: [ python-Bugs-1152723 ] urllib2 dont respect debuglevel in httplib
Message-ID: <E1F4Qni-0004H4-VS@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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
Submitted By: abbatini (abbatini)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 dont respect debuglevel in httplib

Initial Comment:
It is common habit to see http headers:

>>> import httplib
>>> httplib.HTTPConnection.debuglevel = 1
>>> import urllib
>>> feeddata =
urllib.urlopen('http://diveintomark.org/xml/atom.xml').read()

but this dont work with import urllib2 with python 2.4
In rev 1.57 was intoduced code to AbstractHTTPHandler class
that prevent above mentioned construction.
Init method always set debuglevel=0 then do_open method
always do:

h.set_debuglevel(self._debuglevel)

after instantiating HTTPConnection class.

Regards

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

Comment By: John J Lee (jjlee)
Date: 2006-02-01 21:34

Message:
Logged In: YES 
user_id=261020

Can somebody close this?

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

Comment By: John J Lee (jjlee)
Date: 2005-05-19 21:40

Message:
Logged In: YES 
user_id=261020

The .set_debuglevel() method allows debugging
per-HTTPConnection when using urllib2 (instead of turning on
debug prints for *all* HTTPConnection instances).

Since this is just turns on some debug prints, I don't see
any great need to contort the code and/or confuse people
further by attempting to "fix" this.


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

Comment By: abbatini (abbatini)
Date: 2005-02-27 03:57

Message:
Logged In: YES 
user_id=1227778

of course:

# h.set_debuglevel(self._debuglevel)

work very well, but i dont know reason
this code was introduced,
maybe forgotten code since development


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

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

From noreply at sourceforge.net  Thu Feb  2 01:54:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 1 Feb 2006 16:54:22 -0800
Subject: [ python-Bugs-1396622 ] TimedRotatingFileHandler midnight rollover
	time increases
Message-ID: <200602020054.k120sMre015789@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1396622, was opened at 01/04/06 00:25
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470

Please note that this message 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: Accepted
Priority: 5
Submitted By: Andrew Waters (awaters)
Assigned to: Vinay Sajip (vsajip)
Summary: TimedRotatingFileHandler midnight rollover time increases

Initial Comment:
When calculating the next rollover time the 
calculation uses the current time plus the interval.  
Unless the log file is written exactly at midnight 
the rollover time becomes the current time + 1 day.  
So for example, if the log is written at 2:00am then 
the next rollover time will be 2:00am the following 
day rather than midnight.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 02/01/06 16:54

Message:
Logged In: YES 
user_id=1312539

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

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

Comment By: Vinay Sajip (vsajip)
Date: 01/16/06 01:18

Message:
Logged In: YES 
user_id=308438

Fixed the rollover time increase problem (checked into SVN
trunk and release24-maint branch). However, DST adjustment
has not been done yet.



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

Comment By: Josiah Carlson (josiahcarlson)
Date: 01/13/06 19:46

Message:
Logged In: YES 
user_id=341410

For this handler, one should also be aware of the fact that
when DST changes, the time.timezone doesn't change, so
calculation of when midnight actually is (if one does that),
may be off by an hour until the daemon restarts.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 01/04/06 21:46

Message:
Logged In: YES 
user_id=33168

Vinay, any comments?

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

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

From noreply at sourceforge.net  Thu Feb  2 01:59:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 16:59:47 -0800
Subject: [ python-Bugs-1396622 ] TimedRotatingFileHandler midnight rollover
	time increases
Message-ID: <E1F4Sp9-0002rP-N6@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: Accepted
Priority: 5
Submitted By: Andrew Waters (awaters)
Assigned to: Vinay Sajip (vsajip)
Summary: TimedRotatingFileHandler midnight rollover time increases

Initial Comment:
When calculating the next rollover time the 
calculation uses the current time plus the interval.  
Unless the log file is written exactly at midnight 
the rollover time becomes the current time + 1 day.  
So for example, if the log is written at 2:00am then 
the next rollover time will be 2:00am the following 
day rather than midnight.

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

>Comment By: Michael Hudson (mwh)
Date: 2006-02-02 00:59

Message:
Logged In: YES 
user_id=6656

Woah, that's a new one.  When did that get set up?

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

Comment By: SourceForge Robot (sf-robot)
Date: 2006-02-02 00:54

Message:
Logged In: YES 
user_id=1312539

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

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

Comment By: Vinay Sajip (vsajip)
Date: 2006-01-16 09:18

Message:
Logged In: YES 
user_id=308438

Fixed the rollover time increase problem (checked into SVN
trunk and release24-maint branch). However, DST adjustment
has not been done yet.



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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-01-14 03:46

Message:
Logged In: YES 
user_id=341410

For this handler, one should also be aware of the fact that
when DST changes, the time.timezone doesn't change, so
calculation of when midnight actually is (if one does that),
may be off by an hour until the daemon restarts.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-05 05:46

Message:
Logged In: YES 
user_id=33168

Vinay, any comments?

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

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

From noreply at sourceforge.net  Thu Feb  2 03:25:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 01 Feb 2006 18:25:18 -0800
Subject: [ python-Bugs-1422094 ] email.MIME*.as_string removes duplicate spaces
Message-ID: <E1F4U9u-0005i2-RL@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hads (hads)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.MIME*.as_string removes duplicate spaces

Initial Comment:
In the following example all of the multiple spaces  
in the subject will be compressed into one space  
each.   
   
from email.MIMEMultipart import MIMEMultipart   
   
outer = MIMEMultipart()   
outer['Subject'] = "Subjects   longer than 68  
characters   with    multiple spaces   
get converted to    one space."   
   
print outer.as_string()   
  
  
Will print:  
  
Content-Type: multipart/mixed; 
boundary="===============0820565010==" 
MIME-Version: 1.0 
Subject: Subjects longer than 68 characters with 
multiple spaces get converted 
        to one space. 
 
--===============0820565010== 
 
--===============0820565010==-- 
  

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

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

From noreply at sourceforge.net  Thu Feb  2 09:37:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Feb 2006 00:37:14 -0800
Subject: [ python-Bugs-1214859 ] subprocess auto-reaps children
Message-ID: <E1F4Zxq-0007zg-B0@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdeg?rd (yorick)
Assigned to: Peter ?strand (astrand)
Summary: subprocess auto-reaps children

Initial Comment:
The subprocess module automatically reaps child processes, by 
maintaining a list of instances which is traversed each time a new 
Popen instance is created.

Apparently this was originally intended to avoid large number of 
zombie processes to accrete in the system if the programmer is 
lazy and does not wait for them properly, but it can cause problems 
when the programmer wants greater control. In particular, it's not 
possible to use the pid from a subprocess.Popen instance, since it 
may already have disappeared. For instance, it makes it difficult to 
use os.wait() to wait for several child processes at the same time.

The solution is simple: Add an option that disables the auto-reaper 
for a Popen instance. This makes everyone happy: existing code is 
unaffected, the programmer who wants to control her processes 
herself is allowed to do that, and the documentation is improved to 
help avoiding a nasty bug.

A patch was posted to the patch tracker as number 1187312. I 
suggest it for inclusion into the next release.


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

Comment By: Andrew Waters (awaters)
Date: 2006-02-02 08:37

Message:
Logged In: YES 
user_id=1418249

May want to add a lock in order that auto reaping can 
happen in addition to the use of waitpid.

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

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

From noreply at sourceforge.net  Thu Feb  2 12:47:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Feb 2006 03:47:56 -0800
Subject: [ python-Bugs-1422398 ] Unicode IOError:
	execfile(u'\u043a\u043a\u043a/x.py') 
Message-ID: <E1F4cwO-0002H4-P4@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode IOError: execfile(u'\u043a\u043a\u043a/x.py') 

Initial Comment:
WinXP/NTFS/py2.4.2:

>>> glob.glob(u'\u043a\u043a\u043a/x.py')
[u'\u043a\u043a\u043a/x.py']
>>> execfile(u'\u043a\u043a\u043a/x.py')
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IOError: [Errno 2] No such file or directory: '???/x.py'

shouldn't it work even when the base filename is unicode:

>>> glob.glob(u'\u043a\u043a\u043a.py')
[u'\u043a\u043a\u043a.py']
>>> execfile(u'\u043a\u043a\u043a.py')
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IOError: [Errno 2] No such file or directory: '???.py'
>>> 

Robert


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

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

From noreply at sourceforge.net  Thu Feb  2 13:10:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Feb 2006 04:10:20 -0800
Subject: [ python-Bugs-1123695 ] attempting to use urllib2 on some URLs fails
	starting on 2.4
Message-ID: <E1F4dI4-0004F5-6Q@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan Sokolow (ssokolow)
Assigned to: Nobody/Anonymous (nobody)
Summary: attempting to use urllib2 on some URLs fails starting on 2.4

Initial Comment:
The following will work correctly on Python 2.3.3 but fails 
on Python 2.4 
 
Python 2.4 (#1, Dec  4 2004, 01:33:42) 
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> import urllib2 
>>> 
urllib2.urlopen('http://www.fanfiction.net/s/636805/10/').read() 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "/usr/local/lib/python2.4/socket.py", line 285, in read 
    data = self._sock.recv(recv_size) 
  File "/usr/local/lib/python2.4/httplib.py", line 456, in read 
    return self._read_chunked(amt) 
  File "/usr/local/lib/python2.4/httplib.py", line 495, in 
_read_chunked 
    chunk_left = int(line, 16) 
ValueError: invalid literal for int(): 

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

>Comment By: Stephan Sokolow (ssokolow)
Date: 2006-02-02 07:10

Message:
Logged In: YES 
user_id=302370

For the record, I observed the problem on Gentoo Linux.

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

Comment By: Wummel (calvin)
Date: 2006-02-01 17:18

Message:
Logged In: YES 
user_id=9205

I added a testcase mockup attachment at patch #900744:

https://sourceforge.net/support/tracker.php?aid=900744

To reproduce with urllib2, start server.py and then execute:

import urllib2
urllib2.urlopen("http://localhost:8000/").read()

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

Comment By: John J Lee (jjlee)
Date: 2006-02-01 15:38

Message:
Logged In: YES 
user_id=261020

I can't reproduce this.

1. On what OS did you observe the failure?

2. Anybody have another example that does still trigger the bug?

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

Comment By: Wummel (calvin)
Date: 2005-02-16 11:38

Message:
Logged In: YES 
user_id=9205

This bug is in httplib.py, and I already submitted patch
900744. I wonder why on Python 2.3 it seems to work though,
it should fail the same way since this bug is also present
in Python 2.3. But it might be some change in urllib2 that
triggers this in Python 2.4 and not in Python 2.3.

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

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

From noreply at sourceforge.net  Fri Feb  3 01:12:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Feb 2006 16:12:23 -0800
Subject: [ python-Bugs-1423073 ] PEP 4 additions
Message-ID: <E1F4oYp-0006fs-TC@sc8-sf-web5.sourceforge.net>

Bugs item #1423073, was opened at 2006-02-02 19: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=1423073&group_id=5470

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

Initial Comment:
(1)  PEP4 lists deprecated modules in a standard 
format, giving 

Module Name
Rationale
Date
Documentation

It isn't clear what "Documentation" means.  If it just 
means that the documentation also needs to be updated, 
then rfc822, mimetools, MimeWriter, and mimify should 
no longer be TBD.  The documentation was updated Sept 
25, 2002.

(2)  Should multifile also be deprecated?  The email 
package (which replaced the mime* modules) replaces 
this as well.



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

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

From noreply at sourceforge.net  Fri Feb  3 01:20:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Feb 2006 16:20:19 -0800
Subject: [ python-Feature Requests-1423082 ] lib-deprecated
Message-ID: <E1F4ogV-0006MO-Hs@sc8-sf-web2.sourceforge.net>

Feature Requests item #1423082, was opened at 2006-02-02 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=355470&aid=1423082&group_id=5470

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

Initial Comment:
obsolete modules are moved to lib-old.

deprecated modules remain in the library.

This makes the search for a relevant library more 
difficult. People browsing the code may not realize 
that they are deprecated.  (Example, I found no notice 
of deprecation within the code for rfc822.)  Even when 
the notice is there, the modules add to the number of 
alternatives, which hurts One-Obvious-Way-To-Do-It.

If these modules were moved to a deprecated directory, 
these problems would be greatly reduced.  (Ensure 
backwards compatibility by leaving the deprecated 
directory on the search path.) 

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

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

From noreply at sourceforge.net  Fri Feb  3 03:25:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Feb 2006 18:25:55 -0800
Subject: [ python-Bugs-1423153 ] mmap module leaks file descriptors on UNIX
Message-ID: <E1F4qe3-0000jx-IV@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fazal Majid (majid)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap module leaks file descriptors on UNIX

Initial Comment:
On UNIX, mmapmodule.c makes a call to dup(2) prior to
mapping the file descriptor into memory (oddly enough,
it doesn't map the new fd resulting from dup(), but the
old one).

The close method does not release this file descriptor,
however, leading to a leak. If mmap is used repeatedly,
the process will eventually run out of file
descriptors, as can easily be shown with this test case:

import sys, os, mmap

for i in xrange(2000):
  f = os.open('/dev/zero', os.O_RDWR)
  m = mmap.mmap(f, 10000)
  os.close(f)
  a = m[0:100]
  m[100:200] = 'F' * 100
  m.close()


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

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

From noreply at sourceforge.net  Fri Feb  3 03:27:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Feb 2006 18:27:34 -0800
Subject: [ python-Bugs-1423153 ] mmap module leaks file descriptors on UNIX
Message-ID: <E1F4qfe-0000qL-FY@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fazal Majid (majid)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap module leaks file descriptors on UNIX

Initial Comment:
On UNIX, mmapmodule.c makes a call to dup(2) prior to
mapping the file descriptor into memory (oddly enough,
it doesn't map the new fd resulting from dup(), but the
old one).

The close method does not release this file descriptor,
however, leading to a leak. If mmap is used repeatedly,
the process will eventually run out of file
descriptors, as can easily be shown with this test case:

import sys, os, mmap

for i in xrange(2000):
  f = os.open('/dev/zero', os.O_RDWR)
  m = mmap.mmap(f, 10000)
  os.close(f)
  a = m[0:100]
  m[100:200] = 'F' * 100
  m.close()


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

>Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:27

Message:
Logged In: YES 
user_id=110477

SourceForge munged the formatting of the test case, so I am
attaching a copy as well.

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

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

From noreply at sourceforge.net  Fri Feb  3 03:44:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 02 Feb 2006 18:44:59 -0800
Subject: [ python-Bugs-1423153 ] mmap module leaks file descriptors on UNIX
Message-ID: <E1F4qwV-0006uw-T2@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fazal Majid (majid)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap module leaks file descriptors on UNIX

Initial Comment:
On UNIX, mmapmodule.c makes a call to dup(2) prior to
mapping the file descriptor into memory (oddly enough,
it doesn't map the new fd resulting from dup(), but the
old one).

The close method does not release this file descriptor,
however, leading to a leak. If mmap is used repeatedly,
the process will eventually run out of file
descriptors, as can easily be shown with this test case:

import sys, os, mmap

for i in xrange(2000):
  f = os.open('/dev/zero', os.O_RDWR)
  m = mmap.mmap(f, 10000)
  os.close(f)
  a = m[0:100]
  m[100:200] = 'F' * 100
  m.close()


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

>Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:44

Message:
Logged In: YES 
user_id=110477

The following patch closes the file descriptor when the mmap
object's close method is called, and seems to resolve this
problem.

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

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:27

Message:
Logged In: YES 
user_id=110477

SourceForge munged the formatting of the test case, so I am
attaching a copy as well.

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

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

From noreply at sourceforge.net  Fri Feb  3 15:51:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Feb 2006 06:51:30 -0800
Subject: [ python-Bugs-1423153 ] mmap module leaks file descriptors on UNIX
Message-ID: <E1F52Ha-0002H5-Tq@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fazal Majid (majid)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap module leaks file descriptors on UNIX

Initial Comment:
On UNIX, mmapmodule.c makes a call to dup(2) prior to
mapping the file descriptor into memory (oddly enough,
it doesn't map the new fd resulting from dup(), but the
old one).

The close method does not release this file descriptor,
however, leading to a leak. If mmap is used repeatedly,
the process will eventually run out of file
descriptors, as can easily be shown with this test case:

import sys, os, mmap

for i in xrange(2000):
  f = os.open('/dev/zero', os.O_RDWR)
  m = mmap.mmap(f, 10000)
  os.close(f)
  a = m[0:100]
  m[100:200] = 'F' * 100
  m.close()


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

Comment By: Keith Dart (kdart)
Date: 2006-02-03 06:51

Message:
Logged In: YES 
user_id=16527

I would also like to add that the following no longer works
in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But the
fd is ignored in anonymous mmaps and does not need to be
dup-ed. This worked in older Python (2.3). Is the dup() call
really necessary?


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

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:44

Message:
Logged In: YES 
user_id=110477

The following patch closes the file descriptor when the mmap
object's close method is called, and seems to resolve this
problem.

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

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:27

Message:
Logged In: YES 
user_id=110477

SourceForge munged the formatting of the test case, so I am
attaching a copy as well.

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

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

From noreply at sourceforge.net  Fri Feb  3 18:43:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 03 Feb 2006 09:43:30 -0800
Subject: [ python-Bugs-1423153 ] mmap module leaks file descriptors on UNIX
Message-ID: <E1F54y2-0000Bo-OJ@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fazal Majid (majid)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap module leaks file descriptors on UNIX

Initial Comment:
On UNIX, mmapmodule.c makes a call to dup(2) prior to
mapping the file descriptor into memory (oddly enough,
it doesn't map the new fd resulting from dup(), but the
old one).

The close method does not release this file descriptor,
however, leading to a leak. If mmap is used repeatedly,
the process will eventually run out of file
descriptors, as can easily be shown with this test case:

import sys, os, mmap

for i in xrange(2000):
  f = os.open('/dev/zero', os.O_RDWR)
  m = mmap.mmap(f, 10000)
  os.close(f)
  a = m[0:100]
  m[100:200] = 'F' * 100
  m.close()


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

>Comment By: Fazal Majid (majid)
Date: 2006-02-03 09:43

Message:
Logged In: YES 
user_id=110477

>From my reading of the source, the fd is kept around just to
support the mmap.size() and mmap.resize() methods. I tend to
agree, tying down a fd is wasteful.

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

Comment By: Keith Dart (kdart)
Date: 2006-02-03 06:51

Message:
Logged In: YES 
user_id=16527

I would also like to add that the following no longer works
in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But the
fd is ignored in anonymous mmaps and does not need to be
dup-ed. This worked in older Python (2.3). Is the dup() call
really necessary?


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

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:44

Message:
Logged In: YES 
user_id=110477

The following patch closes the file descriptor when the mmap
object's close method is called, and seems to resolve this
problem.

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

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:27

Message:
Logged In: YES 
user_id=110477

SourceForge munged the formatting of the test case, so I am
attaching a copy as well.

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

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

From noreply at sourceforge.net  Sat Feb  4 11:23:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 02:23:34 -0800
Subject: [ python-Bugs-1423972 ] Email tests fail
Message-ID: <E1F5KZq-0007Dp-3N@sc8-sf-web3.sourceforge.net>

Bugs item #1423972, was opened at 2006-02-04 11: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=1423972&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L??wis (loewis)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Email tests fail

Initial Comment:
With the recent changes, the email tests now fail with

test test_email failed -- Traceback (most recent call
last):
  File
"/net/tb0/home/loewis/buildbot/trunk.1/build/Lib/email/test/test_email.py",
line 2110, in test_parsedate_acceptable_to_time_functions
    eq(int(time.mktime(timetup)), 1044470846)
AssertionError: 1044449246 != 1044470846

See python.org/dev/buildbot/ for examples.

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

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

From noreply at sourceforge.net  Sat Feb  4 11:28:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 02:28:50 -0800
Subject: [ python-Bugs-1421811 ] CVS (not SVN) mentioned in Python FAQ
Message-ID: <E1F5Kew-0007z4-7K@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS (not SVN) mentioned in Python FAQ

Initial Comment:
http://python.org/doc/faq/general.html

1.1.11   How do I get a beta test version of Python?

All releases, including alphas, betas and release
candidates, are announced on the comp.lang.python and
comp.lang.python.announce newsgroups. All announcements
also appear on the Python home page, at
http://www.python.org/; an RSS feed of news is available.

You can also access the development version of Python
through CVS. See
http://sourceforge.net/cvs/?group_id=5470 for details.
If you're not familiar with CVS, documents such as
http://linux.oreillynet.com/pub/a/linux/2002/01/03/cvs_intro.html
provide an introduction.




last paragraph should be about SVN, not CVS

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

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

Message:
Logged In: YES 
user_id=21627

Thanks for the report. This is now fixed.

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

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

From noreply at sourceforge.net  Sat Feb  4 11:35:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 02:35:16 -0800
Subject: [ python-Bugs-1421814 ] 2.4.1 mentioned in Python FAQ as most stable
	version
Message-ID: <E1F5KlA-0003uz-NA@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 mentioned in Python FAQ as most stable version

Initial Comment:
http://python.org/doc/faq/general.html

1.2.1   How stable is Python?

Very stable. 

...

The 2.4.1 release is the most stable version at this
point in time.



Is this info outdated?


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

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

Message:
Logged In: YES 
user_id=21627

Thanks; it was outdated, but is now up-to-date.

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

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

From noreply at sourceforge.net  Sat Feb  4 11:41:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 02:41:44 -0800
Subject: [ python-Bugs-1421839 ] Inconsistency in Programming FAQ
Message-ID: <E1F5KrQ-0004aH-0O@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Inconsistency in Programming FAQ

Initial Comment:
http://python.org/doc/faq/programming.html

1.6.8   How do I create static class data and static
class methods?
...
Static methods are possible when you're using new-style
classes:

class C:
    def static(arg1, arg2, arg3):
        # No 'self' parameter!
        ...
    static = staticmethod(static)

- Shouldn't it look like class C(object)?
- it would be nice to mention decorators here


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

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

Message:
Logged In: YES 
user_id=21627

Did you try it out? It works. The comment "new-style
classes" is misleading - what it really should say is that
you need a Python version that has staticmethod.

Andrew, this is your text: would you like to correct it?

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

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

From noreply at sourceforge.net  Sat Feb  4 13:50:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 04:50:26 -0800
Subject: [ python-Bugs-1424017 ] Assert failure in signal handling
Message-ID: <E1F5Mry-0005Eh-8Y@sc8-sf-web1.sourceforge.net>

Bugs item #1424017, was opened at 2006-02-04 12: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=1424017&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: doom (doomtr666)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assert failure in signal handling

Initial Comment:
With Visual Studio 2005 while compiling in debug mode.
Assert faillure occurs line 1657 in pythonrun.c.

New 2005 debug runtime raise an assert while using 
unsupported signals.

Proposed patch :

#else
	PyOS_sighandler_t handler;

//	handler = signal(sig, SIG_IGN);
	handler = SIG_ERR;

	if (handler != SIG_ERR)
		signal(sig, handler);
	return handler;
#endif

if under visual studio 2005 debug runtime




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

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

From noreply at sourceforge.net  Sat Feb  4 14:02:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 05:02:00 -0800
Subject: [ python-Bugs-1422094 ] email.MIME*.as_string removes duplicate spaces
Message-ID: <E1F5N3A-0006vV-DQ@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hads (hads)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.MIME*.as_string removes duplicate spaces

Initial Comment:
In the following example all of the multiple spaces  
in the subject will be compressed into one space  
each.   
   
from email.MIMEMultipart import MIMEMultipart   
   
outer = MIMEMultipart()   
outer['Subject'] = "Subjects   longer than 68  
characters   with    multiple spaces   
get converted to    one space."   
   
print outer.as_string()   
  
  
Will print:  
  
Content-Type: multipart/mixed; 
boundary="===============0820565010==" 
MIME-Version: 1.0 
Subject: Subjects longer than 68 characters with 
multiple spaces get converted 
        to one space. 
 
--===============0820565010== 
 
--===============0820565010==-- 
  

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

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

From noreply at sourceforge.net  Sat Feb  4 14:39:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 05:39:47 -0800
Subject: [ python-Bugs-1424041 ] The mmap module does unnecessary dup()
Message-ID: <E1F5Ndj-0007Ws-8A@sc8-sf-web2.sourceforge.net>

Bugs item #1424041, was opened at 2006-02-04 05: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=1424041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Dart (kdart)
Assigned to: Nobody/Anonymous (nobody)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

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

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

From noreply at sourceforge.net  Sat Feb  4 14:42:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 05:42:03 -0800
Subject: [ python-Bugs-1424041 ] The mmap module does unnecessary dup()
Message-ID: <E1F5Nfv-0007Xf-Hn@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Dart (kdart)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

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

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

From noreply at sourceforge.net  Sat Feb  4 15:33:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 06:33:57 -0800
Subject: [ python-Bugs-1424041 ] The mmap module does unnecessary dup()
Message-ID: <E1F5OU9-0007qM-5T@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Dart (kdart)
Assigned to: Neal Norwitz (nnorwitz)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

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

>Comment By: Keith Dart (kdart)
Date: 2006-02-04 06:33

Message:
Logged In: YES 
user_id=16527

Here is a patch that fixes the problem for anonymous maps.
It simply makes the fd to be ignored if it is less than
zero. This works, but I still don't think having a duped fd
is needed. Whatever it accomplishes could be done in Python.
As a general rule, I prefer these kinds os system call
wrappers to do as little as possible (just wrap the call). 

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

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

From noreply at sourceforge.net  Sat Feb  4 15:39:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 06:39:11 -0800
Subject: [ python-Bugs-1424065 ] The email package needs an "application" type
Message-ID: <E1F5OZD-0005K5-Ba@sc8-sf-web5.sourceforge.net>

Bugs item #1424065, was opened at 2006-02-04 06: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=1424065&group_id=5470

Please note that this message 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
Submitted By: Keith Dart (kdart)
Assigned to: Nobody/Anonymous (nobody)
Summary: The email package needs an "application" type

Initial Comment:
The email package lacks a top-level MIME class for
"application/*" MIME types. Attached to this bug is one
that you might want to include.


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

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

From noreply at sourceforge.net  Sat Feb  4 15:40:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 06:40:35 -0800
Subject: [ python-Bugs-1424065 ] The email package needs an "application" type
Message-ID: <E1F5OaZ-0000AX-Gk@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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
Submitted By: Keith Dart (kdart)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: The email package needs an "application" type

Initial Comment:
The email package lacks a top-level MIME class for
"application/*" MIME types. Attached to this bug is one
that you might want to include.


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

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

From noreply at sourceforge.net  Sat Feb  4 18:35:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 09:35:20 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F5RJg-0003Xl-Bz@sc8-sf-web2.sourceforge.net>

Bugs item #1424148, was opened at 2006-02-04 18: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=1424148&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

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

From noreply at sourceforge.net  Sat Feb  4 18:35:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 09:35:43 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F5RK3-0003f9-8Y@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

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

From noreply at sourceforge.net  Sat Feb  4 18:50:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 09:50:19 -0800
Subject: [ python-Bugs-1424152 ] urllib: HTTPS over (Squid) Proxy fails
Message-ID: <E1F5RYB-0001HF-Fj@sc8-sf-web3.sourceforge.net>

Bugs item #1424152, was opened at 2006-02-04 18: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=1424152&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib: HTTPS over (Squid) Proxy fails

Initial Comment:
py2.4.2/win32

The proxy mechanism of python fails on https and does
work completely wrong (not using the CONNECT scheme).

(after urlopen some minute(s) freeze then EOF error)

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import urllib
>>> urllib.getproxies()
{'ftp': 'ftp://vserver:3128', 'http':
'http://vserver:3128', 'gopher': 'gopher:/
/vserver:3128', 'https': 'https://vserver:3128'}
>>> urllib.urlopen('https://www.elster.de')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\lib\urllib.py", line 77, in urlopen
    return opener.open(url)
  File "C:\Python24\lib\urllib.py", line 185, in open
    return getattr(self, name)(url)
  File "C:\Python24\lib\urllib.py", line 386, in open_https
    h.endheaders()
  File "C:\Python24\lib\httplib.py", line 795, in
endheaders
    self._send_output()
  File "C:\Python24\lib\httplib.py", line 676, in
_send_output
    self.send(msg)
  File "C:\Python24\lib\httplib.py", line 643, in send
    self.connect()
  File "C:\Python24\lib\httplib.py", line 1071, in connect
    ssl = socket.ssl(sock, self.key_file, self.cert_file)
  File "C:\Python24\lib\socket.py", line 74, in ssl
    return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (8, 'EOF occurred in
violation of protocol')
>>>



no CONNECT even appears in the squid proxy access log.

Robert
 

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

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

From noreply at sourceforge.net  Sat Feb  4 19:23:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 10:23:43 -0800
Subject: [ python-Bugs-1424171 ] patch for etree cdata and attr quoting
Message-ID: <E1F5S4V-0007Hy-6s@sc8-sf-web1.sourceforge.net>

Bugs item #1424171, was opened at 2006-02-04 13: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=1424171&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example "&quote;" with 
"&amp;quote;" or "&amp;" with "&amp;amp;", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

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

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

From noreply at sourceforge.net  Sat Feb  4 19:26:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 10:26:17 -0800
Subject: [ python-Bugs-1424171 ] patch for etree cdata and attr quoting
Message-ID: <E1F5S6z-0001UM-6T@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example "&quote;" with 
"&amp;quote;" or "&amp;" with "&amp;amp;", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

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

>Comment By: Chris McDonough (chrism)
Date: 2006-02-04 13:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

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

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

From noreply at sourceforge.net  Sat Feb  4 19:29:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 10:29:50 -0800
Subject: [ python-Bugs-1424171 ] patch for etree cdata and attr quoting
Message-ID: <E1F5SAQ-0006JQ-OH@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
>Assigned to: Fredrik Lundh (effbot)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example "&quote;" with 
"&amp;quote;" or "&amp;" with "&amp;amp;", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

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

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-04 19:29

Message:
Logged In: YES 
user_id=1188172

OP: You did check the box?

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 19:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

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

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

From noreply at sourceforge.net  Sat Feb  4 21:10:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 12:10:21 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F5Tjh-0001WT-VB@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

>Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-04 21:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

=======
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0
user agents
      will erroneously change it into a GET request.

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

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

From noreply at sourceforge.net  Sat Feb  4 21:23:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 12:23:27 -0800
Subject: [ python-Bugs-1424171 ] patch for etree cdata and attr quoting
Message-ID: <E1F5TwN-0002Cq-Uk@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Fredrik Lundh (effbot)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example "&quote;" with 
"&amp;quote;" or "&amp;" with "&amp;amp;", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

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

>Comment By: Chris McDonough (chrism)
Date: 2006-02-04 15:23

Message:
Logged In: YES 
user_id=32974

Egads, I did this time.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-04 13:29

Message:
Logged In: YES 
user_id=1188172

OP: You did check the box?

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 13:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

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

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

From noreply at sourceforge.net  Sun Feb  5 00:01:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 15:01:00 -0800
Subject: [ python-Bugs-1415455 ] Typo in online documentation - 6.8.3.6
	Replacing popen2.*
Message-ID: <E1F5WOq-0001DC-RN@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Phil Wright (phlipped)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Typo in online documentation - 6.8.3.6 Replacing popen2.*

Initial Comment:
I think a module name is misspelled on the following
page of the Python Library Reference ...

Document:      Python Library Reference
Page Title:    6.8.3.6 Replacing popen2.*
Page Address:  http://docs.python.org/lib/node246.html

The page contains the following text ...
"The popen2.Popen3 and popen3.Popen4 basically works as
subprocess.Popen, except that:"

The reference to the class "popen3.Popen4" should be
"popen2.Popen4" (There is no module "popen3")

The correct text would be ...
"The popen2.Popen3 and popen2.Popen4 basically works as
subprocess.Popen, except that:"


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 15:01

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42236. (2.4)
Committed revision 42237.


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

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

From noreply at sourceforge.net  Sun Feb  5 00:47:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 15:47:45 -0800
Subject: [ python-Bugs-1117670 ] profiler: Bad return and Bad call errors with
	exceptions
Message-ID: <E1F5X85-0001SH-5x@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: profiler: Bad return and Bad call errors with exceptions

Initial Comment:
I ran into a weird error when trying to profile a test
script of mine:
AssertionError: ('Bad call', ('', 0, 'encode'))

I managed to whittle it down to some minimal test
cases, which are attached (although the errors they
generate are slightly different.)  

$ python-cvs -m profile profile_badcall.py
Traceback (most recent call last):
[snipped ...]
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "profile_badcall.py", line 10, in ?
    os.path.join("C",'b')
  File
"/home/donut/usr64/python/lib/python2.5/posixpath.py",
line 56, in join
    def join(a, *p):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
    if self.dispatch[event](self, frame, t):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 285, in trace_dispatch_call
    assert (self.cur is None or \
AssertionError: ('Bad call', ('profile_badcall.py', 2,
'trier'))

$ python-cvs -m profile profile_badreturn.py
Traceback (most recent call last):
[snipped...]
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
    if self.dispatch[event](self, frame, t):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 312, in trace_dispatch_return
    assert frame is self.cur[-2].f_back, ("Bad return",
self.cur[-3])
AssertionError: ('Bad return', ('profile_badreturn.py',
1, 'trier'))


The errors occur in python CVS as of 20050206 and
python 2.4, but not in python 2.3.4.  
OS: debian sid (3.1)
Arch: amd64


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

Comment By: Artur de Sousa Rocha (adsr)
Date: 2006-02-05 00:47

Message:
Logged In: YES 
user_id=728207

I've run into this bug too and decided to check the test
cases. Here's what I found:

1) Both test cases fail as mentioned above under Cygwin.

2) Under native Windows Python, profile_badcall.py passes OK
and profile_badreturn.py gives the following traceback:

Traceback (most recent call last):
  File "c:\Python24\lib\profile.py", line 611, in ?
    run('execfile(%r)' % (sys.argv[0],), options.outfile,
options.sort)
  File "c:\Python24\lib\profile.py", line 72, in run
    prof = prof.run(statement)
  File "c:\Python24\lib\profile.py", line 448, in run
    return self.runctx(cmd, dict, dict)
  File "c:\Python24\lib\profile.py", line 454, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "profile_badreturn.py", line 9, in ?
    sum(1,0)
TypeError: iteration over non-sequence

Python versions used:

Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit
(Intel)] on win32


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

Comment By: Andrew Bennetts (spiv)
Date: 2005-10-08 09:05

Message:
Logged In: YES 
user_id=50945

I still see this in current python 2.4, but not in current
python CVS.

Also, hotshot seems to work ok in 2.4 and CVS.

OS: ubuntu breezy (5.10)
Arch: i386


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

Comment By: Gary Oberbrunner (garyoberbrunner)
Date: 2005-03-09 04:35

Message:
Logged In: YES 
user_id=417980

Is there any news on this bug?  It is possibly preventing
scons (http://scons.org) from being profiled on python 2.4
-- we get the same errors as above.  Test case is too large
to include here, but please email me with any news if
possible!  Would be glad to test a fix.
-- Gary

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

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

From noreply at sourceforge.net  Sun Feb  5 00:48:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 15:48:34 -0800
Subject: [ python-Bugs-1423972 ] Email tests fail
Message-ID: <E1F5X8s-0005LO-Ib@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin v. L??wis (loewis)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Email tests fail

Initial Comment:
With the recent changes, the email tests now fail with

test test_email failed -- Traceback (most recent call
last):
  File
"/net/tb0/home/loewis/buildbot/trunk.1/build/Lib/email/test/test_email.py",
line 2110, in test_parsedate_acceptable_to_time_functions
    eq(int(time.mktime(timetup)), 1044470846)
AssertionError: 1044449246 != 1044470846

See python.org/dev/buildbot/ for examples.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-04 18:48

Message:
Logged In: YES 
user_id=12800

r42238 in trunk
r42239 in 2.4 branch
r42240 in 2.3 branch


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

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

From noreply at sourceforge.net  Sun Feb  5 00:54:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 15:54:36 -0800
Subject: [ python-Bugs-1415455 ] Typo in online documentation - 6.8.3.6
	Replacing popen2.*
Message-ID: <E1F5XEi-0005GR-N9@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Phil Wright (phlipped)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Typo in online documentation - 6.8.3.6 Replacing popen2.*

Initial Comment:
I think a module name is misspelled on the following
page of the Python Library Reference ...

Document:      Python Library Reference
Page Title:    6.8.3.6 Replacing popen2.*
Page Address:  http://docs.python.org/lib/node246.html

The page contains the following text ...
"The popen2.Popen3 and popen3.Popen4 basically works as
subprocess.Popen, except that:"

The reference to the class "popen3.Popen4" should be
"popen2.Popen4" (There is no module "popen3")

The correct text would be ...
"The popen2.Popen3 and popen2.Popen4 basically works as
subprocess.Popen, except that:"


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 15:54

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42236. (2.4)
Committed revision 42237.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 15:01

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42236. (2.4)
Committed revision 42237.


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

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

From noreply at sourceforge.net  Sun Feb  5 04:25:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 19:25:25 -0800
Subject: [ python-Bugs-1423153 ] mmap module leaks file descriptors on UNIX
Message-ID: <E1F5aWj-0002E3-MI@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fazal Majid (majid)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: mmap module leaks file descriptors on UNIX

Initial Comment:
On UNIX, mmapmodule.c makes a call to dup(2) prior to
mapping the file descriptor into memory (oddly enough,
it doesn't map the new fd resulting from dup(), but the
old one).

The close method does not release this file descriptor,
however, leading to a leak. If mmap is used repeatedly,
the process will eventually run out of file
descriptors, as can easily be shown with this test case:

import sys, os, mmap

for i in xrange(2000):
  f = os.open('/dev/zero', os.O_RDWR)
  m = mmap.mmap(f, 10000)
  os.close(f)
  a = m[0:100]
  m[100:200] = 'F' * 100
  m.close()


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 19:25

Message:
Logged In: YES 
user_id=33168

A similar fix was checked in to 41368 (2.4) and 41366 on 01
Nov 2005.  Thanks.  There shouldn't be a problem using 2.4
SVN HEAD or 2.5 HEAD.

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

Comment By: Fazal Majid (majid)
Date: 2006-02-03 09:43

Message:
Logged In: YES 
user_id=110477

>From my reading of the source, the fd is kept around just to
support the mmap.size() and mmap.resize() methods. I tend to
agree, tying down a fd is wasteful.

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

Comment By: Keith Dart (kdart)
Date: 2006-02-03 06:51

Message:
Logged In: YES 
user_id=16527

I would also like to add that the following no longer works
in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But the
fd is ignored in anonymous mmaps and does not need to be
dup-ed. This worked in older Python (2.3). Is the dup() call
really necessary?


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

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:44

Message:
Logged In: YES 
user_id=110477

The following patch closes the file descriptor when the mmap
object's close method is called, and seems to resolve this
problem.

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

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:27

Message:
Logged In: YES 
user_id=110477

SourceForge munged the formatting of the test case, so I am
attaching a copy as well.

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

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

From noreply at sourceforge.net  Sun Feb  5 07:01:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 22:01:10 -0800
Subject: [ python-Bugs-1424041 ] The mmap module does unnecessary dup()
Message-ID: <E1F5cxS-0005ba-BT@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Keith Dart (kdart)
Assigned to: Neal Norwitz (nnorwitz)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 22:01

Message:
Logged In: YES 
user_id=33168

I think the dup() was added for resizing and some other
feature.  I'm not really sure about it, but it's safer to
leave in at this point.

There's no file attached.  This problem was fixed by patch
1407135.

Committed revision 42244.
Committed revision 42245. (2.4)


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

Comment By: Keith Dart (kdart)
Date: 2006-02-04 06:33

Message:
Logged In: YES 
user_id=16527

Here is a patch that fixes the problem for anonymous maps.
It simply makes the fd to be ignored if it is less than
zero. This works, but I still don't think having a duped fd
is needed. Whatever it accomplishes could be done in Python.
As a general rule, I prefer these kinds os system call
wrappers to do as little as possible (just wrap the call). 

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

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

From noreply at sourceforge.net  Sun Feb  5 07:05:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 22:05:53 -0800
Subject: [ python-Bugs-1089974 ] mmap missing offset parameter
Message-ID: <E1F5d21-0005me-AW@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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
Submitted By: James Y Knight (foom)
Assigned to: A.M. Kuchling (akuchling)
Summary: mmap missing offset parameter

Initial Comment:
For some reason, the author of the MMap module didn't see fit to 
expose the "offset" parameter of the mmap syscall to python. It 
would be really nice if it had that. Currently, it's always set to 0.

    m_obj->data = mmap(NULL, map_size,
               prot, flags,
               fd, 0);


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 22:05

Message:
Logged In: YES 
user_id=33168

The patch just needs some attention (testing and possible
fixes) on Windows.

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

Comment By: George Yoshida (quiver)
Date: 2004-12-28 21:54

Message:
Logged In: YES 
user_id=671362

There's already a patch for this request:

  http://www.python.org/sf/708374
  add offset to mmap

The rationale is same.
It's almost ready to be committed but has been left out for a 
year now. So give it a second chance.


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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-12-28 15:51

Message:
Logged In: YES 
user_id=341410

I would, but I don't know the slightest about the C-level
mmap internals on any platform, and spending the last hour
looking through Python's mmap.c hasn't made me any more
informed.

James (or anyone else who reads this), are you able?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2004-12-28 12:34

Message:
Logged In: YES 
user_id=11375

Would either of you care to provide a patch adding the
parameter?  I'll review it...


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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-12-23 08:57

Message:
Logged In: YES 
user_id=341410

I agree.  Having access to the offset parameter would be
quite convenient, at least to some who use mmap in a
nontrivial fashion.

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

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

From noreply at sourceforge.net  Sun Feb  5 07:31:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 04 Feb 2006 22:31:02 -0800
Subject: [ python-Bugs-1424017 ] Assert failure in signal handling
Message-ID: <E1F5dQM-0006u9-Bt@sc8-sf-web2.sourceforge.net>

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

Please note that this 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: Out of Date
Priority: 5
Submitted By: doom (doomtr666)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assert failure in signal handling

Initial Comment:
With Visual Studio 2005 while compiling in debug mode.
Assert faillure occurs line 1657 in pythonrun.c.

New 2005 debug runtime raise an assert while using 
unsupported signals.

Proposed patch :

#else
	PyOS_sighandler_t handler;

//	handler = signal(sig, SIG_IGN);
	handler = SIG_ERR;

	if (handler != SIG_ERR)
		signal(sig, handler);
	return handler;
#endif

if under visual studio 2005 debug runtime




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 22:31

Message:
Logged In: YES 
user_id=33168

Python 2.5 fixes this problem, however, the fix was not
backported to 2.4.

See patch 1350409 also #1167262 and #1311784.

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

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

From noreply at sourceforge.net  Sun Feb  5 12:16:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 03:16:07 -0800
Subject: [ python-Bugs-1424041 ] The mmap module does unnecessary dup()
Message-ID: <E1F5hsF-0005n0-SJ@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Keith Dart (kdart)
Assigned to: Neal Norwitz (nnorwitz)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

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

>Comment By: Keith Dart (kdart)
Date: 2006-02-05 03:16

Message:
Logged In: YES 
user_id=16527

Bah, stupid little box... Here is the patch again. Just for
the record (no /dev/zero is needed here).


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 22:01

Message:
Logged In: YES 
user_id=33168

I think the dup() was added for resizing and some other
feature.  I'm not really sure about it, but it's safer to
leave in at this point.

There's no file attached.  This problem was fixed by patch
1407135.

Committed revision 42244.
Committed revision 42245. (2.4)


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

Comment By: Keith Dart (kdart)
Date: 2006-02-04 06:33

Message:
Logged In: YES 
user_id=16527

Here is a patch that fixes the problem for anonymous maps.
It simply makes the fd to be ignored if it is less than
zero. This works, but I still don't think having a duped fd
is needed. Whatever it accomplishes could be done in Python.
As a general rule, I prefer these kinds os system call
wrappers to do as little as possible (just wrap the call). 

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

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

From noreply at sourceforge.net  Mon Feb  6 01:38:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 16:38:39 -0800
Subject: [ python-Bugs-1411097 ] urllib2.urlopen() hangs due to use of
	socket._fileobject?
Message-ID: <E1F5uOt-00049q-7X@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.urlopen() hangs due to use of socket._fileobject?

Initial Comment:
To reproduce:

import urllib2
print urllib2.urlopen("http://66.117.37.13/").read()


The attached patch "fixes" the hang, but that patch is
not acceptable because it also removes the .readline()
and .readlines() methods on the response object
returned by urllib2.urlopen().

The patch seems to demonstrate that the problem is
caused by the (ab)use of socket._fileobject in
urllib2.AbstractHTTPHandler (I believe this hack was
introduced when urllib2 switched to using
httplib.HTTPConnection).

Not sure yet what the actual problem is...


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

>Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:38

Message:
Logged In: YES 
user_id=261020

First, expanding a bit on what I wrote on 2006-01-21: The
problem does relate to chunked encoding, and is unrelated to
urllib2's use of _fileobject.  My hack to remove use of
socket._fileobject from urllib2 merely breaks handling of
chunked encoding by cutting httplib.HTTPResponse out of the
picture.  The problem is seen in urllib2 in recent Pythons
thanks to urllib2 switching to use of httplib.HTTPConnection
and HTTP/1.1, hence chunked encoding is allowed.  urllib
still uses httplib.HTTP, hence HTTP/1.0, so is unaffected.
To reproduce with httplib:
import httplib
conn = httplib.HTTPConnection("66.117.37.13")
conn.request("GET", "/", headers={"Connection": "close"})
r1 = conn.getresponse()
print r1.read()
The Connection: close is required -- if it's not there the
server doesn't use chunked transfer-encoding.
I verified with a packet sniffer that the problem is that
this server does not send the final trailing CRLF required
by section 3.6.1 of RFC 2616.  However, that section also
says that trailers (trailing HTTP headers) MUST NOT be sent
by the server unless either a TE header was present and
indicated that trailers are acceptable (httplib does not
send the TE header), or the trailers are optional metadata
and may be discarded by the client.  So, I propose the
attached patch to httplib (chunk.patch) as a work-around.


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

Comment By: John J Lee (jjlee)
Date: 2006-01-21 22:10

Message:
Logged In: YES 
user_id=261020

In fact the commit message for rev 36871 states the real
reason _fileobject is used (handling chunked encoding),
showing my workaround is even more harmful than I thought. 
Moreover, doing a urlopen on 66.117.37.13 shows the response
*is* chunked.

The problem seems to be caused by httplib failing to find a
CRLF at the end of the chunked response, so the loop at the
end of _read_chunked() never terminates.  Haven't looked in
detail yet, but I'm guessing a) it's the server's fault and
b) httplib should work around it.


Here's the commit message from 36871:


Fix urllib2.urlopen() handling of chunked content encoding.

The change to use the newer httplib interface admitted the
possibility
that we'd get an HTTP/1.1 chunked response, but the code
didn't handle
it correctly.  The raw socket object can't be pass to
addinfourl(),
because it would read the undecoded response.  Instead,
addinfourl()
must call HTTPResponse.read(), which will handle the decoding.

One extra wrinkle is that the HTTPReponse object can't be
passed to
addinfourl() either, because it doesn't implement readline() or
readlines().  As a quick hack, use socket._fileobject(), which
implements those methods on top of a read buffer. 
(suggested by mwh)

Finally, add some tests based on test_urllibnet.

Thanks to Andrew Sawyers for originally reporting the
chunked problem.


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

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

From noreply at sourceforge.net  Mon Feb  6 01:54:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 16:54:06 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F5udq-0000pI-KV@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:54

Message:
Logged In: YES 
user_id=261020

This is not a bug.
See the long discussion here:
http://python.org/sf/549151

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-04 20:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

=======
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0
user agents
      will erroneously change it into a GET request.

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

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

From noreply at sourceforge.net  Mon Feb  6 01:56:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 16:56:22 -0800
Subject: [ python-Bugs-1421696 ] http response dictionary incomplete
Message-ID: <E1F5ug2-0006mI-SV@sc8-sf-web1.sourceforge.net>

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

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

Initial Comment:
httplib and BaseHTTPServer each maintain their own copy 
of possible response codes.

They don't agree.

It looks like the one in httplib is a superset of the 
one in BaseHTTPServer.BaseHTTPRequestHandler.responses, 
and httplib is the logical place for it, but

(1)  They map in opposite directions.

(2)  The httplib version is just a bunch of names at 
the module toplevel, with no particular grouping that 
separates them from random classes, or makes them easy 
to import as a group.

(3)  The httplib names are explicitly not exported.



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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:56

Message:
Logged In: YES 
user_id=261020

There's also one in urllib2 :-(

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

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

From noreply at sourceforge.net  Mon Feb  6 01:58:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 16:58:53 -0800
Subject: [ python-Bugs-1411097 ] httplib patch to make _read_chunked() more
	robust
Message-ID: <E1F5uiT-0006d4-LL@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
>Summary: httplib patch to make _read_chunked() more robust

Initial Comment:
To reproduce:

import urllib2
print urllib2.urlopen("http://66.117.37.13/").read()


The attached patch "fixes" the hang, but that patch is
not acceptable because it also removes the .readline()
and .readlines() methods on the response object
returned by urllib2.urlopen().

The patch seems to demonstrate that the problem is
caused by the (ab)use of socket._fileobject in
urllib2.AbstractHTTPHandler (I believe this hack was
introduced when urllib2 switched to using
httplib.HTTPConnection).

Not sure yet what the actual problem is...


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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:38

Message:
Logged In: YES 
user_id=261020

First, expanding a bit on what I wrote on 2006-01-21: The
problem does relate to chunked encoding, and is unrelated to
urllib2's use of _fileobject.  My hack to remove use of
socket._fileobject from urllib2 merely breaks handling of
chunked encoding by cutting httplib.HTTPResponse out of the
picture.  The problem is seen in urllib2 in recent Pythons
thanks to urllib2 switching to use of httplib.HTTPConnection
and HTTP/1.1, hence chunked encoding is allowed.  urllib
still uses httplib.HTTP, hence HTTP/1.0, so is unaffected.
To reproduce with httplib:
import httplib
conn = httplib.HTTPConnection("66.117.37.13")
conn.request("GET", "/", headers={"Connection": "close"})
r1 = conn.getresponse()
print r1.read()
The Connection: close is required -- if it's not there the
server doesn't use chunked transfer-encoding.
I verified with a packet sniffer that the problem is that
this server does not send the final trailing CRLF required
by section 3.6.1 of RFC 2616.  However, that section also
says that trailers (trailing HTTP headers) MUST NOT be sent
by the server unless either a TE header was present and
indicated that trailers are acceptable (httplib does not
send the TE header), or the trailers are optional metadata
and may be discarded by the client.  So, I propose the
attached patch to httplib (chunk.patch) as a work-around.


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

Comment By: John J Lee (jjlee)
Date: 2006-01-21 22:10

Message:
Logged In: YES 
user_id=261020

In fact the commit message for rev 36871 states the real
reason _fileobject is used (handling chunked encoding),
showing my workaround is even more harmful than I thought. 
Moreover, doing a urlopen on 66.117.37.13 shows the response
*is* chunked.

The problem seems to be caused by httplib failing to find a
CRLF at the end of the chunked response, so the loop at the
end of _read_chunked() never terminates.  Haven't looked in
detail yet, but I'm guessing a) it's the server's fault and
b) httplib should work around it.


Here's the commit message from 36871:


Fix urllib2.urlopen() handling of chunked content encoding.

The change to use the newer httplib interface admitted the
possibility
that we'd get an HTTP/1.1 chunked response, but the code
didn't handle
it correctly.  The raw socket object can't be pass to
addinfourl(),
because it would read the undecoded response.  Instead,
addinfourl()
must call HTTPResponse.read(), which will handle the decoding.

One extra wrinkle is that the HTTPReponse object can't be
passed to
addinfourl() either, because it doesn't implement readline() or
readlines().  As a quick hack, use socket._fileobject(), which
implements those methods on top of a read buffer. 
(suggested by mwh)

Finally, add some tests based on test_urllibnet.

Thanks to Andrew Sawyers for originally reporting the
chunked problem.


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

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

From noreply at sourceforge.net  Mon Feb  6 02:09:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 17:09:36 -0800
Subject: [ python-Bugs-1396543 ] urlparse is confused by /
Message-ID: <E1F5usq-000503-J7@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Hansen (johnhansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse is confused by /

Initial Comment:
If the parameter field of a URL contains a '/', urlparse does not enter date 
in the parameter field, but leaves it attached to the path.

The simplified example is:
>>> urlparse.urlparse("http://f/adi;s=a;c=b/")
('http', 'f', '/adi;s=a;c=b/', '', '', '')

>>> urlparse.urlparse("http://f/adi;s=a;c=b")
('http', 'f', '/adi', 's=a;c=b', '', '')

The realworld case was:

>>> urlparse.urlparse("http://ad.doubleclick.net/adi/
N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/
adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId%
3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900%
3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D")
(''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/
B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink%
7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime
%3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews%
5Fgeneral%3Blink%3D', '', '', '')

What's odd is that the code specifically says to do this:
def _splitparams(url):
    if '/'  in url:
        i = url.find(';', url.rfind('/'))
        if i < 0:
            return url, ''

Is there a reason for the rfind?

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:09

Message:
Logged In: YES 
user_id=261020

The urlparse.urlparse() code should not be changed, for
backwards compatibility reasons.

As the docs for module urlparse explain, you should instead
use urlparse.urlsplit(), then another function to parse
parameters (that other function is not supplied by the
stdlib, IIRC).

Also, note that RFCs 3986 obsoletes RFC 2396 (see also RFC
3987).


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

Comment By: Peter van Kampen (pterk)
Date: 2006-01-14 21:19

Message:
Logged In: YES 
user_id=174455

Actually section 3.3 of RFC2396 is relevant here and it
seems that it is indeed correctly implemented as is.

I'm not sure what the 'python policy' is on RFC vs The Real
World. My guess would be that RFC's carry some weight.
Following the 'real world' is too vague a reference. Your
world might be different than mine and tomorrow's world a
different world than today's.

You can always monkey-patch:

>>> def my_splitparams(url):
...     i = url.find(';')
...     return url[:i], url[i+1:]
...
>>> import urlparse
>>> urlparse._splitparams = my_splitparams
>>> urlparse.urlparse("http://f/adi;s=a;c=b/")
('http', 'f', '/adi', 's=a;c=b/', '', '')


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

Comment By: John Hansen (johnhansen)
Date: 2006-01-13 18:19

Message:
Logged In: YES 
user_id=1418831

Well RFC2396, section 3.4 says "/" is reserved within a query. However, the real 
world doesn't seem to follow RFC2396... so I still think it's a bug: the class 
should be useful, rather than try to enforce an RFC. A warning would be fine.

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

Comment By: Peter van Kampen (pterk)
Date: 2006-01-13 00:25

Message:
Logged In: YES 
user_id=174455

Looking at the testcases it appears the answers must be in
rfc's 1808 or 2396. http://www.ietf.org/rfc/rfc1808.txt and
http://www.ietf.org/rfc/rfc2396.txt See for example section
5.3 of 1808. I don't see why _splitparams does what is does
but I didn't exactly close-read the text either. Also be
sure to look at Lib/test/test_urlparse.py.



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

Comment By: John Hansen (johnhansen)
Date: 2006-01-04 16:31

Message:
Logged In: YES 
user_id=1418831

The first line should have read:

If the parameter field of a URL contains a '/', urlparse does not enter it 
into the parameter field, but leaves it attached to the path.

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

Comment By: John Hansen (johnhansen)
Date: 2006-01-04 05:00

Message:
Logged In: YES 
user_id=1418831

The first line should have read:

If the parameter field of a URL contains a '/', urlparse does not enter it 
into the parameter field, but leaves it attached to the path.

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

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

From noreply at sourceforge.net  Mon Feb  6 02:16:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 17:16:10 -0800
Subject: [ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not
	listable.
Message-ID: <E1F5uzC-0007Sk-Je@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bugs Fly (mozbugbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/urllib2 cannot ftp files which are not listable.

Initial Comment:
For whatever reason (security, privacy), there are ftp
sites which will not allow ftp list command while
normal downloading can be performed "blindly". This
mostly happens on direct linked ftp urls.

In urllib.py, the ftp wrapper first check with
"self.ftp.nlst(file)" before downloading, thus prevent
the above sites from being useful. From the codes
around, I saw no reason this extra step/check was
performed at all. If the file really did not exist,
RETR would return a suitable error anyway as checked by
the code below.



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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:16

Message:
Logged In: YES 
user_id=261020

Bug 1281692 reports the same issue for the urllib case, and
includes a reference to the RFC.

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

Comment By: Bugs Fly (mozbugbox)
Date: 2005-11-17 05:38

Message:
Logged In: YES 
user_id=1033842

  File "/usr/lib/python2.4/ftplib.py", line 241, in sendcmd
    return self.getresp()
  File "/usr/lib/python2.4/ftplib.py", line 216, in getresp
    raise error_perm, resp
IOError: [Errno ftp error] [Errno ftp error] 550
tompda_685692_Professional.Palm.OS.Programming.part12.rar:
No such file or directory.


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

Comment By: Thomas Lee (krumms)
Date: 2005-11-15 13:34

Message:
Logged In: YES 
user_id=315535

what's the expected response/error code from the FTP server
if the NLST fails?

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

Comment By: Bugs Fly (mozbugbox)
Date: 2005-11-15 11:37

Message:
Logged In: YES 
user_id=1033842

This might be related to bug #635453 but this is a bigger
bug than a directory list is returned. If an existing file
cannot be retrieved, then functionally is totally broken,
there are no work around in this case.





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

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

From noreply at sourceforge.net  Mon Feb  6 02:16:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 17:16:49 -0800
Subject: [ python-Bugs-1281692 ] urllib violates rfc 959
Message-ID: <E1F5uzp-0007Su-5u@sc8-sf-web1.sourceforge.net>

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

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

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

python's urllib does the following things "on the line"
when retrieving
a file by ftp:
send(3, "PASV\r\n", 6, 0)               = 6
send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28

But RFC 959 states:
  This command [NLST] causes a directory listing to be
sent from server
  to user site.  The pathname should specify a
directory or other
  system-specific file group descriptor

So, according to the robustness principle, it is wrong
that python
aborts file transfer if the server refuses to support
NLST on files.


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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:16

Message:
Logged In: YES 
user_id=261020

Bug 1357260 reports the same issue for both urllib and urllib2.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-09-08 07:18

Message:
Logged In: YES 
user_id=341410

"The pathname should specify a directory or other
system-specific file group descriptor."

If the system (ftp server) does not support a particular
'file name' as a 'file group descriptor', it seems to me
that the system (ftp server) is braindead.

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

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

From noreply at sourceforge.net  Mon Feb  6 02:24:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 17:24:58 -0800
Subject: [ python-Bugs-1411097 ] httplib patch to make _read_chunked() more
	robust
Message-ID: <E1F5v7i-0007o0-RI@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib patch to make _read_chunked() more robust

Initial Comment:
To reproduce:

import urllib2
print urllib2.urlopen("http://66.117.37.13/").read()


The attached patch "fixes" the hang, but that patch is
not acceptable because it also removes the .readline()
and .readlines() methods on the response object
returned by urllib2.urlopen().

The patch seems to demonstrate that the problem is
caused by the (ab)use of socket._fileobject in
urllib2.AbstractHTTPHandler (I believe this hack was
introduced when urllib2 switched to using
httplib.HTTPConnection).

Not sure yet what the actual problem is...


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

>Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:24

Message:
Logged In: YES 
user_id=261020

Oops, fixed chunk.patch to .strip() before comparing to "".

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:38

Message:
Logged In: YES 
user_id=261020

First, expanding a bit on what I wrote on 2006-01-21: The
problem does relate to chunked encoding, and is unrelated to
urllib2's use of _fileobject.  My hack to remove use of
socket._fileobject from urllib2 merely breaks handling of
chunked encoding by cutting httplib.HTTPResponse out of the
picture.  The problem is seen in urllib2 in recent Pythons
thanks to urllib2 switching to use of httplib.HTTPConnection
and HTTP/1.1, hence chunked encoding is allowed.  urllib
still uses httplib.HTTP, hence HTTP/1.0, so is unaffected.
To reproduce with httplib:
import httplib
conn = httplib.HTTPConnection("66.117.37.13")
conn.request("GET", "/", headers={"Connection": "close"})
r1 = conn.getresponse()
print r1.read()
The Connection: close is required -- if it's not there the
server doesn't use chunked transfer-encoding.
I verified with a packet sniffer that the problem is that
this server does not send the final trailing CRLF required
by section 3.6.1 of RFC 2616.  However, that section also
says that trailers (trailing HTTP headers) MUST NOT be sent
by the server unless either a TE header was present and
indicated that trailers are acceptable (httplib does not
send the TE header), or the trailers are optional metadata
and may be discarded by the client.  So, I propose the
attached patch to httplib (chunk.patch) as a work-around.


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

Comment By: John J Lee (jjlee)
Date: 2006-01-21 22:10

Message:
Logged In: YES 
user_id=261020

In fact the commit message for rev 36871 states the real
reason _fileobject is used (handling chunked encoding),
showing my workaround is even more harmful than I thought. 
Moreover, doing a urlopen on 66.117.37.13 shows the response
*is* chunked.

The problem seems to be caused by httplib failing to find a
CRLF at the end of the chunked response, so the loop at the
end of _read_chunked() never terminates.  Haven't looked in
detail yet, but I'm guessing a) it's the server's fault and
b) httplib should work around it.


Here's the commit message from 36871:


Fix urllib2.urlopen() handling of chunked content encoding.

The change to use the newer httplib interface admitted the
possibility
that we'd get an HTTP/1.1 chunked response, but the code
didn't handle
it correctly.  The raw socket object can't be pass to
addinfourl(),
because it would read the undecoded response.  Instead,
addinfourl()
must call HTTPResponse.read(), which will handle the decoding.

One extra wrinkle is that the HTTPReponse object can't be
passed to
addinfourl() either, because it doesn't implement readline() or
readlines().  As a quick hack, use socket._fileobject(), which
implements those methods on top of a read buffer. 
(suggested by mwh)

Finally, add some tests based on test_urllibnet.

Thanks to Andrew Sawyers for originally reporting the
chunked problem.


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

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

From noreply at sourceforge.net  Mon Feb  6 04:42:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 05 Feb 2006 19:42:07 -0800
Subject: [ python-Bugs-1409455 ] email.Message.set_payload followed by bad
	result get_payload
Message-ID: <E1F5xGR-0001WB-UV@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sapiro (msapiro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Message.set_payload followed by bad result get_payload

Initial Comment:
Under certain circumstances, in particular when charset
is 'iso-8859-1', where msg is an email.Message() instance,

    msg.set_payload(text, charset)

'apparently' encodes the text as quoted-printable and
adds a

Content-Transfer-Encoding: quoted-printable

header to msg. I say 'apparently' because if one prints
msg or creates a Generator instance and writes msg to a
file, the message is printed/written as a correct,
quoted-printable encoded message, but

    text = msg._payload
or

    text = msg.get_payload()

gives the original text, not quoted-printable encoded, and

    text = msg.get_payload(decode=True)

gives a quoted-printable decoding of the original text
which is munged if the original text included '=' in
some ways.

This is causing problems in Mailman which are currently
worked around by flagging if the payload was set by
set_payload() and not subsequently 'decoding' in that
case, but it would be better if
set_payload()/get_payload() worked properly.

A script is attached which illustrates the problem.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-05 22:42

Message:
Logged In: YES 
user_id=12800

See the attached patch for what I think is ultimately the
right fix.  The idea is that when set_payload() is called,
the payload is immediately encoded so that get_payload()
will do the right thing.  Also, Generator.py has to be fixed
to not doubly encode the payload.

Run against your example, it seems to DTRT.  It also passes
all but one of the email pkg unit tests.  The one failure
is, I believe due to an incorrect test.  The patch includes
a fix for that as well as adding a test for
get_payload(decode=True).

I'd like to get some feedback from the email-sig before
applying this, but it seems right to me.

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

Comment By: Mark Sapiro (msapiro)
Date: 2006-01-20 18:19

Message:
Logged In: YES 
user_id=1123998

I've looked at the email library and I see the problem.
msg.set_payload() never QP encodes msg._payload. When the
message is stringified or flattened by a generator, the
generator's _handle_text() method does the encoding and it
is msg._charset that signals the need to do this. Thus when
the message object is ultimately converted to a suitable
external form, the body is QP encoded, but internally it
never is. Thus, subsequent msg.get_payload() calls return
unexpected results.

It appears (from minimal testing) that when a text message
is parsed into an email.Message.Message instance, _charset
is None even if there is a character set specification in a
Content-Type: header.

I have attached a patch (Message.py.patch.txt) which may fix
the problem. It has only been tested against the already
attached example.py so it is really untested. Also, it only
addresses the quoted-printable case. I haven't even thought
about whether there might be a similar problem involving base64.

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

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

From noreply at sourceforge.net  Mon Feb  6 09:24:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 00:24:39 -0800
Subject: [ python-Bugs-1373161 ] r41552 broke test_file on OS X
Message-ID: <E1F61fr-0001X0-P0@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: r41552 broke test_file on OS X

Initial Comment:
Apparently you *can* seek on sys.stdin here.  If you just want seek() to fail 
sys.stdin.seek(-1) seems pretty likely to work...

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-06 00:24

Message:
Logged In: YES 
user_id=33168

Closing since this doesn't seem to be a problem any more on
10.3 and 10.4

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-14 22:07

Message:
Logged In: YES 
user_id=33168

Michael, I reverted the tell() portion.  Do all the tests
work for you now?  Can this be closed?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-05 21:59

Message:
Logged In: YES 
user_id=33168

Sorry, I think I closed the report before I saw that there
was another problem.  From a man page, it looked like tell()
may fail if it is done on a pipe.  So maybe the problem
can't happen on OS X?  We could check if the system is
osx/darwin and skip the test.  Do you want to skip the test?
 Since it was for coverage and to ensure nothing bad goes
wrong with error handling, it's not awful that it can't be
provoked on osx.

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

Comment By: Michael Hudson (mwh)
Date: 2005-12-05 01:31

Message:
Logged In: YES 
user_id=6656

I suspect you know this from what I said on IRC, but test_file still fails, because 
you can tell() on sys.stdin too (I don't really see what you can do about this)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-04 17:17

Message:
Logged In: YES 
user_id=33168

revision 41602

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

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

From noreply at sourceforge.net  Mon Feb  6 11:29:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 02:29:18 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F63cU-0001B3-41@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

>Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-06 11:29

Message:
Logged In: YES 
user_id=972995

> http://python.org/sf/549151

the analyzation of the browsers is right. lynx is best ok to
ask.
But urllibX is not a browser (application) but a lib: As of
now with standard urllibX error handling you cannot code a lynx.

gvr's initial suggestion to raise a clear error (with
redirection-link as attribute of the exception value) is
best ok. Another option would be to simly yield the
undirected stub HTML and leave the 30X-code (and redirection
LOCATION in header).

To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib.
Transcribing smart a short formlike POST to a GET w QUERY
would be so la la.
Don't know if the MS & netscape's also transpose to GET with
long data? ...

The current behaviour is most worst of all 4. All other
methods whould at least have raisen an early hint/error in
my case.

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:54

Message:
Logged In: YES 
user_id=261020

This is not a bug.
See the long discussion here:
http://python.org/sf/549151

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-04 21:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

=======
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0
user agents
      will erroneously change it into a GET request.

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

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

From noreply at sourceforge.net  Mon Feb  6 11:44:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 02:44:09 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F63qr-0002aB-8X@sc8-sf-web3.sourceforge.net>

Bugs item #1425127, was opened at 2006-02-06 10: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=1425127&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

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

From noreply at sourceforge.net  Mon Feb  6 15:07:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 06:07:54 -0800
Subject: [ python-Feature Requests-1425256 ] Support for MSVC 7 and MSVC8 in
	msvccompiler
Message-ID: <E1F6722-0002he-Fs@sc8-sf-web1.sourceforge.net>

Feature Requests item #1425256, was opened at 2006-02-06 15:07
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=1425256&group_id=5470

Please note that this 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
Submitted By: dlm (davidlukas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for MSVC 7 and MSVC8 in msvccompiler

Initial Comment:
Hi,

I tried to build the "ctypes-0.9.6" packages from
source with Microsoft Visual Studio 8 (2005). I
realized that in  module "distutils" of Python 2.4.1
both VC7 and VC8 compilers are not supported at all
(only VC6).
I took a glance at distutils at Python 2.4.2 but also
there no VC8 is supported.

I tried to figure out where I should extend the
compiler detection, but the whole file
"msvccompiler.py" seems to me like a big hack. I've
wrote some code, to get VC8 working on my machine (set
right pathes to Include- and Lib-Directories and to the
binaries), but I don't think it's redistributable.

What do you think of detecting the right MS-Compiler
like this:

def detectCompiler() :
    detectVC6()
    detectVC7()
    detectVC8()

and hiding the code for each particular version of VC
in a separate function. I don't think MS is following a
streight upwards compatibility strategy.

Also ther should be a way, to select on compiler, when
multiple compilers are detected. I saw the

   --compiler=whatever

switch, but did not found any documentation on it.

I've got both versions (VC7 and VC8) installed on my
machine. So I can try out different detection routines
if you want.

Another problem with VC8 is cross-compiling, since ther
e are different library-directories for different
platforms (AMD64, x86, Itanium, Win32, ...). Also here
I see big deficits in the distutil-module at the moment.

Best regards
David

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

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

From noreply at sourceforge.net  Mon Feb  6 18:57:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 09:57:18 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F6Ac2-0005nx-K5@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 12:57

Message:
Logged In: YES 
user_id=764593

In theory, a GET may be automatic, but a POST requires user 
interaction, so the user can be held accountable for the 
results of a POST, but not of a GET.

Often, the page will respond to either; not sending the 
queries protects privacy in case of problems, and works more 
often than not.  (That said, I too would prefer a raised 
error or a transparent repost, at least as options.)

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-06 05:29

Message:
Logged In: YES 
user_id=972995

> http://python.org/sf/549151

the analyzation of the browsers is right. lynx is best ok to
ask.
But urllibX is not a browser (application) but a lib: As of
now with standard urllibX error handling you cannot code a lynx.

gvr's initial suggestion to raise a clear error (with
redirection-link as attribute of the exception value) is
best ok. Another option would be to simly yield the
undirected stub HTML and leave the 30X-code (and redirection
LOCATION in header).

To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib.
Transcribing smart a short formlike POST to a GET w QUERY
would be so la la.
Don't know if the MS & netscape's also transpose to GET with
long data? ...

The current behaviour is most worst of all 4. All other
methods whould at least have raisen an early hint/error in
my case.

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

Comment By: John J Lee (jjlee)
Date: 2006-02-05 19:54

Message:
Logged In: YES 
user_id=261020

This is not a bug.
See the long discussion here:
http://python.org/sf/549151

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-04 15:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

=======
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0
user agents
      will erroneously change it into a GET request.

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

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

From noreply at sourceforge.net  Mon Feb  6 19:28:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 10:28:25 -0800
Subject: [ python-Bugs-1425482 ] msvccompiler.py modified to work with .NET
	2005 on win64
Message-ID: <E1F6B69-0008KU-SI@sc8-sf-web2.sourceforge.net>

Bugs item #1425482, was opened at 2006-02-06 13: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=1425482&group_id=5470

Please note that this 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
Submitted By: beaudrym (beaudrym)
Assigned to: Nobody/Anonymous (nobody)
Summary: msvccompiler.py modified to work with .NET 2005 on win64

Initial Comment:
Hi,

I tried to compile and install pywin32 (python 
extension) using Microsoft Visual Studio .NET 2005.  
This was done on a AMD64 platform which had Python 
2.4.2.10 installed (from www.activestate.com).

When I try to compile pywin32, it uses the file 
msvccompiler.py that comes with python.  For the 
compilation to work, I had to modify 
msvccompiler.py.  I attached a patch file of my 
modifications.  Basically, I had to modify two things:

1 - use .NET framework 2.0 when 1.1 is not found.
2 - use environment variables "path", "lib" 
and "included" already defined in console when 
compiling with Visual Studio 8.0.  See comments in 
patch file for more details.

Let me know if these patches look reasonable to you.

Regards,
Maxime

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

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

From noreply at sourceforge.net  Mon Feb  6 21:24:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 12:24:33 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F6CuX-0001de-Fl@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 20:24

Message:
Logged In: YES 
user_id=261020

First, anyone replying to this, *please* read this page (and
the whole of this tracker note!) first:

http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html


kxroberto: you say that with standard urllibX error handling
you cannot get an exception on redirected 301/302/307 POST.
 That's not true of urllib2, since you may override
HTTPRedirectHandler.redirect_request(), which method was
designed and documented for precisely that purpose.  It
seems sensible to have a default that does what virtually
all browsers do (speaking as a long-time lynx user!).  I
don't know about the urllib case.

It's perfectly reasonable to extend urllib (if necessary) to
allow the option of raising an exception.  Note that (IIRC!)
 urllib's exceptions do not contain the response body data,
however (urllib2's HTTPErrors do contain the response body
data).

It would of course break backwards compatibility to start
raising exceptions by default here.  I don't think it's
reasonable to break old code on the basis of a notional
security issue when the de-facto standard web client
behaviour is to do the redirect.  In reality, the the only
"security" value of the original prescriptive rule was as a
convention to be followed by white-hat web programmers and
web client implementors to help users avoid unintentionally
re-submitting non-idempotent requests.  Since that
convention is NOT followed in the real world (lynx doesn't
count as the real world ;-), I see no value in sticking
rigidly to the original RFC spec -- especially when 2616
even provides 307 precisely in response to this problem. 
Other web client libraries, for example libwww-perl and Java
HTTPClient, do the same as Python here IIRC.  RFC 2616
section 10.3.4 even suggests web programmers use 302 to get
the behaviour you complain about!

The only doubtful case here is 301.  A decision was made on
the default behaviour in that case back when the tracker
item I pointed you to was resolved.  I think it's a mistake
to change our minds again on that default behaviour.


kxroberto.seek(nrBytes)
assert kxroberto.readline() == """\
To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib."""

No.  There is no value in supporting behaviour which is
simply contrary to both de-facto and prescriptive standards
(see final paragraph of RFC 2616 section 10.3.3: if we
accept the "GET on POST redirect" rule, we must accept that
the Location header is exactly the URL that should be
followed).  FYI, many servers return a redirect URL
containing the urlencoded POST data from the original request.


kxroberto: """Don't know if the MS & netscape's also
transpose to GET with long data? ..."""

urllib2's behaviour (and urllib's, I believe) on these
issues is identical to that of IE and Firefox.


jimjewett: """In theory, a GET may be automatic, but a POST
requires user interaction, so the user can be held
accountable for the results of a POST, but not of a GET."""

That theory has been experimentally falsified ;-)


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 17:57

Message:
Logged In: YES 
user_id=764593

In theory, a GET may be automatic, but a POST requires user 
interaction, so the user can be held accountable for the 
results of a POST, but not of a GET.

Often, the page will respond to either; not sending the 
queries protects privacy in case of problems, and works more 
often than not.  (That said, I too would prefer a raised 
error or a transparent repost, at least as options.)

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-06 10:29

Message:
Logged In: YES 
user_id=972995

> http://python.org/sf/549151

the analyzation of the browsers is right. lynx is best ok to
ask.
But urllibX is not a browser (application) but a lib: As of
now with standard urllibX error handling you cannot code a lynx.

gvr's initial suggestion to raise a clear error (with
redirection-link as attribute of the exception value) is
best ok. Another option would be to simly yield the
undirected stub HTML and leave the 30X-code (and redirection
LOCATION in header).

To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib.
Transcribing smart a short formlike POST to a GET w QUERY
would be so la la.
Don't know if the MS & netscape's also transpose to GET with
long data? ...

The current behaviour is most worst of all 4. All other
methods whould at least have raisen an early hint/error in
my case.

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:54

Message:
Logged In: YES 
user_id=261020

This is not a bug.
See the long discussion here:
http://python.org/sf/549151

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-04 20:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

=======
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0
user agents
      will erroneously change it into a GET request.

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

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

From noreply at sourceforge.net  Mon Feb  6 21:36:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 12:36:19 -0800
Subject: [ python-Bugs-1411097 ] httplib patch to make _read_chunked() more
	robust
Message-ID: <E1F6D5v-0005UE-Gn@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib patch to make _read_chunked() more robust

Initial Comment:
To reproduce:

import urllib2
print urllib2.urlopen("http://66.117.37.13/").read()


The attached patch "fixes" the hang, but that patch is
not acceptable because it also removes the .readline()
and .readlines() methods on the response object
returned by urllib2.urlopen().

The patch seems to demonstrate that the problem is
caused by the (ab)use of socket._fileobject in
urllib2.AbstractHTTPHandler (I believe this hack was
introduced when urllib2 switched to using
httplib.HTTPConnection).

Not sure yet what the actual problem is...


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

>Comment By: John J Lee (jjlee)
Date: 2006-02-06 20:36

Message:
Logged In: YES 
user_id=261020

I missed the fact that, if the connection will not close at
the end of the transaction, the behaviour should not change
from what's currently in SVN (we should not assume that the
chunked response has ended unless we see the proper
terminating CRLF).  I intend to upload a slightly modified
patch that tests for self._will_close, and behaves accordingly.


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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:24

Message:
Logged In: YES 
user_id=261020

Oops, fixed chunk.patch to .strip() before comparing to "".

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:38

Message:
Logged In: YES 
user_id=261020

First, expanding a bit on what I wrote on 2006-01-21: The
problem does relate to chunked encoding, and is unrelated to
urllib2's use of _fileobject.  My hack to remove use of
socket._fileobject from urllib2 merely breaks handling of
chunked encoding by cutting httplib.HTTPResponse out of the
picture.  The problem is seen in urllib2 in recent Pythons
thanks to urllib2 switching to use of httplib.HTTPConnection
and HTTP/1.1, hence chunked encoding is allowed.  urllib
still uses httplib.HTTP, hence HTTP/1.0, so is unaffected.
To reproduce with httplib:
import httplib
conn = httplib.HTTPConnection("66.117.37.13")
conn.request("GET", "/", headers={"Connection": "close"})
r1 = conn.getresponse()
print r1.read()
The Connection: close is required -- if it's not there the
server doesn't use chunked transfer-encoding.
I verified with a packet sniffer that the problem is that
this server does not send the final trailing CRLF required
by section 3.6.1 of RFC 2616.  However, that section also
says that trailers (trailing HTTP headers) MUST NOT be sent
by the server unless either a TE header was present and
indicated that trailers are acceptable (httplib does not
send the TE header), or the trailers are optional metadata
and may be discarded by the client.  So, I propose the
attached patch to httplib (chunk.patch) as a work-around.


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

Comment By: John J Lee (jjlee)
Date: 2006-01-21 22:10

Message:
Logged In: YES 
user_id=261020

In fact the commit message for rev 36871 states the real
reason _fileobject is used (handling chunked encoding),
showing my workaround is even more harmful than I thought. 
Moreover, doing a urlopen on 66.117.37.13 shows the response
*is* chunked.

The problem seems to be caused by httplib failing to find a
CRLF at the end of the chunked response, so the loop at the
end of _read_chunked() never terminates.  Haven't looked in
detail yet, but I'm guessing a) it's the server's fault and
b) httplib should work around it.


Here's the commit message from 36871:


Fix urllib2.urlopen() handling of chunked content encoding.

The change to use the newer httplib interface admitted the
possibility
that we'd get an HTTP/1.1 chunked response, but the code
didn't handle
it correctly.  The raw socket object can't be pass to
addinfourl(),
because it would read the undecoded response.  Instead,
addinfourl()
must call HTTPResponse.read(), which will handle the decoding.

One extra wrinkle is that the HTTPReponse object can't be
passed to
addinfourl() either, because it doesn't implement readline() or
readlines().  As a quick hack, use socket._fileobject(), which
implements those methods on top of a read buffer. 
(suggested by mwh)

Finally, add some tests based on test_urllibnet.

Thanks to Andrew Sawyers for originally reporting the
chunked problem.


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

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

From noreply at sourceforge.net  Mon Feb  6 21:52:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 12:52:25 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F6DLV-0006K5-VC@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 15:52

Message:
Logged In: YES 
user_id=764593

Sorry, I was trying to provide a quick explanation of why we 
couldn't just "do the obvious thing" and repost with data.

Yes, I realize that in practice, GET is used for non-
idempotent actions, and POST is (though less often) done 
automatically.

But since that is the official policy, I wouldn't want to 
bet too heavily against it in a courtroom -- so python 
defaults should be at least as conservative as both the spec 
and the common practice.  

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 15:24

Message:
Logged In: YES 
user_id=261020

First, anyone replying to this, *please* read this page (and
the whole of this tracker note!) first:

http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html


kxroberto: you say that with standard urllibX error handling
you cannot get an exception on redirected 301/302/307 POST.
 That's not true of urllib2, since you may override
HTTPRedirectHandler.redirect_request(), which method was
designed and documented for precisely that purpose.  It
seems sensible to have a default that does what virtually
all browsers do (speaking as a long-time lynx user!).  I
don't know about the urllib case.

It's perfectly reasonable to extend urllib (if necessary) to
allow the option of raising an exception.  Note that (IIRC!)
 urllib's exceptions do not contain the response body data,
however (urllib2's HTTPErrors do contain the response body
data).

It would of course break backwards compatibility to start
raising exceptions by default here.  I don't think it's
reasonable to break old code on the basis of a notional
security issue when the de-facto standard web client
behaviour is to do the redirect.  In reality, the the only
"security" value of the original prescriptive rule was as a
convention to be followed by white-hat web programmers and
web client implementors to help users avoid unintentionally
re-submitting non-idempotent requests.  Since that
convention is NOT followed in the real world (lynx doesn't
count as the real world ;-), I see no value in sticking
rigidly to the original RFC spec -- especially when 2616
even provides 307 precisely in response to this problem. 
Other web client libraries, for example libwww-perl and Java
HTTPClient, do the same as Python here IIRC.  RFC 2616
section 10.3.4 even suggests web programmers use 302 to get
the behaviour you complain about!

The only doubtful case here is 301.  A decision was made on
the default behaviour in that case back when the tracker
item I pointed you to was resolved.  I think it's a mistake
to change our minds again on that default behaviour.


kxroberto.seek(nrBytes)
assert kxroberto.readline() == """\
To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib."""

No.  There is no value in supporting behaviour which is
simply contrary to both de-facto and prescriptive standards
(see final paragraph of RFC 2616 section 10.3.3: if we
accept the "GET on POST redirect" rule, we must accept that
the Location header is exactly the URL that should be
followed).  FYI, many servers return a redirect URL
containing the urlencoded POST data from the original request.


kxroberto: """Don't know if the MS & netscape's also
transpose to GET with long data? ..."""

urllib2's behaviour (and urllib's, I believe) on these
issues is identical to that of IE and Firefox.


jimjewett: """In theory, a GET may be automatic, but a POST
requires user interaction, so the user can be held
accountable for the results of a POST, but not of a GET."""

That theory has been experimentally falsified ;-)


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 12:57

Message:
Logged In: YES 
user_id=764593

In theory, a GET may be automatic, but a POST requires user 
interaction, so the user can be held accountable for the 
results of a POST, but not of a GET.

Often, the page will respond to either; not sending the 
queries protects privacy in case of problems, and works more 
often than not.  (That said, I too would prefer a raised 
error or a transparent repost, at least as options.)

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-06 05:29

Message:
Logged In: YES 
user_id=972995

> http://python.org/sf/549151

the analyzation of the browsers is right. lynx is best ok to
ask.
But urllibX is not a browser (application) but a lib: As of
now with standard urllibX error handling you cannot code a lynx.

gvr's initial suggestion to raise a clear error (with
redirection-link as attribute of the exception value) is
best ok. Another option would be to simly yield the
undirected stub HTML and leave the 30X-code (and redirection
LOCATION in header).

To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib.
Transcribing smart a short formlike POST to a GET w QUERY
would be so la la.
Don't know if the MS & netscape's also transpose to GET with
long data? ...

The current behaviour is most worst of all 4. All other
methods whould at least have raisen an early hint/error in
my case.

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

Comment By: John J Lee (jjlee)
Date: 2006-02-05 19:54

Message:
Logged In: YES 
user_id=261020

This is not a bug.
See the long discussion here:
http://python.org/sf/549151

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-04 15:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

=======
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0
user agents
      will erroneously change it into a GET request.

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

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

From noreply at sourceforge.net  Mon Feb  6 22:18:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 13:18:32 -0800
Subject: [ python-Bugs-1411097 ] httplib patch to make _read_chunked() more
	robust
Message-ID: <E1F6Dkm-0007kc-Qj@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib patch to make _read_chunked() more robust

Initial Comment:
To reproduce:

import urllib2
print urllib2.urlopen("http://66.117.37.13/").read()


The attached patch "fixes" the hang, but that patch is
not acceptable because it also removes the .readline()
and .readlines() methods on the response object
returned by urllib2.urlopen().

The patch seems to demonstrate that the problem is
caused by the (ab)use of socket._fileobject in
urllib2.AbstractHTTPHandler (I believe this hack was
introduced when urllib2 switched to using
httplib.HTTPConnection).

Not sure yet what the actual problem is...


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

>Comment By: John J Lee (jjlee)
Date: 2006-02-06 21:18

Message:
Logged In: YES 
user_id=261020

Conservative or not, I see no utility in changing the
default, and several major harmful effects: old code breaks,
and people have to pore over the specs to figure out why
"urlopen() doesn't work".


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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 20:36

Message:
Logged In: YES 
user_id=261020

I missed the fact that, if the connection will not close at
the end of the transaction, the behaviour should not change
from what's currently in SVN (we should not assume that the
chunked response has ended unless we see the proper
terminating CRLF).  I intend to upload a slightly modified
patch that tests for self._will_close, and behaves accordingly.


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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:24

Message:
Logged In: YES 
user_id=261020

Oops, fixed chunk.patch to .strip() before comparing to "".

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:38

Message:
Logged In: YES 
user_id=261020

First, expanding a bit on what I wrote on 2006-01-21: The
problem does relate to chunked encoding, and is unrelated to
urllib2's use of _fileobject.  My hack to remove use of
socket._fileobject from urllib2 merely breaks handling of
chunked encoding by cutting httplib.HTTPResponse out of the
picture.  The problem is seen in urllib2 in recent Pythons
thanks to urllib2 switching to use of httplib.HTTPConnection
and HTTP/1.1, hence chunked encoding is allowed.  urllib
still uses httplib.HTTP, hence HTTP/1.0, so is unaffected.
To reproduce with httplib:
import httplib
conn = httplib.HTTPConnection("66.117.37.13")
conn.request("GET", "/", headers={"Connection": "close"})
r1 = conn.getresponse()
print r1.read()
The Connection: close is required -- if it's not there the
server doesn't use chunked transfer-encoding.
I verified with a packet sniffer that the problem is that
this server does not send the final trailing CRLF required
by section 3.6.1 of RFC 2616.  However, that section also
says that trailers (trailing HTTP headers) MUST NOT be sent
by the server unless either a TE header was present and
indicated that trailers are acceptable (httplib does not
send the TE header), or the trailers are optional metadata
and may be discarded by the client.  So, I propose the
attached patch to httplib (chunk.patch) as a work-around.


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

Comment By: John J Lee (jjlee)
Date: 2006-01-21 22:10

Message:
Logged In: YES 
user_id=261020

In fact the commit message for rev 36871 states the real
reason _fileobject is used (handling chunked encoding),
showing my workaround is even more harmful than I thought. 
Moreover, doing a urlopen on 66.117.37.13 shows the response
*is* chunked.

The problem seems to be caused by httplib failing to find a
CRLF at the end of the chunked response, so the loop at the
end of _read_chunked() never terminates.  Haven't looked in
detail yet, but I'm guessing a) it's the server's fault and
b) httplib should work around it.


Here's the commit message from 36871:


Fix urllib2.urlopen() handling of chunked content encoding.

The change to use the newer httplib interface admitted the
possibility
that we'd get an HTTP/1.1 chunked response, but the code
didn't handle
it correctly.  The raw socket object can't be pass to
addinfourl(),
because it would read the undecoded response.  Instead,
addinfourl()
must call HTTPResponse.read(), which will handle the decoding.

One extra wrinkle is that the HTTPReponse object can't be
passed to
addinfourl() either, because it doesn't implement readline() or
readlines().  As a quick hack, use socket._fileobject(), which
implements those methods on top of a read buffer. 
(suggested by mwh)

Finally, add some tests based on test_urllibnet.

Thanks to Andrew Sawyers for originally reporting the
chunked problem.


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

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

From noreply at sourceforge.net  Mon Feb  6 22:19:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 13:19:30 -0800
Subject: [ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal
	looses data on POST!
Message-ID: <E1F6Dli-0007nz-CE@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl)


... has to become ...


    def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
        if 'location' in headers:
            newurl = headers['location']
        elif 'uri' in headers:
            newurl = headers['uri']
        else:
            return
        void = fp.read()
        fp.close()
        # In case the server sent a relative URL, join
with original:
        newurl = basejoin(self.type + ":" + url, newurl)
        return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 21:19

Message:
Logged In: YES 
user_id=261020

Conservative or not, I see no utility in changing the
default, and several major harmful effects: old code breaks,
and people have to pore over the specs to figure out why
"urlopen() doesn't work".


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 20:52

Message:
Logged In: YES 
user_id=764593

Sorry, I was trying to provide a quick explanation of why we 
couldn't just "do the obvious thing" and repost with data.

Yes, I realize that in practice, GET is used for non-
idempotent actions, and POST is (though less often) done 
automatically.

But since that is the official policy, I wouldn't want to 
bet too heavily against it in a courtroom -- so python 
defaults should be at least as conservative as both the spec 
and the common practice.  

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 20:24

Message:
Logged In: YES 
user_id=261020

First, anyone replying to this, *please* read this page (and
the whole of this tracker note!) first:

http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html


kxroberto: you say that with standard urllibX error handling
you cannot get an exception on redirected 301/302/307 POST.
 That's not true of urllib2, since you may override
HTTPRedirectHandler.redirect_request(), which method was
designed and documented for precisely that purpose.  It
seems sensible to have a default that does what virtually
all browsers do (speaking as a long-time lynx user!).  I
don't know about the urllib case.

It's perfectly reasonable to extend urllib (if necessary) to
allow the option of raising an exception.  Note that (IIRC!)
 urllib's exceptions do not contain the response body data,
however (urllib2's HTTPErrors do contain the response body
data).

It would of course break backwards compatibility to start
raising exceptions by default here.  I don't think it's
reasonable to break old code on the basis of a notional
security issue when the de-facto standard web client
behaviour is to do the redirect.  In reality, the the only
"security" value of the original prescriptive rule was as a
convention to be followed by white-hat web programmers and
web client implementors to help users avoid unintentionally
re-submitting non-idempotent requests.  Since that
convention is NOT followed in the real world (lynx doesn't
count as the real world ;-), I see no value in sticking
rigidly to the original RFC spec -- especially when 2616
even provides 307 precisely in response to this problem. 
Other web client libraries, for example libwww-perl and Java
HTTPClient, do the same as Python here IIRC.  RFC 2616
section 10.3.4 even suggests web programmers use 302 to get
the behaviour you complain about!

The only doubtful case here is 301.  A decision was made on
the default behaviour in that case back when the tracker
item I pointed you to was resolved.  I think it's a mistake
to change our minds again on that default behaviour.


kxroberto.seek(nrBytes)
assert kxroberto.readline() == """\
To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib."""

No.  There is no value in supporting behaviour which is
simply contrary to both de-facto and prescriptive standards
(see final paragraph of RFC 2616 section 10.3.3: if we
accept the "GET on POST redirect" rule, we must accept that
the Location header is exactly the URL that should be
followed).  FYI, many servers return a redirect URL
containing the urlencoded POST data from the original request.


kxroberto: """Don't know if the MS & netscape's also
transpose to GET with long data? ..."""

urllib2's behaviour (and urllib's, I believe) on these
issues is identical to that of IE and Firefox.


jimjewett: """In theory, a GET may be automatic, but a POST
requires user interaction, so the user can be held
accountable for the results of a POST, but not of a GET."""

That theory has been experimentally falsified ;-)


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

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 17:57

Message:
Logged In: YES 
user_id=764593

In theory, a GET may be automatic, but a POST requires user 
interaction, so the user can be held accountable for the 
results of a POST, but not of a GET.

Often, the page will respond to either; not sending the 
queries protects privacy in case of problems, and works more 
often than not.  (That said, I too would prefer a raised 
error or a transparent repost, at least as options.)

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-06 10:29

Message:
Logged In: YES 
user_id=972995

> http://python.org/sf/549151

the analyzation of the browsers is right. lynx is best ok to
ask.
But urllibX is not a browser (application) but a lib: As of
now with standard urllibX error handling you cannot code a lynx.

gvr's initial suggestion to raise a clear error (with
redirection-link as attribute of the exception value) is
best ok. Another option would be to simly yield the
undirected stub HTML and leave the 30X-code (and redirection
LOCATION in header).

To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib.
Transcribing smart a short formlike POST to a GET w QUERY
would be so la la.
Don't know if the MS & netscape's also transpose to GET with
long data? ...

The current behaviour is most worst of all 4. All other
methods whould at least have raisen an early hint/error in
my case.

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:54

Message:
Logged In: YES 
user_id=261020

This is not a bug.
See the long discussion here:
http://python.org/sf/549151

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-04 20:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

=======
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0
user agents
      will erroneously change it into a GET request.

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

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

From noreply at sourceforge.net  Mon Feb  6 22:21:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 13:21:02 -0800
Subject: [ python-Bugs-1411097 ] httplib patch to make _read_chunked() more
	robust
Message-ID: <E1F6DnC-0005cq-JM@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib patch to make _read_chunked() more robust

Initial Comment:
To reproduce:

import urllib2
print urllib2.urlopen("http://66.117.37.13/").read()


The attached patch "fixes" the hang, but that patch is
not acceptable because it also removes the .readline()
and .readlines() methods on the response object
returned by urllib2.urlopen().

The patch seems to demonstrate that the problem is
caused by the (ab)use of socket._fileobject in
urllib2.AbstractHTTPHandler (I believe this hack was
introduced when urllib2 switched to using
httplib.HTTPConnection).

Not sure yet what the actual problem is...


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

>Comment By: John J Lee (jjlee)
Date: 2006-02-06 21:20

Message:
Logged In: YES 
user_id=261020

Please ignore last comment (posted to wrong tracker item).

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 21:18

Message:
Logged In: YES 
user_id=261020

Conservative or not, I see no utility in changing the
default, and several major harmful effects: old code breaks,
and people have to pore over the specs to figure out why
"urlopen() doesn't work".


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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 20:36

Message:
Logged In: YES 
user_id=261020

I missed the fact that, if the connection will not close at
the end of the transaction, the behaviour should not change
from what's currently in SVN (we should not assume that the
chunked response has ended unless we see the proper
terminating CRLF).  I intend to upload a slightly modified
patch that tests for self._will_close, and behaves accordingly.


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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:24

Message:
Logged In: YES 
user_id=261020

Oops, fixed chunk.patch to .strip() before comparing to "".

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

Comment By: John J Lee (jjlee)
Date: 2006-02-06 00:38

Message:
Logged In: YES 
user_id=261020

First, expanding a bit on what I wrote on 2006-01-21: The
problem does relate to chunked encoding, and is unrelated to
urllib2's use of _fileobject.  My hack to remove use of
socket._fileobject from urllib2 merely breaks handling of
chunked encoding by cutting httplib.HTTPResponse out of the
picture.  The problem is seen in urllib2 in recent Pythons
thanks to urllib2 switching to use of httplib.HTTPConnection
and HTTP/1.1, hence chunked encoding is allowed.  urllib
still uses httplib.HTTP, hence HTTP/1.0, so is unaffected.
To reproduce with httplib:
import httplib
conn = httplib.HTTPConnection("66.117.37.13")
conn.request("GET", "/", headers={"Connection": "close"})
r1 = conn.getresponse()
print r1.read()
The Connection: close is required -- if it's not there the
server doesn't use chunked transfer-encoding.
I verified with a packet sniffer that the problem is that
this server does not send the final trailing CRLF required
by section 3.6.1 of RFC 2616.  However, that section also
says that trailers (trailing HTTP headers) MUST NOT be sent
by the server unless either a TE header was present and
indicated that trailers are acceptable (httplib does not
send the TE header), or the trailers are optional metadata
and may be discarded by the client.  So, I propose the
attached patch to httplib (chunk.patch) as a work-around.


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

Comment By: John J Lee (jjlee)
Date: 2006-01-21 22:10

Message:
Logged In: YES 
user_id=261020

In fact the commit message for rev 36871 states the real
reason _fileobject is used (handling chunked encoding),
showing my workaround is even more harmful than I thought. 
Moreover, doing a urlopen on 66.117.37.13 shows the response
*is* chunked.

The problem seems to be caused by httplib failing to find a
CRLF at the end of the chunked response, so the loop at the
end of _read_chunked() never terminates.  Haven't looked in
detail yet, but I'm guessing a) it's the server's fault and
b) httplib should work around it.


Here's the commit message from 36871:


Fix urllib2.urlopen() handling of chunked content encoding.

The change to use the newer httplib interface admitted the
possibility
that we'd get an HTTP/1.1 chunked response, but the code
didn't handle
it correctly.  The raw socket object can't be pass to
addinfourl(),
because it would read the undecoded response.  Instead,
addinfourl()
must call HTTPResponse.read(), which will handle the decoding.

One extra wrinkle is that the HTTPReponse object can't be
passed to
addinfourl() either, because it doesn't implement readline() or
readlines().  As a quick hack, use socket._fileobject(), which
implements those methods on top of a read buffer. 
(suggested by mwh)

Finally, add some tests based on test_urllibnet.

Thanks to Andrew Sawyers for originally reporting the
chunked problem.


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

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

From noreply at sourceforge.net  Mon Feb  6 22:50:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 13:50:26 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F6EFe-0002bZ-Id@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

>Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 22:50

Message:
Logged In: YES 
user_id=38376

If Python gives you a permission error, that's because
Windows cannot remove the file.  Windows does, in general,
not allow you to remove files that are held open by some
process.

I suggest taking this issue to comp.lang.python.  The bug
tracker is not the right place for code review and other
support issues.

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

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

From noreply at sourceforge.net  Mon Feb  6 22:55:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 13:55:49 -0800
Subject: [ python-Bugs-1424171 ] patch for etree cdata and attr quoting
Message-ID: <E1F6EKr-0002sO-Eg@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Fredrik Lundh (effbot)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example "&quote;" with 
"&amp;quote;" or "&amp;" with "&amp;amp;", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

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

>Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 22:55

Message:
Logged In: YES 
user_id=38376

I'm not sure I follow.  ET works on the infoset side of
things, where everything is decoded into Unicode strings (or
compatible ASCII strings).  If you set an attribute to
"&amp;" in the infoset, it *must* be encoded on the way out.  
If you want an ampersand, use "&".

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 21:23

Message:
Logged In: YES 
user_id=32974

Egads, I did this time.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-04 19:29

Message:
Logged In: YES 
user_id=1188172

OP: You did check the box?

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 19:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

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

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

From noreply at sourceforge.net  Mon Feb  6 23:19:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 14:19:23 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F6Ehf-0008Km-3L@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

>Comment By: Tim Peters (tim_one)
Date: 2006-02-06 17:19

Message:
Logged In: YES 
user_id=31435

The problem is that there's no reason to believe anything he
did here _does_ leave files open.  I can confirm the
"permission denied" symptom, and even if I arrange for the
call to "touch" to run a touch.bat that doesn't even look at
the filename passed to it (let alone open or modify the file).

I also see a large number of errors of this sort:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "C:\python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "osremove.py", line 21, in run
    touch(filename)
  File "osremove.py", line 8, in touch
    stdin=None, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
  File "C:\python24\lib\subprocess.py", line 490, in __init__
    _cleanup()
  File "C:\python24\lib\subprocess.py", line 398, in _cleanup
    inst.poll()
  File "C:\python24\lib\subprocess.py", line 739, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Those are clearly due to subprocess.py internals on Windows,
where the poll() and wait() methods and the module internal
_cleanup() function aren't called in mutually threadsafe
ways.  _Those_ errors can be stopped by commenting out the
_cleanup() call at the start of Popen.__init__() (think
about what happens when multiple threads call _cleanup() at
overlapping times on Windows:  all those threads can end up
trying to remove the same items from _active, but only one
thread per item can succeed).

The "permission denied" errors persist, though.

So there's at least one class of subprocess.py Windows bugs
here, and another class of Windows mysteries.  I believe
subprocess.py is a red herring wrt the latter, though.  For
example, I see much the same if I use os.system() to run
`touch` instead.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 16:50

Message:
Logged In: YES 
user_id=38376

If Python gives you a permission error, that's because
Windows cannot remove the file.  Windows does, in general,
not allow you to remove files that are held open by some
process.

I suggest taking this issue to comp.lang.python.  The bug
tracker is not the right place for code review and other
support issues.

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

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

From noreply at sourceforge.net  Mon Feb  6 23:39:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 14:39:12 -0800
Subject: [ python-Bugs-1421696 ] http response dictionary incomplete
Message-ID: <E1F6F0q-0005Ag-C9@sc8-sf-web2.sourceforge.net>

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

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

Initial Comment:
httplib and BaseHTTPServer each maintain their own copy 
of possible response codes.

They don't agree.

It looks like the one in httplib is a superset of the 
one in BaseHTTPServer.BaseHTTPRequestHandler.responses, 
and httplib is the logical place for it, but

(1)  They map in opposite directions.

(2)  The httplib version is just a bunch of names at 
the module toplevel, with no particular grouping that 
separates them from random classes, or makes them easy 
to import as a group.

(3)  The httplib names are explicitly not exported.



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

>Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 17:39

Message:
Logged In: YES 
user_id=764593

That may make the cleanup more urgent.  The mapping in 
urllib2 is new with 2.5, so it should still be fine to 
remove it, or forward to httplib.

The mapping in httplib is explicitly not exported, as there 
is an __all__ which excludes them, so it *should* be 
legitimate to remove them in a new release.

BaseHTTPServer places the mapping as a class attribute on a 
public class.  Therefore, either the final location has to 
include both the message and the long message (so that 
BaseHTTPServer can import it and delegate), or this has to 
be the final location, or we can't at best get down to two.

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

Comment By: John J Lee (jjlee)
Date: 2006-02-05 19:56

Message:
Logged In: YES 
user_id=261020

There's also one in urllib2 :-(

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

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

From noreply at sourceforge.net  Mon Feb  6 23:53:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 14:53:40 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F6FEq-0006HC-NA@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

>Comment By: cheops (atila-cheops)
Date: 2006-02-06 22:53

Message:
Logged In: YES 
user_id=1276121

I did post on the python mailing list first, but got no 
responce there, after further looking into it, I seriously 
think there is at least one bug here.

here is the link to the post: 
http://mail.python.org/pipermail/python-list/2006-
February/323650.html

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

Comment By: Tim Peters (tim_one)
Date: 2006-02-06 22:19

Message:
Logged In: YES 
user_id=31435

The problem is that there's no reason to believe anything he
did here _does_ leave files open.  I can confirm the
"permission denied" symptom, and even if I arrange for the
call to "touch" to run a touch.bat that doesn't even look at
the filename passed to it (let alone open or modify the file).

I also see a large number of errors of this sort:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "C:\python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "osremove.py", line 21, in run
    touch(filename)
  File "osremove.py", line 8, in touch
    stdin=None, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
  File "C:\python24\lib\subprocess.py", line 490, in __init__
    _cleanup()
  File "C:\python24\lib\subprocess.py", line 398, in _cleanup
    inst.poll()
  File "C:\python24\lib\subprocess.py", line 739, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Those are clearly due to subprocess.py internals on Windows,
where the poll() and wait() methods and the module internal
_cleanup() function aren't called in mutually threadsafe
ways.  _Those_ errors can be stopped by commenting out the
_cleanup() call at the start of Popen.__init__() (think
about what happens when multiple threads call _cleanup() at
overlapping times on Windows:  all those threads can end up
trying to remove the same items from _active, but only one
thread per item can succeed).

The "permission denied" errors persist, though.

So there's at least one class of subprocess.py Windows bugs
here, and another class of Windows mysteries.  I believe
subprocess.py is a red herring wrt the latter, though.  For
example, I see much the same if I use os.system() to run
`touch` instead.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 21:50

Message:
Logged In: YES 
user_id=38376

If Python gives you a permission error, that's because
Windows cannot remove the file.  Windows does, in general,
not allow you to remove files that are held open by some
process.

I suggest taking this issue to comp.lang.python.  The bug
tracker is not the right place for code review and other
support issues.

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

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

From noreply at sourceforge.net  Tue Feb  7 00:05:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 15:05:12 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F6FQ0-0006cF-U6@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

>Comment By: Fredrik Lundh (effbot)
Date: 2006-02-07 00:05

Message:
Logged In: YES 
user_id=38376

> The problem is that there's no reason to believe anything
> he did here _does_ leave files open.

Except that he's hitting the file system quite heavily, and
asyncronously.  My guess is that Windows simply gets behind
(a quick filemon test indicates that this is indeed the
case; just before a crash, I see the events CREATE/SUCCESS,
QUERY/SUCCESS, QUERY/SUCCESS, WRITE/SUCCESS, and
OPEN/SHARING VIOLATION for the failing file, with lots of
requests for other files interleaved).

Unless someone wants to fix Windows, a simple workaround
would be to retry the os.remove a few times before giving up
(with a time.sleep(0.1) in between).

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

Comment By: cheops (atila-cheops)
Date: 2006-02-06 23:53

Message:
Logged In: YES 
user_id=1276121

I did post on the python mailing list first, but got no 
responce there, after further looking into it, I seriously 
think there is at least one bug here.

here is the link to the post: 
http://mail.python.org/pipermail/python-list/2006-
February/323650.html

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

Comment By: Tim Peters (tim_one)
Date: 2006-02-06 23:19

Message:
Logged In: YES 
user_id=31435

The problem is that there's no reason to believe anything he
did here _does_ leave files open.  I can confirm the
"permission denied" symptom, and even if I arrange for the
call to "touch" to run a touch.bat that doesn't even look at
the filename passed to it (let alone open or modify the file).

I also see a large number of errors of this sort:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "C:\python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "osremove.py", line 21, in run
    touch(filename)
  File "osremove.py", line 8, in touch
    stdin=None, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
  File "C:\python24\lib\subprocess.py", line 490, in __init__
    _cleanup()
  File "C:\python24\lib\subprocess.py", line 398, in _cleanup
    inst.poll()
  File "C:\python24\lib\subprocess.py", line 739, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Those are clearly due to subprocess.py internals on Windows,
where the poll() and wait() methods and the module internal
_cleanup() function aren't called in mutually threadsafe
ways.  _Those_ errors can be stopped by commenting out the
_cleanup() call at the start of Popen.__init__() (think
about what happens when multiple threads call _cleanup() at
overlapping times on Windows:  all those threads can end up
trying to remove the same items from _active, but only one
thread per item can succeed).

The "permission denied" errors persist, though.

So there's at least one class of subprocess.py Windows bugs
here, and another class of Windows mysteries.  I believe
subprocess.py is a red herring wrt the latter, though.  For
example, I see much the same if I use os.system() to run
`touch` instead.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 22:50

Message:
Logged In: YES 
user_id=38376

If Python gives you a permission error, that's because
Windows cannot remove the file.  Windows does, in general,
not allow you to remove files that are held open by some
process.

I suggest taking this issue to comp.lang.python.  The bug
tracker is not the right place for code review and other
support issues.

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

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

From noreply at sourceforge.net  Tue Feb  7 05:07:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 20:07:03 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F6K87-00076v-Oz@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

>Comment By: Tim Peters (tim_one)
Date: 2006-02-06 23:07

Message:
Logged In: YES 
user_id=31435

[/F]
> Except that he's hitting the file system quite heavily,

Except that _without_ the call to touch(), he's hitting it
even more heavily, creating and destroying little files just
as fast as the OS can do it in each of 10 threads -- but
there aren't any errors then.

> and asyncronously.

What's asynch here?  The OP's touch() function waits for the
spawned process to terminate, and the test driver doesn't
try to delete the file until after that.

> My guess is that Windows simply gets behind
> (a quick filemon test indicates that this is indeed the
> case; just before a crash, I see the events
> CREATE/SUCCESS, QUERY/SUCCESS, QUERY/SUCCESS,
> WRITE/SUCCESS, and OPEN/SHARING VIOLATION for the
> failing file, with lots of requests for other files
> interleaved).

That's consistent with the symptom reported:  an exception
raised upon trying to remove the file, but not during any
other file operation.  Does it tell you more than _just_
that?  It doesn't for me.

> Unless someone wants to fix Windows,

As above, because removing the call to the internal `touch`
function makes all problems go away it's not obvious that
this is a Windows problem.

> a simple workaround would be to retry the os.remove a
> few times before giving up (with a time.sleep(0.1) in
> between).

Because of the internal threading errors in subprocess.py
(see my first comment), the threads in the test program
still usually die, but with instances of list.remove(x)
ValueErrors internal to subprocess.py.

If I hack around that, then this change to the test
program's file-removal code appears adequate to eliminate
all errors on my box (which is a zippy 3.4 GHz):

            try:
                os.remove(filename)
            except OSError:
                time.sleep(0.1)
                os.remove(filename)

It's possible that some virus-scanning or file-indexing
gimmick on my box is opening these little files for its own
purposes -- although, if so, I'm at a loss to account for
why a single "os.remove(filename)" never raises an exception
when the `touch()` call is commented out.

OTOH, with the `touch()` call intact, the time.sleep(0.1)
above is not adequate to prevent os.remove() errors if I
change the file-writing code to:

    f.write("test" * 250000)

Even boosting the sleep() to 0.4 isn't enough then.

That does (mildly) suggest there's another process opening
the temp files, and doing something with them that takes
time proportional to the file size.  However, the
os.remove() errors persist when I disable all such gimmicks
(that I know about ;-)) on my box.

It seems likely I'll never determine a cause for that.  The
bad thread behavior in subprocess.py is independent, and
should be repaired regardless.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 18:05

Message:
Logged In: YES 
user_id=38376

> The problem is that there's no reason to believe anything
> he did here _does_ leave files open.

Except that he's hitting the file system quite heavily, and
asyncronously.  My guess is that Windows simply gets behind
(a quick filemon test indicates that this is indeed the
case; just before a crash, I see the events CREATE/SUCCESS,
QUERY/SUCCESS, QUERY/SUCCESS, WRITE/SUCCESS, and
OPEN/SHARING VIOLATION for the failing file, with lots of
requests for other files interleaved).

Unless someone wants to fix Windows, a simple workaround
would be to retry the os.remove a few times before giving up
(with a time.sleep(0.1) in between).

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

Comment By: cheops (atila-cheops)
Date: 2006-02-06 17:53

Message:
Logged In: YES 
user_id=1276121

I did post on the python mailing list first, but got no 
responce there, after further looking into it, I seriously 
think there is at least one bug here.

here is the link to the post: 
http://mail.python.org/pipermail/python-list/2006-
February/323650.html

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

Comment By: Tim Peters (tim_one)
Date: 2006-02-06 17:19

Message:
Logged In: YES 
user_id=31435

The problem is that there's no reason to believe anything he
did here _does_ leave files open.  I can confirm the
"permission denied" symptom, and even if I arrange for the
call to "touch" to run a touch.bat that doesn't even look at
the filename passed to it (let alone open or modify the file).

I also see a large number of errors of this sort:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "C:\python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "osremove.py", line 21, in run
    touch(filename)
  File "osremove.py", line 8, in touch
    stdin=None, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
  File "C:\python24\lib\subprocess.py", line 490, in __init__
    _cleanup()
  File "C:\python24\lib\subprocess.py", line 398, in _cleanup
    inst.poll()
  File "C:\python24\lib\subprocess.py", line 739, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Those are clearly due to subprocess.py internals on Windows,
where the poll() and wait() methods and the module internal
_cleanup() function aren't called in mutually threadsafe
ways.  _Those_ errors can be stopped by commenting out the
_cleanup() call at the start of Popen.__init__() (think
about what happens when multiple threads call _cleanup() at
overlapping times on Windows:  all those threads can end up
trying to remove the same items from _active, but only one
thread per item can succeed).

The "permission denied" errors persist, though.

So there's at least one class of subprocess.py Windows bugs
here, and another class of Windows mysteries.  I believe
subprocess.py is a red herring wrt the latter, though.  For
example, I see much the same if I use os.system() to run
`touch` instead.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 16:50

Message:
Logged In: YES 
user_id=38376

If Python gives you a permission error, that's because
Windows cannot remove the file.  Windows does, in general,
not allow you to remove files that are held open by some
process.

I suggest taking this issue to comp.lang.python.  The bug
tracker is not the right place for code review and other
support issues.

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

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

From noreply at sourceforge.net  Tue Feb  7 08:18:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 23:18:12 -0800
Subject: [ python-Bugs-876637 ] Random stack corruption from socketmodule.c 
Message-ID: <E1F6N76-0007Yc-Fv@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Pall (mikesfpy)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Random stack corruption from socketmodule.c 

Initial Comment:
THE PROBLEM:

The implementation of the socket_object.settimeout() method
(socketmodule.c, function internal_select()) uses the select() system
call with an unbounded file descriptor number. This will cause random
stack corruption if fd>=FD_SETSIZE.

This took me ages to track down! It happened with a massively 
multithreaded
and massively connection-swamped network server. Basically most of 
the
descriptors did not use that routine (because they were either pure 
blocking
or pure non-blocking). But one module used settimeout() and with a little
bit of luck got an fd>=FD_SETSIZE and with even more luck corrupted 
the
stack and took down the whole server process.

Demonstration script appended.

THE SOLUTION:

The solution is to use poll() and to favour poll() even if select()
is available on a platform. The current trend in modern OS+libc
combinations is to emulate select() in libc and call kernel-level poll()
anyway. And this emulation is costly (both for the caller and for libc).

Not so the other way round (only some systems of historical interest
do that BTW), so we definitely want to use poll() if it's available
(even if it's an emulation).

And if select() is your only choice, then check for FD_SETSIZE before
using the FD_SET macro (and raise some strange exception if that fails).

[
I should note that using SO_RCVTIMEO and SO_SNDTIMEO would be a lot 
more
efficient (kernel-wise at least). Unfortunately they are not universally
available (though defined by most system header files). But a simple
runtime test with a fallback to poll()/select() would do.
]

A PATCH, A PATCH?

Well, the check for FD_SETSIZE is left as an exercise for the reader. :-)
Don't forget to merge this with the stray select() way down by adding 
a return value to internal_select().

But yes, I can do a 'real' patch with poll() [and even one with the
SO_RCVTIMEO trick if you are adventurous]. But, I can't test it with
dozens of platforms, various include files, compilers and so on.

So, dear Python core developers: Please discuss this and tell me,
if you want a patch, then you'll get one ASAP.

Thank you for your time!


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-06 23:18

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42253.
Committed revision 42254. (2.4)


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

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-10 04:15

Message:
Logged In: YES 
user_id=32863

I have created a patch to make socketmodule use poll() when
available. See http://python.org/sf/970288

(I'm not allowed to attach patches to this bug item.)


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

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

From noreply at sourceforge.net  Tue Feb  7 08:59:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 06 Feb 2006 23:59:49 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F6NlN-0003NK-RF@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

>Comment By: Fredrik Lundh (effbot)
Date: 2006-02-07 08:59

Message:
Logged In: YES 
user_id=38376

"Does it tell you more than _just_ that?  It doesn't for me."

All requests against the file in question were issued by the
python process; there's no sign of virus checkers or other
external applications.

Also, whenever things failed, there were always multiple
requests for cmd.exe (caused by os.system) between the WRITE
request and the failing OPEN request.
 
My feel, after staring at filemon output, is that this is a
problem in the Windows file I/O layer.  NTFS queues the
various operations, and calling an external process with
stuff still in the queue messes up the request scheduling.

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

Comment By: Tim Peters (tim_one)
Date: 2006-02-07 05:07

Message:
Logged In: YES 
user_id=31435

[/F]
> Except that he's hitting the file system quite heavily,

Except that _without_ the call to touch(), he's hitting it
even more heavily, creating and destroying little files just
as fast as the OS can do it in each of 10 threads -- but
there aren't any errors then.

> and asyncronously.

What's asynch here?  The OP's touch() function waits for the
spawned process to terminate, and the test driver doesn't
try to delete the file until after that.

> My guess is that Windows simply gets behind
> (a quick filemon test indicates that this is indeed the
> case; just before a crash, I see the events
> CREATE/SUCCESS, QUERY/SUCCESS, QUERY/SUCCESS,
> WRITE/SUCCESS, and OPEN/SHARING VIOLATION for the
> failing file, with lots of requests for other files
> interleaved).

That's consistent with the symptom reported:  an exception
raised upon trying to remove the file, but not during any
other file operation.  Does it tell you more than _just_
that?  It doesn't for me.

> Unless someone wants to fix Windows,

As above, because removing the call to the internal `touch`
function makes all problems go away it's not obvious that
this is a Windows problem.

> a simple workaround would be to retry the os.remove a
> few times before giving up (with a time.sleep(0.1) in
> between).

Because of the internal threading errors in subprocess.py
(see my first comment), the threads in the test program
still usually die, but with instances of list.remove(x)
ValueErrors internal to subprocess.py.

If I hack around that, then this change to the test
program's file-removal code appears adequate to eliminate
all errors on my box (which is a zippy 3.4 GHz):

            try:
                os.remove(filename)
            except OSError:
                time.sleep(0.1)
                os.remove(filename)

It's possible that some virus-scanning or file-indexing
gimmick on my box is opening these little files for its own
purposes -- although, if so, I'm at a loss to account for
why a single "os.remove(filename)" never raises an exception
when the `touch()` call is commented out.

OTOH, with the `touch()` call intact, the time.sleep(0.1)
above is not adequate to prevent os.remove() errors if I
change the file-writing code to:

    f.write("test" * 250000)

Even boosting the sleep() to 0.4 isn't enough then.

That does (mildly) suggest there's another process opening
the temp files, and doing something with them that takes
time proportional to the file size.  However, the
os.remove() errors persist when I disable all such gimmicks
(that I know about ;-)) on my box.

It seems likely I'll never determine a cause for that.  The
bad thread behavior in subprocess.py is independent, and
should be repaired regardless.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-07 00:05

Message:
Logged In: YES 
user_id=38376

> The problem is that there's no reason to believe anything
> he did here _does_ leave files open.

Except that he's hitting the file system quite heavily, and
asyncronously.  My guess is that Windows simply gets behind
(a quick filemon test indicates that this is indeed the
case; just before a crash, I see the events CREATE/SUCCESS,
QUERY/SUCCESS, QUERY/SUCCESS, WRITE/SUCCESS, and
OPEN/SHARING VIOLATION for the failing file, with lots of
requests for other files interleaved).

Unless someone wants to fix Windows, a simple workaround
would be to retry the os.remove a few times before giving up
(with a time.sleep(0.1) in between).

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

Comment By: cheops (atila-cheops)
Date: 2006-02-06 23:53

Message:
Logged In: YES 
user_id=1276121

I did post on the python mailing list first, but got no 
responce there, after further looking into it, I seriously 
think there is at least one bug here.

here is the link to the post: 
http://mail.python.org/pipermail/python-list/2006-
February/323650.html

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

Comment By: Tim Peters (tim_one)
Date: 2006-02-06 23:19

Message:
Logged In: YES 
user_id=31435

The problem is that there's no reason to believe anything he
did here _does_ leave files open.  I can confirm the
"permission denied" symptom, and even if I arrange for the
call to "touch" to run a touch.bat that doesn't even look at
the filename passed to it (let alone open or modify the file).

I also see a large number of errors of this sort:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "C:\python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "osremove.py", line 21, in run
    touch(filename)
  File "osremove.py", line 8, in touch
    stdin=None, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
  File "C:\python24\lib\subprocess.py", line 490, in __init__
    _cleanup()
  File "C:\python24\lib\subprocess.py", line 398, in _cleanup
    inst.poll()
  File "C:\python24\lib\subprocess.py", line 739, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Those are clearly due to subprocess.py internals on Windows,
where the poll() and wait() methods and the module internal
_cleanup() function aren't called in mutually threadsafe
ways.  _Those_ errors can be stopped by commenting out the
_cleanup() call at the start of Popen.__init__() (think
about what happens when multiple threads call _cleanup() at
overlapping times on Windows:  all those threads can end up
trying to remove the same items from _active, but only one
thread per item can succeed).

The "permission denied" errors persist, though.

So there's at least one class of subprocess.py Windows bugs
here, and another class of Windows mysteries.  I believe
subprocess.py is a red herring wrt the latter, though.  For
example, I see much the same if I use os.system() to run
`touch` instead.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 22:50

Message:
Logged In: YES 
user_id=38376

If Python gives you a permission error, that's because
Windows cannot remove the file.  Windows does, in general,
not allow you to remove files that are held open by some
process.

I suggest taking this issue to comp.lang.python.  The bug
tracker is not the right place for code review and other
support issues.

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

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

From noreply at sourceforge.net  Tue Feb  7 12:32:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Feb 2006 03:32:22 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F6R54-0003kF-GX@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

>Comment By: cheops (atila-cheops)
Date: 2006-02-07 11:32

Message:
Logged In: YES 
user_id=1276121

for the subprocess.py I did the following in a few places

try:
    _active.remove(self)
except:
    pass

see also bug 1199282
https://sourceforge.net/tracker/index.php?func=detail&aid=1199282&group_id=5470&atid=105470

in my current script I circumvent the "Permission denied"
error in the following way:

removed = False
while not removed:
try:
    os.remove(file)
    except OSError, error:
        logger.warning("could not remove file %s, %s"
%(file, error))
        time.sleep(1)
    else:
        removed = True

I also have a virus scanner (Mcafee, corporate stuff), and
still get the same behaviour when disabling the virus scanner.

>My feel, after staring at filemon output, is that this is a
>problem in the Windows file I/O layer.  NTFS queues the
>various operations, and calling an external process with
>stuff still in the queue messes up the request scheduling.

this seems strange to me, since every thread works with its
own temp files, and all requests are send one after another
to the file I/O layer

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-07 07:59

Message:
Logged In: YES 
user_id=38376

"Does it tell you more than _just_ that?  It doesn't for me."

All requests against the file in question were issued by the
python process; there's no sign of virus checkers or other
external applications.

Also, whenever things failed, there were always multiple
requests for cmd.exe (caused by os.system) between the WRITE
request and the failing OPEN request.
 
My feel, after staring at filemon output, is that this is a
problem in the Windows file I/O layer.  NTFS queues the
various operations, and calling an external process with
stuff still in the queue messes up the request scheduling.

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

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

Message:
Logged In: YES 
user_id=31435

[/F]
> Except that he's hitting the file system quite heavily,

Except that _without_ the call to touch(), he's hitting it
even more heavily, creating and destroying little files just
as fast as the OS can do it in each of 10 threads -- but
there aren't any errors then.

> and asyncronously.

What's asynch here?  The OP's touch() function waits for the
spawned process to terminate, and the test driver doesn't
try to delete the file until after that.

> My guess is that Windows simply gets behind
> (a quick filemon test indicates that this is indeed the
> case; just before a crash, I see the events
> CREATE/SUCCESS, QUERY/SUCCESS, QUERY/SUCCESS,
> WRITE/SUCCESS, and OPEN/SHARING VIOLATION for the
> failing file, with lots of requests for other files
> interleaved).

That's consistent with the symptom reported:  an exception
raised upon trying to remove the file, but not during any
other file operation.  Does it tell you more than _just_
that?  It doesn't for me.

> Unless someone wants to fix Windows,

As above, because removing the call to the internal `touch`
function makes all problems go away it's not obvious that
this is a Windows problem.

> a simple workaround would be to retry the os.remove a
> few times before giving up (with a time.sleep(0.1) in
> between).

Because of the internal threading errors in subprocess.py
(see my first comment), the threads in the test program
still usually die, but with instances of list.remove(x)
ValueErrors internal to subprocess.py.

If I hack around that, then this change to the test
program's file-removal code appears adequate to eliminate
all errors on my box (which is a zippy 3.4 GHz):

            try:
                os.remove(filename)
            except OSError:
                time.sleep(0.1)
                os.remove(filename)

It's possible that some virus-scanning or file-indexing
gimmick on my box is opening these little files for its own
purposes -- although, if so, I'm at a loss to account for
why a single "os.remove(filename)" never raises an exception
when the `touch()` call is commented out.

OTOH, with the `touch()` call intact, the time.sleep(0.1)
above is not adequate to prevent os.remove() errors if I
change the file-writing code to:

    f.write("test" * 250000)

Even boosting the sleep() to 0.4 isn't enough then.

That does (mildly) suggest there's another process opening
the temp files, and doing something with them that takes
time proportional to the file size.  However, the
os.remove() errors persist when I disable all such gimmicks
(that I know about ;-)) on my box.

It seems likely I'll never determine a cause for that.  The
bad thread behavior in subprocess.py is independent, and
should be repaired regardless.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 23:05

Message:
Logged In: YES 
user_id=38376

> The problem is that there's no reason to believe anything
> he did here _does_ leave files open.

Except that he's hitting the file system quite heavily, and
asyncronously.  My guess is that Windows simply gets behind
(a quick filemon test indicates that this is indeed the
case; just before a crash, I see the events CREATE/SUCCESS,
QUERY/SUCCESS, QUERY/SUCCESS, WRITE/SUCCESS, and
OPEN/SHARING VIOLATION for the failing file, with lots of
requests for other files interleaved).

Unless someone wants to fix Windows, a simple workaround
would be to retry the os.remove a few times before giving up
(with a time.sleep(0.1) in between).

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

Comment By: cheops (atila-cheops)
Date: 2006-02-06 22:53

Message:
Logged In: YES 
user_id=1276121

I did post on the python mailing list first, but got no 
responce there, after further looking into it, I seriously 
think there is at least one bug here.

here is the link to the post: 
http://mail.python.org/pipermail/python-list/2006-
February/323650.html

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

Comment By: Tim Peters (tim_one)
Date: 2006-02-06 22:19

Message:
Logged In: YES 
user_id=31435

The problem is that there's no reason to believe anything he
did here _does_ leave files open.  I can confirm the
"permission denied" symptom, and even if I arrange for the
call to "touch" to run a touch.bat that doesn't even look at
the filename passed to it (let alone open or modify the file).

I also see a large number of errors of this sort:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "C:\python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "osremove.py", line 21, in run
    touch(filename)
  File "osremove.py", line 8, in touch
    stdin=None, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
  File "C:\python24\lib\subprocess.py", line 490, in __init__
    _cleanup()
  File "C:\python24\lib\subprocess.py", line 398, in _cleanup
    inst.poll()
  File "C:\python24\lib\subprocess.py", line 739, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Those are clearly due to subprocess.py internals on Windows,
where the poll() and wait() methods and the module internal
_cleanup() function aren't called in mutually threadsafe
ways.  _Those_ errors can be stopped by commenting out the
_cleanup() call at the start of Popen.__init__() (think
about what happens when multiple threads call _cleanup() at
overlapping times on Windows:  all those threads can end up
trying to remove the same items from _active, but only one
thread per item can succeed).

The "permission denied" errors persist, though.

So there's at least one class of subprocess.py Windows bugs
here, and another class of Windows mysteries.  I believe
subprocess.py is a red herring wrt the latter, though.  For
example, I see much the same if I use os.system() to run
`touch` instead.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 21:50

Message:
Logged In: YES 
user_id=38376

If Python gives you a permission error, that's because
Windows cannot remove the file.  Windows does, in general,
not allow you to remove files that are held open by some
process.

I suggest taking this issue to comp.lang.python.  The bug
tracker is not the right place for code review and other
support issues.

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

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

From noreply at sourceforge.net  Wed Feb  8 01:06:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Feb 2006 16:06:27 -0800
Subject: [ python-Bugs-1409538 ] email.Charset.py CODEC_MAP no longer requires
	'japanese'
Message-ID: <E1F6cqp-0007x4-3s@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Charset.py CODEC_MAP no longer requires 'japanese'

Initial Comment:
The commonly used JapaneseCodecs no longer requires
'japanese' prefix in codec specification.  On the other
hand if a user install CJKCodecs instead of
JapaneseCodecs, 'japanese' prefix cause error.

This was already fixed in email-3.0 (Python 2.4) but
should be fixed in email-2.5.x if we want to support
mailman-2.2 for Python 2.3.

It looks like 'korean' can also be stripped.

See attached patch.


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

>Comment By: Tokio Kikuchi (tkikuchi)
Date: 2006-02-08 00:06

Message:
Logged In: YES 
user_id=67709

Looks like we should retain CODEC_MAP in order to properly
encode Japanese text into iso-2022-jp (canonical japanese
message charset).  We need lines like this:

CODEC_MAP = {
    'euc-jp':      'euc-jp',
    'iso-2022-jp': 'iso-2022-jp',
...
    'us-ascii':    None
}



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

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

From noreply at sourceforge.net  Wed Feb  8 04:07:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Feb 2006 19:07:02 -0800
Subject: [ python-Bugs-1409538 ] email.Charset.py CODEC_MAP no longer requires
	'japanese'
Message-ID: <E1F6ffa-0006x0-J4@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Charset.py CODEC_MAP no longer requires 'japanese'

Initial Comment:
The commonly used JapaneseCodecs no longer requires
'japanese' prefix in codec specification.  On the other
hand if a user install CJKCodecs instead of
JapaneseCodecs, 'japanese' prefix cause error.

This was already fixed in email-3.0 (Python 2.4) but
should be fixed in email-2.5.x if we want to support
mailman-2.2 for Python 2.3.

It looks like 'korean' can also be stripped.

See attached patch.


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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-07 22:07

Message:
Logged In: YES 
user_id=12800

The attached patch addresses the issue both in this issue
and in 1409544.  It's a bit more extensive because it tries
to figure out whether the Japanese and Korean codecs are
available under their Python 2.4 names or under their old
names.  I've run this test under all Pythons from 2.1 to
2.5, albeit without the third party codecs under anything
before 2.4.

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

Comment By: Tokio Kikuchi (tkikuchi)
Date: 2006-02-07 19:06

Message:
Logged In: YES 
user_id=67709

Looks like we should retain CODEC_MAP in order to properly
encode Japanese text into iso-2022-jp (canonical japanese
message charset).  We need lines like this:

CODEC_MAP = {
    'euc-jp':      'euc-jp',
    'iso-2022-jp': 'iso-2022-jp',
...
    'us-ascii':    None
}



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

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

From noreply at sourceforge.net  Wed Feb  8 04:07:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 07 Feb 2006 19:07:38 -0800
Subject: [ python-Bugs-1409455 ] email.Message.set_payload followed by bad
	result get_payload
Message-ID: <E1F6fgA-0006z7-SN@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sapiro (msapiro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Message.set_payload followed by bad result get_payload

Initial Comment:
Under certain circumstances, in particular when charset
is 'iso-8859-1', where msg is an email.Message() instance,

    msg.set_payload(text, charset)

'apparently' encodes the text as quoted-printable and
adds a

Content-Transfer-Encoding: quoted-printable

header to msg. I say 'apparently' because if one prints
msg or creates a Generator instance and writes msg to a
file, the message is printed/written as a correct,
quoted-printable encoded message, but

    text = msg._payload
or

    text = msg.get_payload()

gives the original text, not quoted-printable encoded, and

    text = msg.get_payload(decode=True)

gives a quoted-printable decoding of the original text
which is munged if the original text included '=' in
some ways.

This is causing problems in Mailman which are currently
worked around by flagging if the payload was set by
set_payload() and not subsequently 'decoding' in that
case, but it would be better if
set_payload()/get_payload() worked properly.

A script is attached which illustrates the problem.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-07 22:07

Message:
Logged In: YES 
user_id=12800

See the latest patch in issue 1409458:

https://sourceforge.net/support/tracker.php?aid=1409538


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-05 22:42

Message:
Logged In: YES 
user_id=12800

See the attached patch for what I think is ultimately the
right fix.  The idea is that when set_payload() is called,
the payload is immediately encoded so that get_payload()
will do the right thing.  Also, Generator.py has to be fixed
to not doubly encode the payload.

Run against your example, it seems to DTRT.  It also passes
all but one of the email pkg unit tests.  The one failure
is, I believe due to an incorrect test.  The patch includes
a fix for that as well as adding a test for
get_payload(decode=True).

I'd like to get some feedback from the email-sig before
applying this, but it seems right to me.

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

Comment By: Mark Sapiro (msapiro)
Date: 2006-01-20 18:19

Message:
Logged In: YES 
user_id=1123998

I've looked at the email library and I see the problem.
msg.set_payload() never QP encodes msg._payload. When the
message is stringified or flattened by a generator, the
generator's _handle_text() method does the encoding and it
is msg._charset that signals the need to do this. Thus when
the message object is ultimately converted to a suitable
external form, the body is QP encoded, but internally it
never is. Thus, subsequent msg.get_payload() calls return
unexpected results.

It appears (from minimal testing) that when a text message
is parsed into an email.Message.Message instance, _charset
is None even if there is a character set specification in a
Content-Type: header.

I have attached a patch (Message.py.patch.txt) which may fix
the problem. It has only been tested against the already
attached example.py so it is really untested. Also, it only
addresses the quoted-printable case. I haven't even thought
about whether there might be a similar problem involving base64.

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

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

From noreply at sourceforge.net  Wed Feb  8 15:13:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 06:13:54 -0800
Subject: [ python-Bugs-1427552 ] tarfile.open bug / corrupt data
Message-ID: <E1F6q4w-0004BS-PV@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris86 (chris86)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.open bug / corrupt data

Initial Comment:
Hi!

I want to create a bz2 compressed tar file.
Here is my code:
full="/home/test/test.sql"
tar = tarfile.open("test.tar.bz2", "w:bz2")
tarinfo = tar.gettarinfo(full,"blubb.sql")
tar.addfile(tarinfo,file(full))
tar.close()

i think this should work, but the sql file is corrupt:
- the created sql file in the compressed tar has only
4745 Lines, the original file has 4753


Regards,
Chris

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

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

From noreply at sourceforge.net  Wed Feb  8 15:14:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 06:14:28 -0800
Subject: [ python-Bugs-1427552 ] tarfile.open bug / corrupt data
Message-ID: <E1F6q5U-0004Ec-2l@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: 7
Submitted By: Chris86 (chris86)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.open bug / corrupt data

Initial Comment:
Hi!

I want to create a bz2 compressed tar file.
Here is my code:
full="/home/test/test.sql"
tar = tarfile.open("test.tar.bz2", "w:bz2")
tarinfo = tar.gettarinfo(full,"blubb.sql")
tar.addfile(tarinfo,file(full))
tar.close()

i think this should work, but the sql file is corrupt:
- the created sql file in the compressed tar has only
4745 Lines, the original file has 4753


Regards,
Chris

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

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

From noreply at sourceforge.net  Wed Feb  8 15:15:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 06:15:14 -0800
Subject: [ python-Bugs-1427552 ] tarfile.open bug / corrupt data
Message-ID: <E1F6q6E-0004Hp-I1@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: 7
Submitted By: Chris86 (chris86)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.open bug / corrupt data

Initial Comment:
Hi!

I want to create a bz2 compressed tar file.
Here is my code:
full="/home/test/test.sql"
tar = tarfile.open("test.tar.bz2", "w:bz2")
tarinfo = tar.gettarinfo(full,"blubb.sql")
tar.addfile(tarinfo,file(full))
tar.close()

i think this should work, but the sql file is corrupt:
- the created sql file in the compressed tar has only
4745 Lines, the original file has 4753


Regards,
Chris

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

>Comment By: Chris86 (chris86)
Date: 2006-02-08 14:15

Message:
Logged In: YES 
user_id=1133569

I'm using Python 2.4.2 (#2, Nov 20 2005, 17:04:48)
[GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2

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

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

From noreply at sourceforge.net  Wed Feb  8 16:13:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 07:13:31 -0800
Subject: [ python-Bugs-1427552 ] tarfile.open bug / corrupt data
Message-ID: <E1F6r0d-0007F0-J3@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: 7
Submitted By: Chris86 (chris86)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.open bug / corrupt data

Initial Comment:
Hi!

I want to create a bz2 compressed tar file.
Here is my code:
full="/home/test/test.sql"
tar = tarfile.open("test.tar.bz2", "w:bz2")
tarinfo = tar.gettarinfo(full,"blubb.sql")
tar.addfile(tarinfo,file(full))
tar.close()

i think this should work, but the sql file is corrupt:
- the created sql file in the compressed tar has only
4745 Lines, the original file has 4753


Regards,
Chris

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

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-02-08 16:13

Message:
Logged In: YES 
user_id=642936

Just to identify whether this is a tarfile or bz2 module
related issue:
- Do you have the same problem without compression or with
gzip compression?
- Have you tried compressing your sql file directly with the
bz2 module? 

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

Comment By: Chris86 (chris86)
Date: 2006-02-08 15:17

Message:
Logged In: YES 
user_id=1133569

same error with Python 2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2


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

Comment By: Chris86 (chris86)
Date: 2006-02-08 15:15

Message:
Logged In: YES 
user_id=1133569

I'm using Python 2.4.2 (#2, Nov 20 2005, 17:04:48)
[GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2

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

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

From noreply at sourceforge.net  Wed Feb  8 18:00:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 09:00:56 -0800
Subject: [ python-Bugs-1424171 ] patch for etree cdata and attr quoting
Message-ID: <E1F6sga-0004F1-5W@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Fredrik Lundh (effbot)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example "&quote;" with 
"&amp;quote;" or "&amp;" with "&amp;amp;", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

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

>Comment By: Chris McDonough (chrism)
Date: 2006-02-08 12:00

Message:
Logged In: YES 
user_id=32974

Doh, of course.  Sorry, I suspect I'll need to go to remedial XML class.  Ignore 
this.


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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 16:55

Message:
Logged In: YES 
user_id=38376

I'm not sure I follow.  ET works on the infoset side of
things, where everything is decoded into Unicode strings (or
compatible ASCII strings).  If you set an attribute to
"&amp;" in the infoset, it *must* be encoded on the way out.  
If you want an ampersand, use "&".

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 15:23

Message:
Logged In: YES 
user_id=32974

Egads, I did this time.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-04 13:29

Message:
Logged In: YES 
user_id=1188172

OP: You did check the box?

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 13:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

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

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

From noreply at sourceforge.net  Wed Feb  8 19:55:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 10:55:33 -0800
Subject: [ python-Bugs-1427789 ] List not initialized if used as default
	argument
Message-ID: <E1F6uTV-00088L-MP@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason (griminventions)
Assigned to: Nobody/Anonymous (nobody)
Summary: List not initialized if used as default argument

Initial Comment:
class A( object ):
    def __init__( self, someList = [] ):
        self.someList = someList

if __name__ == "__main__":
    for i in range( 10 ):
        a = A()
        a.someList.append( "abc" )
        print a.someList

Instead of each instance of A getting an empty list, it
is somehow the same list as the previous instance of A.
It will not occur with the following change:

class A( object ):
    def __init__( self ):
        self.someList = []

I'm using Windows XP, Python 2.4.1.
jason at griminventions.com


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

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

From noreply at sourceforge.net  Wed Feb  8 20:13:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 11:13:31 -0800
Subject: [ python-Bugs-1427789 ] List not initialized if used as default
	argument
Message-ID: <E1F6ukt-0008IA-Qq@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jason (griminventions)
Assigned to: Nobody/Anonymous (nobody)
Summary: List not initialized if used as default argument

Initial Comment:
class A( object ):
    def __init__( self, someList = [] ):
        self.someList = someList

if __name__ == "__main__":
    for i in range( 10 ):
        a = A()
        a.someList.append( "abc" )
        print a.someList

Instead of each instance of A getting an empty list, it
is somehow the same list as the previous instance of A.
It will not occur with the following change:

class A( object ):
    def __init__( self ):
        self.someList = []

I'm using Windows XP, Python 2.4.1.
jason at griminventions.com


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

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-08 20:13

Message:
Logged In: YES 
user_id=1188172

This is intended behavior. Default values for function
arguments are only evaluated once, so it's not advisable to
use mutables there.

Use None as default and create your empty list within the
constructor if None is given, as in your second example.

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

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

From noreply at sourceforge.net  Wed Feb  8 20:13:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 11:13:39 -0800
Subject: [ python-Bugs-1427789 ] List not initialized if used as default
	argument
Message-ID: <E1F6ul1-0008IJ-7C@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jason (griminventions)
Assigned to: Nobody/Anonymous (nobody)
Summary: List not initialized if used as default argument

Initial Comment:
class A( object ):
    def __init__( self, someList = [] ):
        self.someList = someList

if __name__ == "__main__":
    for i in range( 10 ):
        a = A()
        a.someList.append( "abc" )
        print a.someList

Instead of each instance of A getting an empty list, it
is somehow the same list as the previous instance of A.
It will not occur with the following change:

class A( object ):
    def __init__( self ):
        self.someList = []

I'm using Windows XP, Python 2.4.1.
jason at griminventions.com


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

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-08 20:13

Message:
Logged In: YES 
user_id=1188172

This is intended behavior. Default values for function
arguments are only evaluated once, so it's not advisable to
use mutables there.

Use None as default and create your empty list within the
constructor if None is given, as in your second example.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-08 20:13

Message:
Logged In: YES 
user_id=1188172

This is intended behavior. Default values for function
arguments are only evaluated once, so it's not advisable to
use mutables there.

Use None as default and create your empty list within the
constructor if None is given, as in your second example.

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

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

From noreply at sourceforge.net  Wed Feb  8 20:15:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 11:15:08 -0800
Subject: [ python-Bugs-1427789 ] List not initialized if used as default
	argument
Message-ID: <E1F6umS-0005i5-3e@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Jason (griminventions)
Assigned to: Nobody/Anonymous (nobody)
Summary: List not initialized if used as default argument

Initial Comment:
class A( object ):
    def __init__( self, someList = [] ):
        self.someList = someList

if __name__ == "__main__":
    for i in range( 10 ):
        a = A()
        a.someList.append( "abc" )
        print a.someList

Instead of each instance of A getting an empty list, it
is somehow the same list as the previous instance of A.
It will not occur with the following change:

class A( object ):
    def __init__( self ):
        self.someList = []

I'm using Windows XP, Python 2.4.1.
jason at griminventions.com


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

>Comment By: David Goodger (goodger)
Date: 2006-02-08 14:15

Message:
Logged In: YES 
user_id=7733

This is not a bug.  Default values are evaluated when the
"def" statement is evaluated, at compile time.  See
http://www.python.org/doc/faq/general.html#why-are-default-values-shared-between-objects

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-08 14:13

Message:
Logged In: YES 
user_id=1188172

This is intended behavior. Default values for function
arguments are only evaluated once, so it's not advisable to
use mutables there.

Use None as default and create your empty list within the
constructor if None is given, as in your second example.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-08 14:13

Message:
Logged In: YES 
user_id=1188172

This is intended behavior. Default values for function
arguments are only evaluated once, so it's not advisable to
use mutables there.

Use None as default and create your empty list within the
constructor if None is given, as in your second example.

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

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

From noreply at sourceforge.net  Wed Feb  8 20:18:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 11:18:48 -0800
Subject: [ python-Bugs-1427789 ] List not initialized if used as default
	argument
Message-ID: <E1F6uq0-0001Ck-Jq@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Jason (griminventions)
Assigned to: Nobody/Anonymous (nobody)
Summary: List not initialized if used as default argument

Initial Comment:
class A( object ):
    def __init__( self, someList = [] ):
        self.someList = someList

if __name__ == "__main__":
    for i in range( 10 ):
        a = A()
        a.someList.append( "abc" )
        print a.someList

Instead of each instance of A getting an empty list, it
is somehow the same list as the previous instance of A.
It will not occur with the following change:

class A( object ):
    def __init__( self ):
        self.someList = []

I'm using Windows XP, Python 2.4.1.
jason at griminventions.com


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

Comment By: David Stanek (dstanek)
Date: 2006-02-08 14:18

Message:
Logged In: YES 
user_id=260643

This is actually correct behavior. See the "Important
Warning" in this section of the tutorial:
http://docs.python.org/tut/node6.html#SECTION006710000000000000000

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

Comment By: David Goodger (goodger)
Date: 2006-02-08 14:15

Message:
Logged In: YES 
user_id=7733

This is not a bug.  Default values are evaluated when the
"def" statement is evaluated, at compile time.  See
http://www.python.org/doc/faq/general.html#why-are-default-values-shared-between-objects

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-08 14:13

Message:
Logged In: YES 
user_id=1188172

This is intended behavior. Default values for function
arguments are only evaluated once, so it's not advisable to
use mutables there.

Use None as default and create your empty list within the
constructor if None is given, as in your second example.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-08 14:13

Message:
Logged In: YES 
user_id=1188172

This is intended behavior. Default values for function
arguments are only evaluated once, so it's not advisable to
use mutables there.

Use None as default and create your empty list within the
constructor if None is given, as in your second example.

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

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

From noreply at sourceforge.net  Wed Feb  8 20:36:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 11:36:25 -0800
Subject: [ python-Bugs-1425482 ] msvccompiler.py modified to work with .NET
	2005 on win64
Message-ID: <E1F6v73-0001Ih-C7@sc8-sf-web1.sourceforge.net>

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

Please note that this 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: Closed
>Resolution: Rejected
Priority: 5
Submitted By: beaudrym (beaudrym)
Assigned to: Nobody/Anonymous (nobody)
Summary: msvccompiler.py modified to work with .NET 2005 on win64

Initial Comment:
Hi,

I tried to compile and install pywin32 (python 
extension) using Microsoft Visual Studio .NET 2005.  
This was done on a AMD64 platform which had Python 
2.4.2.10 installed (from www.activestate.com).

When I try to compile pywin32, it uses the file 
msvccompiler.py that comes with python.  For the 
compilation to work, I had to modify 
msvccompiler.py.  I attached a patch file of my 
modifications.  Basically, I had to modify two things:

1 - use .NET framework 2.0 when 1.1 is not found.
2 - use environment variables "path", "lib" 
and "included" already defined in console when 
compiling with Visual Studio 8.0.  See comments in 
patch file for more details.

Let me know if these patches look reasonable to you.

Regards,
Maxime

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

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

Message:
Logged In: YES 
user_id=21627

Please report this to ActiveState - currently, there is not
a supported AMD64 distribution from python.org. If it ever
is, it is likely that your patch will be incorrect: I'm
currently planning to use the Platform SDK compiler for
AMD64 binaries, instead of VS2005.

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

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

From noreply at sourceforge.net  Thu Feb  9 05:04:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 08 Feb 2006 20:04:43 -0800
Subject: [ python-Bugs-1409403 ] email.Message should supress warning from
	uu.decode
Message-ID: <E1F732x-0003eA-JP@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Sapiro (msapiro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Message should supress warning from uu.decode

Initial Comment:
part.get_payload(decode=True) of a uuencoded
email.Message() sub-part can result in warning messages
being written to sys.stderr. These warnings occur when
pad characters other than encoded zeros were used to
fill out the last encoded line to a multiple of 4
characters (+1 for the count character). Such non-zero
padded encoded parts are produced by some current
versions of Eudora and perhaps other MUAs. The warnings
are unnecessary in this case and cause problems for
other software, e.g., Mailman.

get_payload(decode=True) calls uu.decode to actually
decode the part payload. It should specify the
quiet=True flag in this call to supress the warning.

A suggested patch against Python 2.4.2 is attached.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-08 23:04

Message:
Logged In: YES 
user_id=12800

r42279 for email 2.5, although we have to be more elaborate
since Python 2.1's uu.decode() does not have a 'quiet' flag.
 When I port this to Python 2.4 and 2.5, I will implement
the fix as given since we won't need the sneakiness.

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

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

From noreply at sourceforge.net  Thu Feb  9 13:07:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Feb 2006 04:07:26 -0800
Subject: [ python-Bugs-1428264 ] Crash on invalid coding pragma
Message-ID: <E1F7Aa6-0004bT-A1@sc8-sf-web1.sourceforge.net>

Bugs item #1428264, was opened at 2006-02-09 21:07
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=1428264&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ocean-city (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash on invalid coding pragma

Initial Comment:
Hi. Attached script crashes my Python2.4.2.

Note that "xxx" is not valid code name.

I'm using Win2000SP4, downloaded python msi package
from python.org.

Thank you.


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

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

From noreply at sourceforge.net  Thu Feb  9 13:13:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Feb 2006 04:13:34 -0800
Subject: [ python-Bugs-1428264 ] Crash on invalid coding pragma
Message-ID: <E1F7Ag2-0000hZ-LF@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: Out of Date
Priority: 5
Submitted By: ocean-city (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash on invalid coding pragma

Initial Comment:
Hi. Attached script crashes my Python2.4.2.

Note that "xxx" is not valid code name.

I'm using Win2000SP4, downloaded python msi package
from python.org.

Thank you.


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

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-09 13:13

Message:
Logged In: YES 
user_id=1188172

This is fixed in Subversion.

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

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

From noreply at sourceforge.net  Thu Feb  9 13:29:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Feb 2006 04:29:35 -0800
Subject: [ python-Bugs-1428264 ] Crash on invalid coding pragma
Message-ID: <E1F7AvX-0000ms-Nx@sc8-sf-web3.sourceforge.net>

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

Please note that this message 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: Out of Date
Priority: 5
Submitted By: ocean-city (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash on invalid coding pragma

Initial Comment:
Hi. Attached script crashes my Python2.4.2.

Note that "xxx" is not valid code name.

I'm using Win2000SP4, downloaded python msi package
from python.org.

Thank you.


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

>Comment By: ocean-city (ocean-city)
Date: 2006-02-09 21:29

Message:
Logged In: YES 
user_id=1200846

Thank you. I'll wait for next release. :-)

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-09 21:13

Message:
Logged In: YES 
user_id=1188172

This is fixed in Subversion.

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

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

From noreply at sourceforge.net  Thu Feb  9 16:20:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Feb 2006 07:20:12 -0800
Subject: [ python-Bugs-876637 ] Random stack corruption from socketmodule.c 
Message-ID: <E1F7Dae-0001Yt-Pj@sc8-sf-web3.sourceforge.net>

Bugs item #876637, was opened at 2004-01-14 06:41
Message generated for change (Comment added) made by arkadini
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876637&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mike Pall (mikesfpy)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Random stack corruption from socketmodule.c 

Initial Comment:
THE PROBLEM:

The implementation of the socket_object.settimeout() method
(socketmodule.c, function internal_select()) uses the select() system
call with an unbounded file descriptor number. This will cause random
stack corruption if fd>=FD_SETSIZE.

This took me ages to track down! It happened with a massively 
multithreaded
and massively connection-swamped network server. Basically most of 
the
descriptors did not use that routine (because they were either pure 
blocking
or pure non-blocking). But one module used settimeout() and with a little
bit of luck got an fd>=FD_SETSIZE and with even more luck corrupted 
the
stack and took down the whole server process.

Demonstration script appended.

THE SOLUTION:

The solution is to use poll() and to favour poll() even if select()
is available on a platform. The current trend in modern OS+libc
combinations is to emulate select() in libc and call kernel-level poll()
anyway. And this emulation is costly (both for the caller and for libc).

Not so the other way round (only some systems of historical interest
do that BTW), so we definitely want to use poll() if it's available
(even if it's an emulation).

And if select() is your only choice, then check for FD_SETSIZE before
using the FD_SET macro (and raise some strange exception if that fails).

[
I should note that using SO_RCVTIMEO and SO_SNDTIMEO would be a lot 
more
efficient (kernel-wise at least). Unfortunately they are not universally
available (though defined by most system header files). But a simple
runtime test with a fallback to poll()/select() would do.
]

A PATCH, A PATCH?

Well, the check for FD_SETSIZE is left as an exercise for the reader. :-)
Don't forget to merge this with the stray select() way down by adding 
a return value to internal_select().

But yes, I can do a 'real' patch with poll() [and even one with the
SO_RCVTIMEO trick if you are adventurous]. But, I can't test it with
dozens of platforms, various include files, compilers and so on.

So, dear Python core developers: Please discuss this and tell me,
if you want a patch, then you'll get one ASAP.

Thank you for your time!


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

Comment By: Arek Korbik (arkadini)
Date: 2006-02-09 15:20

Message:
Logged In: YES 
user_id=1346917

Unfortunately r42253 breaks things on win32 (at least on my
machine).

By default FD_SETSIZE is 64 (winsock.h, winsock2.h). Even if
the check from select module WAS included, that would end up
in 512. Most of the time, first socket I create after
starting python gets a fd > 900.

What is a reasonable value for FD_SETSIZE then? 1024?
Compared to the default value of 64 doesn't look that
reasonable, though...

Are there plans to "elaborate" on the last fix?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-07 07:18

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42253.
Committed revision 42254. (2.4)


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

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-10 12:15

Message:
Logged In: YES 
user_id=32863

I have created a patch to make socketmodule use poll() when
available. See http://python.org/sf/970288

(I'm not allowed to attach patches to this bug item.)


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

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

From noreply at sourceforge.net  Fri Feb 10 02:55:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Feb 2006 17:55:04 -0800
Subject: [ python-Bugs-1428789 ] add /usr/local support
Message-ID: <E1F7NV2-0006eB-FQ@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Karol Pietrzak (noodlez84)
Assigned to: Nobody/Anonymous (nobody)
Summary: add /usr/local support

Initial Comment:
Generally, /usr/local support needs to be added for   
python.  Many distributions already do this, either   
partially or completely, causing inconsistencies   
between Python installations among Linux   
distributions.   
   
1. There should be a site-packages directory   
in /usr/local,   
probably /usr/local/lib/python/site-packages.  Just   
like in /usr, it'll need the appropriate symlinks.    
x86_64 bit issues also need to be taken into account,   
so /usr/local/lib64/python2.4/site-packages should be   
the local site-packages directory for Python 2.4.x on   
a x86_64 machine.   
   
The reasons for these are numerous.  $PATH   
contains /usr/local/bin, $GTK_PATH   
contains /usr/local, $MANPATH   
contains /usr/local/share/man, and $PKG_CONFIG_PATH   
contains /usr/local/lib/pkgconfig.  Adding a   
site-packages directory in /usr/local will simply   
fill in the hole in the Python configuration.   
   
As the FHS points out, /usr may very well be mounted   
read-only for security purposes.  /usr/local should   
be used instead, especially for non-system / testing   
software.   
   
2. Distutils should install, by default, in   
the site-packages directory in /usr/local described  
in part (1).  This will simply mimic the auto(conf| 
make|etc.) default installation path (isn't the  
default installation path for Python  
itself /usr/local?).  
  
For simplicity and consistency's sake, the default  
installation path for distutils should be the 
site-packages directory in /usr/local. 
 
If someone would point me in the right direction, I 
will gladly write the patch myself. 

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

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

From noreply at sourceforge.net  Fri Feb 10 06:12:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 09 Feb 2006 21:12:03 -0800
Subject: [ python-Bugs-876637 ] Random stack corruption from socketmodule.c 
Message-ID: <E1F7QZf-0001V6-NV@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mike Pall (mikesfpy)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Random stack corruption from socketmodule.c 

Initial Comment:
THE PROBLEM:

The implementation of the socket_object.settimeout() method
(socketmodule.c, function internal_select()) uses the select() system
call with an unbounded file descriptor number. This will cause random
stack corruption if fd>=FD_SETSIZE.

This took me ages to track down! It happened with a massively 
multithreaded
and massively connection-swamped network server. Basically most of 
the
descriptors did not use that routine (because they were either pure 
blocking
or pure non-blocking). But one module used settimeout() and with a little
bit of luck got an fd>=FD_SETSIZE and with even more luck corrupted 
the
stack and took down the whole server process.

Demonstration script appended.

THE SOLUTION:

The solution is to use poll() and to favour poll() even if select()
is available on a platform. The current trend in modern OS+libc
combinations is to emulate select() in libc and call kernel-level poll()
anyway. And this emulation is costly (both for the caller and for libc).

Not so the other way round (only some systems of historical interest
do that BTW), so we definitely want to use poll() if it's available
(even if it's an emulation).

And if select() is your only choice, then check for FD_SETSIZE before
using the FD_SET macro (and raise some strange exception if that fails).

[
I should note that using SO_RCVTIMEO and SO_SNDTIMEO would be a lot 
more
efficient (kernel-wise at least). Unfortunately they are not universally
available (though defined by most system header files). But a simple
runtime test with a fallback to poll()/select() would do.
]

A PATCH, A PATCH?

Well, the check for FD_SETSIZE is left as an exercise for the reader. :-)
Don't forget to merge this with the stray select() way down by adding 
a return value to internal_select().

But yes, I can do a 'real' patch with poll() [and even one with the
SO_RCVTIMEO trick if you are adventurous]. But, I can't test it with
dozens of platforms, various include files, compilers and so on.

So, dear Python core developers: Please discuss this and tell me,
if you want a patch, then you'll get one ASAP.

Thank you for your time!


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

Comment By: Scott Dial (geekmug)
Date: 2006-02-10 00:12

Message:
Logged In: YES 
user_id=383208

The patch that has been applied has no relevance to Windows
and should not be used when compiling for Windows. The use
of an internal counter to assign descriptors to the fd_set
array avoids the problem noted here so there is no such bug
on Windows. Futhermore, as Arek notes, Windows creates
descriptor numbers with no bound.

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

Comment By: Arek Korbik (arkadini)
Date: 2006-02-09 10:20

Message:
Logged In: YES 
user_id=1346917

Unfortunately r42253 breaks things on win32 (at least on my
machine).

By default FD_SETSIZE is 64 (winsock.h, winsock2.h). Even if
the check from select module WAS included, that would end up
in 512. Most of the time, first socket I create after
starting python gets a fd > 900.

What is a reasonable value for FD_SETSIZE then? 1024?
Compared to the default value of 64 doesn't look that
reasonable, though...

Are there plans to "elaborate" on the last fix?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-07 02:18

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42253.
Committed revision 42254. (2.4)


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

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-10 06:15

Message:
Logged In: YES 
user_id=32863

I have created a patch to make socketmodule use poll() when
available. See http://python.org/sf/970288

(I'm not allowed to attach patches to this bug item.)


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

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

From noreply at sourceforge.net  Fri Feb 10 13:26:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Feb 2006 04:26:56 -0800
Subject: [ python-Bugs-1429063 ] set documentation deficiencies
Message-ID: <E1F7XMW-0001dB-P8@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: set documentation deficiencies

Initial Comment:
http://www.python.org/doc/current/lib/types-set.html
has a dead link: "Module sets".

Also, there does not seem to be any documentation on
how to construct a set.   Does set()==set([])?   What
is allowed  as an argument to set()?  Any iterable?

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

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

From noreply at sourceforge.net  Fri Feb 10 16:53:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Feb 2006 07:53:37 -0800
Subject: [ python-Bugs-1429053 ] set documentation deficiencies
Message-ID: <E1F7aaX-0005QQ-0P@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: set documentation deficiencies

Initial Comment:
http://www.python.org/doc/current/lib/types-set.html
has a dead link: "Module sets".

Also, there does not seem to be any documentation on
how to construct a set.   Does set()==set([])?   What
is allowed  as an argument to set()?  Any iterable?

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

>Comment By: Keith Briggs (kbriggs)
Date: 2006-02-10 15:53

Message:
Logged In: YES 
user_id=888261

Furthermore, the operations update etc. are mutations of s,
so wouldn't the definitions

s.update(t)  	s |= t  	return set s with elements added from t
s.intersection_update(t) 	s &= t 	return set s keeping only
elements also found in t
s.difference_update(t) 	s -= t 	return set s after removing
elements found in t
s.symmetric_difference_update(t) 	s ^= t 	return set s with
elements from s or t but not both

be better as 

s.update(t)  	s |= t  	add elements from t to s

etc.?
I'm not sure what the word "return" is doing here.


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

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

From noreply at sourceforge.net  Fri Feb 10 17:20:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Feb 2006 08:20:58 -0800
Subject: [ python-Bugs-1429063 ] set documentation deficiencies
Message-ID: <E1F7b10-00036y-6G@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: set documentation deficiencies

Initial Comment:
http://www.python.org/doc/current/lib/types-set.html
has a dead link: "Module sets".

Also, there does not seem to be any documentation on
how to construct a set.   Does set()==set([])?   What
is allowed  as an argument to set()?  Any iterable?

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

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-10 17:20

Message:
Logged In: YES 
user_id=1188172

Duplicate of #1429053.

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

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

From noreply at sourceforge.net  Fri Feb 10 17:21:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Feb 2006 08:21:46 -0800
Subject: [ python-Bugs-1429053 ] set documentation deficiencies
Message-ID: <E1F7b1m-00037G-Gw@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: set documentation deficiencies

Initial Comment:
http://www.python.org/doc/current/lib/types-set.html
has a dead link: "Module sets".

Also, there does not seem to be any documentation on
how to construct a set.   Does set()==set([])?   What
is allowed  as an argument to set()?  Any iterable?

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

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-10 17:21

Message:
Logged In: YES 
user_id=1188172

This is all already corrected, except for the empty set thing.

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

Comment By: Keith Briggs (kbriggs)
Date: 2006-02-10 16:53

Message:
Logged In: YES 
user_id=888261

Furthermore, the operations update etc. are mutations of s,
so wouldn't the definitions

s.update(t)  	s |= t  	return set s with elements added from t
s.intersection_update(t) 	s &= t 	return set s keeping only
elements also found in t
s.difference_update(t) 	s -= t 	return set s after removing
elements found in t
s.symmetric_difference_update(t) 	s ^= t 	return set s with
elements from s or t but not both

be better as 

s.update(t)  	s |= t  	add elements from t to s

etc.?
I'm not sure what the word "return" is doing here.


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

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

From noreply at sourceforge.net  Sat Feb 11 01:13:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Feb 2006 16:13:22 -0800
Subject: [ python-Bugs-1429481 ] For loop exit early
Message-ID: <E1F7iOA-0005o0-Fd@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: msmith (mike_smith)
Assigned to: Nobody/Anonymous (nobody)
Summary: For loop exit early

Initial Comment:
When I run the following snippet the "for" loop exits
early, not examining every item in the "lines" list. 
It will only print part of the list, i.e., only
approximately 65% of any list I use is printed.  (E.g.,
a list of 100 items only about 65 is printed)

If I wrap the for statement in another for statement
with a range() operator it works.

I'm pretty new to scripting, so I'm sure there's a
better way to do what I'm trying; but this seems like a
 bug.

Thanks for your help,

=========================

count = 0
lines =
["1","2","3","4","5","6","7","8","9","10","11","12","13","14","15","16"]
def getnextline():
		l = lines.pop()
		l = l.strip()
		return l
for x in lines:
	count += 1
	newline = "%s,%s,\n" % (getnextline(),getnextline())
	print count, ":", newline	

Output:
---------
1 : 16,15,

2 : 14,13,

3 : 12,11,

4 : 10,9,

5 : 8,7,

6 : 6,5,

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

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

From noreply at sourceforge.net  Sat Feb 11 05:34:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 10 Feb 2006 20:34:55 -0800
Subject: [ python-Bugs-1429481 ] For loop exit early
Message-ID: <E1F7mTH-0007Eu-2j@sc8-sf-web5.sourceforge.net>

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

Please note that this message 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: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: msmith (mike_smith)
Assigned to: Nobody/Anonymous (nobody)
Summary: For loop exit early

Initial Comment:
When I run the following snippet the "for" loop exits
early, not examining every item in the "lines" list. 
It will only print part of the list, i.e., only
approximately 65% of any list I use is printed.  (E.g.,
a list of 100 items only about 65 is printed)

If I wrap the for statement in another for statement
with a range() operator it works.

I'm pretty new to scripting, so I'm sure there's a
better way to do what I'm trying; but this seems like a
 bug.

Thanks for your help,

=========================

count = 0
lines =
["1","2","3","4","5","6","7","8","9","10","11","12","13","14","15","16"]
def getnextline():
		l = lines.pop()
		l = l.strip()
		return l
for x in lines:
	count += 1
	newline = "%s,%s,\n" % (getnextline(),getnextline())
	print count, ":", newline	

Output:
---------
1 : 16,15,

2 : 14,13,

3 : 12,11,

4 : 10,9,

5 : 8,7,

6 : 6,5,

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

>Comment By: Tim Peters (tim_one)
Date: 2006-02-10 23:34

Message:
Logged In: YES 
user_id=31435

Changed "group" to not-a-bug.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-02-10 19:25

Message:
Logged In: YES 
user_id=80475

Sorry, the bug is in your code (the for-loop is looping 
over a list that is being mutated by pops).  I recommend 
posting on comp.lang.python or to the python-tutor list to 
get feedback on how to write this correctly.

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

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

From noreply at sourceforge.net  Sat Feb 11 09:16:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Feb 2006 00:16:57 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F7pw9-0004yx-BC@sc8-sf-web2.sourceforge.net>

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

Please note that this 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
Submitted By: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

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

From noreply at sourceforge.net  Sat Feb 11 19:15:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Feb 2006 10:15:44 -0800
Subject: [ python-Bugs-1429783 ] urllib.py: AttributeError on BadStatusLine
Message-ID: <E1F7zHc-0003xo-9E@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.py: AttributeError on BadStatusLine

Initial Comment:
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.


in httplib errcode -1 &
file=self._conn.sock.makefile('rb', 0) is returned on
Badstatusline:

        except BadStatusLine, e:
            ### hmm. if getresponse() ever closes the
socket on a bad request,
            ### then we are going to have problems with
self.sock

            ### should we keep this behavior? do people
use it?
            # keep the socket open (as a file), and
return it
            self.file = self._conn.sock.makefile('rb', 0)

            # close our socket -- we want to restart
after any protocol error
            self.close()

            self.headers = None
            return -1, e.line, None



fp = h.getfile()

delivers None in urllib.URLopener.open_http

and this is traceback leading to an AttributeError 


Traceback (most recent call last):

  File "<interactive input>", line 1, in ?
  File "C:\Python23\lib\urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "C:\Python23\lib\urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg,
headers)
  File "C:\Python23\lib\urllib.py", line 319, in http_error
    result = method(url, fp, errcode, errmsg, headers)
  File "C:\Python23\lib\urllib.py", line 584, in
http_error_301
    return self.http_error_302(url, fp, errcode,
errmsg, headers, data)
  File "C:\Python23\lib\urllib.py", line 565, in
http_error_302
    data)
  File "C:\Python23\lib\urllib.py", line 580, in
redirect_internal
    return self.open(newurl)
  File "C:\Python23\lib\urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "C:\Python23\lib\urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg,
headers)
  File "C:\Python23\lib\urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode,
errmsg, headers)
  File "C:\Python23\lib\urllib.py", line 327, in
http_error_default
    void = fp.read()
AttributeError: 'NoneType' object has no attribute 'read'



As I get this error rarely I cannot reproduce exactly how

self._conn.sock.makefile('rb', 0)

delivers None in that case.



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

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

From noreply at sourceforge.net  Sat Feb 11 19:28:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Feb 2006 10:28:40 -0800
Subject: [ python-Bugs-1424152 ] urllib: HTTPS over (Squid) Proxy fails
Message-ID: <E1F7zU8-0003zQ-J1@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib: HTTPS over (Squid) Proxy fails

Initial Comment:
py2.4.2/win32

The proxy mechanism of python fails on https and does
work completely wrong (not using the CONNECT scheme).

(after urlopen some minute(s) freeze then EOF error)

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import urllib
>>> urllib.getproxies()
{'ftp': 'ftp://vserver:3128', 'http':
'http://vserver:3128', 'gopher': 'gopher:/
/vserver:3128', 'https': 'https://vserver:3128'}
>>> urllib.urlopen('https://www.elster.de')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\lib\urllib.py", line 77, in urlopen
    return opener.open(url)
  File "C:\Python24\lib\urllib.py", line 185, in open
    return getattr(self, name)(url)
  File "C:\Python24\lib\urllib.py", line 386, in open_https
    h.endheaders()
  File "C:\Python24\lib\httplib.py", line 795, in
endheaders
    self._send_output()
  File "C:\Python24\lib\httplib.py", line 676, in
_send_output
    self.send(msg)
  File "C:\Python24\lib\httplib.py", line 643, in send
    self.connect()
  File "C:\Python24\lib\httplib.py", line 1071, in connect
    ssl = socket.ssl(sock, self.key_file, self.cert_file)
  File "C:\Python24\lib\socket.py", line 74, in ssl
    return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (8, 'EOF occurred in
violation of protocol')
>>>



no CONNECT even appears in the squid proxy access log.

Robert
 

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

>Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-11 19:28

Message:
Logged In: YES 
user_id=972995

Meanwhile I wrote my own CONNECT quick hack.   As indeed
this hack works correct for all proxied environments tested
up to now (>30) I wonder how open_https  (in urllib and
urllib2) ever in the past managed to come through a proxy,
because there is some differentiation in open_https for the
case, that there is a proxy!? Who has written that
if..else's? Are there proxies which really do
SSL-handshaking directly and make an extra connection to the
target server? I guess that would even make certificate
handling very strange... I cannot immagine and never saw
one. But maybe such proxies exist. I am not a real expert
for such networking questions, but I guess CONNECT is widely
used and in my own proxies I can see in the log file, that
all common browsers use a HTTP CONNECT request for https
proxying. CONNECT should at least be implemented as an
option in urllibX

Robert


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

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

From noreply at sourceforge.net  Sun Feb 12 07:19:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Feb 2006 22:19:41 -0800
Subject: [ python-Bugs-876637 ] Random stack corruption from socketmodule.c 
Message-ID: <E1F8AaD-0007YW-9P@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mike Pall (mikesfpy)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Random stack corruption from socketmodule.c 

Initial Comment:
THE PROBLEM:

The implementation of the socket_object.settimeout() method
(socketmodule.c, function internal_select()) uses the select() system
call with an unbounded file descriptor number. This will cause random
stack corruption if fd>=FD_SETSIZE.

This took me ages to track down! It happened with a massively 
multithreaded
and massively connection-swamped network server. Basically most of 
the
descriptors did not use that routine (because they were either pure 
blocking
or pure non-blocking). But one module used settimeout() and with a little
bit of luck got an fd>=FD_SETSIZE and with even more luck corrupted 
the
stack and took down the whole server process.

Demonstration script appended.

THE SOLUTION:

The solution is to use poll() and to favour poll() even if select()
is available on a platform. The current trend in modern OS+libc
combinations is to emulate select() in libc and call kernel-level poll()
anyway. And this emulation is costly (both for the caller and for libc).

Not so the other way round (only some systems of historical interest
do that BTW), so we definitely want to use poll() if it's available
(even if it's an emulation).

And if select() is your only choice, then check for FD_SETSIZE before
using the FD_SET macro (and raise some strange exception if that fails).

[
I should note that using SO_RCVTIMEO and SO_SNDTIMEO would be a lot 
more
efficient (kernel-wise at least). Unfortunately they are not universally
available (though defined by most system header files). But a simple
runtime test with a fallback to poll()/select() would do.
]

A PATCH, A PATCH?

Well, the check for FD_SETSIZE is left as an exercise for the reader. :-)
Don't forget to merge this with the stray select() way down by adding 
a return value to internal_select().

But yes, I can do a 'real' patch with poll() [and even one with the
SO_RCVTIMEO trick if you are adventurous]. But, I can't test it with
dozens of platforms, various include files, compilers and so on.

So, dear Python core developers: Please discuss this and tell me,
if you want a patch, then you'll get one ASAP.

Thank you for your time!


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:19

Message:
Logged In: YES 
user_id=33168

Martin has fixed my Window's breakage by only checking for
selectability on non-Windows platforms.

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

Comment By: Scott Dial (geekmug)
Date: 2006-02-09 21:12

Message:
Logged In: YES 
user_id=383208

The patch that has been applied has no relevance to Windows
and should not be used when compiling for Windows. The use
of an internal counter to assign descriptors to the fd_set
array avoids the problem noted here so there is no such bug
on Windows. Futhermore, as Arek notes, Windows creates
descriptor numbers with no bound.

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

Comment By: Arek Korbik (arkadini)
Date: 2006-02-09 07:20

Message:
Logged In: YES 
user_id=1346917

Unfortunately r42253 breaks things on win32 (at least on my
machine).

By default FD_SETSIZE is 64 (winsock.h, winsock2.h). Even if
the check from select module WAS included, that would end up
in 512. Most of the time, first socket I create after
starting python gets a fd > 900.

What is a reasonable value for FD_SETSIZE then? 1024?
Compared to the default value of 64 doesn't look that
reasonable, though...

Are there plans to "elaborate" on the last fix?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-06 23:18

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42253.
Committed revision 42254. (2.4)


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

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-10 04:15

Message:
Logged In: YES 
user_id=32863

I have created a patch to make socketmodule use poll() when
available. See http://python.org/sf/970288

(I'm not allowed to attach patches to this bug item.)


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

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

From noreply at sourceforge.net  Sun Feb 12 07:21:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Feb 2006 22:21:20 -0800
Subject: [ python-Bugs-1427552 ] tarfile.open bug / corrupt data
Message-ID: <E1F8Abo-0007Yi-F4@sc8-sf-web2.sourceforge.net>

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

Please note that this message 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: 7
Submitted By: Chris86 (chris86)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.open bug / corrupt data

Initial Comment:
Hi!

I want to create a bz2 compressed tar file.
Here is my code:
full="/home/test/test.sql"
tar = tarfile.open("test.tar.bz2", "w:bz2")
tarinfo = tar.gettarinfo(full,"blubb.sql")
tar.addfile(tarinfo,file(full))
tar.close()

i think this should work, but the sql file is corrupt:
- the created sql file in the compressed tar has only
4745 Lines, the original file has 4753


Regards,
Chris

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:21

Message:
Logged In: YES 
user_id=33168

Chris can you attach your sql file (or a small test case) so
we can reproduce the problem?

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

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-02-08 07:13

Message:
Logged In: YES 
user_id=642936

Just to identify whether this is a tarfile or bz2 module
related issue:
- Do you have the same problem without compression or with
gzip compression?
- Have you tried compressing your sql file directly with the
bz2 module? 

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

Comment By: Chris86 (chris86)
Date: 2006-02-08 06:17

Message:
Logged In: YES 
user_id=1133569

same error with Python 2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2


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

Comment By: Chris86 (chris86)
Date: 2006-02-08 06:15

Message:
Logged In: YES 
user_id=1133569

I'm using Python 2.4.2 (#2, Nov 20 2005, 17:04:48)
[GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2

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

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

From noreply at sourceforge.net  Sun Feb 12 07:54:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Feb 2006 22:54:52 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F8B8G-0007cF-9v@sc8-sf-web2.sourceforge.net>

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

Please note that this 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
Submitted By: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:54

Message:
Logged In: YES 
user_id=33168

Can you build python from source?  You can try checking out
the current 2.4 SVN.  This problem may have been fixed
recently.  I'm guessing that the socket descriptor value is
larger than FD_SETSIZE (probably 1k or 4k).  You also may
want to build python with debugging.

If that doesn't solve your problem, you will need to provide
more information about how to reproduce your problem.

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

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

From noreply at sourceforge.net  Sun Feb 12 07:55:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Feb 2006 22:55:54 -0800
Subject: [ python-Bugs-1429783 ] urllib.py: AttributeError on BadStatusLine
Message-ID: <E1F8B9G-0007cP-Kf@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.py: AttributeError on BadStatusLine

Initial Comment:
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.


in httplib errcode -1 &
file=self._conn.sock.makefile('rb', 0) is returned on
Badstatusline:

        except BadStatusLine, e:
            ### hmm. if getresponse() ever closes the
socket on a bad request,
            ### then we are going to have problems with
self.sock

            ### should we keep this behavior? do people
use it?
            # keep the socket open (as a file), and
return it
            self.file = self._conn.sock.makefile('rb', 0)

            # close our socket -- we want to restart
after any protocol error
            self.close()

            self.headers = None
            return -1, e.line, None



fp = h.getfile()

delivers None in urllib.URLopener.open_http

and this is traceback leading to an AttributeError 


Traceback (most recent call last):

  File "<interactive input>", line 1, in ?
  File "C:\Python23\lib\urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "C:\Python23\lib\urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg,
headers)
  File "C:\Python23\lib\urllib.py", line 319, in http_error
    result = method(url, fp, errcode, errmsg, headers)
  File "C:\Python23\lib\urllib.py", line 584, in
http_error_301
    return self.http_error_302(url, fp, errcode,
errmsg, headers, data)
  File "C:\Python23\lib\urllib.py", line 565, in
http_error_302
    data)
  File "C:\Python23\lib\urllib.py", line 580, in
redirect_internal
    return self.open(newurl)
  File "C:\Python23\lib\urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "C:\Python23\lib\urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg,
headers)
  File "C:\Python23\lib\urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode,
errmsg, headers)
  File "C:\Python23\lib\urllib.py", line 327, in
http_error_default
    void = fp.read()
AttributeError: 'NoneType' object has no attribute 'read'



As I get this error rarely I cannot reproduce exactly how

self._conn.sock.makefile('rb', 0)

delivers None in that case.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:55

Message:
Logged In: YES 
user_id=33168

This may be a duplicate of a bug submitted by Bram Cohen. 
It was a couple of years ago and I don't remember any other
details.

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

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

From noreply at sourceforge.net  Sun Feb 12 07:56:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 11 Feb 2006 22:56:17 -0800
Subject: [ python-Bugs-1429783 ] urllib.py: AttributeError on BadStatusLine
Message-ID: <E1F8B9d-0007cV-Vo@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.py: AttributeError on BadStatusLine

Initial Comment:
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.


in httplib errcode -1 &
file=self._conn.sock.makefile('rb', 0) is returned on
Badstatusline:

        except BadStatusLine, e:
            ### hmm. if getresponse() ever closes the
socket on a bad request,
            ### then we are going to have problems with
self.sock

            ### should we keep this behavior? do people
use it?
            # keep the socket open (as a file), and
return it
            self.file = self._conn.sock.makefile('rb', 0)

            # close our socket -- we want to restart
after any protocol error
            self.close()

            self.headers = None
            return -1, e.line, None



fp = h.getfile()

delivers None in urllib.URLopener.open_http

and this is traceback leading to an AttributeError 


Traceback (most recent call last):

  File "<interactive input>", line 1, in ?
  File "C:\Python23\lib\urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "C:\Python23\lib\urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg,
headers)
  File "C:\Python23\lib\urllib.py", line 319, in http_error
    result = method(url, fp, errcode, errmsg, headers)
  File "C:\Python23\lib\urllib.py", line 584, in
http_error_301
    return self.http_error_302(url, fp, errcode,
errmsg, headers, data)
  File "C:\Python23\lib\urllib.py", line 565, in
http_error_302
    data)
  File "C:\Python23\lib\urllib.py", line 580, in
redirect_internal
    return self.open(newurl)
  File "C:\Python23\lib\urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "C:\Python23\lib\urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg,
headers)
  File "C:\Python23\lib\urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode,
errmsg, headers)
  File "C:\Python23\lib\urllib.py", line 327, in
http_error_default
    void = fp.read()
AttributeError: 'NoneType' object has no attribute 'read'



As I get this error rarely I cannot reproduce exactly how

self._conn.sock.makefile('rb', 0)

delivers None in that case.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:56

Message:
Logged In: YES 
user_id=33168

I should add that the other bug is still open.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:55

Message:
Logged In: YES 
user_id=33168

This may be a duplicate of a bug submitted by Bram Cohen. 
It was a couple of years ago and I don't remember any other
details.

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

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

From noreply at sourceforge.net  Sun Feb 12 17:28:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 08:28:43 -0800
Subject: [ python-Bugs-1430076 ] typo in tutorial
Message-ID: <E1F8K5b-0007Oa-O6@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Hicken (silverfish)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in tutorial

Initial Comment:
In the "Whetting Your Appetite" section of the 
tutorial:
http://www.python.org/doc/2.4.2/tut/node3.html

Near the end
"Python enables programs to written compactly..." 
should read "Python enables programs to be written 
compactly"

This is from Python version 2.4.2.




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

>Comment By: Fredrik Lundh (effbot)
Date: 2006-02-12 17:28

Message:
Logged In: YES 
user_id=38376

This has been fixed in SVN (revision 39344).

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

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

From noreply at sourceforge.net  Sun Feb 12 17:31:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 08:31:30 -0800
Subject: [ python-Bugs-1424171 ] patch for etree cdata and attr quoting
Message-ID: <E1F8K8I-0007Oz-5R@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Fredrik Lundh (effbot)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example "&quote;" with 
"&amp;quote;" or "&amp;" with "&amp;amp;", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-08 18:00

Message:
Logged In: YES 
user_id=32974

Doh, of course.  Sorry, I suspect I'll need to go to remedial XML class.  Ignore 
this.


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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 22:55

Message:
Logged In: YES 
user_id=38376

I'm not sure I follow.  ET works on the infoset side of
things, where everything is decoded into Unicode strings (or
compatible ASCII strings).  If you set an attribute to
"&amp;" in the infoset, it *must* be encoded on the way out.  
If you want an ampersand, use "&".

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 21:23

Message:
Logged In: YES 
user_id=32974

Egads, I did this time.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-04 19:29

Message:
Logged In: YES 
user_id=1188172

OP: You did check the box?

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

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 19:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

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

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

From noreply at sourceforge.net  Sun Feb 12 17:47:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 08:47:39 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F8KNv-0007RC-LK@sc8-sf-web2.sourceforge.net>

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

Please note that this 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
Submitted By: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 19:47

Message:
Logged In: YES 
user_id=1450360

This is test program that generates fault:
----------------------------
#!/usr/local/bin/python

import socket, time
from threading import Thread

class cthread(Thread):
        def __init__ (self):
                Thread.__init__(self)

        def run(self):
                socket.setdefaulttimeout(5)
                res = socket.getaddrinfo('19.54.123.2', 33, 
0, socket.SOCK_STREAM)[0]
                sock = socket.socket(res[0], res[1], res[2])
                try:
                        sock.connect(res[4])
                except: pass

def main():
        for i in range(1900):
                print "starting " + str(i)
                ct = cthread()
                ct.start()

if __name__ == '__main__':
        main()

----------------------------
IP 19.54.123.2 is random. Results are various for some IPs 
and hostnames.


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

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

Message:
Logged In: YES 
user_id=33168

Can you build python from source?  You can try checking out
the current 2.4 SVN.  This problem may have been fixed
recently.  I'm guessing that the socket descriptor value is
larger than FD_SETSIZE (probably 1k or 4k).  You also may
want to build python with debugging.

If that doesn't solve your problem, you will need to provide
more information about how to reproduce your problem.

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

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

From noreply at sourceforge.net  Sun Feb 12 18:48:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 09:48:12 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F8LKW-0007ZA-T7@sc8-sf-web2.sourceforge.net>

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

Please note that this 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
Submitted By: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 20:48

Message:
Logged In: YES 
user_id=1450360

This is detailed backtrace (from python compiled with 
CFLAGS+="-g"):
======================================
#0  0xa8348959 in ?? ()
#1  0x08ebb800 in ?? ()
#2  0x00000001 in ?? ()
#3  0x77881688 in ?? ()
#4  0x28348947 in internal_connect (s=0x8ebb800, 
addr=0x8ebb818, addrlen=16,
    timeoutp=0x778816b4)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1740
#5  0x28348a00 in sock_connect (s=0x8ebb800, 
addro=0x8ebd72c)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1771
======================================

This is the /usr/ports/lang/python/work/Python-2.4.2/
Modules/socketmodule.c:
======================================
        if (s->sock_timeout > 0.0) {
1740:           if (res < 0 && errno == EINPROGRESS) {
                        timeout = internal_select(s, 1);
                        res = connect(s->sock_fd, addr, 
addrlen);
                        if (res < 0 && errno == EISCONN)
                                res = 0;
                }
        }
======================================

No ideas :-(

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 19:47

Message:
Logged In: YES 
user_id=1450360

This is test program that generates fault:
----------------------------
#!/usr/local/bin/python

import socket, time
from threading import Thread

class cthread(Thread):
        def __init__ (self):
                Thread.__init__(self)

        def run(self):
                socket.setdefaulttimeout(5)
                res = socket.getaddrinfo('19.54.123.2', 33, 
0, socket.SOCK_STREAM)[0]
                sock = socket.socket(res[0], res[1], res[2])
                try:
                        sock.connect(res[4])
                except: pass

def main():
        for i in range(1900):
                print "starting " + str(i)
                ct = cthread()
                ct.start()

if __name__ == '__main__':
        main()

----------------------------
IP 19.54.123.2 is random. Results are various for some IPs 
and hostnames.


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

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

Message:
Logged In: YES 
user_id=33168

Can you build python from source?  You can try checking out
the current 2.4 SVN.  This problem may have been fixed
recently.  I'm guessing that the socket descriptor value is
larger than FD_SETSIZE (probably 1k or 4k).  You also may
want to build python with debugging.

If that doesn't solve your problem, you will need to provide
more information about how to reproduce your problem.

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

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

From noreply at sourceforge.net  Sun Feb 12 21:54:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 12:54:52 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F8OFA-00051U-Hr@sc8-sf-web1.sourceforge.net>

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

Please note that this 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
Submitted By: aix-d (aix-d)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 12:54

Message:
Logged In: YES 
user_id=33168

Can you "print *s" ?  My guess is that s->sock_fd >
FD_SETSIZE on your box.  I will try your test code with the
current versions and see if they still fail.

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 09:48

Message:
Logged In: YES 
user_id=1450360

This is detailed backtrace (from python compiled with 
CFLAGS+="-g"):
======================================
#0  0xa8348959 in ?? ()
#1  0x08ebb800 in ?? ()
#2  0x00000001 in ?? ()
#3  0x77881688 in ?? ()
#4  0x28348947 in internal_connect (s=0x8ebb800, 
addr=0x8ebb818, addrlen=16,
    timeoutp=0x778816b4)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1740
#5  0x28348a00 in sock_connect (s=0x8ebb800, 
addro=0x8ebd72c)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1771
======================================

This is the /usr/ports/lang/python/work/Python-2.4.2/
Modules/socketmodule.c:
======================================
        if (s->sock_timeout > 0.0) {
1740:           if (res < 0 && errno == EINPROGRESS) {
                        timeout = internal_select(s, 1);
                        res = connect(s->sock_fd, addr, 
addrlen);
                        if (res < 0 && errno == EISCONN)
                                res = 0;
                }
        }
======================================

No ideas :-(

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 08:47

Message:
Logged In: YES 
user_id=1450360

This is test program that generates fault:
----------------------------
#!/usr/local/bin/python

import socket, time
from threading import Thread

class cthread(Thread):
        def __init__ (self):
                Thread.__init__(self)

        def run(self):
                socket.setdefaulttimeout(5)
                res = socket.getaddrinfo('19.54.123.2', 33, 
0, socket.SOCK_STREAM)[0]
                sock = socket.socket(res[0], res[1], res[2])
                try:
                        sock.connect(res[4])
                except: pass

def main():
        for i in range(1900):
                print "starting " + str(i)
                ct = cthread()
                ct.start()

if __name__ == '__main__':
        main()

----------------------------
IP 19.54.123.2 is random. Results are various for some IPs 
and hostnames.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:54

Message:
Logged In: YES 
user_id=33168

Can you build python from source?  You can try checking out
the current 2.4 SVN.  This problem may have been fixed
recently.  I'm guessing that the socket descriptor value is
larger than FD_SETSIZE (probably 1k or 4k).  You also may
want to build python with debugging.

If that doesn't solve your problem, you will need to provide
more information about how to reproduce your problem.

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

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

From noreply at sourceforge.net  Sun Feb 12 22:09:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 13:09:23 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F8OTD-0000dM-8c@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Extension Modules
Group: Python 2.4
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: aix-d (aix-d)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 13:09

Message:
Logged In: YES 
user_id=33168

I get exceptions when running normally. I had to do ulimit
-n 2000 to be able to run without exception.

I can confirm that with an unpatched 2.4.2, python crashed.
 With the 2.4.2+ patch, no crash.  On SVN head (2.5), I
didn't get a crash, but got a thread exception.  I think
this bug may be fixed.  To get the new features, you need to
update at least these files:

http://svn.python.org/projects/python/branches/release24-maint/Modules/socketmodule.c
http://svn.python.org/projects/python/branches/release24-maint/Modules/_ssl.c
http://svn.python.org/projects/python/branches/release24-maint/PC/pyconfig.h

Please verify if this is fixed for you.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 12:54

Message:
Logged In: YES 
user_id=33168

Can you "print *s" ?  My guess is that s->sock_fd >
FD_SETSIZE on your box.  I will try your test code with the
current versions and see if they still fail.

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 09:48

Message:
Logged In: YES 
user_id=1450360

This is detailed backtrace (from python compiled with 
CFLAGS+="-g"):
======================================
#0  0xa8348959 in ?? ()
#1  0x08ebb800 in ?? ()
#2  0x00000001 in ?? ()
#3  0x77881688 in ?? ()
#4  0x28348947 in internal_connect (s=0x8ebb800, 
addr=0x8ebb818, addrlen=16,
    timeoutp=0x778816b4)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1740
#5  0x28348a00 in sock_connect (s=0x8ebb800, 
addro=0x8ebd72c)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1771
======================================

This is the /usr/ports/lang/python/work/Python-2.4.2/
Modules/socketmodule.c:
======================================
        if (s->sock_timeout > 0.0) {
1740:           if (res < 0 && errno == EINPROGRESS) {
                        timeout = internal_select(s, 1);
                        res = connect(s->sock_fd, addr, 
addrlen);
                        if (res < 0 && errno == EISCONN)
                                res = 0;
                }
        }
======================================

No ideas :-(

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 08:47

Message:
Logged In: YES 
user_id=1450360

This is test program that generates fault:
----------------------------
#!/usr/local/bin/python

import socket, time
from threading import Thread

class cthread(Thread):
        def __init__ (self):
                Thread.__init__(self)

        def run(self):
                socket.setdefaulttimeout(5)
                res = socket.getaddrinfo('19.54.123.2', 33, 
0, socket.SOCK_STREAM)[0]
                sock = socket.socket(res[0], res[1], res[2])
                try:
                        sock.connect(res[4])
                except: pass

def main():
        for i in range(1900):
                print "starting " + str(i)
                ct = cthread()
                ct.start()

if __name__ == '__main__':
        main()

----------------------------
IP 19.54.123.2 is random. Results are various for some IPs 
and hostnames.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:54

Message:
Logged In: YES 
user_id=33168

Can you build python from source?  You can try checking out
the current 2.4 SVN.  This problem may have been fixed
recently.  I'm guessing that the socket descriptor value is
larger than FD_SETSIZE (probably 1k or 4k).  You also may
want to build python with debugging.

If that doesn't solve your problem, you will need to provide
more information about how to reproduce your problem.

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

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

From noreply at sourceforge.net  Sun Feb 12 22:11:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 13:11:32 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F8OVI-0000dZ-BR@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: aix-d (aix-d)
Assigned to: Neal Norwitz (nnorwitz)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 13:11

Message:
Logged In: YES 
user_id=33168

The 2.4 fix was committed in revision 42339.

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

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

Message:
Logged In: YES 
user_id=33168

I get exceptions when running normally. I had to do ulimit
-n 2000 to be able to run without exception.

I can confirm that with an unpatched 2.4.2, python crashed.
 With the 2.4.2+ patch, no crash.  On SVN head (2.5), I
didn't get a crash, but got a thread exception.  I think
this bug may be fixed.  To get the new features, you need to
update at least these files:

http://svn.python.org/projects/python/branches/release24-maint/Modules/socketmodule.c
http://svn.python.org/projects/python/branches/release24-maint/Modules/_ssl.c
http://svn.python.org/projects/python/branches/release24-maint/PC/pyconfig.h

Please verify if this is fixed for you.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 12:54

Message:
Logged In: YES 
user_id=33168

Can you "print *s" ?  My guess is that s->sock_fd >
FD_SETSIZE on your box.  I will try your test code with the
current versions and see if they still fail.

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 09:48

Message:
Logged In: YES 
user_id=1450360

This is detailed backtrace (from python compiled with 
CFLAGS+="-g"):
======================================
#0  0xa8348959 in ?? ()
#1  0x08ebb800 in ?? ()
#2  0x00000001 in ?? ()
#3  0x77881688 in ?? ()
#4  0x28348947 in internal_connect (s=0x8ebb800, 
addr=0x8ebb818, addrlen=16,
    timeoutp=0x778816b4)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1740
#5  0x28348a00 in sock_connect (s=0x8ebb800, 
addro=0x8ebd72c)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1771
======================================

This is the /usr/ports/lang/python/work/Python-2.4.2/
Modules/socketmodule.c:
======================================
        if (s->sock_timeout > 0.0) {
1740:           if (res < 0 && errno == EINPROGRESS) {
                        timeout = internal_select(s, 1);
                        res = connect(s->sock_fd, addr, 
addrlen);
                        if (res < 0 && errno == EISCONN)
                                res = 0;
                }
        }
======================================

No ideas :-(

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 08:47

Message:
Logged In: YES 
user_id=1450360

This is test program that generates fault:
----------------------------
#!/usr/local/bin/python

import socket, time
from threading import Thread

class cthread(Thread):
        def __init__ (self):
                Thread.__init__(self)

        def run(self):
                socket.setdefaulttimeout(5)
                res = socket.getaddrinfo('19.54.123.2', 33, 
0, socket.SOCK_STREAM)[0]
                sock = socket.socket(res[0], res[1], res[2])
                try:
                        sock.connect(res[4])
                except: pass

def main():
        for i in range(1900):
                print "starting " + str(i)
                ct = cthread()
                ct.start()

if __name__ == '__main__':
        main()

----------------------------
IP 19.54.123.2 is random. Results are various for some IPs 
and hostnames.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:54

Message:
Logged In: YES 
user_id=33168

Can you build python from source?  You can try checking out
the current 2.4 SVN.  This problem may have been fixed
recently.  I'm guessing that the socket descriptor value is
larger than FD_SETSIZE (probably 1k or 4k).  You also may
want to build python with debugging.

If that doesn't solve your problem, you will need to provide
more information about how to reproduce your problem.

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

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

From noreply at sourceforge.net  Sun Feb 12 22:36:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 13:36:25 -0800
Subject: [ python-Bugs-1430298 ] smtplib: empty mail addresses
Message-ID: <E1F8OtN-00057K-0z@sc8-sf-web1.sourceforge.net>

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

Please note that this message 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
Submitted By: Freek Dijkstra (macfreek)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib: empty mail addresses

Initial Comment:
It is not possible to send an email with smtplib with an empty return 
address.

if you leave the sender mail address empty, smtplib will use "<None>" as 
sender, instead of "<>", as it should do. Note that an empty return 
address is typically used for mail delivery warnings (it has a valid usage!)

This bug is still in current SVN (I just checked http://svn.python.org/
projects/python/trunk/Lib/smtplib.py). Below is a fix for smtplib.py that 
came with Python 2.3 (since I still use that version). The bug is in the 
function "quoteaddr(addr):"

*** orig/smtplib.py   2005-05-14 23:48:03.000000000 +0200
--- smtplib.py  2006-02-08 09:52:25.000000000 +0100
***************
*** 176,181 ****
--- 176,183 ----
      if m == (None, None): # Indicates parse failure or AttributeError
          #something weird here.. punt -ddm
          return "<%s>" % addr
+     elif m == None:
+         return "<>"
      else:
          return "<%s>" % m
  


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

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

From noreply at sourceforge.net  Sun Feb 12 22:54:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 13:54:29 -0800
Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler
Message-ID: <E1F8PAr-0000iD-0U@sc8-sf-web5.sourceforge.net>

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

Please note that this 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: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


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

>Comment By: Armin Rigo (arigo)
Date: 2006-02-12 21:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}        # !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

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

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 15:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
    def __setitem__(self, i, v):
        print i, v
    def __getitem__(self, i):
        print i
        return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-18 07:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

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

Comment By: Michael Hudson (mwh)
Date: 2005-12-11 00:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

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

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 23:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

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

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 10:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

-----------------------
assert 1, ([s for s in x] +
           [s for s in x])
pass
-----------------------

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 19:14

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think all the others
mentioned so far have been fixed:

 * Raymond's warnings in compile.c (unused locals are fixed)
 * EXTENDED_ARG problem
 * LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-23 04:53

Message:
Logged In: YES 
user_id=80475

FWIW, here are the warnings issued by my compiler:

Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : 
unreferenced local variable


compile.c
C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation 
from 'const int ' to 'char '


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-22 07:28

Message:
Logged In: YES 
user_id=33168

I assigned to Jeremy and Neil in the hopes they will see
this message and know about these problems.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:45

Message:
Logged In: YES 
user_id=4771

The following (similarly strange-looking) code snippets
compiled successfully before, now they give SyntaxErrors:

--------------------
def f():
    class g:
        exec "hi"
        x
--------------------
def f(x):
    class g:
        exec "hi"
        x
--------------------
def f():
    class g:
        from a import *
        x
--------------------
def f(x):
    class g:
        from a import *
        x


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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    while x:
        x -= 1
        # EXTENDED_ARG/JUMP_ABSOLUTE here
    return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
...     def g(self):
...       return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in <stdin>


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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

    def f():
        'a'
        'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '<lambda>' ?

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

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

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
    print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

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

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

From noreply at sourceforge.net  Mon Feb 13 00:14:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 15:14:25 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F8QQD-0008NZ-0u@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: aix-d (aix-d)
Assigned to: Neal Norwitz (nnorwitz)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

Comment By: Uyamba (uyamba)
Date: 2006-02-13 02:14

Message:
Logged In: YES 
user_id=1450360

Thank you very much!!! :-)
It works fine: python-devel from FreeBSD ports with three 
files updated by SVN to latest version. But i can't compile 
full last SVN release on FreeBSD :-( Could you help with 
updating FreeBSD port please.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-13 00:11

Message:
Logged In: YES 
user_id=33168

The 2.4 fix was committed in revision 42339.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-13 00:09

Message:
Logged In: YES 
user_id=33168

I get exceptions when running normally. I had to do ulimit
-n 2000 to be able to run without exception.

I can confirm that with an unpatched 2.4.2, python crashed.
 With the 2.4.2+ patch, no crash.  On SVN head (2.5), I
didn't get a crash, but got a thread exception.  I think
this bug may be fixed.  To get the new features, you need to
update at least these files:

http://svn.python.org/projects/python/branches/release24-maint/Modules/socketmodule.c
http://svn.python.org/projects/python/branches/release24-maint/Modules/_ssl.c
http://svn.python.org/projects/python/branches/release24-maint/PC/pyconfig.h

Please verify if this is fixed for you.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 23:54

Message:
Logged In: YES 
user_id=33168

Can you "print *s" ?  My guess is that s->sock_fd >
FD_SETSIZE on your box.  I will try your test code with the
current versions and see if they still fail.

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 20:48

Message:
Logged In: YES 
user_id=1450360

This is detailed backtrace (from python compiled with 
CFLAGS+="-g"):
======================================
#0  0xa8348959 in ?? ()
#1  0x08ebb800 in ?? ()
#2  0x00000001 in ?? ()
#3  0x77881688 in ?? ()
#4  0x28348947 in internal_connect (s=0x8ebb800, 
addr=0x8ebb818, addrlen=16,
    timeoutp=0x778816b4)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1740
#5  0x28348a00 in sock_connect (s=0x8ebb800, 
addro=0x8ebd72c)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1771
======================================

This is the /usr/ports/lang/python/work/Python-2.4.2/
Modules/socketmodule.c:
======================================
        if (s->sock_timeout > 0.0) {
1740:           if (res < 0 && errno == EINPROGRESS) {
                        timeout = internal_select(s, 1);
                        res = connect(s->sock_fd, addr, 
addrlen);
                        if (res < 0 && errno == EISCONN)
                                res = 0;
                }
        }
======================================

No ideas :-(

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 19:47

Message:
Logged In: YES 
user_id=1450360

This is test program that generates fault:
----------------------------
#!/usr/local/bin/python

import socket, time
from threading import Thread

class cthread(Thread):
        def __init__ (self):
                Thread.__init__(self)

        def run(self):
                socket.setdefaulttimeout(5)
                res = socket.getaddrinfo('19.54.123.2', 33, 
0, socket.SOCK_STREAM)[0]
                sock = socket.socket(res[0], res[1], res[2])
                try:
                        sock.connect(res[4])
                except: pass

def main():
        for i in range(1900):
                print "starting " + str(i)
                ct = cthread()
                ct.start()

if __name__ == '__main__':
        main()

----------------------------
IP 19.54.123.2 is random. Results are various for some IPs 
and hostnames.


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

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

Message:
Logged In: YES 
user_id=33168

Can you build python from source?  You can try checking out
the current 2.4 SVN.  This problem may have been fixed
recently.  I'm guessing that the socket descriptor value is
larger than FD_SETSIZE (probably 1k or 4k).  You also may
want to build python with debugging.

If that doesn't solve your problem, you will need to provide
more information about how to reproduce your problem.

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

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

From noreply at sourceforge.net  Mon Feb 13 00:20:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 15:20:29 -0800
Subject: [ python-Bugs-1429585 ] segfault in FreeBSD
Message-ID: <E1F8QW5-0000RL-5a@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: aix-d (aix-d)
Assigned to: Neal Norwitz (nnorwitz)
Summary: segfault in FreeBSD

Initial Comment:
Dear developers,

My program has many TCP connections (~30 per second),
MySQL connections (~100 per second) and threads (~280).
It works long time and receives this segmentation fault:

exited on signal 11 (core dumped)

=========== GDB OUTPUT
=================================================
Program received signal SIGSEGV, Segmentation fault.
0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
(gdb) backtrace
#0  0x283199e8 in ?? () from
/usr/local/lib/python2.4/lib-dynload/_socket.so
#1  0x2831b3d5 in internal_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#2  0x2831b440 in sock_connect ()
   from /usr/local/lib/python2.4/lib-dynload/_socket.so
#3  0x0805a828 in PyObject_Call ()
#4  0x080a01dd in PyEval_EvalFrame ()
#5  0x080a294f in PyEval_EvalCodeEx ()
#6  0x080a138b in PyEval_EvalFrame ()
#7  0x080a212d in PyEval_EvalFrame ()
#8  0x080a212d in PyEval_EvalFrame ()
#9  0x080a212d in PyEval_EvalFrame ()
#10 0x080a212d in PyEval_EvalFrame ()
#11 0x080a212d in PyEval_EvalFrame ()
#12 0x080a294f in PyEval_EvalCodeEx ()
#13 0x080a138b in PyEval_EvalFrame ()
#14 0x080a212d in PyEval_EvalFrame ()
#15 0x080a294f in PyEval_EvalCodeEx ()
#16 0x080da027 in PyFunction_SetClosure ()
#17 0x0805a828 in PyObject_Call ()
#18 0x080a01dd in PyEval_EvalFrame ()
#19 0x080a294f in PyEval_EvalCodeEx ()
#20 0x080a138b in PyEval_EvalFrame ()
#21 0x080a294f in PyEval_EvalCodeEx ()
#22 0x080a138b in PyEval_EvalFrame ()
#23 0x080a294f in PyEval_EvalCodeEx ()
#24 0x080a138b in PyEval_EvalFrame ()
#25 0x080a294f in PyEval_EvalCodeEx ()
#26 0x080a138b in PyEval_EvalFrame ()
#27 0x080a294f in PyEval_EvalCodeEx ()
#28 0x080a138b in PyEval_EvalFrame ()
#29 0x080a294f in PyEval_EvalCodeEx ()
#30 0x080a138b in PyEval_EvalFrame ()
#31 0x080a212d in PyEval_EvalFrame ()
#32 0x080a294f in PyEval_EvalCodeEx ()
#33 0x080da027 in PyFunction_SetClosure ()
#34 0x0805a828 in PyObject_Call ()
#35 0x080601e9 in PyMethod_New ()
#36 0x0805a828 in PyObject_Call ()
#37 0x0809cd31 in PyEval_CallObjectWithKeywords ()
#38 0x080c21a5 in _PyObject_GC_Del ()
#39 0x2821e0cc in pthread_create () from
/usr/lib/libpthread.so.2
#40 0x282db757 in _ctx_start () from /lib/libc.so.6
(gdb)
==== END OF GDB OUTPUT
=================================================

Imported modules: socket, atexit, time, pickle, os,
random, traceback, MySQLdb, re, urllib, urllib2, threading

Python version: 2.4.2

Operating system: FreeBSD 6.0-STABLE

Can you help with debugging?

Best regards, Alexander.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 15:20

Message:
Logged In: YES 
user_id=33168

Closing this bug report since it's fixed.

As to python not compiling on FreeBSD, open a new bug report
with all the info about what is causing the failure.  It
would be great if you can help diagnose the problem as not
many python developers have access to FreeBSD.  Is the
FreeBSD port up-to-date?

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 15:14

Message:
Logged In: YES 
user_id=1450360

Thank you very much!!! :-)
It works fine: python-devel from FreeBSD ports with three 
files updated by SVN to latest version. But i can't compile 
full last SVN release on FreeBSD :-( Could you help with 
updating FreeBSD port please.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 13:11

Message:
Logged In: YES 
user_id=33168

The 2.4 fix was committed in revision 42339.

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

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

Message:
Logged In: YES 
user_id=33168

I get exceptions when running normally. I had to do ulimit
-n 2000 to be able to run without exception.

I can confirm that with an unpatched 2.4.2, python crashed.
 With the 2.4.2+ patch, no crash.  On SVN head (2.5), I
didn't get a crash, but got a thread exception.  I think
this bug may be fixed.  To get the new features, you need to
update at least these files:

http://svn.python.org/projects/python/branches/release24-maint/Modules/socketmodule.c
http://svn.python.org/projects/python/branches/release24-maint/Modules/_ssl.c
http://svn.python.org/projects/python/branches/release24-maint/PC/pyconfig.h

Please verify if this is fixed for you.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-12 12:54

Message:
Logged In: YES 
user_id=33168

Can you "print *s" ?  My guess is that s->sock_fd >
FD_SETSIZE on your box.  I will try your test code with the
current versions and see if they still fail.

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 09:48

Message:
Logged In: YES 
user_id=1450360

This is detailed backtrace (from python compiled with 
CFLAGS+="-g"):
======================================
#0  0xa8348959 in ?? ()
#1  0x08ebb800 in ?? ()
#2  0x00000001 in ?? ()
#3  0x77881688 in ?? ()
#4  0x28348947 in internal_connect (s=0x8ebb800, 
addr=0x8ebb818, addrlen=16,
    timeoutp=0x778816b4)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1740
#5  0x28348a00 in sock_connect (s=0x8ebb800, 
addro=0x8ebd72c)
    at /usr/ports/lang/python/work/Python-2.4.2/Modules/
socketmodule.c:1771
======================================

This is the /usr/ports/lang/python/work/Python-2.4.2/
Modules/socketmodule.c:
======================================
        if (s->sock_timeout > 0.0) {
1740:           if (res < 0 && errno == EINPROGRESS) {
                        timeout = internal_select(s, 1);
                        res = connect(s->sock_fd, addr, 
addrlen);
                        if (res < 0 && errno == EISCONN)
                                res = 0;
                }
        }
======================================

No ideas :-(

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

Comment By: Uyamba (uyamba)
Date: 2006-02-12 08:47

Message:
Logged In: YES 
user_id=1450360

This is test program that generates fault:
----------------------------
#!/usr/local/bin/python

import socket, time
from threading import Thread

class cthread(Thread):
        def __init__ (self):
                Thread.__init__(self)

        def run(self):
                socket.setdefaulttimeout(5)
                res = socket.getaddrinfo('19.54.123.2', 33, 
0, socket.SOCK_STREAM)[0]
                sock = socket.socket(res[0], res[1], res[2])
                try:
                        sock.connect(res[4])
                except: pass

def main():
        for i in range(1900):
                print "starting " + str(i)
                ct = cthread()
                ct.start()

if __name__ == '__main__':
        main()

----------------------------
IP 19.54.123.2 is random. Results are various for some IPs 
and hostnames.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-11 22:54

Message:
Logged In: YES 
user_id=33168

Can you build python from source?  You can try checking out
the current 2.4 SVN.  This problem may have been fixed
recently.  I'm guessing that the socket descriptor value is
larger than FD_SETSIZE (probably 1k or 4k).  You also may
want to build python with debugging.

If that doesn't solve your problem, you will need to provide
more information about how to reproduce your problem.

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

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

From noreply at sourceforge.net  Mon Feb 13 05:30:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 20:30:38 -0800
Subject: [ python-Bugs-1430435 ] urlib2
Message-ID: <E1F8VME-0001b5-Kc@sc8-sf-web5.sourceforge.net>

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

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

Initial Comment:
reg = urllib2.Request(url, data, headers)
rl_handle = urllib2.urlopen(reg)

urllib2 has hot memory leaks.

gc: uncollectable <_fileobject memory_adres>
gc: uncollectable <list memory adres>


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

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

From noreply at sourceforge.net  Mon Feb 13 05:35:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 20:35:59 -0800
Subject: [ python-Bugs-1430436 ] recursive __getattr__ in thread crashes OS X
Message-ID: <E1F8VRP-0006CD-Li@sc8-sf-web1.sourceforge.net>

Bugs item #1430436, was opened at 2006-02-12 22: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=1430436&group_id=5470

Please note that this 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
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: recursive __getattr__ in thread crashes OS X

Initial Comment:
The following code consistently crashes Python 2.4 on Mac OS X:

import threading

class foo:
    def __getattr__(self, x): self.foo

def j(): foo().bar

t = threading.Thread(target=j, args=())
t.start()

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

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

From noreply at sourceforge.net  Mon Feb 13 05:41:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 20:41:51 -0800
Subject: [ python-Bugs-1430436 ] recursive __getattr__ in thread crashes BSDs
Message-ID: <E1F8VX5-0003W5-Gu@sc8-sf-web6.sourceforge.net>

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

Please note that this 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
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
>Summary: recursive __getattr__ in thread crashes BSDs

Initial Comment:
The following code consistently crashes Python 2.4 on Mac OS X:

import threading

class foo:
    def __getattr__(self, x): self.foo

def j(): foo().bar

t = threading.Thread(target=j, args=())
t.start()

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

>Comment By: Aaron Swartz (aaronsw)
Date: 2006-02-12 22:41

Message:
Logged In: YES 
user_id=122141

I've also tested it on FreeBSD and it has the same problem (Segmentation fault 
(core dumped)).

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

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

From noreply at sourceforge.net  Mon Feb 13 05:44:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 20:44:00 -0800
Subject: [ python-Bugs-1430436 ] recursive __getattr__ in thread crashes BSDs
Message-ID: <E1F8VZA-0000uv-Hz@sc8-sf-web2.sourceforge.net>

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

Please note that this 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
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: recursive __getattr__ in thread crashes BSDs

Initial Comment:
The following code consistently crashes Python 2.4 on Mac OS X:

import threading

class foo:
    def __getattr__(self, x): self.foo

def j(): foo().bar

t = threading.Thread(target=j, args=())
t.start()

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

>Comment By: Aaron Swartz (aaronsw)
Date: 2006-02-12 22:44

Message:
Logged In: YES 
user_id=122141

Since the indenting was off above, I've attached the code.

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

Comment By: Aaron Swartz (aaronsw)
Date: 2006-02-12 22:41

Message:
Logged In: YES 
user_id=122141

I've also tested it on FreeBSD and it has the same problem (Segmentation fault 
(core dumped)).

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

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

From noreply at sourceforge.net  Mon Feb 13 06:05:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 12 Feb 2006 21:05:20 -0800
Subject: [ python-Bugs-1428789 ] add /usr/local support
Message-ID: <E1F8Vto-0001fI-D2@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Karol Pietrzak (noodlez84)
Assigned to: Nobody/Anonymous (nobody)
Summary: add /usr/local support

Initial Comment:
Generally, /usr/local support needs to be added for   
python.  Many distributions already do this, either   
partially or completely, causing inconsistencies   
between Python installations among Linux   
distributions.   
   
1. There should be a site-packages directory   
in /usr/local,   
probably /usr/local/lib/python/site-packages.  Just   
like in /usr, it'll need the appropriate symlinks.    
x86_64 bit issues also need to be taken into account,   
so /usr/local/lib64/python2.4/site-packages should be   
the local site-packages directory for Python 2.4.x on   
a x86_64 machine.   
   
The reasons for these are numerous.  $PATH   
contains /usr/local/bin, $GTK_PATH   
contains /usr/local, $MANPATH   
contains /usr/local/share/man, and $PKG_CONFIG_PATH   
contains /usr/local/lib/pkgconfig.  Adding a   
site-packages directory in /usr/local will simply   
fill in the hole in the Python configuration.   
   
As the FHS points out, /usr may very well be mounted   
read-only for security purposes.  /usr/local should   
be used instead, especially for non-system / testing   
software.   
   
2. Distutils should install, by default, in   
the site-packages directory in /usr/local described  
in part (1).  This will simply mimic the auto(conf| 
make|etc.) default installation path (isn't the  
default installation path for Python  
itself /usr/local?).  
  
For simplicity and consistency's sake, the default  
installation path for distutils should be the 
site-packages directory in /usr/local. 
 
If someone would point me in the right direction, I 
will gladly write the patch myself. 

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

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

Message:
Logged In: YES 
user_id=21627

I fail to see the bug in Python here. In the default
configuration, Python does use site-packages in /usr/local,
and distutils does install into /usr/local. So it appears
that Python already does what you say you want.

Apparently, you are talking about Linux here. However, even
on Linux, Python installs to /usr/local by default. If Linux
distributors chose to install it into /usr, then why can't
they also arrange these other changes?

To get /usr/local<something> into sys.path, either edit
site.py, or add a file sitecustomize.py. At compile time,
you can also edit Modules/Setup[.local] to set SITEPATH.

To change the default installation directories, add a
distutils.cfg into the distutils directory, or edit the
unix_prefix scheme in command/install.py

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

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

From noreply at sourceforge.net  Mon Feb 13 13:12:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Feb 2006 04:12:05 -0800
Subject: [ python-Bugs-1429053 ] set documentation deficiencies
Message-ID: <E1F8cYn-0001jq-EP@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: set documentation deficiencies

Initial Comment:
http://www.python.org/doc/current/lib/types-set.html
has a dead link: "Module sets".

Also, there does not seem to be any documentation on
how to construct a set.   Does set()==set([])?   What
is allowed  as an argument to set()?  Any iterable?

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

>Comment By: Keith Briggs (kbriggs)
Date: 2006-02-13 12:12

Message:
Logged In: YES 
user_id=888261

Where is it fixed?  I see all the same problems at
http://www.python.org/dev/doc/devel/lib/types-set.html.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-10 16:21

Message:
Logged In: YES 
user_id=1188172

This is all already corrected, except for the empty set thing.

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

Comment By: Keith Briggs (kbriggs)
Date: 2006-02-10 15:53

Message:
Logged In: YES 
user_id=888261

Furthermore, the operations update etc. are mutations of s,
so wouldn't the definitions

s.update(t)  	s |= t  	return set s with elements added from t
s.intersection_update(t) 	s &= t 	return set s keeping only
elements also found in t
s.difference_update(t) 	s -= t 	return set s after removing
elements found in t
s.symmetric_difference_update(t) 	s ^= t 	return set s with
elements from s or t but not both

be better as 

s.update(t)  	s |= t  	add elements from t to s

etc.?
I'm not sure what the word "return" is doing here.


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

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

From noreply at sourceforge.net  Mon Feb 13 14:19:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Feb 2006 05:19:19 -0800
Subject: [ python-Bugs-1428789 ] add /usr/local support
Message-ID: <E1F8dbr-0001xa-BZ@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Karol Pietrzak (noodlez84)
Assigned to: Nobody/Anonymous (nobody)
Summary: add /usr/local support

Initial Comment:
Generally, /usr/local support needs to be added for   
python.  Many distributions already do this, either   
partially or completely, causing inconsistencies   
between Python installations among Linux   
distributions.   
   
1. There should be a site-packages directory   
in /usr/local,   
probably /usr/local/lib/python/site-packages.  Just   
like in /usr, it'll need the appropriate symlinks.    
x86_64 bit issues also need to be taken into account,   
so /usr/local/lib64/python2.4/site-packages should be   
the local site-packages directory for Python 2.4.x on   
a x86_64 machine.   
   
The reasons for these are numerous.  $PATH   
contains /usr/local/bin, $GTK_PATH   
contains /usr/local, $MANPATH   
contains /usr/local/share/man, and $PKG_CONFIG_PATH   
contains /usr/local/lib/pkgconfig.  Adding a   
site-packages directory in /usr/local will simply   
fill in the hole in the Python configuration.   
   
As the FHS points out, /usr may very well be mounted   
read-only for security purposes.  /usr/local should   
be used instead, especially for non-system / testing   
software.   
   
2. Distutils should install, by default, in   
the site-packages directory in /usr/local described  
in part (1).  This will simply mimic the auto(conf| 
make|etc.) default installation path (isn't the  
default installation path for Python  
itself /usr/local?).  
  
For simplicity and consistency's sake, the default  
installation path for distutils should be the 
site-packages directory in /usr/local. 
 
If someone would point me in the right direction, I 
will gladly write the patch myself. 

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

>Comment By: Karol Pietrzak (noodlez84)
Date: 2006-02-13 08:19

Message:
Logged In: YES 
user_id=474815

Thanks for the response loewis! 
 
I apologize for mis-construing how Python is configured.  
It's easy to do because few compile their own Python; most 
just use the binary for their distribution. 
 
Based on your response, then yes, Python already does what 
I want, and the bug is in the packaging of my 
distribution--SuSE 10.0 x86_64.  For those interested in 
following this, the SuSE bug this relates to is: 
https://bugzilla.novell.com/show_bug.cgi?id=149809 

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

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

Message:
Logged In: YES 
user_id=21627

I fail to see the bug in Python here. In the default
configuration, Python does use site-packages in /usr/local,
and distutils does install into /usr/local. So it appears
that Python already does what you say you want.

Apparently, you are talking about Linux here. However, even
on Linux, Python installs to /usr/local by default. If Linux
distributors chose to install it into /usr, then why can't
they also arrange these other changes?

To get /usr/local<something> into sys.path, either edit
site.py, or add a file sitecustomize.py. At compile time,
you can also edit Modules/Setup[.local] to set SITEPATH.

To change the default installation directories, add a
distutils.cfg into the distutils directory, or edit the
unix_prefix scheme in command/install.py

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

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

From noreply at sourceforge.net  Mon Feb 13 20:29:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Feb 2006 11:29:11 -0800
Subject: [ python-Bugs-1429053 ] set documentation deficiencies
Message-ID: <E1F8jNn-0003mI-PE@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: set documentation deficiencies

Initial Comment:
http://www.python.org/doc/current/lib/types-set.html
has a dead link: "Module sets".

Also, there does not seem to be any documentation on
how to construct a set.   Does set()==set([])?   What
is allowed  as an argument to set()?  Any iterable?

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

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-13 20:29

Message:
Logged In: YES 
user_id=1188172

The new location of the devel docs is
http://docs.python.org/dev.

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

Comment By: Keith Briggs (kbriggs)
Date: 2006-02-13 13:12

Message:
Logged In: YES 
user_id=888261

Where is it fixed?  I see all the same problems at
http://www.python.org/dev/doc/devel/lib/types-set.html.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-10 17:21

Message:
Logged In: YES 
user_id=1188172

This is all already corrected, except for the empty set thing.

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

Comment By: Keith Briggs (kbriggs)
Date: 2006-02-10 16:53

Message:
Logged In: YES 
user_id=888261

Furthermore, the operations update etc. are mutations of s,
so wouldn't the definitions

s.update(t)  	s |= t  	return set s with elements added from t
s.intersection_update(t) 	s &= t 	return set s keeping only
elements also found in t
s.difference_update(t) 	s -= t 	return set s after removing
elements found in t
s.symmetric_difference_update(t) 	s ^= t 	return set s with
elements from s or t but not both

be better as 

s.update(t)  	s |= t  	add elements from t to s

etc.?
I'm not sure what the word "return" is doing here.


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

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

From noreply at sourceforge.net  Mon Feb 13 23:47:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Feb 2006 14:47:32 -0800
Subject: [ python-Bugs-1431091 ] CSV Sniffer fails to report mismatch of
	column counts
Message-ID: <E1F8mTk-0006Mi-HW@sc8-sf-web6.sourceforge.net>

Bugs item #1431091, was opened at 2006-02-13 19:47
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=1431091&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Vinko (vvrsalob)
Assigned to: Nobody/Anonymous (nobody)
Summary: CSV Sniffer fails to report mismatch of column counts

Initial Comment:
If one line of a CSV file is missing one or more
commas, the delimiter detection code of the Sniffer
class fails, setting delimiter to an empty string.

This leads to a totally misleading error when using
has_header(). 

This code shows the problem (Python 2.4.2, FC3 and
Ubuntu Breezy):

import csv

str1 = "a,b,c,d\r\n1,2,foo bar,dead
beef\r\nthis,line,is,ok\r\n"
str2 = "a,b,c,d\r\n1,2,foo bar,dead beef\r\nthis,line
is,not\r\n"

s = csv.Sniffer()

d1 = s.sniff(str1)
d2 = s.sniff(str2)

for line in str1.split('\r\n'):
    print line.count(',')

print d1.delimiter
print s.has_header(str1)

for line in str2.split('\r\n'):
    print line.count(',')

print d2.delimiter
print s.has_header(str2)


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

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

From noreply at sourceforge.net  Tue Feb 14 07:07:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 13 Feb 2006 22:07:50 -0800
Subject: [ python-Bugs-1431253 ] Logging hangs thread after detaching a
	StreamHandler's termi
Message-ID: <E1F8tLq-00076x-Ul@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Logging hangs thread after detaching a StreamHandler's termi

Initial Comment:
Hi all,

After many hours, I think I've found a bug in the 
logging module!

If you add a (stdout) StreamHandler to a logger, then 
detach the terminal for that stdout, subsequent calls 
to log() will hang the calling thread.

To reproduce this, write the following scripts (this 
was a small test case I came up with - maybe there's 
something simpler):

$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ; 
done'

$ cat hup.bash
#!/usr/bin/env bash
./hup.py &

$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
        logging.basicConfig( filename = '/tmp/lup.out', 
filemode = 'w' )
        # XXX PROBLEM LINE BELOW
        logging.getLogger('').addHandler( logging.
StreamHandler() )
        while True:
                f.write( '-------\n' )
                f.flush()
                logging.critical( '======' )
                time.sleep(1)
finally:
        f.close()

Run ./tryhup.bash. It will sit in an idle spin. Monitor 
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on 
tryhup to kill it. The python process is still running, 
but is stalled (the .out files are no longer changing).

If you remove the above labeled line, however, this 
doesn't happen.

Can anybody please acknowledge this bug? Any temporary 
workarounds to this problem? Thanks in advance for 
looking into this and for hearing me in!

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

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

From noreply at sourceforge.net  Tue Feb 14 12:34:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 14 Feb 2006 03:34:45 -0800
Subject: [ python-Bugs-1431253 ] Logging hangs thread after detaching a
	StreamHandler's termi
Message-ID: <E1F8ySD-0005Ha-33@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Yang Zhang (yangzhang)
>Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi

Initial Comment:
Hi all,

After many hours, I think I've found a bug in the 
logging module!

If you add a (stdout) StreamHandler to a logger, then 
detach the terminal for that stdout, subsequent calls 
to log() will hang the calling thread.

To reproduce this, write the following scripts (this 
was a small test case I came up with - maybe there's 
something simpler):

$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ; 
done'

$ cat hup.bash
#!/usr/bin/env bash
./hup.py &

$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
        logging.basicConfig( filename = '/tmp/lup.out', 
filemode = 'w' )
        # XXX PROBLEM LINE BELOW
        logging.getLogger('').addHandler( logging.
StreamHandler() )
        while True:
                f.write( '-------\n' )
                f.flush()
                logging.critical( '======' )
                time.sleep(1)
finally:
        f.close()

Run ./tryhup.bash. It will sit in an idle spin. Monitor 
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on 
tryhup to kill it. The python process is still running, 
but is stalled (the .out files are no longer changing).

If you remove the above labeled line, however, this 
doesn't happen.

Can anybody please acknowledge this bug? Any temporary 
workarounds to this problem? Thanks in advance for 
looking into this and for hearing me in!

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

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

From noreply at sourceforge.net  Tue Feb 14 12:35:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 14 Feb 2006 03:35:04 -0800
Subject: [ python-Bugs-1431091 ] CSV Sniffer fails to report mismatch of
	column counts
Message-ID: <E1F8ySW-0005Hg-Sl@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Vinko (vvrsalob)
>Assigned to: Andrew McNamara (andrewmcnamara)
Summary: CSV Sniffer fails to report mismatch of column counts

Initial Comment:
If one line of a CSV file is missing one or more
commas, the delimiter detection code of the Sniffer
class fails, setting delimiter to an empty string.

This leads to a totally misleading error when using
has_header(). 

This code shows the problem (Python 2.4.2, FC3 and
Ubuntu Breezy):

import csv

str1 = "a,b,c,d\r\n1,2,foo bar,dead
beef\r\nthis,line,is,ok\r\n"
str2 = "a,b,c,d\r\n1,2,foo bar,dead beef\r\nthis,line
is,not\r\n"

s = csv.Sniffer()

d1 = s.sniff(str1)
d2 = s.sniff(str2)

for line in str1.split('\r\n'):
    print line.count(',')

print d1.delimiter
print s.has_header(str1)

for line in str2.split('\r\n'):
    print line.count(',')

print d2.delimiter
print s.has_header(str2)


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

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

From noreply at sourceforge.net  Tue Feb 14 16:44:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 14 Feb 2006 07:44:02 -0800
Subject: [ python-Bugs-1431582 ] long path support in win32 part of
	os.listdir(posixmodule.c)
Message-ID: <E1F92LS-0006sU-NR@sc8-sf-web5.sourceforge.net>

Bugs item #1431582, was opened at 2006-02-14 18: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=1431582&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergey Dorofeev (fidoman)
Assigned to: Nobody/Anonymous (nobody)
Summary: long path support in win32 part of os.listdir(posixmodule.c)

Initial Comment:
When passing path to os.listdir that is longer then 
MAX_PATH (what is supported in Windows API, 
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/fileio/fs/naming_a_file.asp) the 
path is truncated at position MAX_PATH=260 and 
appended with "/*.*", so underlying Windows API 
function FindFirstFileW gets garbage on input: 
original path truncated, and symbol "/" is added, 
which may not be used as path separator in long path.
I think posix_listdir should or raise error when 
getting extra long string, or pass it unchanged to 
underlying API.
Affected code is in Modules\posixmodule.c, lines 1470-
1478 (Python 2.4.2).
I think there is enough to change base when 
calculating size of allocated memory and copied block 
from fixed value of MAX_PATH to length of passed to 
function string.
And use os.sep instead of "/", of course.


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

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

From noreply at sourceforge.net  Tue Feb 14 18:14:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 14 Feb 2006 09:14:10 -0800
Subject: [ python-Bugs-672578 ] pydoc does not cope well with lambda
Message-ID: <E1F93kg-00082U-FH@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.2.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jim Meyer (purp)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc does not cope well with lambda

Initial Comment:
pydoc doesn't deal well with lambda expressions. Here's
some sample code:
================================================================
#!/usr/bin/env python2
&quot;&quot;&quot;a bogus program

Demonstrate that pydoc doesn't handle lambdas well
&quot;&quot;&quot;

#
--------------------------------------------------------------------
# A comment heading
#
--------------------------------------------------------------------
def foo (optional = 1) :
	''' A bogus function '''
	return optional

bar = lambda opt : foo(opt)
================================================================

...and here's what pydoc says:

================================================================
&gt; pydoc /tmp/foo.py
Python Library Documentation: module foo

NAME
    foo - a bogus program

FILE
    /tmp/foo.py

DESCRIPTION
    Demonstrate that pydoc doesn't handle lambdas well

FUNCTIONS
    lambdaopt
        #
--------------------------------------------------------------------
        # A comment heading
        #
--------------------------------------------------------------------
    
    foo(optional=1)
         A bogus function

DATA
    __file__ = '/tmp/foo.pyc'
    __name__ = 'foo'

================================================================

I'm looking for the cause now and hope to contribute a
patch shortly.

--j

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

Comment By: William McVey (wamcvey)
Date: 2006-02-14 17:14

Message:
Logged In: YES 
user_id=25956

This problem still appears to exist under python 2.4.2

drop the following into PydocLambdaTest.py and run 'pydoc
PydocLambdaTest':

#!/usr/bin/env python

"""Simple test cases for doc strings attached to lambda
generated functions
and methods
"""

def test_function(x, y):
        """This is a test function doc string"""
        pass

test_lambda = lambda x, y: True

test_lambda2 = lambda x, y: True
test_lambda2.__doc__ = "This is a docstring on a lambda
function"


class TestClass:
        def test_method(self, x, y):
                """Just a docstring on a method"""
                pass
        
        sum = lambda self, x, y: x+y

        mult = lambda self, x, y: x*y
        mult.__doc__ = "Multiplies the two arguments "

if __name__ == '__main__':
        obj = TestClass()
        print "sum of 5 and 7:", obj.sum(5, 7)
        print "mult of 5 and 7:", obj.mult(5, 7)


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-23 01:55

Message:
Logged In: YES 
user_id=80475

The underlying cause is that the inspect module was not 
trained to handle lambdas or single line function defintions 
like:

def oneliner(x): return x**2

The problem was fixed in Py2.3 and backported for 
Py2.2.3.

Marking as fixed and closing.

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

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

From noreply at sourceforge.net  Wed Feb 15 11:14:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 02:14:29 -0800
Subject: [ python-Bugs-1431582 ] long path support in win32 part of
	os.listdir(posixmodule.c)
Message-ID: <E1F9Jg5-0000xv-2w@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergey Dorofeev (fidoman)
>Assigned to: Martin v. L??wis (loewis)
Summary: long path support in win32 part of os.listdir(posixmodule.c)

Initial Comment:
When passing path to os.listdir that is longer then 
MAX_PATH (what is supported in Windows API, 
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/fileio/fs/naming_a_file.asp) the 
path is truncated at position MAX_PATH=260 and 
appended with "/*.*", so underlying Windows API 
function FindFirstFileW gets garbage on input: 
original path truncated, and symbol "/" is added, 
which may not be used as path separator in long path.
I think posix_listdir should or raise error when 
getting extra long string, or pass it unchanged to 
underlying API.
Affected code is in Modules\posixmodule.c, lines 1470-
1478 (Python 2.4.2).
I think there is enough to change base when 
calculating size of allocated memory and copied block 
from fixed value of MAX_PATH to length of passed to 
function string.
And use os.sep instead of "/", of course.


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

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

From noreply at sourceforge.net  Wed Feb 15 17:03:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 08:03:21 -0800
Subject: [ python-Bugs-1432260 ] pydoc still doesn't handle lambda well
Message-ID: <E1F9P7h-000549-9R@sc8-sf-web1.sourceforge.net>

Bugs item #1432260, was opened at 2006-02-15 16: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=1432260&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: William McVey (wamcvey)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc still doesn't handle lambda well

Initial Comment:
This is a duplicate of Bug ID 672578, but I could find
no way for a 'normal user' to reopen a closed bug ticket. 

Pydoc doesn't currently handle functions and methods
defined with lambda very well. Not only are names
associated with a lambda defined function/method not
indicated in the generated module and class
definitions, but docstrings attached to the object
generated by lambda are not integrated into the output.

I've attached a sample program that illustrates the
discrepency of handling methods defined with 'def'
versus those that are handled with 'lambda'.


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

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

From noreply at sourceforge.net  Wed Feb 15 17:15:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 08:15:15 -0800
Subject: [ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission
	denied
Message-ID: <E1F9PJD-0002rO-6v@sc8-sf-web3.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied

Initial Comment:
When running the following program I get frequent
errors like this one

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
    self.run()
  File "os.remove.py", line 25, in run
    os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'

When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?

Thanks in advance

Joram Agten



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

>Comment By: cheops (atila-cheops)
Date: 2006-02-15 16:15

Message:
Logged In: YES 
user_id=1276121

os.remove3.py
when using the os.write() function and os.close() function
to do the file writing, no problems are seen either.

so this seems to be a bug in the 'normal' file input output
functions under windows.
they don't seem to be thread safe in a way or another.
maybe the close() function returns too early?

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

Comment By: cheops (atila-cheops)
Date: 2006-02-15 15:50

Message:
Logged In: YES 
user_id=1276121

further looking into the problem:
when using the win32api calls to write to the file, this
seems to work.
see os.remove_win.py

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

Comment By: cheops (atila-cheops)
Date: 2006-02-10 09:58

Message:
Logged In: YES 
user_id=1276121

When running the same script, but now with the windows
remove function (cmd /c rm filename)
still problems occur, so maybe this is a windows problem
after all?
or does subprocess do things wrong?

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

Comment By: cheops (atila-cheops)
Date: 2006-02-07 11:32

Message:
Logged In: YES 
user_id=1276121

for the subprocess.py I did the following in a few places

try:
    _active.remove(self)
except:
    pass

see also bug 1199282
https://sourceforge.net/tracker/index.php?func=detail&aid=1199282&group_id=5470&atid=105470

in my current script I circumvent the "Permission denied"
error in the following way:

removed = False
while not removed:
try:
    os.remove(file)
    except OSError, error:
        logger.warning("could not remove file %s, %s"
%(file, error))
        time.sleep(1)
    else:
        removed = True

I also have a virus scanner (Mcafee, corporate stuff), and
still get the same behaviour when disabling the virus scanner.

>My feel, after staring at filemon output, is that this is a
>problem in the Windows file I/O layer.  NTFS queues the
>various operations, and calling an external process with
>stuff still in the queue messes up the request scheduling.

this seems strange to me, since every thread works with its
own temp files, and all requests are send one after another
to the file I/O layer

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-07 07:59

Message:
Logged In: YES 
user_id=38376

"Does it tell you more than _just_ that?  It doesn't for me."

All requests against the file in question were issued by the
python process; there's no sign of virus checkers or other
external applications.

Also, whenever things failed, there were always multiple
requests for cmd.exe (caused by os.system) between the WRITE
request and the failing OPEN request.
 
My feel, after staring at filemon output, is that this is a
problem in the Windows file I/O layer.  NTFS queues the
various operations, and calling an external process with
stuff still in the queue messes up the request scheduling.

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

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

Message:
Logged In: YES 
user_id=31435

[/F]
> Except that he's hitting the file system quite heavily,

Except that _without_ the call to touch(), he's hitting it
even more heavily, creating and destroying little files just
as fast as the OS can do it in each of 10 threads -- but
there aren't any errors then.

> and asyncronously.

What's asynch here?  The OP's touch() function waits for the
spawned process to terminate, and the test driver doesn't
try to delete the file until after that.

> My guess is that Windows simply gets behind
> (a quick filemon test indicates that this is indeed the
> case; just before a crash, I see the events
> CREATE/SUCCESS, QUERY/SUCCESS, QUERY/SUCCESS,
> WRITE/SUCCESS, and OPEN/SHARING VIOLATION for the
> failing file, with lots of requests for other files
> interleaved).

That's consistent with the symptom reported:  an exception
raised upon trying to remove the file, but not during any
other file operation.  Does it tell you more than _just_
that?  It doesn't for me.

> Unless someone wants to fix Windows,

As above, because removing the call to the internal `touch`
function makes all problems go away it's not obvious that
this is a Windows problem.

> a simple workaround would be to retry the os.remove a
> few times before giving up (with a time.sleep(0.1) in
> between).

Because of the internal threading errors in subprocess.py
(see my first comment), the threads in the test program
still usually die, but with instances of list.remove(x)
ValueErrors internal to subprocess.py.

If I hack around that, then this change to the test
program's file-removal code appears adequate to eliminate
all errors on my box (which is a zippy 3.4 GHz):

            try:
                os.remove(filename)
            except OSError:
                time.sleep(0.1)
                os.remove(filename)

It's possible that some virus-scanning or file-indexing
gimmick on my box is opening these little files for its own
purposes -- although, if so, I'm at a loss to account for
why a single "os.remove(filename)" never raises an exception
when the `touch()` call is commented out.

OTOH, with the `touch()` call intact, the time.sleep(0.1)
above is not adequate to prevent os.remove() errors if I
change the file-writing code to:

    f.write("test" * 250000)

Even boosting the sleep() to 0.4 isn't enough then.

That does (mildly) suggest there's another process opening
the temp files, and doing something with them that takes
time proportional to the file size.  However, the
os.remove() errors persist when I disable all such gimmicks
(that I know about ;-)) on my box.

It seems likely I'll never determine a cause for that.  The
bad thread behavior in subprocess.py is independent, and
should be repaired regardless.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 23:05

Message:
Logged In: YES 
user_id=38376

> The problem is that there's no reason to believe anything
> he did here _does_ leave files open.

Except that he's hitting the file system quite heavily, and
asyncronously.  My guess is that Windows simply gets behind
(a quick filemon test indicates that this is indeed the
case; just before a crash, I see the events CREATE/SUCCESS,
QUERY/SUCCESS, QUERY/SUCCESS, WRITE/SUCCESS, and
OPEN/SHARING VIOLATION for the failing file, with lots of
requests for other files interleaved).

Unless someone wants to fix Windows, a simple workaround
would be to retry the os.remove a few times before giving up
(with a time.sleep(0.1) in between).

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

Comment By: cheops (atila-cheops)
Date: 2006-02-06 22:53

Message:
Logged In: YES 
user_id=1276121

I did post on the python mailing list first, but got no 
responce there, after further looking into it, I seriously 
think there is at least one bug here.

here is the link to the post: 
http://mail.python.org/pipermail/python-list/2006-
February/323650.html

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

Comment By: Tim Peters (tim_one)
Date: 2006-02-06 22:19

Message:
Logged In: YES 
user_id=31435

The problem is that there's no reason to believe anything he
did here _does_ leave files open.  I can confirm the
"permission denied" symptom, and even if I arrange for the
call to "touch" to run a touch.bat that doesn't even look at
the filename passed to it (let alone open or modify the file).

I also see a large number of errors of this sort:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "C:\python24\lib\threading.py", line 442, in __bootstrap
    self.run()
  File "osremove.py", line 21, in run
    touch(filename)
  File "osremove.py", line 8, in touch
    stdin=None, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
  File "C:\python24\lib\subprocess.py", line 490, in __init__
    _cleanup()
  File "C:\python24\lib\subprocess.py", line 398, in _cleanup
    inst.poll()
  File "C:\python24\lib\subprocess.py", line 739, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Those are clearly due to subprocess.py internals on Windows,
where the poll() and wait() methods and the module internal
_cleanup() function aren't called in mutually threadsafe
ways.  _Those_ errors can be stopped by commenting out the
_cleanup() call at the start of Popen.__init__() (think
about what happens when multiple threads call _cleanup() at
overlapping times on Windows:  all those threads can end up
trying to remove the same items from _active, but only one
thread per item can succeed).

The "permission denied" errors persist, though.

So there's at least one class of subprocess.py Windows bugs
here, and another class of Windows mysteries.  I believe
subprocess.py is a red herring wrt the latter, though.  For
example, I see much the same if I use os.system() to run
`touch` instead.

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

Comment By: Fredrik Lundh (effbot)
Date: 2006-02-06 21:50

Message:
Logged In: YES 
user_id=38376

If Python gives you a permission error, that's because
Windows cannot remove the file.  Windows does, in general,
not allow you to remove files that are held open by some
process.

I suggest taking this issue to comp.lang.python.  The bug
tracker is not the right place for code review and other
support issues.

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

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

From noreply at sourceforge.net  Wed Feb 15 18:49:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 09:49:14 -0800
Subject: [ python-Bugs-1432343 ] Descript of file-object read() method is
	wrong.
Message-ID: <E1F9QmA-0005ZS-As@sc8-sf-web1.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Edwards (grante)
Assigned to: Nobody/Anonymous (nobody)
Summary: Descript of file-object read() method is wrong.

Initial Comment:
There are two errors in the documentation of the file
object's
read() method found at

http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242

Suggested changes (unindented) are shown below interspersed
with the current text with insertions noted by a '+' in the
first column:

     Read at most size bytes from the file (less if the
read
     hits EOF before obtaining size bytes). If the size
     argument is negative or omitted, read all data
until EOF
     is reached.
     
+ Under some circumstances (e.g. system call aborted by
+ a signal) read() called with a negative or absent size
+ argument may return data before EOF is reached (even in
+ blocking mode).
     
     The bytes are returned as a string object. An
empty string
     is returned when EOF is encountered immediately. (For
     certain files, like ttys, it makes sense to continue
     reading after an EOF is hit.)

The last sentence above (the parenthetical one) is
false for
Linux/Unix.  Once you hit EOF on a tty, it will return EOF
forever until it's closed and re-opened.  If the above
sentence
is true for other OSes, I suggest it be so qualified --
otherwise it should just be deleted.
     
     Note that this method may call the underlying C
function
     fread() more than once in an effort to acquire as
close to
     size bytes as possible. Also note that when in
     non-blocking mode, less data than what was
requested may
     be returned, even if no size parameter was given. 


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

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

From noreply at sourceforge.net  Wed Feb 15 18:51:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 09:51:08 -0800
Subject: [ python-Bugs-1432343 ] Description of file-object read() method is
	wrong.
Message-ID: <E1F9Qo0-0004UO-SM@sc8-sf-web6.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Edwards (grante)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Description of file-object read() method is wrong.

Initial Comment:
There are two errors in the documentation of the file
object's
read() method found at

http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242

Suggested changes (unindented) are shown below interspersed
with the current text with insertions noted by a '+' in the
first column:

     Read at most size bytes from the file (less if the
read
     hits EOF before obtaining size bytes). If the size
     argument is negative or omitted, read all data
until EOF
     is reached.
     
+ Under some circumstances (e.g. system call aborted by
+ a signal) read() called with a negative or absent size
+ argument may return data before EOF is reached (even in
+ blocking mode).
     
     The bytes are returned as a string object. An
empty string
     is returned when EOF is encountered immediately. (For
     certain files, like ttys, it makes sense to continue
     reading after an EOF is hit.)

The last sentence above (the parenthetical one) is
false for
Linux/Unix.  Once you hit EOF on a tty, it will return EOF
forever until it's closed and re-opened.  If the above
sentence
is true for other OSes, I suggest it be so qualified --
otherwise it should just be deleted.
     
     Note that this method may call the underlying C
function
     fread() more than once in an effort to acquire as
close to
     size bytes as possible. Also note that when in
     non-blocking mode, less data than what was
requested may
     be returned, even if no size parameter was given. 


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

>Comment By: Grant Edwards (grante)
Date: 2006-02-15 17:51

Message:
Logged In: YES 
user_id=61937

Well, that didn't work very well.  I really hate these web
interfaces.  I've attached the suggested changes as a text file.

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

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

From noreply at sourceforge.net  Wed Feb 15 19:16:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 10:16:05 -0800
Subject: [ python-Bugs-1432350 ] arrayobject should use PyObject_VAR_HEAD
Message-ID: <E1F9RC9-0002RJ-Qg@sc8-sf-web5.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: arrayobject should use PyObject_VAR_HEAD

Initial Comment:
The only difference between PyObject_VAR_HEAD and 
PyObject_HEAD is that VAR_HEAD adds Py_ssize_t ob_size;

This is also the first field that arrayobject adds; it 
would be clearer to just use PyObject_VAR_HEAD and take 
the field out of arrayobject's explicit declaration.

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

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

From noreply at sourceforge.net  Wed Feb 15 21:26:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 12:26:42 -0800
Subject: [ python-Feature Requests-1432437 ] itertools.any and itertools.all
Message-ID: <E1F9TEY-0003jY-Ro@sc8-sf-web3.sourceforge.net>

Feature Requests item #1432437, was opened at 2006-02-15 13: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=1432437&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul cannon (paulcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: itertools.any and itertools.all

Initial Comment:
Just a couple very simple "shortcutting" functions that
I find myself needing quite frequently.
"reduce(operator.or_, foo, False)" is all right, but
potentially does a lot more work.


def any(i):
    """Returns true if any element from i is true."""

    for element in i:
        if i:
            return True
    return False


all() would also be nice:


def all(i):
    """Returns true if all elements from i are true."""

    for element in i:
        if not i:
            return False
    return True


..although it /could/ simply be built on any() as "not
any(imap(operator.not_, i))".


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

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

From noreply at sourceforge.net  Wed Feb 15 21:44:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 12:44:30 -0800
Subject: [ python-Feature Requests-1432437 ] itertools.any and itertools.all
Message-ID: <E1F9TVm-00052a-3M@sc8-sf-web6.sourceforge.net>

Feature Requests item #1432437, was opened at 2006-02-15 21:26
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432437&group_id=5470

Please note that this message 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: Out of Date
Priority: 5
Submitted By: paul cannon (paulcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: itertools.any and itertools.all

Initial Comment:
Just a couple very simple "shortcutting" functions that
I find myself needing quite frequently.
"reduce(operator.or_, foo, False)" is all right, but
potentially does a lot more work.


def any(i):
    """Returns true if any element from i is true."""

    for element in i:
        if i:
            return True
    return False


all() would also be nice:


def all(i):
    """Returns true if all elements from i are true."""

    for element in i:
        if not i:
            return False
    return True


..although it /could/ simply be built on any() as "not
any(imap(operator.not_, i))".


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

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-15 21:44

Message:
Logged In: YES 
user_id=1188172

These two happen to become builtins in 2.5.

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

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

From noreply at sourceforge.net  Thu Feb 16 07:39:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 15 Feb 2006 22:39:24 -0800
Subject: [ python-Bugs-1431962 ] crash when using grid(row or column >9998)
Message-ID: <E1F9cnU-0003Sa-51@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Niekel (cniekel)
Assigned to: Martin v. L??wis (loewis)
Summary: crash when using grid(row or column >9998)

Initial Comment:
Hi,

The following crashes python with a coredump in linux, 
and a 'send report'-message in windows:

from Tkinter import *
r = Tk()
l = Label(r, text='hello')
l.grid(row=10000,column=10000)

Amanjit Gill looked at the tk code and found in tkgrid.
c: if (slot < 0 || slot >= MAX_ELEMENT) { return 
TCL_ERROR; }

(Where MAX_ELEMENT is 10000)
It would be better (imho) if python would raise an 
exception instead of crashing.


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

>Comment By: Chris Niekel (cniekel)
Date: 2006-02-16 07:39

Message:
Logged In: YES 
user_id=106343

>From more discussion on the tkinter mailinglist, I 
understood that the problem is in Tk, since a tcl script has 
the same problem. 

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

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

From noreply at sourceforge.net  Thu Feb 16 09:11:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 00:11:55 -0800
Subject: [ python-Feature Requests-1432694 ] Implement preemptive threads in
	Python
Message-ID: <E1F9eF1-00050T-54@sc8-sf-web3.sourceforge.net>

Feature Requests item #1432694, was opened at 2006-02-16 10:11
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=1432694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implement preemptive threads in Python

Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.

The idea behind Python is that programming should not
be a pain, right?

This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.

I apologize if this issue has already been raised before.

Cheers,
darkprokoba

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

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

From noreply at sourceforge.net  Thu Feb 16 12:17:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 03:17:51 -0800
Subject: [ python-Bugs-1432343 ] Description of file-object read() method is
	wrong.
Message-ID: <E1F9h8x-00047j-NV@sc8-sf-web2.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Edwards (grante)
Assigned to: Nobody/Anonymous (nobody)
Summary: Description of file-object read() method is wrong.

Initial Comment:
There are two errors in the documentation of the file
object's
read() method found at

http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242

Suggested changes (unindented) are shown below interspersed
with the current text with insertions noted by a '+' in the
first column:

     Read at most size bytes from the file (less if the
read
     hits EOF before obtaining size bytes). If the size
     argument is negative or omitted, read all data
until EOF
     is reached.
     
+ Under some circumstances (e.g. system call aborted by
+ a signal) read() called with a negative or absent size
+ argument may return data before EOF is reached (even in
+ blocking mode).
     
     The bytes are returned as a string object. An
empty string
     is returned when EOF is encountered immediately. (For
     certain files, like ttys, it makes sense to continue
     reading after an EOF is hit.)

The last sentence above (the parenthetical one) is
false for
Linux/Unix.  Once you hit EOF on a tty, it will return EOF
forever until it's closed and re-opened.  If the above
sentence
is true for other OSes, I suggest it be so qualified --
otherwise it should just be deleted.
     
     Note that this method may call the underlying C
function
     fread() more than once in an effort to acquire as
close to
     size bytes as possible. Also note that when in
     non-blocking mode, less data than what was
requested may
     be returned, even if no size parameter was given. 


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

Comment By: YoHell (yohell)
Date: 2006-02-16 12:17

Message:
Logged In: YES 
user_id=1008220

Well spoken!

However I'm not sure I quite follow you here:

> The last sentence above (the parenthetical one) is false 
> for Linux/Unix. Once you hit EOF on a tty, it will return
> EOF forever until it's closed and re-opened. 

A quote from Donn Cave in a discussion on comp.lang.python:
"""
They were probably thinking of the way the UNIX tty
driver delivers an EOF on <ctrl>D, after which of
course you can continue to read data from the same tty.

"""
This is also true for the Linux tty (afaik), so under those
circumstances it may really make sense to continue reading
past EOF.

example:
-------------------------------------------------
#!/usr/bin/python
import sys
while True:
    s = sys.stdin.read()
    print s
-------------------------------------------------

Pressing Ctrl-D while providing input to sys.stdin via the
keyboard will cause sys.stdin.read() to return, and you will
still be able to keep reading from sys.stdin without closing
and reopening it explicitly.

But then again I might have missed something.

/Joel Hedlund

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

Comment By: Grant Edwards (grante)
Date: 2006-02-15 18:51

Message:
Logged In: YES 
user_id=61937

Well, that didn't work very well.  I really hate these web
interfaces.  I've attached the suggested changes as a text file.

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

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

From noreply at sourceforge.net  Thu Feb 16 12:41:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 03:41:46 -0800
Subject: [ python-Bugs-1293741 ] doctest runner cannot handle non-ascii
	characters 
Message-ID: <E1F9hW6-0007gH-S1@sc8-sf-web1.sourceforge.net>

Bugs item #1293741, was opened at 2005-09-17 13:41
Message generated for change (Comment added) made by bjoti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: GRISEL (ogrisel)
Assigned to: Tim Peters (tim_one)
Summary: doctest runner cannot handle non-ascii characters 

Initial Comment:
The doctest module fails when the expected result
string has non-ascii charcaters even if the # -*-
coding: XXX -*- line is properly set.

The enclosed code sample produce the following error:

Traceback (most recent call last):
  File "test_iso-8859-15.py", line 41, in ?
    _test()
  File "test_iso-8859-15.py", line 26, in _test
    tried, failed = runner.run(t)
  File "/usr/lib/python2.4/doctest.py", line 1376, in run
    return self.__run(test, compileflags, out)
  File "/usr/lib/python2.4/doctest.py", line 1259, in __run
    if check(example.want, got, self.optionflags):
  File "/usr/lib/python2.4/doctest.py", line 1475, in
check_output
    if got == want:
UnicodeDecodeError: 'ascii' codec can't decode byte
0xe9 in position 8: ordinal not in range(128)



----------------------------------------------------------------------

Comment By: Bjorn Tillenius (bjoti)
Date: 2006-02-16 12:41

Message:
Logged In: YES 
user_id=1032069

I'm quite sure that you can use non-ASCII characters in 
your doctest, given that it's a unicode string. So if you 
make your docstring a unicode string, it should work. That 
is:

u"""Docstring containing non-ASCII characters.
...
"""


----------------------------------------------------------------------

Comment By: GRISEL (ogrisel)
Date: 2005-09-18 12:25

Message:
Logged In: YES 
user_id=795041

Unfortunateny that patch does not fix my problem. The patch
at bug #1080727 fixes the problem for doctests written in
external reST files (testfile and DocFileTest functions). My
problem is related to internal docstring encoding (testmod
for instance). However, Bjorn Tillenius says:
"""
If one writes doctests within documentation strings of
classes and
functions, it's possible to use non-ASCII characters since
one can
specify the encoding used in the source file.
"""
So according to him, docstrings' doctests with non-ascii
characters should work by default. So maybe my system setup
is somewhat broken. Could somebody please confirm/infirm
this by running the attached sample script on his system?

My system config:
LANG=fr_FR at euro (on linux)
python 2.4.1 with:  sys.getdefaultencoding() == 'ascii' 
and locale.getpreferredencoding() == 'ISO-8859-15'
$ file test_iso-8859-15.py
test_iso-8859-15.py: ISO-8859 English text


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-09-17 19:42

Message:
Logged In: YES 
user_id=31435

Please try the patch at

http://www.python.org/sf/1080727

and report back on whether it solves your problem (attaching 
comments to the patch report would be most useful).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470

From noreply at sourceforge.net  Thu Feb 16 13:28:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 04:28:52 -0800
Subject: [ python-Bugs-1432838 ] optparse docs double-dash confusion
Message-ID: <E1F9iFg-0007p4-HQ@sc8-sf-web1.sourceforge.net>

Bugs item #1432838, was opened at 2006-02-16 12: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=1432838&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Veness (pelago)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse docs double-dash confusion

Initial Comment:
Page
http://docs.python.org/lib/optparse-terminology.html says:

The GNU project introduced "-" followed by a series of
hyphen-separated words, e.g. "-file" or "-dry-run".

but should say:

The GNU project introduced "--" followed by a series of
hyphen-separated words, e.g. "--file" or "--dry-run".

Also at the bottom of that page:

"-v" and "-report" are both options.

should be:

"-v" and "--report" are both options.

It looks in general that there is a documentation
rendering problem when double-dash appears in quotes.
Other double-dash items on that page are ok, when not
in quotes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432838&group_id=5470

From noreply at sourceforge.net  Thu Feb 16 14:08:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 05:08:43 -0800
Subject: [ python-Bugs-1432343 ] Description of file-object read() method is
	wrong.
Message-ID: <E1F9isF-00075O-4g@sc8-sf-web6.sourceforge.net>

Bugs item #1432343, was opened at 2006-02-15 17:49
Message generated for change (Comment added) made by grante
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Edwards (grante)
Assigned to: Nobody/Anonymous (nobody)
Summary: Description of file-object read() method is wrong.

Initial Comment:
There are two errors in the documentation of the file
object's
read() method found at

http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242

Suggested changes (unindented) are shown below interspersed
with the current text with insertions noted by a '+' in the
first column:

     Read at most size bytes from the file (less if the
read
     hits EOF before obtaining size bytes). If the size
     argument is negative or omitted, read all data
until EOF
     is reached.
     
+ Under some circumstances (e.g. system call aborted by
+ a signal) read() called with a negative or absent size
+ argument may return data before EOF is reached (even in
+ blocking mode).
     
     The bytes are returned as a string object. An
empty string
     is returned when EOF is encountered immediately. (For
     certain files, like ttys, it makes sense to continue
     reading after an EOF is hit.)

The last sentence above (the parenthetical one) is
false for
Linux/Unix.  Once you hit EOF on a tty, it will return EOF
forever until it's closed and re-opened.  If the above
sentence
is true for other OSes, I suggest it be so qualified --
otherwise it should just be deleted.
     
     Note that this method may call the underlying C
function
     fread() more than once in an effort to acquire as
close to
     size bytes as possible. Also note that when in
     non-blocking mode, less data than what was
requested may
     be returned, even if no size parameter was given. 


----------------------------------------------------------------------

>Comment By: Grant Edwards (grante)
Date: 2006-02-16 13:08

Message:
Logged In: YES 
user_id=61937

My bad.  You're right about the Ctrl-D case.  The code I was
looking that caused a permanent EOF was when the master end
of a pty was closed.  I think.  Anyway, Ctrl-D doesn't cause
a permanent EOF condition and you can read more data afterwards.


----------------------------------------------------------------------

Comment By: YoHell (yohell)
Date: 2006-02-16 11:17

Message:
Logged In: YES 
user_id=1008220

Well spoken!

However I'm not sure I quite follow you here:

> The last sentence above (the parenthetical one) is false 
> for Linux/Unix. Once you hit EOF on a tty, it will return
> EOF forever until it's closed and re-opened. 

A quote from Donn Cave in a discussion on comp.lang.python:
"""
They were probably thinking of the way the UNIX tty
driver delivers an EOF on <ctrl>D, after which of
course you can continue to read data from the same tty.

"""
This is also true for the Linux tty (afaik), so under those
circumstances it may really make sense to continue reading
past EOF.

example:
-------------------------------------------------
#!/usr/bin/python
import sys
while True:
    s = sys.stdin.read()
    print s
-------------------------------------------------

Pressing Ctrl-D while providing input to sys.stdin via the
keyboard will cause sys.stdin.read() to return, and you will
still be able to keep reading from sys.stdin without closing
and reopening it explicitly.

But then again I might have missed something.

/Joel Hedlund

----------------------------------------------------------------------

Comment By: Grant Edwards (grante)
Date: 2006-02-15 17:51

Message:
Logged In: YES 
user_id=61937

Well, that didn't work very well.  I really hate these web
interfaces.  I've attached the suggested changes as a text file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&group_id=5470

From noreply at sourceforge.net  Thu Feb 16 15:14:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 06:14:37 -0800
Subject: [ python-Feature Requests-1432694 ] Implement preemptive threads in
	Python
Message-ID: <E1F9ju1-0005lk-Ev@sc8-sf-web3.sourceforge.net>

Feature Requests item #1432694, was opened at 2006-02-16 08:11
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
>Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python

Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.

The idea behind Python is that programming should not
be a pain, right?

This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.

I apologize if this issue has already been raised before.

Cheers,
darkprokoba

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-02-16 14:14

Message:
Logged In: YES 
user_id=6656

We _have_ preemptive threads in Python ("import threading").  Suggest you 
report a real problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 02:04:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 17:04:49 -0800
Subject: [ python-Bugs-1431253 ] Logging hangs thread after detaching a
	StreamHandler's termi
Message-ID: <E1F9u3F-0006kt-6e@sc8-sf-web5.sourceforge.net>

Bugs item #1431253, was opened at 2006-02-14 06:07
Message generated for change (Settings changed) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470

Please note that this message 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: Works For Me
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi

Initial Comment:
Hi all,

After many hours, I think I've found a bug in the 
logging module!

If you add a (stdout) StreamHandler to a logger, then 
detach the terminal for that stdout, subsequent calls 
to log() will hang the calling thread.

To reproduce this, write the following scripts (this 
was a small test case I came up with - maybe there's 
something simpler):

$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ; 
done'

$ cat hup.bash
#!/usr/bin/env bash
./hup.py &

$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
        logging.basicConfig( filename = '/tmp/lup.out', 
filemode = 'w' )
        # XXX PROBLEM LINE BELOW
        logging.getLogger('').addHandler( logging.
StreamHandler() )
        while True:
                f.write( '-------\n' )
                f.flush()
                logging.critical( '======' )
                time.sleep(1)
finally:
        f.close()

Run ./tryhup.bash. It will sit in an idle spin. Monitor 
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on 
tryhup to kill it. The python process is still running, 
but is stalled (the .out files are no longer changing).

If you remove the above labeled line, however, this 
doesn't happen.

Can anybody please acknowledge this bug? Any temporary 
workarounds to this problem? Thanks in advance for 
looking into this and for hearing me in!

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2006-02-17 01:04

Message:
Logged In: YES 
user_id=308438

Please provide more information about your OS - I ran these
scripts on Ubuntu 5.10 and did not see the problems you
mention. The script continues to run (printing dashes to the
console), and hup.out/lup.out are also updated continuously. 

Also, note that the logging module merely opens the stream
passed to the StreamHander for output, so check if in
your configuration you get a hang just doing a write to
sys.stderr.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 02:06:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 17:06:46 -0800
Subject: [ python-Bugs-1284928 ] logging module's setLoggerClass not really
	working
Message-ID: <E1F9u58-0006l8-Pr@sc8-sf-web5.sourceforge.net>

Bugs item #1284928, was opened at 2005-09-08 13:51
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rotem Yaari (rotem_ya)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module's setLoggerClass not really working

Initial Comment:
The logging package should be modified in a way which
would let users call the setLoggerClass API, and then
consistently get loggers only from that class. 

In the logging package as it is today, the root logger
will always be a logging.Logger instance, and not the
new class specified in the call to setLoggerClass.
These semantics are not clear.

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2006-02-17 01:06

Message:
Logged In: YES 
user_id=308438

Recent checkins to CVS cater for adding user-defined
attributes to a LogRecord, and the function name is also
available in the LogRecord.

----------------------------------------------------------------------

Comment By: Rotem Yaari (rotem_ya)
Date: 2005-09-19 13:15

Message:
Logged In: YES 
user_id=1340892

That sounds fine.

The only thing I think is important is that it'll be
possible to add fields to the LogRecord in the period of
time between its creation and its "emitting". That will let
users add any behavior desired to the logging mechanism.

In addition, since setLoggerClass is obviously not intended
for users, it should be prefixed with an underscore or made
"pseudo private"... its otherwise confusing.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2005-09-19 12:31

Message:
Logged In: YES 
user_id=308438

OK - I'm part way through implementing a change whereby the
function name is available through the base logging
functionality - the findCaller() implementation in CVS
currently gets the function name, but I have not yet
implemented the part which puts it into the LogRecord. So
this particular patch of yours will soon not be necessary.

Also note that you can also redefine the record-making
function - but I am currently thinking of how to make this
part of the system better, as it is a little untidy at the
moment. The objective is to make it easy to add whatever you
want to the LogRecord __dict__ which can later be used in
the formatted output.



----------------------------------------------------------------------

Comment By: Rotem Yaari (rotem_ya)
Date: 2005-09-19 06:34

Message:
Logged In: YES 
user_id=1340892

This is an example logger class I would like to use:

class PatchedLogger(logging.Logger):
    def __init__(self, name, *patches):
        logging.Logger.__init__(self, name)
        self.patches = patches
    def handle(self, record):
        #copied from the actual Logger implementation
        if (not self.disabled) and self.filter(record):
            for patch in self.patches:
                patch(record)
            self.callHandlers(record)

And an example "patch":
def EnableTrace(record):
    """
    adds the %(function)s for logging records
    """
    function_name = _get_function_name(inspect.stack()[4])
    record.function = function_name


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2005-09-19 01:00

Message:
Logged In: YES 
user_id=308438

Can you please explain your use case? Why does the package
have to be modified in that way? Why do you need to be able
to have the root logger be creatable from a custom class?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 08:16:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 23:16:41 -0800
Subject: [ python-Bugs-1431253 ] Logging hangs thread after detaching a
	StreamHandler's termi
Message-ID: <E1F9zr7-0002OV-Or@sc8-sf-web1.sourceforge.net>

Bugs item #1431253, was opened at 2006-02-13 22:07
Message generated for change (Comment added) made by yangzhang
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470

Please note that this message 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: Works For Me
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi

Initial Comment:
Hi all,

After many hours, I think I've found a bug in the 
logging module!

If you add a (stdout) StreamHandler to a logger, then 
detach the terminal for that stdout, subsequent calls 
to log() will hang the calling thread.

To reproduce this, write the following scripts (this 
was a small test case I came up with - maybe there's 
something simpler):

$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ; 
done'

$ cat hup.bash
#!/usr/bin/env bash
./hup.py &

$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
        logging.basicConfig( filename = '/tmp/lup.out', 
filemode = 'w' )
        # XXX PROBLEM LINE BELOW
        logging.getLogger('').addHandler( logging.
StreamHandler() )
        while True:
                f.write( '-------\n' )
                f.flush()
                logging.critical( '======' )
                time.sleep(1)
finally:
        f.close()

Run ./tryhup.bash. It will sit in an idle spin. Monitor 
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on 
tryhup to kill it. The python process is still running, 
but is stalled (the .out files are no longer changing).

If you remove the above labeled line, however, this 
doesn't happen.

Can anybody please acknowledge this bug? Any temporary 
workarounds to this problem? Thanks in advance for 
looking into this and for hearing me in!

----------------------------------------------------------------------

>Comment By: Yang Zhang (yangzhang)
Date: 2006-02-16 23:16

Message:
Logged In: YES 
user_id=1207658

Hi, yes, after I submitted this bug I actually looked into 
logging.StreamHandler, and found that its code was not too 
complicated (as with everything Python :).

I tried some more experiments, and found that the problem is 
in stderr, which throws an exception. The problem was that I 
couldn't see the exception (and didn't suspect that's what 
was happening), so the fact that the next line never came 
out led me to believe that the thread froze.

Is stderr supposed to raise an exception like this? Is this 
a bug?

Unfortunately, it's hard for me to tell what's going on 
(what the exception is that's being thrown). How do I tell 
what it's raising? (stderr is no longer avail. after all) I 
don't know how to catch an exception of any type and (say) 
print its str or repr value to a file so that I can tell 
what's going on.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2006-02-16 17:04

Message:
Logged In: YES 
user_id=308438

Please provide more information about your OS - I ran these
scripts on Ubuntu 5.10 and did not see the problems you
mention. The script continues to run (printing dashes to the
console), and hup.out/lup.out are also updated continuously. 

Also, note that the logging module merely opens the stream
passed to the StreamHander for output, so check if in
your configuration you get a hang just doing a write to
sys.stderr.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 08:17:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 16 Feb 2006 23:17:20 -0800
Subject: [ python-Bugs-1431253 ] Logging hangs thread after detaching a
	StreamHandler's termi
Message-ID: <E1F9zrk-0002Of-6J@sc8-sf-web1.sourceforge.net>

Bugs item #1431253, was opened at 2006-02-13 22:07
Message generated for change (Comment added) made by yangzhang
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470

Please note that this message 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: Works For Me
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi

Initial Comment:
Hi all,

After many hours, I think I've found a bug in the 
logging module!

If you add a (stdout) StreamHandler to a logger, then 
detach the terminal for that stdout, subsequent calls 
to log() will hang the calling thread.

To reproduce this, write the following scripts (this 
was a small test case I came up with - maybe there's 
something simpler):

$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ; 
done'

$ cat hup.bash
#!/usr/bin/env bash
./hup.py &

$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
        logging.basicConfig( filename = '/tmp/lup.out', 
filemode = 'w' )
        # XXX PROBLEM LINE BELOW
        logging.getLogger('').addHandler( logging.
StreamHandler() )
        while True:
                f.write( '-------\n' )
                f.flush()
                logging.critical( '======' )
                time.sleep(1)
finally:
        f.close()

Run ./tryhup.bash. It will sit in an idle spin. Monitor 
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on 
tryhup to kill it. The python process is still running, 
but is stalled (the .out files are no longer changing).

If you remove the above labeled line, however, this 
doesn't happen.

Can anybody please acknowledge this bug? Any temporary 
workarounds to this problem? Thanks in advance for 
looking into this and for hearing me in!

----------------------------------------------------------------------

>Comment By: Yang Zhang (yangzhang)
Date: 2006-02-16 23:17

Message:
Logged In: YES 
user_id=1207658

Hi, yes, after I submitted this bug I actually looked into 
logging.StreamHandler, and found that its code was not too 
complicated (as with everything Python :).

I tried some more experiments, and found that the problem is 
in stderr, which throws an exception. The problem was that I 
couldn't see the exception (and didn't suspect that's what 
was happening), so the fact that the next line never came 
out led me to believe that the thread froze.

Is stderr supposed to raise an exception like this? Is this 
a bug?

Unfortunately, it's hard for me to tell what's going on 
(what the exception is that's being thrown). How do I tell 
what it's raising? (stderr is no longer avail. after all) I 
don't know how to catch an exception of any type and (say) 
print its str or repr value to a file so that I can tell 
what's going on.

----------------------------------------------------------------------

Comment By: Yang Zhang (yangzhang)
Date: 2006-02-16 23:16

Message:
Logged In: YES 
user_id=1207658

Hi, yes, after I submitted this bug I actually looked into 
logging.StreamHandler, and found that its code was not too 
complicated (as with everything Python :).

I tried some more experiments, and found that the problem is 
in stderr, which throws an exception. The problem was that I 
couldn't see the exception (and didn't suspect that's what 
was happening), so the fact that the next line never came 
out led me to believe that the thread froze.

Is stderr supposed to raise an exception like this? Is this 
a bug?

Unfortunately, it's hard for me to tell what's going on 
(what the exception is that's being thrown). How do I tell 
what it's raising? (stderr is no longer avail. after all) I 
don't know how to catch an exception of any type and (say) 
print its str or repr value to a file so that I can tell 
what's going on.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2006-02-16 17:04

Message:
Logged In: YES 
user_id=308438

Please provide more information about your OS - I ran these
scripts on Ubuntu 5.10 and did not see the problems you
mention. The script continues to run (printing dashes to the
console), and hup.out/lup.out are also updated continuously. 

Also, note that the logging module merely opens the stream
passed to the StreamHander for output, so check if in
your configuration you get a hang just doing a write to
sys.stderr.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 10:16:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 01:16:12 -0800
Subject: [ python-Feature Requests-1433435 ] Use new expat version 2.0
Message-ID: <E1FA1im-0007Eu-8u@sc8-sf-web2.sourceforge.net>

Feature Requests item #1433435, was opened at 2006-02-17 10:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&group_id=5470

Please note that this 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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Wolfgang Langner (tds33)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use new expat version 2.0

Initial Comment:
New expat version 2.0 is released. This one schould be
used in the next python release (2.5).

I checked the repository and feature request and there
is no note about usage of new expat versions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 10:48:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 01:48:26 -0800
Subject: [ python-Bugs-1432260 ] pydoc still doesn't handle lambda well
Message-ID: <E1FA2Dy-0007I9-4z@sc8-sf-web2.sourceforge.net>

Bugs item #1432260, was opened at 2006-02-15 17:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432260&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: William McVey (wamcvey)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc still doesn't handle lambda well

Initial Comment:
This is a duplicate of Bug ID 672578, but I could find
no way for a 'normal user' to reopen a closed bug ticket. 

Pydoc doesn't currently handle functions and methods
defined with lambda very well. Not only are names
associated with a lambda defined function/method not
indicated in the generated module and class
definitions, but docstrings attached to the object
generated by lambda are not integrated into the output.

I've attached a sample program that illustrates the
discrepency of handling methods defined with 'def'
versus those that are handled with 'lambda'.


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 10:48

Message:
Logged In: YES 
user_id=1188172

Thanks, I fixed this to look as in the HTML doc.

Revisions 42439, 42440.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432260&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 10:52:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 01:52:00 -0800
Subject: [ python-Feature Requests-1432694 ] Implement preemptive threads in
	Python
Message-ID: <E1FA2HQ-0000Ab-6s@sc8-sf-web3.sourceforge.net>

Feature Requests item #1432694, was opened at 2006-02-16 10:11
Message generated for change (Comment added) made by darkprokoba
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: None
>Status: Pending
Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python

Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.

The idea behind Python is that programming should not
be a pain, right?

This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.

I apologize if this issue has already been raised before.

Cheers,
darkprokoba

----------------------------------------------------------------------

>Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-17 11:52

Message:
Logged In: YES 
user_id=950037

OK, let me try again :-)
The problem is in the global interpreter lock:
http://docs.python.org/api/threads.html
this basically says that you can have as many native threads
as you like but only one of them could have the global
interpreter lock and could therefore be executing python
code at a time. The only use of python's multiple threads
then is so they could release the global lock and block on
i/o operations while one lucky thread has the lock and
executes python code and accesses python objects happily.
So we have multiple native threads (e.g. pthreads) but they
pass arround the global lock in a cooperative manner. This
is not preemptive threading imho.
It's a severely limited model and has the following
potential problem: a thread may enter a time-consuming i/o
operation but forget to release the global interpreter lock
- leading to a freeze in the entire interpreter (all threads
are waiting for the global lock, while the thread that has
it waits on the i/o operation)
Are there any plans for alleviating this problem? A thread
should not voluntarily release the lock so that the rest of
the threads get a chance to execute python code. It should
be possible to preempt any thread at any time without its
consent in order to have a true preemptive threading model.
Or please correct me If I'm wrong.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-16 16:14

Message:
Logged In: YES 
user_id=6656

We _have_ preemptive threads in Python ("import threading").  Suggest you 
report a real problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 10:53:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 01:53:19 -0800
Subject: [ python-Bugs-1430298 ] smtplib: empty mail addresses
Message-ID: <E1FA2Ih-0007Iq-Tb@sc8-sf-web2.sourceforge.net>

Bugs item #1430298, was opened at 2006-02-12 22:36
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430298&group_id=5470

Please note that this message 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: Fixed
Priority: 5
Submitted By: Freek Dijkstra (macfreek)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib: empty mail addresses

Initial Comment:
It is not possible to send an email with smtplib with an empty return 
address.

if you leave the sender mail address empty, smtplib will use "<None>" as 
sender, instead of "<>", as it should do. Note that an empty return 
address is typically used for mail delivery warnings (it has a valid usage!)

This bug is still in current SVN (I just checked http://svn.python.org/
projects/python/trunk/Lib/smtplib.py). Below is a fix for smtplib.py that 
came with Python 2.3 (since I still use that version). The bug is in the 
function "quoteaddr(addr):"

*** orig/smtplib.py   2005-05-14 23:48:03.000000000 +0200
--- smtplib.py  2006-02-08 09:52:25.000000000 +0100
***************
*** 176,181 ****
--- 176,183 ----
      if m == (None, None): # Indicates parse failure or AttributeError
          #something weird here.. punt -ddm
          return "<%s>" % addr
+     elif m == None:
+         return "<>"
      else:
          return "<%s>" % m
  


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 10:53

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, I applied your patch in rev. 42442,
42443 (2.4).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430298&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 10:58:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 01:58:30 -0800
Subject: [ python-Feature Requests-1432694 ] Implement preemptive threads in
	Python
Message-ID: <E1FA2Ni-0000CA-Pj@sc8-sf-web3.sourceforge.net>

Feature Requests item #1432694, was opened at 2006-02-16 10:11
Message generated for change (Settings changed) made by darkprokoba
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python

Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.

The idea behind Python is that programming should not
be a pain, right?

This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.

I apologize if this issue has already been raised before.

Cheers,
darkprokoba

----------------------------------------------------------------------

Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-17 11:52

Message:
Logged In: YES 
user_id=950037

OK, let me try again :-)
The problem is in the global interpreter lock:
http://docs.python.org/api/threads.html
this basically says that you can have as many native threads
as you like but only one of them could have the global
interpreter lock and could therefore be executing python
code at a time. The only use of python's multiple threads
then is so they could release the global lock and block on
i/o operations while one lucky thread has the lock and
executes python code and accesses python objects happily.
So we have multiple native threads (e.g. pthreads) but they
pass arround the global lock in a cooperative manner. This
is not preemptive threading imho.
It's a severely limited model and has the following
potential problem: a thread may enter a time-consuming i/o
operation but forget to release the global interpreter lock
- leading to a freeze in the entire interpreter (all threads
are waiting for the global lock, while the thread that has
it waits on the i/o operation)
Are there any plans for alleviating this problem? A thread
should not voluntarily release the lock so that the rest of
the threads get a chance to execute python code. It should
be possible to preempt any thread at any time without its
consent in order to have a true preemptive threading model.
Or please correct me If I'm wrong.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-16 16:14

Message:
Logged In: YES 
user_id=6656

We _have_ preemptive threads in Python ("import threading").  Suggest you 
report a real problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 13:10:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 04:10:33 -0800
Subject: [ python-Bugs-882297 ] socket's makefile file object doesn't work
	with timeouts.
Message-ID: <E1FA4RV-0001sp-Qd@sc8-sf-web6.sourceforge.net>

Bugs item #882297, was opened at 2004-01-22 19:36
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470

Please note that this message 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
Submitted By: Jeremy Fincher (jemfinch)
>Assigned to: Skip Montanaro (montanaro)
Summary: socket's makefile file object doesn't work with timeouts.

Initial Comment:
Ok, here's what I did:

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('', 9009))
>>> s.listen(5)
>>> s.accept()

Now, I opened a second Python interpreter in which I
typed this:

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 9009))

In the first interpreter I did this:

>>> s.accept()
(<socket._socketobject object at 0x40163e14>,
('127.0.0.1', 33059))
>>> s1 = _[0]
>>> s1.settimeout(3)
>>> fd = s1.makefile()

Then I tested that the timeout worked correctly.  Still
in the first interpreter:

>>> fd.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
    data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()

Now, while that was blocking, I did this in the second
interpreter:

>>> s.send('foo')
3

Which caused this in the first interpreter (as
expected, since I didn't send a newline):

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
    data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()

While that was blocking, I did this in the second
interpreter:

>>> s.send('bar\n')
4

Finally sending a newline.  But lo and behold!  In the
first interpreter I got this:

>>> fd.readline()
'bar\n'

Alas, my 'foo' has been lost!

Anyway, the documentation does explicitly state that
the socket should be in blocking mode, *implying* that
it does no buffering, but it doesn't say anything about
timeouts.  Ideally, the file object would buffer enough
data until the readline could return meaningfully, but
failing that, the documentation should probably be
updated to mention that timeouts shouldn't be used with
readline on the returned file object.


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:10

Message:
Logged In: YES 
user_id=1188172

If this is a bug, it hasn't been fixed. I reproduced it here.

Assigning to Skip since he worked on "makefile" as it seems.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-02-01 20:38

Message:
Logged In: YES 
user_id=261020

I believe this was fixed in socket.py in rev 32056, closing
bug 707074.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 13:10:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 04:10:59 -0800
Subject: [ python-Bugs-882297 ] socket's makefile file object doesn't work
	with timeouts.
Message-ID: <E1FA4Rv-0001su-SJ@sc8-sf-web6.sourceforge.net>

Bugs item #882297, was opened at 2004-01-22 19:36
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Skip Montanaro (montanaro)
Summary: socket's makefile file object doesn't work with timeouts.

Initial Comment:
Ok, here's what I did:

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('', 9009))
>>> s.listen(5)
>>> s.accept()

Now, I opened a second Python interpreter in which I
typed this:

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 9009))

In the first interpreter I did this:

>>> s.accept()
(<socket._socketobject object at 0x40163e14>,
('127.0.0.1', 33059))
>>> s1 = _[0]
>>> s1.settimeout(3)
>>> fd = s1.makefile()

Then I tested that the timeout worked correctly.  Still
in the first interpreter:

>>> fd.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
    data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()

Now, while that was blocking, I did this in the second
interpreter:

>>> s.send('foo')
3

Which caused this in the first interpreter (as
expected, since I didn't send a newline):

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
    data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()

While that was blocking, I did this in the second
interpreter:

>>> s.send('bar\n')
4

Finally sending a newline.  But lo and behold!  In the
first interpreter I got this:

>>> fd.readline()
'bar\n'

Alas, my 'foo' has been lost!

Anyway, the documentation does explicitly state that
the socket should be in blocking mode, *implying* that
it does no buffering, but it doesn't say anything about
timeouts.  Ideally, the file object would buffer enough
data until the readline could return meaningfully, but
failing that, the documentation should probably be
updated to mention that timeouts shouldn't be used with
readline on the returned file object.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:10

Message:
Logged In: YES 
user_id=1188172

If this is a bug, it hasn't been fixed. I reproduced it here.

Assigning to Skip since he worked on "makefile" as it seems.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-02-01 20:38

Message:
Logged In: YES 
user_id=261020

I believe this was fixed in socket.py in rev 32056, closing
bug 707074.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 13:13:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 04:13:09 -0800
Subject: [ python-Bugs-1421513 ] IMPORT PROBLEM: Local submodule shadows
	global module
Message-ID: <E1FA4U1-0001tD-Nh@sc8-sf-web6.sourceforge.net>

Bugs item #1421513, was opened at 2006-02-01 15:48
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Postponed
Priority: 5
Submitted By: Jens Engel (jens_engel)
Assigned to: Nobody/Anonymous (nobody)
Summary: IMPORT PROBLEM: Local submodule shadows global module

Initial Comment:
PYTHON: 2.3, 2.4
PLATFORMS: Solaris, Linux, Cygwin, Win32

Local sister modules seem to hide global ones (of the 
standard Python library) when import occurs in a 
submodule. This statement even holds for indirect 
imports from the standard Python library.


FILE STRUCTURE for EXAMPLES:
  - my/
      +-- __init__.py
      +-- main.py
      +-- main2.py
      +-- symbol.py
      \-- types.py

EXAMPLE 1: Local submodule shadows global one.
# -- file:my.main.py
# COMMAND-LINE: python my/main.py
# MY INTENTION: Import standard module "types".
import types  #< FAILURE: Imports my.types

if __name__ == "__main__":
    print types.StringTypes  #< EXCEPTION: StringTypes 
are not known.
# -- FILE-END


EXAMPLE 2: Indirect import uses "my.symbol" instead.
# -- file:my.main2.py
# COMMAND-LINE: python my/main2.py
# MY INTENTION: Import standard module "compiler".
# NOTE: Module "compiler" imports module "symbol"
import compiler  #< FAILURE: Imports my.symbol instead

if __name__ == "__main__":
    pass
# -- FILE-END
  
NOTE: Module import problems can be better checked 
with "python -v".

I have not found a work-around that let me decide if I 
want to import the global module or the local one. The 
only solution seens to be to relocate the module 
where "__main__" is used to another place where no 
such import conflict occurs.

If my analysis is correct, the "main" module provides 
another ROOT filesystem for Python libraries that is 
normally preferred over the PYTHONHOME filesystem.
If this is true, module names at this level must be 
UNIQUE in a GLOBAL namespace (that is only partly 
under my control) which I consider BAD.

NOTE: In C++ if have the "::" prefix to indicate that 
I want to use the global/default namespace (=module) 
and not a sub-namespace. I am not aware of such a idom 
in Python.


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:13

Message:
Logged In: YES 
user_id=1188172

This is, unfortunately, correct behavior. Python 2.5 will
hopefully fix this with new import semantics for relative
imports.

As a workaround, don't call your modules like global ones
when you need those.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421513&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 13:16:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 04:16:26 -0800
Subject: [ python-Bugs-1419989 ] class dictionary shortcircuits __getattr__
Message-ID: <E1FA4XC-0001tS-1k@sc8-sf-web6.sourceforge.net>

Bugs item #1419989, was opened at 2006-01-31 08:08
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419989&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Shaun Cutts (shauncutts)
Assigned to: Nobody/Anonymous (nobody)
Summary: class dictionary shortcircuits __getattr__

Initial Comment:
page 3.3.2 of Language Reference states:

"....Note that at least for instance variables, you 
can fake total control by not inserting any values in 
the instance attribute dictionary (but instead 
inserting them in another object)."

A counterexample (doctest style):
-----------------------------
>>> class Foo:
...     bar = None
...     def __getattr__( self, attr ):
...         return 'boo'
...
>>> f = Foo()
>>> print "bar: ",f.bar
bar: None
------------------------------
'bar' in class dictionary (not just in instance 
dictionary) also causes __getattr__ not to be called.

BTW.. above in the doc, it says that __getattr__ 
called only if "normal methods" can't find attribute. 
So this would seem a documentation bug. 

However, right now at least, I would prefer if the 
instance dictionary alone were decisive.


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:16

Message:
Logged In: YES 
user_id=1188172

This is correct behavior as documented. The first sentence
in the cited page is:

""" [__getattr__ is] Called when an attribute lookup has not
found the attribute in the usual places (i.e. it is not an
instance attribute nor is it found in the class tree for
self)."""

"""Note that **at least** for instance variables,"""
explicitly tells you that you can't do anything about class
variables.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419989&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 13:19:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 04:19:15 -0800
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1FA4Zv-0001tg-OI@sc8-sf-web6.sourceforge.net>

Bugs item #1417699, was opened at 2006-01-29 02:04
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Martin v. L??wis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 14:36:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 05:36:43 -0800
Subject: [ python-Bugs-1417554 ] SimpleHTTPServer doesn't return last-modified
	headers
Message-ID: <E1FA5mt-00025Q-K8@sc8-sf-web6.sourceforge.net>

Bugs item #1417554, was opened at 2006-01-28 20:24
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417554&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleHTTPServer doesn't return last-modified headers

Initial Comment:
SimpleHTTPServer doesn't return any Last-Modified headers with its 
responses, which means browsers can't cache them, which means if you 
try and view pages with images and things it has to reload all of them 
every time.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 14:36

Message:
Logged In: YES 
user_id=1188172

Committed a patch in rev. 42450.

----------------------------------------------------------------------

Comment By: Aaron Swartz (aaronsw)
Date: 2006-01-28 20:25

Message:
Logged In: YES 
user_id=122141

Here's a patch:

http://sourceforge.net/tracker/index.php?
func=detail&aid=1417555&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417554&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 17:03:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 08:03:07 -0800
Subject: [ python-Bugs-1433667 ] os.path.expandvars sometimes doesn't expand
	$HOSTNAME
Message-ID: <E1FA84Z-0002Zi-MH@sc8-sf-web6.sourceforge.net>

Bugs item #1433667, was opened at 2006-02-17 11: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=1433667&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars sometimes doesn't expand $HOSTNAME

Initial Comment:

$ echo "$HOSTNAME"
c0a80165.tipt.aol.com
$ /usr/local/bin/python
Python 2.4.2 (#1, Dec 30 2005, 11:14:42) 
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/Users/dougfort'
>>> os.path.expandvars("$HOSTNAME")
'$HOSTNAME'
>>> 

arthurformat-d09:arthur$ echo $HOSTNAME
arthurformat-d09.ats.aol.com
arthurformat-d09:arthur$ /cm/tools/bin/python
Python 2.3.4 (#1, Jul 28 2004, 14:55:53) 
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/opt/aol/production/arthur'
>>> os.path.expandvars("$HOSTNAME")
'arthurformat-d09.ats.aol.com'


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 17:52:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 08:52:32 -0800
Subject: [ python-Bugs-1433694 ] normalize function in minidom unlinks empty
	child nodes
Message-ID: <E1FA8qO-0004V2-U4@sc8-sf-web1.sourceforge.net>

Bugs item #1433694, was opened at 2006-02-17 11:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: RomanKliotzkin (romankliotzkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: normalize function in minidom unlinks empty child nodes

Initial Comment:
Hi,

When calling the "normalize" method of DOM objects in
the minidom library, the method will attempt to collate
text nodes together. When it encounters an empty text
node, it will do the following:

(line 197 in minidom.py)

  else:                                               
                                    
      # empty text node; discard                      
                                    
      child.unlink()

unlink() sets all the members of the child node to
None, BUT the parent node still has a link to the child
node. Therefore, if one is later iterating through the
parent node and calls removeChild on the unlinked node,
a NotFoundErr exception will be thrown by the library.

To trigger, use the test case script along with the
test case XML document included in the zip file.

testcase.py testcase.xml

My suggestion is to call self.removeChild(child), then
call child.unlink(). That way, there is no ambiguity
about an unlinked child being referenced by the parent.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433694&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 19:13:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 10:13:09 -0800
Subject: [ python-Bugs-1433667 ] os.path.expandvars sometimes doesn't expand
	$HOSTNAME
Message-ID: <E1FAA6P-0001VH-RX@sc8-sf-web3.sourceforge.net>

Bugs item #1433667, was opened at 2006-02-17 17:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars sometimes doesn't expand $HOSTNAME

Initial Comment:

$ echo "$HOSTNAME"
c0a80165.tipt.aol.com
$ /usr/local/bin/python
Python 2.4.2 (#1, Dec 30 2005, 11:14:42) 
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/Users/dougfort'
>>> os.path.expandvars("$HOSTNAME")
'$HOSTNAME'
>>> 

arthurformat-d09:arthur$ echo $HOSTNAME
arthurformat-d09.ats.aol.com
arthurformat-d09:arthur$ /cm/tools/bin/python
Python 2.3.4 (#1, Jul 28 2004, 14:55:53) 
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/opt/aol/production/arthur'
>>> os.path.expandvars("$HOSTNAME")
'arthurformat-d09.ats.aol.com'


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 19:13

Message:
Logged In: YES 
user_id=1188172

It might be good if you explain what the differences between
the two snippets are, environment-wise.

The first question that comes to mind is: is $HOSTNAME
exported in the first shell?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 19:47:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 10:47:50 -0800
Subject: [ python-Bugs-1419652 ] PyImport_AppendInittab stores pointer to
	parameter
Message-ID: <E1FAAdy-0000mj-Df@sc8-sf-web5.sourceforge.net>

Bugs item #1419652, was opened at 2006-01-31 04:19
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419652&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: coder_5 (coder_5)
>Assigned to: Martin v. L??wis (loewis)
Summary: PyImport_AppendInittab stores pointer to parameter

Initial Comment:
signature is:

int PyImport_AppendInittab(char *name, void
(*initfunc)(void))

if the 'name' pointer is freed or overwritten directly
after the call to PyImport_AppendInittab, this call
returns true but fails making the module known, and the
interpreter crashes on PyFinalize();
this suggests that PyImport_AppendInittab stores the
name pointer and uses it later, after leaving this
function. this is undocumented and leads to crashes if
name is freed in the meantime. (a typical c problem)

this function is important to boost::python library to
extend python with c++.

workaround for c/c++ users:
-malloc a char* for the name,
-copy the modulename to name
-call PyImport_AppendInittab with this name
-DONT free name. (leaving a memory-leak)


btw, 'char *' should be 'const char*', but this applies
to most other Python API functions.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 19:47

Message:
Logged In: YES 
user_id=1188172

Should AppendInittab() itself malloc a char buffer?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419652&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 20:20:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 11:20:08 -0800
Subject: [ python-Bugs-1433667 ] os.path.expandvars sometimes doesn't expand
	$HOSTNAME
Message-ID: <E1FAB9E-00015I-Nl@sc8-sf-web2.sourceforge.net>

Bugs item #1433667, was opened at 2006-02-17 12:03
Message generated for change (Comment added) made by neurogeek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars sometimes doesn't expand $HOSTNAME

Initial Comment:

$ echo "$HOSTNAME"
c0a80165.tipt.aol.com
$ /usr/local/bin/python
Python 2.4.2 (#1, Dec 30 2005, 11:14:42) 
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/Users/dougfort'
>>> os.path.expandvars("$HOSTNAME")
'$HOSTNAME'
>>> 

arthurformat-d09:arthur$ echo $HOSTNAME
arthurformat-d09.ats.aol.com
arthurformat-d09:arthur$ /cm/tools/bin/python
Python 2.3.4 (#1, Jul 28 2004, 14:55:53) 
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/opt/aol/production/arthur'
>>> os.path.expandvars("$HOSTNAME")
'arthurformat-d09.ats.aol.com'


----------------------------------------------------------------------

Comment By: neurogeek (neurogeek)
Date: 2006-02-17 15:20

Message:
Logged In: YES 
user_id=1394223

No problem for me in a Gentoo box in python 2.3.4 nor python
2.4.2

Is the problem persistent? could you give some meore info on
this?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 14:13

Message:
Logged In: YES 
user_id=1188172

It might be good if you explain what the differences between
the two snippets are, environment-wise.

The first question that comes to mind is: is $HOSTNAME
exported in the first shell?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 20:20:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 11:20:18 -0800
Subject: [ python-Bugs-1421696 ] http response dictionary incomplete
Message-ID: <E1FAB9O-0001hT-OO@sc8-sf-web3.sourceforge.net>

Bugs item #1421696, was opened at 2006-02-01 18:56
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421696&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: http response dictionary incomplete

Initial Comment:
httplib and BaseHTTPServer each maintain their own copy 
of possible response codes.

They don't agree.

It looks like the one in httplib is a superset of the 
one in BaseHTTPServer.BaseHTTPRequestHandler.responses, 
and httplib is the logical place for it, but

(1)  They map in opposite directions.

(2)  The httplib version is just a bunch of names at 
the module toplevel, with no particular grouping that 
separates them from random classes, or makes them easy 
to import as a group.

(3)  The httplib names are explicitly not exported.



----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 20:20

Message:
Logged In: YES 
user_id=1188172

I moved the urllib2 one to httplib as it belongs there.

The constants httplib are explicitly documented and must remain.

The BaseHTTPServer mapping includes its own "unofficial"
long error messages and therefore cannot be merged with the
others.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-06 23:39

Message:
Logged In: YES 
user_id=764593

That may make the cleanup more urgent.  The mapping in 
urllib2 is new with 2.5, so it should still be fine to 
remove it, or forward to httplib.

The mapping in httplib is explicitly not exported, as there 
is an __all__ which excludes them, so it *should* be 
legitimate to remove them in a new release.

BaseHTTPServer places the mapping as a class attribute on a 
public class.  Therefore, either the final location has to 
include both the message and the long message (so that 
BaseHTTPServer can import it and delegate), or this has to 
be the final location, or we can't at best get down to two.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:56

Message:
Logged In: YES 
user_id=261020

There's also one in urllib2 :-(

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421696&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 21:46:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 12:46:41 -0800
Subject: [ python-Bugs-1019808 ] wrong socket error returned
Message-ID: <E1FACUz-00018p-A9@sc8-sf-web5.sourceforge.net>

Bugs item #1019808, was opened at 2004-08-31 18:18
Message generated for change (Comment added) made by vercruesse
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Schwindt (fgsch)
Assigned to: Neal Norwitz (nnorwitz)
Summary: wrong socket error returned

Initial Comment:
hi,

  first, background:

  OS: OpenBSD-current/i386
  Python version: 2.3.4

   example script:

import socket

socket.setdefaulttimeout(30)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 9999))

   where nothing is listening on 9999 (ECONNREFUSED
should be returned).
   when ran it i get:

Traceback (most recent call last):
  File "bug.py", line 8, in ?
    s.connect(('127.0.0.1', 9999))
  File "<string>", line 1, in connect
socket.error: (22, 'Invalid argument')

  this is a problem in the socketmodule.c, in the
internal_connect() function. getsockopt with SOCK_ERROR
should be used once EINPROGRESS is returned to get the
real error.
  this code works on linux, but the connect semantic
is, imho, broken. you cannot reuse a socket once it
failed (a test afterwards shown that this is valid
under linux!!!!).
  please contact me if you need further details,
although i find this very clear.
  thanks,

  f.-


----------------------------------------------------------------------

Comment By: Frank Vercruesse (vercruesse)
Date: 2006-02-17 21:46

Message:
Logged In: YES 
user_id=202246

I can confirm the bug running Python 2.4.2 on Mac OS X
10.4.5 (PPC). However, the patch doesn't seem to resolve the
issue. Now I get the following traceback when running the
posted script:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in connect
socket.error: (36, 'Operation now in progress')


----------------------------------------------------------------------

Comment By: Federico Schwindt (fgsch)
Date: 2005-10-03 21:44

Message:
Logged In: YES 
user_id=50493

patch against 2.4.1 appended. not tested in anything but
openbsd. nevertheless, i think it should work in linux and
osx. not sure about others.
cheers.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 08:02

Message:
Logged In: YES 
user_id=33168

Can you provide a patch that you believe corrects this problem?

----------------------------------------------------------------------

Comment By: Federico Schwindt (fgsch)
Date: 2005-06-24 11:41

Message:
Logged In: YES 
user_id=50493

just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and
the problem is still there :-(

----------------------------------------------------------------------

Comment By: Federico Schwindt (fgsch)
Date: 2004-09-23 05:58

Message:
Logged In: YES 
user_id=50493

any news? this may be a problem in other *BSDs as well..

----------------------------------------------------------------------

Comment By: Federico Schwindt (fgsch)
Date: 2004-08-31 18:22

Message:
Logged In: YES 
user_id=50493

maybe i was not clear. the problem is only happening when
setdefaulttimeout is used. otherwise ECONNREFUSED is
correctly returned.

f.-

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 21:50:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 12:50:08 -0800
Subject: [ python-Bugs-1433667 ] os.path.expandvars sometimes doesn't expand
	$HOSTNAME
Message-ID: <E1FACYK-0001yc-UL@sc8-sf-web3.sourceforge.net>

Bugs item #1433667, was opened at 2006-02-17 17:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470

Please note that this message 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: Invalid
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars sometimes doesn't expand $HOSTNAME

Initial Comment:

$ echo "$HOSTNAME"
c0a80165.tipt.aol.com
$ /usr/local/bin/python
Python 2.4.2 (#1, Dec 30 2005, 11:14:42) 
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/Users/dougfort'
>>> os.path.expandvars("$HOSTNAME")
'$HOSTNAME'
>>> 

arthurformat-d09:arthur$ echo $HOSTNAME
arthurformat-d09.ats.aol.com
arthurformat-d09:arthur$ /cm/tools/bin/python
Python 2.3.4 (#1, Jul 28 2004, 14:55:53) 
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/opt/aol/production/arthur'
>>> os.path.expandvars("$HOSTNAME")
'arthurformat-d09.ats.aol.com'


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 21:50

Message:
Logged In: YES 
user_id=1188172

Closing as requested.

----------------------------------------------------------------------

Comment By: Doug Fort (dougfort)
Date: 2006-02-17 21:11

Message:
Logged In: YES 
user_id=6399

It looks like posixpath.py uses os.environ to resolve
environment variables. That makes sense. On my OS X 10.4
Python 2.4.2, HOSTNAME does not appear in os.environ. There
must be some shell gimmick to resolve it from the command line. 

I originally experienced this error on RedHat Enterprise
Linux. I'm unable to reproduce it in the interpreteer. The
process experiencing the error is launched from our client's
version of init. I suspect it just isn't getting the
HOSTNAME environment variable passed to it.

So in short, os.expandvars works as designed. I apologize
for submitting the bug without checking more throughly.

----------------------------------------------------------------------

Comment By: neurogeek (neurogeek)
Date: 2006-02-17 20:20

Message:
Logged In: YES 
user_id=1394223

No problem for me in a Gentoo box in python 2.3.4 nor python
2.4.2

Is the problem persistent? could you give some meore info on
this?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 19:13

Message:
Logged In: YES 
user_id=1188172

It might be good if you explain what the differences between
the two snippets are, environment-wise.

The first question that comes to mind is: is $HOSTNAME
exported in the first shell?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 23:29:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 14:29:55 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FAE6t-0002Hr-79@sc8-sf-web3.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 16: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=1433877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Nobody/Anonymous (nobody)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Fri Feb 17 23:56:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 14:56:44 -0800
Subject: [ python-Bugs-1433886 ] pointer aliasing causes core dump,
	with workaround
Message-ID: <E1FAEWq-0002Jb-Bu@sc8-sf-web3.sourceforge.net>

Bugs item #1433886, was opened at 2006-02-17 16:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470

Please note that this message 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
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Nobody/Anonymous (nobody)
Summary: pointer aliasing causes core dump, with workaround

Initial Comment:
When building 2.3.3 on Solaris using Studio 11 and
"-xalias_level=std" to enable ISO C99 pointer aliasing
rules, the interpreter would core dump when running
test_descr2.py.  From examining the source, I believe
this problem exists in 2.4.2 as well, but did not
verify it.

I was able to simplify the code to invoke the problem
down to:
====
class C1(object):
   def __new__(cls):
       return super(C1, cls).__new__(cls)

a = C1()
====

I tracked the problem to super_init() in
Objects/typeobject.c.

The local variable "obj" is of type "PyObject *" and
"type" is of type "PyTypeObject *".  In this function,
both variables can be pointing to the same object in
memory.  Since the pointers are not of compatible
types, the compiler ends up optimizing out a memory
load between Py_INCREF(obj) and Py_INCREF(type) caching
a previously read value.  This causes the object
reference counter to only be incremented once instead
of twice.  When the object is deallocated, the
interpreter blows up.

A workaround is to cast one of the pointers to the
others type so that the compiler can see the pointer
aliasing potential.  This is what I did in the patch.

What I suspect needs to be done as a more global fix is
to discontinue use of the PyObject_VAR_HEAD macro hack.
 Casting between structures containing this macro
creates ISO C99 pointer aliasing violations.  The
contents of the macro needs to be in its own structure
which is referenced so a compliant compiler can know of
 possible aliasing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 07:50:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 22:50:20 -0800
Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler
Message-ID: <E1FALvA-0006aW-KI@sc8-sf-web1.sourceforge.net>

Bugs item #1333982, was opened at 2005-10-21 03:08
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

Please note that this 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: AST
Status: Open
Resolution: None
>Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 13:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}        # !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 07:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
    def __setitem__(self, i, v):
        print i, v
    def __getitem__(self, i):
        print i
        return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 23:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-12-10 16:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 15:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 02:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

-----------------------
assert 1, ([s for s in x] +
           [s for s in x])
pass
-----------------------

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 12:14

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think all the others
mentioned so far have been fixed:

 * Raymond's warnings in compile.c (unused locals are fixed)
 * EXTENDED_ARG problem
 * LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-22 21:53

Message:
Logged In: YES 
user_id=80475

FWIW, here are the warnings issued by my compiler:

Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : 
unreferenced local variable


compile.c
C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation 
from 'const int ' to 'char '


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-22 00:28

Message:
Logged In: YES 
user_id=33168

I assigned to Jeremy and Neil in the hopes they will see
this message and know about these problems.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:45

Message:
Logged In: YES 
user_id=4771

The following (similarly strange-looking) code snippets
compiled successfully before, now they give SyntaxErrors:

--------------------
def f():
    class g:
        exec "hi"
        x
--------------------
def f(x):
    class g:
        exec "hi"
        x
--------------------
def f():
    class g:
        from a import *
        x
--------------------
def f(x):
    class g:
        from a import *
        x


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    while x:
        x -= 1
        # EXTENDED_ARG/JUMP_ABSOLUTE here
    return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
...     def g(self):
...       return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in <stdin>


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

    def f():
        'a'
        'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 04:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '<lambda>' ?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 03:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 03:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
    print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 07:56:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 22:56:23 -0800
Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler
Message-ID: <E1FAM11-0006aj-CA@sc8-sf-web1.sourceforge.net>

Bugs item #1333982, was opened at 2005-10-21 03:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

Please note that this 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: AST
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-17 22:56

Message:
Logged In: YES 
user_id=33168

Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10.  The last two by Armin,
Michael, then my last comment are the only important ones. 
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 13:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}        # !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 07:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
    def __setitem__(self, i, v):
        print i, v
    def __getitem__(self, i):
        print i
        return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 23:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-12-10 16:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 15:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 02:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

-----------------------
assert 1, ([s for s in x] +
           [s for s in x])
pass
-----------------------

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 12:14

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think all the others
mentioned so far have been fixed:

 * Raymond's warnings in compile.c (unused locals are fixed)
 * EXTENDED_ARG problem
 * LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-22 21:53

Message:
Logged In: YES 
user_id=80475

FWIW, here are the warnings issued by my compiler:

Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : 
unreferenced local variable
C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : 
unreferenced local variable


compile.c
C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation 
from 'const int ' to 'char '
C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation 
from 'const int ' to 'char '


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-22 00:28

Message:
Logged In: YES 
user_id=33168

I assigned to Jeremy and Neil in the hopes they will see
this message and know about these problems.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:45

Message:
Logged In: YES 
user_id=4771

The following (similarly strange-looking) code snippets
compiled successfully before, now they give SyntaxErrors:

--------------------
def f():
    class g:
        exec "hi"
        x
--------------------
def f(x):
    class g:
        exec "hi"
        x
--------------------
def f():
    class g:
        from a import *
        x
--------------------
def f(x):
    class g:
        from a import *
        x


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    %s
    while x:
        x -= 1
        # EXTENDED_ARG/JUMP_ABSOLUTE here
    return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
...     def g(self):
...       return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in <stdin>


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 05:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

    def f():
        'a'
        'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 04:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '<lambda>' ?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 03:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 03:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
    print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 08:14:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 23:14:31 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FAMIZ-0004c4-7q@sc8-sf-web6.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 14:29
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 9
Submitted By: Quentin Barnes (qbarnes)
>Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-17 23:14

Message:
Logged In: YES 
user_id=33168

Thomas, could this have caused the flakiness that you just
fixed with test_pty?  This patch seems correct to me and I
think it should be applied.  (If you want I can do that, but
I wanted you to see this first.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 08:22:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 17 Feb 2006 23:22:24 -0800
Subject: [ python-Bugs-1432525 ] os.listdir doesn't release GIL
Message-ID: <E1FAMQC-0004cY-Fy@sc8-sf-web6.sourceforge.net>

Bugs item #1432525, was opened at 2006-02-15 14:45
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Ellis (ellisj)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir doesn't release GIL

Initial Comment:
posix_listdir in posixmodule.c does not release the
global interpreter lock, blocking all other threads for
the duration of the call.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 12:24:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 03:24:27 -0800
Subject: [ python-Bugs-1432838 ] optparse docs double-dash confusion
Message-ID: <E1FAQCR-0002r9-Ob@sc8-sf-web2.sourceforge.net>

Bugs item #1432838, was opened at 2006-02-16 12:28
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432838&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Veness (pelago)
Assigned to: Greg Ward (gward)
Summary: optparse docs double-dash confusion

Initial Comment:
Page
http://docs.python.org/lib/optparse-terminology.html says:

The GNU project introduced "-" followed by a series of
hyphen-separated words, e.g. "-file" or "-dry-run".

but should say:

The GNU project introduced "--" followed by a series of
hyphen-separated words, e.g. "--file" or "--dry-run".

Also at the bottom of that page:

"-v" and "-report" are both options.

should be:

"-v" and "--report" are both options.

It looks in general that there is a documentation
rendering problem when double-dash appears in quotes.
Other double-dash items on that page are ok, when not
in quotes.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-18 11:24

Message:
Logged In: YES 
user_id=1126061

Yeah, that's all that the patch that I provided does.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 09:05

Message:
Logged In: YES 
user_id=1188172

A suggested fix is to replace "-{}-" by "{--}" for long
options. Greg?

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-16 20:59

Message:
Logged In: YES 
user_id=1126061

Patch provided: #1433148

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432838&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 21:36:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 12:36:05 -0800
Subject: [ python-Bugs-1434298 ] CHM file contains proprietary link format
Message-ID: <E1FAYoH-0005za-DX@sc8-sf-web6.sourceforge.net>

Bugs item #1434298, was opened at 2006-02-18 21:22
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1434298&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Martin v. L??wis (loewis)
Summary: CHM file contains proprietary link format

Initial Comment:
The .chm file distributed with Python contains URL 
using the proprietary link scheme mk:@MSITStore. While 
this is not a problem in Windows environments, it 
prevents e.g. xchm from loading the pictures.
My suggestion is to advise the html help compiler to 
make these links absolute without specifying a 
protocol. As I do not have setup the html help compiler 
here, I cannot check if this is a working work around.

Having a .chm file that is compatible to multiple 
platforms is a large advantage because you can advise 
newbies to get this file. They are easy navigatable and 
tend to be complete.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-02-18 21:36

Message:
Logged In: YES 
user_id=11105

Can you tell me how this is done?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 21:27

Message:
Logged In: YES 
user_id=1188172

Moving to Bugs.

Martin, do you create the CHM file?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1434298&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 21:50:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 12:50:03 -0800
Subject: [ python-Bugs-1434298 ] CHM file contains proprietary link format
Message-ID: <E1FAZ1n-00061U-Az@sc8-sf-web6.sourceforge.net>

Bugs item #1434298, was opened at 2006-02-18 21:22
Message generated for change (Comment added) made by alexanderweb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1434298&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Martin v. L??wis (loewis)
Summary: CHM file contains proprietary link format

Initial Comment:
The .chm file distributed with Python contains URL 
using the proprietary link scheme mk:@MSITStore. While 
this is not a problem in Windows environments, it 
prevents e.g. xchm from loading the pictures.
My suggestion is to advise the html help compiler to 
make these links absolute without specifying a 
protocol. As I do not have setup the html help compiler 
here, I cannot check if this is a working work around.

Having a .chm file that is compatible to multiple 
platforms is a large advantage because you can advise 
newbies to get this file. They are easy navigatable and 
tend to be complete.

----------------------------------------------------------------------

>Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-02-18 21:50

Message:
Logged In: YES 
user_id=254738

I could check if it is possible if you can tell me where the 
HTML help compiler project etc. files are in the source 
tree.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-02-18 21:36

Message:
Logged In: YES 
user_id=11105

Can you tell me how this is done?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 21:27

Message:
Logged In: YES 
user_id=1188172

Moving to Bugs.

Martin, do you create the CHM file?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1434298&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 22:19:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 13:19:16 -0800
Subject: [ python-Bugs-1434298 ] CHM file contains proprietary link format
Message-ID: <E1FAZU4-00087C-K9@sc8-sf-web1.sourceforge.net>

Bugs item #1434298, was opened at 2006-02-18 21:22
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1434298&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
>Assigned to: Thomas Heller (theller)
Summary: CHM file contains proprietary link format

Initial Comment:
The .chm file distributed with Python contains URL 
using the proprietary link scheme mk:@MSITStore. While 
this is not a problem in Windows environments, it 
prevents e.g. xchm from loading the pictures.
My suggestion is to advise the html help compiler to 
make these links absolute without specifying a 
protocol. As I do not have setup the html help compiler 
here, I cannot check if this is a working work around.

Having a .chm file that is compatible to multiple 
platforms is a large advantage because you can advise 
newbies to get this file. They are easy navigatable and 
tend to be complete.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-02-18 22:19

Message:
Logged In: YES 
user_id=11105

The project files are generated by calling the script
Doc/tools/prechm.py.  See als PEP 101.

----------------------------------------------------------------------

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-02-18 21:50

Message:
Logged In: YES 
user_id=254738

I could check if it is possible if you can tell me where the 
HTML help compiler project etc. files are in the source 
tree.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-02-18 21:36

Message:
Logged In: YES 
user_id=11105

Can you tell me how this is done?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 21:27

Message:
Logged In: YES 
user_id=1188172

Moving to Bugs.

Martin, do you create the CHM file?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1434298&group_id=5470

From noreply at sourceforge.net  Sat Feb 18 22:57:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 13:57:45 -0800
Subject: [ python-Bugs-1366000 ] Bug bz2.BZ2File(...).seek(0,2)
Message-ID: <E1FAa5J-0003w1-BO@sc8-sf-web2.sourceforge.net>

Bugs item #1366000, was opened at 2005-11-25 03:14
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366000&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: STINNER Victor (haypo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug bz2.BZ2File(...).seek(0,2)

Initial Comment:
Hi,

Look at the following code:
 import bz2
 bz2.BZ2File("test.bz2","r")
 bz2.seek(0,2)
 assert bz2.tell() != 0

seek() method is buggy (when 0<=offset and where=2).

I wrote a patch.

Haypo

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-18 22:57

Message:
Logged In: YES 
user_id=1188172

Thanks for the bug report, fixed in rev. 42468, 42469(2.4).

----------------------------------------------------------------------

Comment By: STINNER Victor (haypo)
Date: 2005-11-25 03:21

Message:
Logged In: YES 
user_id=365388

Please check it :-) I'm not sure that it works well because
I'm new in CPython code.

Oooooops ... I just tried my code, and seek(x,2) with 0<x
worked like seek(-x,2)! So here is a new patch :-P

Haypo

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366000&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 01:05:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 16:05:57 -0800
Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *=
Message-ID: <E1FAc5N-0008O0-1G@sc8-sf-web1.sourceforge.net>

Bugs item #1355842, was opened at 2005-11-13 12:17
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Connelly (connelly)
>Assigned to: Armin Rigo (arigo)
Summary: Incorrect Decimal-float behavior for += and *=

Initial Comment:
The += and *= operators have strange behavior when the
LHS is a Decimal and the RHS is a float (as of
2005-11-13 CVS decimal.py).

Example:

>>> d = Decimal('1.02')
>>> d += 2.1
>>> d
NotImplemented

A blatant violation of "Errors should never pass silently."

Also, a bad error description is produced for the *=
operator:

>>> d = Decimal('1.02')
>>> d *= 2.9
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can't multiply sequence by non-int


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 01:05

Message:
Logged In: YES 
user_id=1188172

The patch was committed and fixed this, but only in SVN
HEAD, not for 2.4.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-26 17:31

Message:
Logged In: YES 
user_id=4771

See proposed patch: #1390657

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-22 22:31

Message:
Logged In: YES 
user_id=38388

Hi Facundo,

the problem you are seeing seems to be in the way new-style
classes implement number coercion. 

Apparently some part in the (not so new-style anymore)
coercion logic is masking an exception which then triggers
later during processing. 

The NotImplemented singleton should never make it to the
interactive shell since it is normally only used internally
by the number coercion logic to signal "object method
doesn't handle mixed type operation".


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-12-22 18:10

Message:
Logged In: YES 
user_id=752496

Regarding problem 1:

Nick also detected this behaviour, back in March
(http://mail.python.org/pipermail/python-dev/2005-March/051834.html),
in python-dev discussions about how integrate better the
Decimal behaviour into Python framework.

Even knowing this, Raymond Hettinger and I made a patch
(almost exactly the same), and corrected another behaviour.
Will this issue be resolved somewhen? Raymond said that this
problem is also present in sets.py and datetime objects
(http://mail.python.org/pipermail/python-dev/2005-March/051825.html),
and that should be addressed in a larger context than decimal.

As Neil Schemenauer proposed
(http://mail.python.org/pipermail/python-dev/2005-March/051829.html),
Decimal now returns NotImplemented instead of raise
TypeError, which should be the correct way to deal with
operation capabilities in the numbers.

And look at this:

>>> d
Decimal("1")   # using decimal.py rev. 39328 from svn
>>> d + 1.2
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'Decimal' and
'float'
>>> d += 1.2
>>> d
NotImplemented
>>>

Why this happens? Really don't know, it's beyond my actual
knowledge, I'll keep searching. But I'm not so sure that
this is a Decimal issue.


Regarding problem 2:

I'll fix that.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-22 06:52

Message:
Logged In: YES 
user_id=33168

Facundo, can you look into this?  Are you still working on
Decimal?

----------------------------------------------------------------------

Comment By: Connelly (connelly)
Date: 2005-12-02 07:17

Message:
Logged In: YES 
user_id=1039782

The += and *= operations also give the same strange behavior
when the LHS is a Decimal and the RHS is str or unicode:

>>> d = Decimal("1.0")
>>> d += "5"
>>> d
NotImplemented

>>> d = Decimal("1.0")
>>> d *= "1.0"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can't multiply sequence by non-int


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 05:43

Message:
Logged In: YES 
user_id=33168

Hmmm.  __add__ returns NotImplemented which works with
classic classes, but not new-style classes.  I wonder if
NotImplementedError is supposed to be raised for new-style
classes.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 01:14:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 16:14:31 -0800
Subject: [ python-Bugs-1430435 ] urllib2 has memory leaks
Message-ID: <E1FAcDf-0008PE-Ai@sc8-sf-web1.sourceforge.net>

Bugs item #1430435, was opened at 2006-02-13 05:30
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: halfik (halfik)
Assigned to: Nobody/Anonymous (nobody)
>Summary: urllib2 has memory leaks

Initial Comment:
reg = urllib2.Request(url, data, headers)
rl_handle = urllib2.urlopen(reg)

urllib2 has hot memory leaks.

gc: uncollectable <_fileobject memory_adres>
gc: uncollectable <list memory adres>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 01:21:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 16:21:33 -0800
Subject: [ python-Bugs-1258485 ] http auth documentation/implementation
	conflict
Message-ID: <E1FAcKT-0006Nd-0N@sc8-sf-web6.sourceforge.net>

Bugs item #1258485, was opened at 2005-08-13 18:49
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258485&group_id=5470

Please note that this message 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
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: http auth documentation/implementation conflict

Initial Comment:
 [forwarded from http://bugs.debian.org/304925]

Bug reporter writes:

I was trying to implement a basic HTTP client using
HTTP basic
authorization. The current preferred method of doing
this is by using
urllib2 HTTPPasswordMgr. 

A simple test snippet to try this:

pwmgr=urllib2.HTTPPasswordMgrWithDefaultRealm()
pwmgr.add_password(None, url, username, password)
handler=urllib2.HTTPBasicAuthHandler(pwmgr)
opener=urllib2.build_opener(handler)
urllib2.install_opener(opener)
u=urllib2.urlopen(url)

This did not work. Modifying the second line to:

pwmgr.add_password(None, urlparse.urlparse(url)[1],
username, password)

fixed things, which shows a problem in the
documentation: instead of
a URI or sequence of URIs the add_password method takes
a hostname. 

The documented behaviour would be better since it
allows for multiple
passwords per host, although in reality those will use
different realms.
So I suggest not changing the code in order to not
break existing
application but fixing the documentation instead.



----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 01:21

Message:
Logged In: YES 
user_id=1188172

The given URI is split via urlparse, so adding a protocol
wouldn't matter. The problem must have been a different one,
perhaps a misspelling.

Closing as Invalid.

----------------------------------------------------------------------

Comment By: Mike Foord (mjfoord)
Date: 2005-08-30 14:58

Message:
Logged In: YES 
user_id=1123892

I think it likely that the OP was using a URL that *included* 
the protocol - (i.e. "http://www.somedomain.com/path") 
instead of just "www.somedomain.com/path".

It is a problem that also bit me - and could *definitely* do with 
a mention in the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258485&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 01:54:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 16:54:42 -0800
Subject: [ python-Bugs-1396678 ] bsddb.__init__ causes error
Message-ID: <E1FAcqY-0004Ec-QC@sc8-sf-web2.sourceforge.net>

Bugs item #1396678, was opened at 2006-01-04 10:56
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396678&group_id=5470

Please note that this 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: Fixed
Priority: 5
Submitted By: Fabian_M (fmareyen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.__init__ causes error

Initial Comment:
I've found an Error in the bsddb.__init__.py-module:

pythonversion = 2.4 (problem may also be in version 2.3)

After creating and closing a db with bsddb.hashopen I
called globals().
Next there occured an Error:


#Error-Message
---------------------------------------------
>>> globals()
{'__builtins__': <module '__builtin__' (built-in)>,
'f4': <function f4 at 0x00B5A130>, 'dbtest1': Traceback
(most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Programme\python24\lib\UserDict.py", line
162, in __repr__
    return repr(dict(self.iteritems()))
  File "<string>", line 46, in iteritems
  File "<string>", line 4, in _make_iter_cursor
AttributeError: 'NoneType' object has no attribute 'cursor'
>>>
----------------------------------------------


#Way of the Error
The way of the Error is:
1.
globals() asked for bsddb._DBWithCursor.__repr__ with
the __repr__-method inherriting from bsddb._iter_mixin
based on UserDict.DictMixin.
2.
The __repr__-method in UserDict.DictMixin at line 162
calls self.iteritems overwritten by
bsddb._iter_mixin.iteritems at line 113.
3.
This method calls self._make_iter_cursor (line 115).
bsddb._iter_mixin._make_iter_cursor calls bsddb.db
which was set to None at closing the bd with db.close()
at line 223.


#Solution:
That way the error was created. To avoid this, the
bsddb._iter_mixin.iteritems-method should be something
like this:
-------------------------
def iteritems(self):
        if not self.db:
                return ""
        try:
                cur = self._make_iter_cursor()
                ...
        ...
-------------------------


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 01:54

Message:
Logged In: YES 
user_id=1188172

Thanks for the report. Fixed in rev. 42480.

----------------------------------------------------------------------

Comment By: Fabian_M (fmareyen)
Date: 2006-01-08 18:07

Message:
Logged In: YES 
user_id=1418961

I've added an example-file.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-05 06:54

Message:
Logged In: YES 
user_id=33168

Can you attach a complete test case which demonstrates this
behaviour?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396678&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 01:58:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 16:58:54 -0800
Subject: [ python-Bugs-1379393 ] StreamReader.readline doesn't advance on
	decode errors
Message-ID: <E1FAcuc-00043N-6S@sc8-sf-web5.sourceforge.net>

Bugs item #1379393, was opened at 2005-12-13 11:35
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470

Please note that this message 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: Wont Fix
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: Walter D?rwald (doerwalter)
Summary: StreamReader.readline doesn't advance on decode errors

Initial Comment:
In previous versions of python, when there was a
unicode decode error, StreamReader.readline() would
advance to the next line.  In the current version(2.4.2
and trunk),  it doesn't.  Testing under Linux AMD64
(Ubuntu 5.10)

Attaching an example script.  In python2.3 it prints:

hi~
hi
error: 'utf8' codec can't decode byte 0x80 in position
2: unexpected code byte
error: 'utf8' codec can't decode byte 0x81 in position
2: unexpected code byte
all done


In python2.4 and trunk it prints:
hi~
hi
error: 'utf8' codec can't decode byte 0x80 in position
0: unexpected code byte
error: 'utf8' codec can't decode byte 0x80 in position
0: unexpected code byte
error: 'utf8' codec can't decode byte 0x80 in position
0: unexpected code byte
[repeats forever]


Maybe this isn't actually supposed to work (the docs
don't mention what should happen with strict error
checking..), but it would be nice, given the alternatives:
1. use errors='replace' and then search the result for
the replacement character. (ick)
2. define a custom error handler similar to ignore or
replace, that also sets some flag. (slightly less ick,
but more work.)


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 01:58

Message:
Logged In: YES 
user_id=1188172

Closing as Won't Fix, then.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-12-16 18:25

Message:
Logged In: YES 
user_id=89016

IMHO the current behaviour is more consistent. To read the
broken utf-8 stream from the test script the appropriate
error handler should be used. What is the desired outcome?
If only the broken byte sequence should be skipped
errors="replace" is appropriate. To skip a complete line
that contains a broken byte sequence do something like in
the attached skipbadlines.py. The StreamReader can't know
which behaviour is wanted.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 22:42

Message:
Logged In: YES 
user_id=1188172

I don't know what should be correct. Walter?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 01:59:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 18 Feb 2006 16:59:40 -0800
Subject: [ python-Bugs-1376400 ] test_struct crashed, py2.3.5, solaris 10
Message-ID: <E1FAcvM-00043X-7y@sc8-sf-web5.sourceforge.net>

Bugs item #1376400, was opened at 2005-12-08 17:06
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470

Please note that this 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.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: rrogans (rrogans)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_struct crashed, py2.3.5, solaris 10

Initial Comment:
Hi,

I am building python 2.3.5 on solaris 10 using gcc 
3.3.2. Run I perform the test I get one test failure - 
test_struct crashes.

Rgds,

Richard

>>>>>>>>>>>>

trying std qQ on 1471797217424382203 == 
0x146CDFC575FD18FBL
trying std qQ on 1471797217424382204 == 
0x146CDFC575FD18FCL
trying std qQ on 1471797217424382205 == 
0x146CDFC575FD18FDL
test test_struct crashed -- exceptions.OverflowError: 
math range error
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 394, in runtest
    the_package = __import__(abstest, globals(), locals
(), [])
  File "/home/richardr/app/Python-
2.3.5/Lib/test/test_struct.py", line 439, in ?
    test_705836()
  File "/home/richardr/app/Python-
2.3.5/Lib/test/test_struct.py", line 424, in 
test_705836
    big = math.ldexp(big, 127 - 23)
OverflowError: math range error
1 test failed:
    test_struct

<<<<<<<<<<<

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 01:59

Message:
Logged In: YES 
user_id=1188172

To the OP: Can you provide information whether this happens
with Python 2.4?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-12-28 01:06

Message:
Logged In: YES 
user_id=21627

Also, Python 2.3 is no longer maintained. So unless this
problem also shows up with 2.4, we are unlikely to take any
action.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 21:15

Message:
Logged In: YES 
user_id=33168

Could you try disabling optimization and rebuilding python?
 Also, depending on which compiler you are using, ensure
that you are using strict math.  Sometimes the option is
-ieee I think.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 10:39:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Feb 2006 01:39:17 -0800
Subject: [ python-Bugs-1351707 ] zipimport produces incomplete IOError
	instances
Message-ID: <E1FAl2D-0005W9-3O@sc8-sf-web3.sourceforge.net>

Bugs item #1351707, was opened at 2005-11-08 22:43
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipimport produces incomplete IOError instances

Initial Comment:
The get_data() method on the zipimport.zipimporter
object produces IOError exceptions that only have an
error message.  It should use
PyErr_SetFromErrnoWithFilename() instead of
PyErr_Format() for IOError exceptions.

This should be fixed for both Python 2.4.3 and 2.5.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 10:39

Message:
Logged In: YES 
user_id=1188172

Fixed in rev. 42487, 42488.

----------------------------------------------------------------------

Comment By: Thomas Lee (krumms)
Date: 2005-11-10 01:46

Message:
Logged In: YES 
user_id=315535

Patch against HEAD here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1352711&group_id=5470&atid=305470


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 15:58:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Feb 2006 06:58:10 -0800
Subject: [ python-Feature Requests-563141 ] fileinput/gzip modules should play
	well
Message-ID: <E1FAq0o-00035S-Ln@sc8-sf-web5.sourceforge.net>

Feature Requests item #563141, was opened at 2002-06-01 02:27
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470

Please note that this message 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: Accepted
Priority: 5
Submitted By: Greg White (groggygreggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: fileinput/gzip modules should play well

Initial Comment:
It seems to be nearly impossible to use the fileinput 
module to read gzip files, even though gzip support is 
available in the gzip module.

As a first step, it would be nice if the fileinput.FileInput 
class provided an overridable method that let outsiders 
glue the gzip module in place.

It would also be nice if there was a way to make fileinput 
just automatically support gzip files (if, for instance, it 
saw a .gz extension).

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 15:58

Message:
Logged In: YES 
user_id=1188172

Accepted by committing patch #1215184.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-05 16:52

Message:
Logged In: YES 
user_id=1188172

See patch #1215184.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-13 04:25

Message:
Logged In: YES 
user_id=357491

The hook is reasonable, the automatic opening of gzip is not.  No need to 
have magic done based purely on extension.

Any chance you could write a patch to expose the hook?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 16:10:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Feb 2006 07:10:40 -0800
Subject: [ python-Bugs-764493 ] test test_nis crashed -- nis.error: no such
	key in map
Message-ID: <E1FAqCu-0008RQ-2z@sc8-sf-web1.sourceforge.net>

Bugs item #764493, was opened at 2003-07-02 12:09
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Martin Mokrejs (mmokrejs)
Assigned to: Nobody/Anonymous (nobody)
Summary: test test_nis crashed -- nis.error: no such key in map

Initial Comment:
I always ignored this test error, but maybe you want to
fix this:

test test_nis crashed -- nis.error: no such key in map


$ ./python Lib/test/test_nis.py
nis.maps()
group.bygid.tmp
mail.aliases
      
     n.strack strack
Traceback (most recent call last):
  File &quot;Lib/test/test_nis.py&quot;, line 24, in ?
    if nis.match(k, nismap) != v:
nis.error: no such key in map
$

I believe this might be some misconfiguration of NIS on
thsi host(we use it on other machines, but it should
not be enabled on this particular machine). 

But, when I do &quot;ypcat mail.aliases&quot;, I do not see a
line with &quot;n.strack strack&quot;. Maybe more debug trace
would help to find what's going on.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 16:10

Message:
Logged In: YES 
user_id=1188172

Does this error persist in Python 2.4?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764493&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 21:03:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Feb 2006 12:03:49 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FAumb-0004ra-KM@sc8-sf-web2.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 17:29
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 9
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 15:03

Message:
Logged In: YES 
user_id=6380

One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way.  Whether null-terminating it makes
sense or not depends on the particular operation code.

I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied.  A quick code review reveals a
few more issues:

- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)

- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense!  Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.

- In the first branch of the function, this line:

    if (mutate_arg && (len < sizeof buf)) {

ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use

    if (mutate_arg && arg == buf) {

- If it's important to null-terminate the data in the buffer
when a string is passed in, shouldn't we null-terminate it
also when a writable buffer-interface object is passed in? 
If not in the latter case, why if a string is passed?  One
could argue that a string with an explicit \0 (visible to
Python code) at the end ought to be passed in if the
semantics of the op code requires a null-terminated argument
(which most ioctl op codes don't -- the typical argument is
a C struct).

- The proposed patch reduces the maximum buffer size to
1023, which violates the docs. (Yes the docs explicitly
mention 1024.)

- The best we can do seems to be: increase the buffer size
to 1025; null-pad it in all cases; change the code for
mutable buffers to test for sizeof buf - 1.  This still
leaves the case where the buffer isn't used because a
mutable buffer is passed that's longer than 1024.  Which
suggests that we can't completely fix this -- it will always
be possible to crash Python using this function by passing
an op code that encodes a buffer length > 1024 while passing
a shorter argument, so the internal buffer is used.  I guess
we could do the null-padding as long as we document it and
document that when a mutable buffer is passed we don't
guarantee it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 02:14

Message:
Logged In: YES 
user_id=33168

Thomas, could this have caused the flakiness that you just
fixed with test_pty?  This patch seems correct to me and I
think it should be applied.  (If you want I can do that, but
I wanted you to see this first.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 22:34:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Feb 2006 13:34:06 -0800
Subject: [ python-Bugs-1431253 ] Logging hangs thread after detaching a
	StreamHandler's termi
Message-ID: <E1FAwBy-000531-0w@sc8-sf-web2.sourceforge.net>

Bugs item #1431253, was opened at 2006-02-14 06:07
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470

Please note that this message 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: Works For Me
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi

Initial Comment:
Hi all,

After many hours, I think I've found a bug in the 
logging module!

If you add a (stdout) StreamHandler to a logger, then 
detach the terminal for that stdout, subsequent calls 
to log() will hang the calling thread.

To reproduce this, write the following scripts (this 
was a small test case I came up with - maybe there's 
something simpler):

$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ; 
done'

$ cat hup.bash
#!/usr/bin/env bash
./hup.py &

$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
        logging.basicConfig( filename = '/tmp/lup.out', 
filemode = 'w' )
        # XXX PROBLEM LINE BELOW
        logging.getLogger('').addHandler( logging.
StreamHandler() )
        while True:
                f.write( '-------\n' )
                f.flush()
                logging.critical( '======' )
                time.sleep(1)
finally:
        f.close()

Run ./tryhup.bash. It will sit in an idle spin. Monitor 
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on 
tryhup to kill it. The python process is still running, 
but is stalled (the .out files are no longer changing).

If you remove the above labeled line, however, this 
doesn't happen.

Can anybody please acknowledge this bug? Any temporary 
workarounds to this problem? Thanks in advance for 
looking into this and for hearing me in!

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2006-02-19 21:34

Message:
Logged In: YES 
user_id=308438

I can't tell from the info you've given what the problem
might be (e.g. state of redirections), but as it doesn't
appear to be a logging bug, I'm closing this.

By default, raiseExceptions is set to 1 in the logging
package, so a handler's handleError should be called when an
exception is raised in a handler.

You catch an exception with a try/except clause, like so:

try:
  # code which raises some exception
except Exception, e:
  open('/tmp/exc.txt', 'w').write(str(e))





----------------------------------------------------------------------

Comment By: Yang Zhang (yangzhang)
Date: 2006-02-17 07:17

Message:
Logged In: YES 
user_id=1207658

Hi, yes, after I submitted this bug I actually looked into 
logging.StreamHandler, and found that its code was not too 
complicated (as with everything Python :).

I tried some more experiments, and found that the problem is 
in stderr, which throws an exception. The problem was that I 
couldn't see the exception (and didn't suspect that's what 
was happening), so the fact that the next line never came 
out led me to believe that the thread froze.

Is stderr supposed to raise an exception like this? Is this 
a bug?

Unfortunately, it's hard for me to tell what's going on 
(what the exception is that's being thrown). How do I tell 
what it's raising? (stderr is no longer avail. after all) I 
don't know how to catch an exception of any type and (say) 
print its str or repr value to a file so that I can tell 
what's going on.

----------------------------------------------------------------------

Comment By: Yang Zhang (yangzhang)
Date: 2006-02-17 07:16

Message:
Logged In: YES 
user_id=1207658

Hi, yes, after I submitted this bug I actually looked into 
logging.StreamHandler, and found that its code was not too 
complicated (as with everything Python :).

I tried some more experiments, and found that the problem is 
in stderr, which throws an exception. The problem was that I 
couldn't see the exception (and didn't suspect that's what 
was happening), so the fact that the next line never came 
out led me to believe that the thread froze.

Is stderr supposed to raise an exception like this? Is this 
a bug?

Unfortunately, it's hard for me to tell what's going on 
(what the exception is that's being thrown). How do I tell 
what it's raising? (stderr is no longer avail. after all) I 
don't know how to catch an exception of any type and (say) 
print its str or repr value to a file so that I can tell 
what's going on.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2006-02-17 01:04

Message:
Logged In: YES 
user_id=308438

Please provide more information about your OS - I ran these
scripts on Ubuntu 5.10 and did not see the problems you
mention. The script continues to run (printing dashes to the
console), and hup.out/lup.out are also updated continuously. 

Also, note that the logging module merely opens the stream
passed to the StreamHander for output, so check if in
your configuration you get a hang just doing a write to
sys.stderr.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470

From noreply at sourceforge.net  Sun Feb 19 23:40:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Feb 2006 14:40:23 -0800
Subject: [ python-Bugs-1430436 ] recursive __getattr__ in thread crashes BSDs
Message-ID: <E1FAxE7-0000vY-NS@sc8-sf-web1.sourceforge.net>

Bugs item #1430436, was opened at 2006-02-13 07:35
Message generated for change (Comment added) made by aix-d
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430436&group_id=5470

Please note that this 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
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: recursive __getattr__ in thread crashes BSDs

Initial Comment:
The following code consistently crashes Python 2.4 on Mac OS X:

import threading

class foo:
    def __getattr__(self, x): self.foo

def j(): foo().bar

t = threading.Thread(target=j, args=())
t.start()

----------------------------------------------------------------------

Comment By: aix-d (aix-d)
Date: 2006-02-20 01:40

Message:
Logged In: YES 
user_id=1449422

Hello.

I have the same segfault :-(

Python version: from SVN
Python 2.5a0 (trunk, Feb 19 2006, 22:22:12)
[GCC 3.4.4 [FreeBSD] 20050518] on freebsd6

Best regards, Alexander.

----------------------------------------------------------------------

Comment By: Aaron Swartz (aaronsw)
Date: 2006-02-13 07:44

Message:
Logged In: YES 
user_id=122141

Since the indenting was off above, I've attached the code.

----------------------------------------------------------------------

Comment By: Aaron Swartz (aaronsw)
Date: 2006-02-13 07:41

Message:
Logged In: YES 
user_id=122141

I've also tested it on FreeBSD and it has the same problem (Segmentation fault 
(core dumped)).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430436&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 01:31:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Feb 2006 16:31:03 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FAyxD-00017N-PA@sc8-sf-web1.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 16:29
Message generated for change (Comment added) made by qbarnes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 9
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

>Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-19 18:31

Message:
Logged In: YES 
user_id=288734

I've practically never used python.  I just found
this bug in the interpreter while porting the
tool to the current Solaris compiler release, so please
keep that in mind about my lack of python knowledge.
I also have no idea who's who as well in the python
world so forgive me if I've stepped on anyone's
toes.

I don't follow the remark about "making ioctl
'safe'".  I never said anything about making it
"safe".  It's about a bug.

I also never said anything about the interpreter
crashing.  The interpreter never crashed.  The
pty test just simply failed since the module
name passed to the OS's ioctl was corrupted.

Are you sure you responded to the right bug
report with these remarks?

Anyways...

This problem should be reduced to a classic
data marshaling problem between python data
space and C data space which should have already
been addressed in many contexts many times before
in the interpreter.  How are python strings
converted for use by C in similar situations?

This problem I encountered is either a bug in
the code that passed the string to the ioctl
service by not putting an explicit '\0' on the
end of the "ptem" string, or it is a bug in the
fcntlmodule.c which should have done it for it.
Which is it?

If a python code isn't expected to put a literal
null at the end of their string when passing to
a C service, then ioctl needs to be fixed similar
to the way in my patch.

As for null-terminating other raw data, I don't
see the point other than a defensive programming
practice.

The problem I ran across is limited to just
a data marshaling problem.  The patch only
touched the case when the type of data passed
to ioctl is known to be a string.

As for the buffer vs. documentation, the
buffer could be changed to 1025 for the string
case, or the documentation could be updated
to clarify that, unlike raw data, strings are
limited to 1023 to leave room for the
requisite null that conversion to a C string
requires.  I don't think anyone would care
either way as long as it is qualified.

Since python strings serve dual roles of being
both raw data and being just textual containers,
one can't assume that a string passed to ioctl
is always meant to be just a textual string.  Going
the 1025 route is probably a 'better' approach due to
python string's duality.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 14:03

Message:
Logged In: YES 
user_id=6380

One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way.  Whether null-terminating it makes
sense or not depends on the particular operation code.

I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied.  A quick code review reveals a
few more issues:

- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)

- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense!  Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.

- In the first branch of the function, this line:

    if (mutate_arg && (len < sizeof buf)) {

ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use

    if (mutate_arg && arg == buf) {

- If it's important to null-terminate the data in the buffer
when a string is passed in, shouldn't we null-terminate it
also when a writable buffer-interface object is passed in? 
If not in the latter case, why if a string is passed?  One
could argue that a string with an explicit \0 (visible to
Python code) at the end ought to be passed in if the
semantics of the op code requires a null-terminated argument
(which most ioctl op codes don't -- the typical argument is
a C struct).

- The proposed patch reduces the maximum buffer size to
1023, which violates the docs. (Yes the docs explicitly
mention 1024.)

- The best we can do seems to be: increase the buffer size
to 1025; null-pad it in all cases; change the code for
mutable buffers to test for sizeof buf - 1.  This still
leaves the case where the buffer isn't used because a
mutable buffer is passed that's longer than 1024.  Which
suggests that we can't completely fix this -- it will always
be possible to crash Python using this function by passing
an op code that encodes a buffer length > 1024 while passing
a shorter argument, so the internal buffer is used.  I guess
we could do the null-padding as long as we document it and
document that when a mutable buffer is passed we don't
guarantee it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 01:14

Message:
Logged In: YES 
user_id=33168

Thomas, could this have caused the flakiness that you just
fixed with test_pty?  This patch seems correct to me and I
think it should be applied.  (If you want I can do that, but
I wanted you to see this first.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 06:04:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 19 Feb 2006 21:04:56 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FB3EG-0004d5-Gs@sc8-sf-web5.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 17:29
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 9
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-20 00:04

Message:
Logged In: YES 
user_id=6380

Sorry for the confusion. I was in part responding to an
off-line discussion I had with Neal Norwitz, to which you
weren't a party. You can ignore my comments about safety and
crashing.

The difference in marshalling Python data to C data for
ioctl(), compared to the many other places where (indeed)
this problem has been solved before, is that almost
everywhere else, we *know* what the data is supposed to
mean.  C has many more data types than Python, and the
choice of how to convert a string, or an int, to C data
depends on what is expected by the receiver of the C data. 
Unfortunately for ioctl we don't know the required C data
type because it's defined by the kernel module that handles
the particular ioctl opcode.  Some of these (like the one
you apparently ran into when porting the pty code to
Solaris) require a null-terminated string; others (like the
classic tty ioctls) require a C structure, which in Python
can be created by using the struct module.  Both return
Python strings.

I tend to agree with your conclusion that we should extend
the buffer to 1025 bytes and not bother null-terminating
non-string data.  Would you like to attempt another patch?

----------------------------------------------------------------------

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-19 19:31

Message:
Logged In: YES 
user_id=288734

I've practically never used python.  I just found
this bug in the interpreter while porting the
tool to the current Solaris compiler release, so please
keep that in mind about my lack of python knowledge.
I also have no idea who's who as well in the python
world so forgive me if I've stepped on anyone's
toes.

I don't follow the remark about "making ioctl
'safe'".  I never said anything about making it
"safe".  It's about a bug.

I also never said anything about the interpreter
crashing.  The interpreter never crashed.  The
pty test just simply failed since the module
name passed to the OS's ioctl was corrupted.

Are you sure you responded to the right bug
report with these remarks?

Anyways...

This problem should be reduced to a classic
data marshaling problem between python data
space and C data space which should have already
been addressed in many contexts many times before
in the interpreter.  How are python strings
converted for use by C in similar situations?

This problem I encountered is either a bug in
the code that passed the string to the ioctl
service by not putting an explicit '\0' on the
end of the "ptem" string, or it is a bug in the
fcntlmodule.c which should have done it for it.
Which is it?

If a python code isn't expected to put a literal
null at the end of their string when passing to
a C service, then ioctl needs to be fixed similar
to the way in my patch.

As for null-terminating other raw data, I don't
see the point other than a defensive programming
practice.

The problem I ran across is limited to just
a data marshaling problem.  The patch only
touched the case when the type of data passed
to ioctl is known to be a string.

As for the buffer vs. documentation, the
buffer could be changed to 1025 for the string
case, or the documentation could be updated
to clarify that, unlike raw data, strings are
limited to 1023 to leave room for the
requisite null that conversion to a C string
requires.  I don't think anyone would care
either way as long as it is qualified.

Since python strings serve dual roles of being
both raw data and being just textual containers,
one can't assume that a string passed to ioctl
is always meant to be just a textual string.  Going
the 1025 route is probably a 'better' approach due to
python string's duality.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 15:03

Message:
Logged In: YES 
user_id=6380

One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way.  Whether null-terminating it makes
sense or not depends on the particular operation code.

I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied.  A quick code review reveals a
few more issues:

- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)

- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense!  Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.

- In the first branch of the function, this line:

    if (mutate_arg && (len < sizeof buf)) {

ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use

    if (mutate_arg && arg == buf) {

- If it's important to null-terminate the data in the buffer
when a string is passed in, shouldn't we null-terminate it
also when a writable buffer-interface object is passed in? 
If not in the latter case, why if a string is passed?  One
could argue that a string with an explicit \0 (visible to
Python code) at the end ought to be passed in if the
semantics of the op code requires a null-terminated argument
(which most ioctl op codes don't -- the typical argument is
a C struct).

- The proposed patch reduces the maximum buffer size to
1023, which violates the docs. (Yes the docs explicitly
mention 1024.)

- The best we can do seems to be: increase the buffer size
to 1025; null-pad it in all cases; change the code for
mutable buffers to test for sizeof buf - 1.  This still
leaves the case where the buffer isn't used because a
mutable buffer is passed that's longer than 1024.  Which
suggests that we can't completely fix this -- it will always
be possible to crash Python using this function by passing
an op code that encodes a buffer length > 1024 while passing
a shorter argument, so the internal buffer is used.  I guess
we could do the null-padding as long as we document it and
document that when a mutable buffer is passed we don't
guarantee it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 02:14

Message:
Logged In: YES 
user_id=33168

Thomas, could this have caused the flakiness that you just
fixed with test_pty?  This patch seems correct to me and I
think it should be applied.  (If you want I can do that, but
I wanted you to see this first.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 09:12:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 00:12:21 -0800
Subject: [ python-Feature Requests-1379573 ] python executable optionally
	should search script on PATH
Message-ID: <E1FB69d-0001r2-0B@sc8-sf-web1.sourceforge.net>

Feature Requests item #1379573, was opened at 2005-12-13 16:13
Message generated for change (Comment added) made by cconrad
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Conrad (cconrad)
Assigned to: Nobody/Anonymous (nobody)
Summary: python executable optionally should search script on PATH

Initial Comment:
I've seen that with perl - parameter -S means search
script on path. Very helpful.

----------------------------------------------------------------------

>Comment By: Christoph Conrad (cconrad)
Date: 2006-02-20 09:12

Message:
Logged In: YES 
user_id=21338

I checked the registry. It's ok. It's windows 2000.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-01-16 22:29

Message:
Logged In: YES 
user_id=21627

That (arguments not passed to the script) was a bug in some
versions of the Windows installer. Please verify that the
registry, at
(HKCU|HKLM)\Software\Classes\Python.File\open\command has
the value '[path]python.exe "%1" %*'. The %* part should
arrange for arguments being passed.

----------------------------------------------------------------------

Comment By: Christoph Conrad (cconrad)
Date: 2006-01-16 11:59

Message:
Logged In: YES 
user_id=21338

> On windows, you should be able to just invoke the_script.py
> (i.e. without a preceding python.exe). Does this not work
> for you?

It works - but command line args are not given to the called
script. If i prepend python.exe, command line args are
transferred correctly.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-01-14 19:34

Message:
Logged In: YES 
user_id=21627

On windows, you should be able to just invoke the_script.py
(i.e. without a preceding python.exe). Does this not work
for you?

----------------------------------------------------------------------

Comment By: Christoph Conrad (cconrad)
Date: 2005-12-15 23:00

Message:
Logged In: YES 
user_id=21338

i meant the windows operating system.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 22:40

Message:
Logged In: YES 
user_id=1188172

I don't know... if the script is in the PATH, isn't it
normally executable too?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 09:21:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 00:21:13 -0800
Subject: [ python-Bugs-1393109 ] cannot build SVN trunk on old systems
Message-ID: <E1FB6ID-0004yD-In@sc8-sf-web5.sourceforge.net>

Bugs item #1393109, was opened at 2005-12-29 21:25
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470

Please note that this 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: Pending
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot build SVN trunk on old systems

Initial Comment:
Parser/asdl_c.py uses "/usr/bin/env python" to
find a proper python, but the script don't work
on old Pythons (at least it fails on 2.1 and
older).

iirc, various solutions to this were discussed on
python-dev, but nobody seems to have done anything
about it.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-01-11 23:47

Message:
Logged In: YES 
user_id=21627

Is this still a problem? Parser/asdl_c.py should not
normally be invoked, unless you edit the grammar

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-02 05:31

Message:
Logged In: YES 
user_id=33168

One issue I see in asdl.py is that new-style classes are
used.  I don't know if they are really necessary.  You could
try adding something like this to the top of asdl.py and see
if that fixes things:

try:
  object
except NameError:
  class object: pass

Or maybe we just shouldn't make them new-style if that does
fix things.  I don't have an old version of python around.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 09:21:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 00:21:53 -0800
Subject: [ python-Bugs-1367183 ] inspect.getdoc fails on objs that use
	property for __doc__
Message-ID: <E1FB6Ir-0004yU-Fb@sc8-sf-web5.sourceforge.net>

Bugs item #1367183, was opened at 2005-11-26 22:42
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Drew Perttula (drewp)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getdoc fails on objs that use property for __doc__

Initial Comment:
inspect.getdoc has these lines:

     if not isinstance(doc, types.StringTypes):
         return None

which interfere with the case where __doc__ is some
other thing that has a good __str__. I wanted to make a
lazy __doc__ that did an expensive lookup of some
external documentation only when it was str()'d, but
since doc displayers often (correctly) use
inspect.getdoc, they were getting None.

I think the intention of the test in getdoc() is to
avoid trying string operations on a __doc__ that is
None. I think that a more lenient version would allow
me to do my fancy docstrings but still solve the
'__doc__ is None' problem. Please consider the
following patch:

if doc is None:
     return None
doc = str(doc)



----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 09:21

Message:
Logged In: YES 
user_id=1188172

I don't know. Neal, do you have an opinion about property
docstrings?

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-02-01 12:35

Message:
Logged In: YES 
user_id=1344176

It's not a good idea to use properties for __doc__:

"""
>>> class Foo(object):
...    def _get(self):
...        return 'the docstring'
...    __doc__ = property(_get)
...
>>> print Foo().__doc__
the docstring
>>> print Foo.__doc__
<property object at 0xb7b3a234>
>>>
"""

In this light, I don't view inspect.getdoc's lack of support
for __doc__-as-property as a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 09:22:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 00:22:25 -0800
Subject: [ python-Bugs-969718 ] BASECFLAGS are not passed to module build line
Message-ID: <E1FB6JN-0004yf-Md@sc8-sf-web5.sourceforge.net>

Bugs item #969718, was opened at 2004-06-09 17:56
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470

Please note that this 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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Beardsley (vaxhacker)
>Assigned to: Martin v. L??wis (loewis)
Summary: BASECFLAGS are not passed to module build line

Initial Comment:
The value of BASECFLAGS from
/prefix/lib/pythonver/config/Makefile is not present on
the compile command for modules being built by
distutils ("python setup.py build").  It seems that
only the value of OPT is passed along.

This is insufficient when BASECFLAGS contains
"-fno-static-aliasing", since recent versions of gcc
will emit incorrect (crashing) code if this flag is not
provided, when compiling certain modules (the mx
products from egenix, for example).

I did try to set CFLAGS in my environment, as directed
by documentation, but this also had zero effect on the
final build command.


----------------------------------------------------------------------

Comment By: nyogtha (nyogtha)
Date: 2006-01-13 22:19

Message:
Logged In: YES 
user_id=1426882

This is still a bug in Python 2.4.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 09:22:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 00:22:39 -0800
Subject: [ python-Bugs-969718 ] BASECFLAGS are not passed to module build line
Message-ID: <E1FB6Jb-0004yz-LL@sc8-sf-web5.sourceforge.net>

Bugs item #969718, was opened at 2004-06-09 17:56
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Beardsley (vaxhacker)
Assigned to: Martin v. L??wis (loewis)
Summary: BASECFLAGS are not passed to module build line

Initial Comment:
The value of BASECFLAGS from
/prefix/lib/pythonver/config/Makefile is not present on
the compile command for modules being built by
distutils ("python setup.py build").  It seems that
only the value of OPT is passed along.

This is insufficient when BASECFLAGS contains
"-fno-static-aliasing", since recent versions of gcc
will emit incorrect (crashing) code if this flag is not
provided, when compiling certain modules (the mx
products from egenix, for example).

I did try to set CFLAGS in my environment, as directed
by documentation, but this also had zero effect on the
final build command.


----------------------------------------------------------------------

Comment By: nyogtha (nyogtha)
Date: 2006-01-13 22:19

Message:
Logged In: YES 
user_id=1426882

This is still a bug in Python 2.4.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 10:13:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 01:13:15 -0800
Subject: [ python-Bugs-1413790 ] zipfile: inserting some filenames produces
	corrupt .zips
Message-ID: <E1FB76Z-0006Gc-J7@sc8-sf-web2.sourceforge.net>

Bugs item #1413790, was opened at 2006-01-24 16:57
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413790&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Grant Olson (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile: inserting some filenames produces corrupt .zips

Initial Comment:
Running something like the following produces a corrupt
.zip file.  The builtin XP zip folder view won't show
any documents and attempting to extract via "right
click -> Extract files..." will set off an untrusted
file alert:

import zipfile
z = zipfile.ZipFile("c:\\foo.zip","w")
z.write("c:\\autoexec.bat", "\\autoexec.bat")
z.close()

zipfile should either throw an error when adding these
files or attempt to normalize the path.  I would prefer
that zipfile make the assumption that any files
starting with absolute or relative pathnames
("\\foo\\bar.txt" or ".\\foo\\bar.txt") should join in
at the root of the zipfile ("foo\\bar.txt" in this case).

Patch to accomplish the latter is attached.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:13

Message:
Logged In: YES 
user_id=1188172

Thanks for the bug report, fixed in rev. 42508.

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-01-25 21:52

Message:
Logged In: YES 
user_id=699438

Just wanted to note that the documentation of the .zip
format from pkzip explicitly states that a drive letter or
leading slash is not allowed.  The pertinent text:

file name: (Variable)

          The name of the file, with optional relative path.
          The path stored should not contain a drive or
          device letter, or a leading slash.  All slashes
          should be forward slashes '/' as opposed to
          backwards slashes '\' for compatibility with Amiga
          and UNIX file systems etc.  If input came from
standard
          input, there is no file name field.  If encrypting
          the central directory and general purpose bit flag
13 is set 
          indicating masking, the file name stored in the
Local Header 
          will not be the actual file name.  A masking value
consisting 
          of a unique hexadecimal value will be stored. 
This value will 
          be sequentially incremented for each file in the
archive. See
          the section on the Strong Encryption Specification
for details 
          on retrieving the encrypted file name. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413790&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 10:14:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 01:14:19 -0800
Subject: [ python-Feature Requests-1379573 ] python executable optionally
	should search script on PATH
Message-ID: <E1FB77b-0006Gq-MT@sc8-sf-web2.sourceforge.net>

Feature Requests item #1379573, was opened at 2005-12-13 16:13
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Conrad (cconrad)
Assigned to: Nobody/Anonymous (nobody)
Summary: python executable optionally should search script on PATH

Initial Comment:
I've seen that with perl - parameter -S means search
script on path. Very helpful.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:14

Message:
Logged In: YES 
user_id=1188172

Do you mean that the registry setting is ok, but the
parameters are not passed correctly?

----------------------------------------------------------------------

Comment By: Christoph Conrad (cconrad)
Date: 2006-02-20 09:12

Message:
Logged In: YES 
user_id=21338

I checked the registry. It's ok. It's windows 2000.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-01-16 22:29

Message:
Logged In: YES 
user_id=21627

That (arguments not passed to the script) was a bug in some
versions of the Windows installer. Please verify that the
registry, at
(HKCU|HKLM)\Software\Classes\Python.File\open\command has
the value '[path]python.exe "%1" %*'. The %* part should
arrange for arguments being passed.

----------------------------------------------------------------------

Comment By: Christoph Conrad (cconrad)
Date: 2006-01-16 11:59

Message:
Logged In: YES 
user_id=21338

> On windows, you should be able to just invoke the_script.py
> (i.e. without a preceding python.exe). Does this not work
> for you?

It works - but command line args are not given to the called
script. If i prepend python.exe, command line args are
transferred correctly.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-01-14 19:34

Message:
Logged In: YES 
user_id=21627

On windows, you should be able to just invoke the_script.py
(i.e. without a preceding python.exe). Does this not work
for you?

----------------------------------------------------------------------

Comment By: Christoph Conrad (cconrad)
Date: 2005-12-15 23:00

Message:
Logged In: YES 
user_id=21338

i meant the windows operating system.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 22:40

Message:
Logged In: YES 
user_id=1188172

I don't know... if the script is in the PATH, isn't it
normally executable too?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 10:15:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 01:15:57 -0800
Subject: [ python-Bugs-729236 ] building readline module fails on Irix 6.5
Message-ID: <E1FB79B-0006H0-G3@sc8-sf-web2.sourceforge.net>

Bugs item #729236, was opened at 2003-04-29 01:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470

Please note that this 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.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
Summary: building readline module fails on Irix 6.5

Initial Comment:
I am trying to build  Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30

I can't get the readline module to build. I get the
following error:
cc  -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include 
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
  The &quot;return&quot; expression type differs from the
function return type.

        return completion_matches(text, *on_completion);
               ^

cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
  The variable &quot;m&quot; is set but never used.

        PyObject *m;
                  ^

1 error detected in the compilation of
&quot;../Modules/readline.c&quot;.
gmake: *** [Modules/readline.o] Error 2


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:15

Message:
Logged In: YES 
user_id=1188172

Is this still the case with Python 2.4?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 01:49

Message:
Logged In: YES 
user_id=33168

Is HAVE_RL_COMPLETION_MATCHES defined?  If so is
rl_completion_matches() defined to return char ** in
readline.h?  If HAVE_* is not defined, where is
completion_matches() defined and what does it return?

----------------------------------------------------------------------

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 20:02

Message:
Logged In: YES 
user_id=150999

I was able to compile readline on Irix after changing the
function flex_complete. the function prototyte say it should
return a char** .So we did put the following change and it
works. Is it a right way to do it?

** readline.c  2003-05-09 13:45:38.000000000 -0700
--- readline.c~ 2003-03-01 07:19:41.000000000 -0800
***************
*** 577,589 ****
  /* A more flexible constructor that saves the &quot;begidx&quot; and
&quot;endidx&quot;
   * before calling the normal completer */

! static char ** flex_complete(char *text, int start, int end)
  {
        Py_XDECREF(begidx);
        Py_XDECREF(endidx);
        begidx = PyInt_FromLong((long) start);
        endidx = PyInt_FromLong((long) end);
!       return (char **)completion_matches(text,
*on_completion);
  }


--- 577,590 ----
  /* A more flexible constructor that saves the &quot;begidx&quot; and
&quot;endidx&quot;
   * before calling the normal completer */

! static char **
! flex_complete(char *text, int start, int end)
  {
        Py_XDECREF(begidx);
        Py_XDECREF(endidx);
        begidx = PyInt_FromLong((long) start);
        endidx = PyInt_FromLong((long) end);
!       return completion_matches(text, *on_completion);
  }











----------------------------------------------------------------------

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 19:44

Message:
Logged In: YES 
user_id=150999

My readline version is 4.3

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-04-29 13:44

Message:
Logged In: YES 
user_id=21627

What is your readline version?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 10:17:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 01:17:52 -0800
Subject: [ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run after
	test_openpty
Message-ID: <E1FB7B2-0006HT-Eh@sc8-sf-web2.sourceforge.net>

Bugs item #713169, was opened at 2003-04-01 09:35
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_pty fails on HP-UX and AIX when run after test_openpty

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src &gt; ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File &quot;Lib/test/test_pty.py&quot;, line 58, in ?
    test_basic_pty()
  File &quot;Lib/test/test_pty.py&quot;, line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File &quot;Lib/test/test_pty.py&quot;, line 50, in handle_sig
    raise TestFailed, &quot;isatty hung&quot;
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-01-25 17:29

Message:
Logged In: YES 
user_id=987664

This happens with Python 2.4 on Tru64Unix V5.1 when
compiling using gcc-3.4.3, but not if you use the vendor cc.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 10:30

Message:
Logged In: YES 
user_id=200117

This still happens with Python-2.4.0a1 on HP-UX11i


----------------------------------------------------------------------

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 18:22

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:31

Message:
Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 12:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 10:18:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 01:18:23 -0800
Subject: [ python-Bugs-1367183 ] inspect.getdoc fails on objs that use
	property for __doc__
Message-ID: <E1FB7BX-0006HY-6k@sc8-sf-web2.sourceforge.net>

Bugs item #1367183, was opened at 2005-11-26 22:42
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Drew Perttula (drewp)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: inspect.getdoc fails on objs that use property for __doc__

Initial Comment:
inspect.getdoc has these lines:

     if not isinstance(doc, types.StringTypes):
         return None

which interfere with the case where __doc__ is some
other thing that has a good __str__. I wanted to make a
lazy __doc__ that did an expensive lookup of some
external documentation only when it was str()'d, but
since doc displayers often (correctly) use
inspect.getdoc, they were getting None.

I think the intention of the test in getdoc() is to
avoid trying string operations on a __doc__ that is
None. I think that a more lenient version would allow
me to do my fancy docstrings but still solve the
'__doc__ is None' problem. Please consider the
following patch:

if doc is None:
     return None
doc = str(doc)



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 09:21

Message:
Logged In: YES 
user_id=1188172

I don't know. Neal, do you have an opinion about property
docstrings?

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2006-02-01 12:35

Message:
Logged In: YES 
user_id=1344176

It's not a good idea to use properties for __doc__:

"""
>>> class Foo(object):
...    def _get(self):
...        return 'the docstring'
...    __doc__ = property(_get)
...
>>> print Foo().__doc__
the docstring
>>> print Foo.__doc__
<property object at 0xb7b3a234>
>>>
"""

In this light, I don't view inspect.getdoc's lack of support
for __doc__-as-property as a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 10:31:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 01:31:32 -0800
Subject: [ python-Bugs-818490 ] socketmodule.c compile error using SunPro cc
Message-ID: <E1FB7OG-0005A8-Hh@sc8-sf-web5.sourceforge.net>

Bugs item #818490, was opened at 2003-10-06 10:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818490&group_id=5470

Please note that this 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.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Rick Ratzel (rlratzel)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c compile error using SunPro cc

Initial Comment:

   If the _socket module is to be included in
libpython.a rather than built as a shared lib (by
specifying it in Modules/Setup.local under a *static*
line), compile errors result on SunOS 5.7 using the Sun
WorkShop 6 compiler.  Undefined symbol &quot;AF_INET6&quot; on
line 2972 and undefined symbol &quot;INET_ADDRSTRLEN&quot; on
3016 are a few of the errors...please see the attached
output file.

   Note that the configure process completed successfully.

   Here is some additional info:

Python version: 2.3.2
&quot;uname -a&quot; output: SunOS blueberry 5.7
Generic_106541-15 sun4u sparc SUNW,Ultra-60
compiler version: Sun WorkShop 6 update 1 C 5.2 2000/09/11


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:31

Message:
Logged In: YES 
user_id=1188172

Duplicate of #854823.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818490&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 10:44:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 01:44:31 -0800
Subject: [ python-Bugs-854823 ] Python-2.3.3c1,
	Solaris 2.7: socketmodule does not compile
Message-ID: <E1FB7ap-0005Bk-RS@sc8-sf-web5.sourceforge.net>

Bugs item #854823, was opened at 2003-12-05 17:01
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=854823&group_id=5470

Please note that this 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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Falko Sauermann (fsm2761)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.3.3c1, Solaris 2.7: socketmodule does not compile

Initial Comment:
Compiling Python-2.3.3c1 on Solaris 2.7 with gcc 2.95.3
gave me two errors:

socketmodule.c:2975: `AF_INET6' undeclared (first use
in this function)

socketmodule.c:3019: `INET_ADDRSTRLEN' undeclared
(first use in this function)

The first problem was already reported for Solaris 2.7
with SunPro cc (see item 814613) but is also true for
Solaris 2.7 with gcc.

The real problem is that AF_INET6 is used when
ENABLE_IPV6 is undefined. I believe this must fail for
any system where IPV6 is not avalilable.

The second problem was already reported for Irix (see
item 818490) but is also true for Solaris 2.7. The
solution for Irix is also valid for Solaris. If I
change socketmodule.c line 204 to:

#if (defined(__sgi) || defined(sun)) &amp;&amp;
!defined(INET_ADDRSTRLEN)

the error is gone.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:44

Message:
Logged In: YES 
user_id=1188172

Fixed in revisions 42509, 42510.

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-10-20 19:52

Message:
Logged In: YES 
user_id=246063

Okay, here are my results:

Python 2.3.3 and 2.3.4 both give errors about both AF_INET6
and INET_ADDRSTRLEN being undeclared. The line numbers are
different, but everything else is the same. The specific
errors from the 2.3.4 install are:

socketmodule.c:2979: `AF_INET6' undeclared (first use in
this function)
socketmodule.c:3023: `INET_ADDRSTRLEN' undeclared (first use
in this function)


Python 2.4b1 only gives an error about INET_ADDRSTRLEN:

socketmodule.c:3350: `INET_ADDRSTRLEN' undeclared (first use
in this function)


The string INET_ADDRSTRLEN did not appear anywhere in the
files under /usr/include on this system.

In the 2.4b1 tree, if I just #define INET_ADDRSTRLEN to 16,
as hinted by Lib/plat-sunos5/IN.py, then socketmodule.c
compiles with only minor warnings. I don't know the right
way to get this information into the source file though,
sorry. Also, I'm not sure what a good test would be to
determine whether this value is actually correct.

Because a fresh build of both 2.3.4 and 2.4b1 does not
create the _socket module, I believe this bug should not yet
be closed.

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-10-20 03:11

Message:
Logged In: YES 
user_id=246063

I built and installed both 2.3.3 and 2.3.4, and I get the
same error that I was before. It actually occurs in the
install phase, when building socketmodule.c. This is on
Solaris 2.7 with gcc 2.95.2.

I've run out of time tonight to finish building 2.4b1, but
I'll do that tomorrow and see what happens.

I'm happy to provide the complete or partial build logs if
that would help.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-10-19 03:29

Message:
Logged In: YES 
user_id=33168

Does this problem still exist in 2.3.4 or 2.4b1?  Can this
be closed?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-10-18 04:37

Message:
Logged In: YES 
user_id=33168

Does this problem still exist in 2.3.4 or 2.4b1?  Can this
be closed?

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-02-26 18:23

Message:
Logged In: YES 
user_id=246063

I think it's worth noting that the preprocessor directive
near line 2975 is #ifndef , whereas all other preprocessor
directives in the file that refer to the IPV6 symbol are
#ifdef . In other words, it looks like just that one
directive is a typo. Changing #ifndef to #ifdef fixes it for me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=854823&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 10:46:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 01:46:09 -0800
Subject: [ python-Bugs-854823 ] Python-2.3.3c1,
	Solaris 2.7: socketmodule does not compile
Message-ID: <E1FB7cP-0005Bu-PJ@sc8-sf-web5.sourceforge.net>

Bugs item #854823, was opened at 2003-12-05 17:01
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=854823&group_id=5470

Please note that this 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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Falko Sauermann (fsm2761)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.3.3c1, Solaris 2.7: socketmodule does not compile

Initial Comment:
Compiling Python-2.3.3c1 on Solaris 2.7 with gcc 2.95.3
gave me two errors:

socketmodule.c:2975: `AF_INET6' undeclared (first use
in this function)

socketmodule.c:3019: `INET_ADDRSTRLEN' undeclared
(first use in this function)

The first problem was already reported for Solaris 2.7
with SunPro cc (see item 814613) but is also true for
Solaris 2.7 with gcc.

The real problem is that AF_INET6 is used when
ENABLE_IPV6 is undefined. I believe this must fail for
any system where IPV6 is not avalilable.

The second problem was already reported for Irix (see
item 818490) but is also true for Solaris 2.7. The
solution for Irix is also valid for Solaris. If I
change socketmodule.c line 204 to:

#if (defined(__sgi) || defined(sun)) &amp;&amp;
!defined(INET_ADDRSTRLEN)

the error is gone.

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:46

Message:
Logged In: YES 
user_id=1188172

Fixed in revisions 42509, 42510.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:44

Message:
Logged In: YES 
user_id=1188172

Fixed in revisions 42509, 42510.

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-10-20 19:52

Message:
Logged In: YES 
user_id=246063

Okay, here are my results:

Python 2.3.3 and 2.3.4 both give errors about both AF_INET6
and INET_ADDRSTRLEN being undeclared. The line numbers are
different, but everything else is the same. The specific
errors from the 2.3.4 install are:

socketmodule.c:2979: `AF_INET6' undeclared (first use in
this function)
socketmodule.c:3023: `INET_ADDRSTRLEN' undeclared (first use
in this function)


Python 2.4b1 only gives an error about INET_ADDRSTRLEN:

socketmodule.c:3350: `INET_ADDRSTRLEN' undeclared (first use
in this function)


The string INET_ADDRSTRLEN did not appear anywhere in the
files under /usr/include on this system.

In the 2.4b1 tree, if I just #define INET_ADDRSTRLEN to 16,
as hinted by Lib/plat-sunos5/IN.py, then socketmodule.c
compiles with only minor warnings. I don't know the right
way to get this information into the source file though,
sorry. Also, I'm not sure what a good test would be to
determine whether this value is actually correct.

Because a fresh build of both 2.3.4 and 2.4b1 does not
create the _socket module, I believe this bug should not yet
be closed.

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-10-20 03:11

Message:
Logged In: YES 
user_id=246063

I built and installed both 2.3.3 and 2.3.4, and I get the
same error that I was before. It actually occurs in the
install phase, when building socketmodule.c. This is on
Solaris 2.7 with gcc 2.95.2.

I've run out of time tonight to finish building 2.4b1, but
I'll do that tomorrow and see what happens.

I'm happy to provide the complete or partial build logs if
that would help.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-10-19 03:29

Message:
Logged In: YES 
user_id=33168

Does this problem still exist in 2.3.4 or 2.4b1?  Can this
be closed?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-10-18 04:37

Message:
Logged In: YES 
user_id=33168

Does this problem still exist in 2.3.4 or 2.4b1?  Can this
be closed?

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-02-26 18:23

Message:
Logged In: YES 
user_id=246063

I think it's worth noting that the preprocessor directive
near line 2975 is #ifndef , whereas all other preprocessor
directives in the file that refer to the IPV6 symbol are
#ifdef . In other words, it looks like just that one
directive is a typo. Changing #ifndef to #ifdef fixes it for me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=854823&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:15:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:15:40 -0800
Subject: [ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform?
Message-ID: <E1FB84y-0006Nl-SA@sc8-sf-web2.sourceforge.net>

Bugs item #1212703, was opened at 2005-06-01 15:05
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470

Please note that this 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: Pending
Resolution: None
Priority: 5
Submitted By: Vincent Jamart (ranma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 CVS broken for HP-UX platform?

Initial Comment:
While trying to compile Python 2.5 from the nighlty CVS
image, it raises the following errors on HP-UX. (OS
version= HP-UX 11.22 on ia64, compiler= aCC: HP
aC++/ANSI C B3910B A.06.00 [Aug 25 2004])

Compilation flags:
export CC=aCC
export CFLAGS="-Ae +DD64"
export LDFLAGS="+DD64"
make clean
./configure --prefix=/usr/local/python_cvs --with-cxx=aCC


(...)
creating Makefile
        aCC -c  -DNDEBUG -O  -I. -I./Include  
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline truncate(const char *a, off_t b)       { return
__truncate64(a,b); }
         ^
 
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline prealloc(int a, off_t b)               { return
__prealloc64(a,b); }
         ^
 
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline lockf(int a, int b, off_t c)           { return
__lockf64(a,b,c); }
         ^
 
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline ftruncate(int a, off_t b)              { return
__ftruncate64(a,b); }
         ^
 
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
       inline lstat __((const char *, struct stat *));
              ^
 
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
          definition appears wrong for platform (bad
gcc/glibc
config?)."
  #error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
   ^
 
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
 
Stop.
        aCC -c  -DNDEBUG -O  -I. -I./Include  
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline truncate(const char *a, off_t b)       { return
__truncate64(a,b); }
         ^
 
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline prealloc(int a, off_t b)               { return
__prealloc64(a,b); }
         ^
 
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline lockf(int a, int b, off_t c)           { return
__lockf64(a,b,c); }
         ^
 
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
  inline ftruncate(int a, off_t b)              { return
__ftruncate64(a,b); }
         ^
 
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
          type is nonstandard ("int" assumed)
       inline lstat __((const char *, struct stat *));
              ^
 
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
          definition appears wrong for platform (bad
gcc/glibc
config?)."
  #error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
   ^
 
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
 
Stop.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-09-20 08:32

Message:
Logged In: YES 
user_id=29957

As far as I know, the patches contributed by Elemental
Security make current CVS HEAD work fine on ia64 HP/UX.
Please do test them, though - I think Guido put some notes
in the toplevel README about how to get the build to work.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-20 08:21

Message:
Logged In: YES 
user_id=33168

I think there was a fix checked in recently to address some
(hopefully all) of these issues.  Does the current CVS build
on your HPUX box?

----------------------------------------------------------------------

Comment By: Vincent Jamart (ranma)
Date: 2005-06-29 08:50

Message:
Logged In: YES 
user_id=150220

This is how we managed to solve the problem here, but it's
not a clean solution:

#install script for HP-UX 11.xx
CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include"
export CPPFLAGS
CC="/opt/aCC/bin/aCC -Ae +DD64"
export CC
CFLAGS="-Ae +DD64"
export CFLAGS
CXX="/opt/aCC/bin/aCC -Ae"
export CXX
CXXFLAGS="-Ae +DD64"
export CXXFLAGS
LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
export LDFLAGS
cd dist/src
#
# Do not use the --without-gcc flag because the CC env.var.
will be
# reset to 'cc' (which do not want)
# Additionally we're not using --with-cxx because we want
the system to use
# the CC as it is defined above. The reason is that
apparantly CFLAGS is not
# taken into account thus all options should go into the
definition of CC
#
./configure --prefix=/usr/local/python --without-threads
#
# Finally after the configure we need to edit the resulting
Makefile
# by hand because 'ld' will be used to link the extension
modules. However
# 'ld' does not know the '+DD64' flag and we should link
with aCC instead.
# However there is no way to ask 'configure' to link with
aCC instead of ld.

----------------------------------------------------------------------

Comment By: Vincent Jamart (ranma)
Date: 2005-06-28 17:05

Message:
Logged In: YES 
user_id=150220

This is how we managed to solve the problem here, but it's
not a clean solution:

#install script for HP-UX 11.xx
CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include"
export CPPFLAGS
CC="/opt/aCC/bin/aCC -Ae +DD64"
export CC
CFLAGS="-Ae +DD64"
export CFLAGS
CXX="/opt/aCC/bin/aCC -Ae"
export CXX
CXXFLAGS="-Ae +DD64"
export CXXFLAGS
LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
export LDFLAGS
cd dist/src
#
# Do not use the --without-gcc flag because the CC env.var.
will be
# reset to 'cc' (which do not want)
# Additionally we're not using --with-cxx because we want
the system to use
# the CC as it is defined above. The reason is that
apparantly CFLAGS is not
# taken into account thus all options should go into the
definition of CC
#
./configure --prefix=/usr/local/python --without-threads
#
# Finally after the configure we need to edit the resulting
Makefile
# by hand because 'ld' will be used to link the extension
modules. However
# 'ld' does not know the '+DD64' flag and we should link
with aCC instead.
# However there is no way to ask 'configure' to link with
aCC instead of ld.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-06-19 11:01

Message:
Logged In: YES 
user_id=29957

It's not clear from your message - did you find a fix for
this? It seems like this should be closed as notabug...



----------------------------------------------------------------------

Comment By: Vincent Jamart (ranma)
Date: 2005-06-16 12:09

Message:
Logged In: YES 
user_id=150220

We nailed down the problem. 
Apparantly the option "+DD64" is not used by 'make'. 
Nevertheless we added this to CPPFLAGS and CFLAGS. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:17:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:17:23 -0800
Subject: [ python-Bugs-1002465 ] MemoryError on AIX52
Message-ID: <E1FB86d-00067F-Qp@sc8-sf-web3.sourceforge.net>

Bugs item #1002465, was opened at 2004-08-03 10:04
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470

Please note that this 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.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Datranet (richardjmason)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError on AIX52

Initial Comment:
I found the orginal problem when trying to send large 
email attachments on AIX 5.2. I tracked the issue down 
to the fact that a string can only grow to a very 
restricted size on AIX 5.2. bin2ascii fails at the pint the 
function tries to join the list togther to form 1 string.

I wrote the following test program to prove the issue:

a = ''
cnt = 0

while cnt < 1024:
 a = a + 'x'
 cnt += 1

c = ''
cnt = 0

while cnt < 1024:
 c = c + a
 cnt += 1

b = ''
cnt2 = 0

while 1:
   b = b + c
   cnt2 += 1
   print cnt2

On AIX 5.2 you get a MemoryError with a cnt2 value of 
42. I can run the test program on all other platforms and 
get a cnt2 value over 150 before stopping to program 
myself.

I have tried the binary python 2.2 from the IBM site and 
building python 2.3.4 myself using the gcc from the IBM 
site. Both fail with a cnt2 value of 42.

Can anyone please advise on how to get AIX 5.2 to 
allow single objects to have more memory allocated.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 07:23

Message:
Logged In: YES 
user_id=33168

richardjmason, are you still having this problem?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-05 13:59

Message:
Logged In: YES 
user_id=6656

A way this has happened in the past is calling "malloc(0)",
which is entitled to return NULL and Python then thinks this
is a memory error.  This doesn't seeme especially likely
here, though.  Agree with Martin that you're probably going
to need to use a debugger.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-08-04 20:09

Message:
Logged In: YES 
user_id=21627

You need to use a debugger to find the cause of the problem.
What is the string parameter of the MemoryError? This might
give a clue where precisely it is raised.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:22:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:22:06 -0800
Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *=
Message-ID: <E1FB8BC-00027D-Vr@sc8-sf-web1.sourceforge.net>

Bugs item #1355842, was opened at 2005-11-13 11:17
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Armin Rigo (arigo)
Summary: Incorrect Decimal-float behavior for += and *=

Initial Comment:
The += and *= operators have strange behavior when the
LHS is a Decimal and the RHS is a float (as of
2005-11-13 CVS decimal.py).

Example:

>>> d = Decimal('1.02')
>>> d += 2.1
>>> d
NotImplemented

A blatant violation of "Errors should never pass silently."

Also, a bad error description is produced for the *=
operator:

>>> d = Decimal('1.02')
>>> d *= 2.9
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can't multiply sequence by non-int


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2006-02-20 10:22

Message:
Logged In: YES 
user_id=4771

Backported as r42511.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 00:05

Message:
Logged In: YES 
user_id=1188172

The patch was committed and fixed this, but only in SVN
HEAD, not for 2.4.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-12-26 16:31

Message:
Logged In: YES 
user_id=4771

See proposed patch: #1390657

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-22 21:31

Message:
Logged In: YES 
user_id=38388

Hi Facundo,

the problem you are seeing seems to be in the way new-style
classes implement number coercion. 

Apparently some part in the (not so new-style anymore)
coercion logic is masking an exception which then triggers
later during processing. 

The NotImplemented singleton should never make it to the
interactive shell since it is normally only used internally
by the number coercion logic to signal "object method
doesn't handle mixed type operation".


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-12-22 17:10

Message:
Logged In: YES 
user_id=752496

Regarding problem 1:

Nick also detected this behaviour, back in March
(http://mail.python.org/pipermail/python-dev/2005-March/051834.html),
in python-dev discussions about how integrate better the
Decimal behaviour into Python framework.

Even knowing this, Raymond Hettinger and I made a patch
(almost exactly the same), and corrected another behaviour.
Will this issue be resolved somewhen? Raymond said that this
problem is also present in sets.py and datetime objects
(http://mail.python.org/pipermail/python-dev/2005-March/051825.html),
and that should be addressed in a larger context than decimal.

As Neil Schemenauer proposed
(http://mail.python.org/pipermail/python-dev/2005-March/051829.html),
Decimal now returns NotImplemented instead of raise
TypeError, which should be the correct way to deal with
operation capabilities in the numbers.

And look at this:

>>> d
Decimal("1")   # using decimal.py rev. 39328 from svn
>>> d + 1.2
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'Decimal' and
'float'
>>> d += 1.2
>>> d
NotImplemented
>>>

Why this happens? Really don't know, it's beyond my actual
knowledge, I'll keep searching. But I'm not so sure that
this is a Decimal issue.


Regarding problem 2:

I'll fix that.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-22 05:52

Message:
Logged In: YES 
user_id=33168

Facundo, can you look into this?  Are you still working on
Decimal?

----------------------------------------------------------------------

Comment By: Connelly (connelly)
Date: 2005-12-02 06:17

Message:
Logged In: YES 
user_id=1039782

The += and *= operations also give the same strange behavior
when the LHS is a Decimal and the RHS is str or unicode:

>>> d = Decimal("1.0")
>>> d += "5"
>>> d
NotImplemented

>>> d = Decimal("1.0")
>>> d *= "1.0"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can't multiply sequence by non-int


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 04:43

Message:
Logged In: YES 
user_id=33168

Hmmm.  __add__ returns NotImplemented which works with
classic classes, but not new-style classes.  I wonder if
NotImplementedError is supposed to be raised for new-style
classes.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:24:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:24:18 -0800
Subject: [ python-Bugs-872175 ] README build instructions for fpectl
Message-ID: <E1FB8DK-00027g-Ht@sc8-sf-web1.sourceforge.net>

Bugs item #872175, was opened at 2004-01-07 07:15
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872175&group_id=5470

Please note that this 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: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Steve Chaplin (stevech)
Assigned to: Nobody/Anonymous (nobody)
Summary: README build instructions for fpectl

Initial Comment:
configure.in supports the option '--with-fpectl'

However, the "Configuration options and variables"
section in the Python-2.3.3/README file mentions many
options, but does not mention --with-fpectl

I think the README should contain a few lines saying
what the default setting is and why you may want to
switch it on or off.


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:24

Message:
Logged In: YES 
user_id=1188172

Added a note in rev. 42512.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872175&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:25:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:25:21 -0800
Subject: [ python-Bugs-1188231 ] Rebuilding from source on RH9 fails
	(_tkinter.so missing)
Message-ID: <E1FB8EL-00027t-SJ@sc8-sf-web1.sourceforge.net>

Bugs item #1188231, was opened at 2005-04-22 20:21
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Marty Heyman (mheyman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rebuilding from source on RH9 fails (_tkinter.so missing)

Initial Comment:
On a Red Hat 9 system, I downloaded the python2.4-2.4.
1-1pydotorg.src.rpm and, following the web page ran "rpm --rebuild .
..". It went a long for a good long while with no apparent errors and 
then said:

---

RPM build errors:
   File not found by glob: /var/tmp/python2.4-2.4.
1-root/usr/lib/python2.4/lib-dynload/_tkinter.so*

---
I looked in the directory and there is, in fact, no _tkinter.so file(s) 
there. 

--
Marty Heyman

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:25

Message:
Logged In: YES 
user_id=1188172

This looks like it is not Python's fault.

----------------------------------------------------------------------

Comment By: green-ghost (green-ghost)
Date: 2005-07-30 17:35

Message:
Logged In: YES 
user_id=1321225

I had a similar problem compiling python from source on a
(nominally) redhat8 system.  For whatever reason, X11
headers were not installed (probably because it's a server I
only use from an ssh console). YMMV

Try:
apt-get install XFree86-devel
or:
rpm -i XFree86-devel-<correct version for your dist>.rpm

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-05-02 23:16

Message:
Logged In: YES 
user_id=21627

Ah, so it seems you are lacking the X11 header files. They
should have been installed as a dependency on the Tk
headers. So this is either a Redhat bug (for not including a
dependency of the -dev packages) or a local misconfiguration
of some kind (e.g. forcefully installing Tk headers without
all prerequisites present).

----------------------------------------------------------------------

Comment By: Marty Heyman (mheyman)
Date: 2005-04-22 20:42

Message:
Logged In: YES 
user_id=421967

APOLOGIES: ADDITIONAL INFO FOLLOWS 
---Snip from rebuild output follows
In file included from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory
In file included from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tk.h:581: parse error before "Bool"
/usr/include/tk.h:583: parse error before "event"
/usr/include/tk.h:584: parse error before "root"
/usr/include/tk.h:585: parse error before "subwindow"
/usr/include/tk.h:586: parse error before "time"
/usr/include/tk.h:586: `time' redeclared as different kind
of symbol
/usr/include/time.h:184: previous declaration of `time'
/usr/include/tk.h:591: parse error before "same_screen"
--- snip ends
many more "parse error lines occurred after this. I doubt
they're interesting .
A bit later, another group of failures begins
--Snip starts
In file included from /usr/include/tk.h:1361,
                 from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tkDecls.h:37: parse error before '*' token
/usr/include/tkDecls.h:39: parse error before "Tk_3DBorderGC"
/usr/include/tkDecls.h:45: parse error before "Drawable"
/usr/include/tkDecls.h:50: parse error before "Drawable"
/usr/include/tkDecls.h:58: parse error before "XEvent"
--Snip ends
   Again, there are many more similar messages following
those and then:
--Snip starts
/usr/include/tkDecls.h:843: `GC' declared as function
returning a function
... [parse errors]
/usr/include/tkDecls.h:906: `Font' declared as function
returning a function
--Snip ends
There are many such embedded in that group. Then the
messages stop followed by a line that says: "running
build_scripts" ... and things proceed as if all was OK for
hundreds more lines of output before the failure copied into
the original report.

I captured the complete log and can upload it if needed on
request. I'd need to trim it and it doesn't look all that
interesting otherwise but then, what do I know :-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:27:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:27:24 -0800
Subject: [ python-Bugs-1071597 ] configure problem on HP-UX 11.11
Message-ID: <E1FB8GK-0006Oo-3Q@sc8-sf-web2.sourceforge.net>

Bugs item #1071597, was opened at 2004-11-23 11:30
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470

Please note that this 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: Pending
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure problem on HP-UX 11.11

Initial Comment:
Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ 
 
Using gcc 3.3.3 to build on HP-UX 11.11, the  
configure out of the box is a bit off, resulting in a failed build, due 
to missing thread symbols: 
 
/usr/ccs/bin/ld: Unsatisfied symbols: 
   PyThread_acquire_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_exit_thread (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_allocate_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_free_lock (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_start_new_thread (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_release_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_get_thread_ident (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread__init_thread (first referenced in 
libpython2.4.a(thread.o)) (code) 
collect2: ld returned 1 exit status 
 
A workaround is to manually edit pyconfig.h, adding  
#define _POSIX_THREADS 
 
(The reason it is not picked up is that unistd.h on HP-UX has this 
comment: 
 
/************************************************************************ 
 * The following defines are specified in the standard, but are not 
yet 
 * implemented: 
 * 
 *        _POSIX_THREADS                     can't be defined until all 
 *                                           features are implemented 
) 
 
The implementation seems however to be sufficiently complete 
to permit compiling and running Python with _POSIX_THREADS. 
 
While I'm editing pyconfig.h, I also comment out 
_POSIX_C_SOURCE definition, as it will result in lots of 
compilation warnings, of the style: 
 
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I. -I../Python-2.4c1/Include  
-DPy_BUILD_CORE -o 
Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c 
In file included from ../Python-2.4c1/Include/Python.h:8, 
                 from ../Python-2.4c1/Objects/frameobject.c:4: 
pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined 
<command line>:6:1: warning: this is the location of the 
previous definition 
 
------------ 
 
So, to recapitulate:  After configure, add  
#define _POSIX_THREADS 
and comment out 
#define _POSIX_C_SOURCE 200112L 
 
That will give you a Python working rather well,  
with "make test" producing: 
 
251 tests OK. 
1 test failed: 
    test_pty 
38 tests skipped: 
    test_aepack test_al test_applesingle test_bsddb 
test_bsddb185 
    test_bsddb3 test_cd test_cl test_codecmaps_cn 
test_codecmaps_hk 
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw 
test_curses 
    test_dl test_gdbm test_gl test_imgfile test_largefile 
    test_linuxaudiodev test_locale test_macfs test_macostools 
test_nis 
    test_normalization test_ossaudiodev test_pep277 test_plistlib 
    test_scriptpackages test_socket_ssl test_socketserver 
    test_sunaudiodev test_tcl test_timeout test_urllib2net 
    test_urllibnet test_winreg test_winsound 
1 skip unexpected on hp-ux11: 
    test_tcl 
 
 
 

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:27

Message:
Logged In: YES 
user_id=1188172

cbeatley: your problem should be fixed as the pwd module is
now builtin.

OP: do you still have problems with recent releases?

----------------------------------------------------------------------

Comment By: Cameron Beatley (cbeatley)
Date: 2005-06-15 22:18

Message:
Logged In: YES 
user_id=991535

I have the same problems. When I edit the pyconfig.h file as 
described and run Make again, I get the following

Traceback (most recent call last):
  File "./setup.py", line 1184, in ?
    main()
  File "./setup.py", line 1178, in main
    scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle',
  File "/CVS/apps/Python-2.4.1/Lib/distutils/core.py", line 
123, in setup
    dist.parse_config_files()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/dist.py", line 339, 
in parse_config_files
    filenames = self.find_config_files()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/dist.py", line 302, 
in find_config_files
    check_environ()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/util.py", line 155, 
in check_environ
    import pwd
ImportError: No module named pwd
*** Error exit code 1


any idea what THIS is?

----------------------------------------------------------------------

Comment By: Harri Pasanen (harripasanen)
Date: 2005-01-06 12:01

Message:
Logged In: YES 
user_id=77088

Note that the _POSIX_C_SOURCE is also defined for gcc 3.4.3 on 
HP-UX 11.23 (Itanium).   I don't know if it defined for all the gcc 
platforms, as it would only show up if the definition in pyconfig.h is 
different from what the gcc driver uses. 

----------------------------------------------------------------------

Comment By: Harri Pasanen (harripasanen)
Date: 2005-01-05 15:46

Message:
Logged In: YES 
user_id=77088

_POSIX_C_SOURCE appears to come from the gcc driver, along with a 
few other macros. 
 
If I add "-v" to compilation, the output expands to: 
 
Reading specs 
from /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/specs 
Configured 
with: /scratch/zack/pkgbuild/3.3.1/hpux-11/gcc-3.3.3/configure 
--enable-languages=c,c++ --enable-threads=posix --disable-nls 
--with-gnu-as --without-gnu-ld --with-as=/usr/local/bin/as 
--prefix=/usr/local 
Thread model: posix 
gcc version 3.3.3 
 /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/cc1 -quiet -v -I. 
-I./Include -D__GNUC__=3 -D__GNUC_MINOR__=3 
-D__GNUC_PATCHLEVEL__=3 -D_REENTRANT -D_THREAD_SAFE 
-D_POSIX_C_SOURCE=199506L -DNDEBUG -DPy_BUILD_CORE 
Modules/python.c -quiet -dumpbase python.c -auxbase-strip 
Modules/python.o -g -O3 -Wall -Wstrict-prototypes -version 
-fno-strict-aliasing -o /var/tmp//ccLnAhZ0.s 
GNU C version 3.3.3 (hppa2.0w-hp-hpux11.11) 
        compiled by GNU C version 3.3.3. 
GGC heuristics: --param ggc-min-expand=100 --param 
ggc-min-heapsize=131072 
ignoring nonexistent directory 
"/usr/local/hppa2.0w-hp-hpux11.11/include" 
#include "..." search starts here: 
#include <...> search starts here: 
 . 
 Include 
 /usr/local/include 
 /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/include 
 /usr/include 
End of search list. 
In file included from Include/Python.h:8, 
                 from Modules/python.c:3: 
pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined 
<command line>:6:1: warning: this is the location of the previous 
definition 
 /usr/local/bin/as --traditional-format -o 
Modules/python.o /var/tmp//ccLnAhZ0.s 
 

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-12-24 00:50

Message:
Logged In: YES 
user_id=21627

Can you find out why gcc says that "_POSIX_C_SOURCE" is
defined on the command line? On the command line you
provide, it isn't.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:29:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:29:20 -0800
Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses
	Qt moc utility
Message-ID: <E1FB8IC-00068z-D8@sc8-sf-web3.sourceforge.net>

Bugs item #1086854, was opened at 2004-12-17 05:07
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470

Please note that this 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
Submitted By: Jeremy Friesner (jfriesne)
>Assigned to: Martin v. L??wis (loewis)
Summary: "slots" member variable in object.h confuses Qt moc utility

Initial Comment:
This isn't really a Python bug per se, but it's easy to fix so I'm 
filing a bug report anyway.  The problem is with the line  
 
PyObject *name, *slots; 
 
in the definition of struct _heaptypeobject at line 343 of 
Include/object.h.  I'm embedding Python into my app that uses 
the TrollTech Qt GUI, and Qt has a preprocessor program 
named "moc" that looks for certain non-standard keywords.  
 
One of these keywords is the word "slots"... so having a 
member variable named "slots" in Include/object.h confuses 
moc and causes my app to have a build error.  I was able to 
fix the problem by renaming the "slots" member variable to 
"xslots" in the Python source, but it would be nicer if it was 
renamed in the official Python distribution so that the problem 
doesn't come up for the next guy. 
 

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:29

Message:
Logged In: YES 
user_id=1188172

Assigning you again, Martin: should I change the names for 2.5?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-10-02 09:46

Message:
Logged In: YES 
user_id=21627

I would assume that the changes are necessary *only* in
header files, which means that only heaptype is to be changed.

I don't know what happened to the old principle of
protecting struct members against name collisions; I think
if they are to be renamed, their names should be ht_type,
ht_name, ht_slots. (I never understood the rationale for
this convention until this report: there always might be a
collision with a macro name).

Unfortunately, such a change is not so easy as it may sound:
it may break existing applications. Still, I think it should
be done, but only for 2.5.

Unassigning myself.

----------------------------------------------------------------------

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-30 17:38

Message:
Logged In: YES 
user_id=383828

On second thought, I believe mwh is right; most of those
changes are unnecessary.  (I made the changes a long time
ago, so when I grepped for them the other day the memory for
their motivation wasn't fresh).  The Python .c files aren't
fed to moc, so references to 'signals' and 'slots' in the .c
files should compile okay.  It's just the references to
those identifiers in the Python .h files that cause a
problem, if the .h files are #included in a Qt-using C++
program, after #including a Qt header.  So I think probably
just the original three changes are sufficient.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-09-30 10:44

Message:
Logged In: YES 
user_id=6656

I'm not particularly convinced that this is a great idea.  Python uses 'new' 
and 'class' as C identifiers which mean you can't compile it as C++ -- but 
Python isn't written in C++, so this is fine.  Similarly, Python isn't designed 
to be fed to moc -- so why feed it to moc?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-29 22:50

Message:
Logged In: YES 
user_id=1188172

Ah, okay. However, I can't decide whether this will be done,
assigning to Martin for this case.

----------------------------------------------------------------------

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-29 22:48

Message:
Logged In: YES 
user_id=383828

Unfortunately, yes,  When compiling with Qt, the words "signals" 
and "slots" become essentially reserved keywords, and any use of 
them as variable names causes a compile error. 

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-29 22:37

Message:
Logged In: YES 
user_id=1188172

Okay. Most of your replacements are function parameters or
function local variables, do they have to be replaced too?

----------------------------------------------------------------------

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-28 18:59

Message:
Logged In: YES 
user_id=383828

Here is a file containing grep output showing all the lines
where I changed 'slots' to 'xslots' in my codebase:

http://www.lcscanada.com/jaf/xslots.zip

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-28 15:02

Message:
Logged In: YES 
user_id=1188172

I can find 3 occurences in typeobject.c where the variable
would have to be renamed. Can you find any other?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:32:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:32:22 -0800
Subject: [ python-Bugs-1101233 ] test_fcntl fails on netbsd2
Message-ID: <E1FB8L8-0006Pw-Jl@sc8-sf-web2.sourceforge.net>

Bugs item #1101233, was opened at 2005-01-12 22:30
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101233&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Howard (mikeh-id)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_fcntl fails on netbsd2

Initial Comment:
edit line 23 of test_fcntl.py to add 'netbsd2' to the tuple
and it passes

----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:32

Message:
Logged In: YES 
user_id=1188172

Fixed in rev. 42513, 42514.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101233&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 11:32:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 02:32:54 -0800
Subject: [ python-Bugs-1345313 ] Python 2.4 and 2.3.5 won't build on OpenBSD
	3.7
Message-ID: <E1FB8Le-0006Q7-Re@sc8-sf-web2.sourceforge.net>

Bugs item #1345313, was opened at 2005-11-01 22:37
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Dan (catdude)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 and 2.3.5 won't build on OpenBSD 3.7

Initial Comment:
Both Python 2.3.5 and 2.4 fail to build, and both
report the same errors. The output of configure and of
make are attached.


----------------------------------------------------------------------

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:32

Message:
Logged In: YES 
user_id=1188172

I assume this is not Python specific, then?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-11-02 05:10

Message:
Logged In: YES 
user_id=21627

Please report this as a bug to the OpenBSD developers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 12:10:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 03:10:31 -0800
Subject: [ python-Feature Requests-1379573 ] python executable optionally
	should search script on PATH
Message-ID: <E1FB8w3-0002Fq-JS@sc8-sf-web1.sourceforge.net>

Feature Requests item #1379573, was opened at 2005-12-13 16:13
Message generated for change (Comment added) made by cconrad
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Conrad (cconrad)
Assigned to: Nobody/Anonymous (nobody)
Summary: python executable optionally should search script on PATH

Initial Comment:
I've seen that with perl - parameter -S means search
script on path. Very helpful.

----------------------------------------------------------------------

>Comment By: Christoph Conrad (cconrad)
Date: 2006-02-20 12:10

Message:
Logged In: YES 
user_id=21338

(1)

(HKCU|HKLM)\Software\Classes\Python.File\open\command

really is

(HKCU|HKLM)\Software\Classes\Python.File\shell\open\command

(2)

with python 24 a new behaviour occurs: i try to execute the
script on the commandline, but a dialog boy appears with:

the file "[...correct complete path to the script...]" could
not be found. Again, if i prepend python.exe, everything
works as expected. windows 2000 professional.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:14

Message:
Logged In: YES 
user_id=1188172

Do you mean that the registry setting is ok, but the
parameters are not passed correctly?

----------------------------------------------------------------------

Comment By: Christoph Conrad (cconrad)
Date: 2006-02-20 09:12

Message:
Logged In: YES 
user_id=21338

I checked the registry. It's ok. It's windows 2000.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-01-16 22:29

Message:
Logged In: YES 
user_id=21627

That (arguments not passed to the script) was a bug in some
versions of the Windows installer. Please verify that the
registry, at
(HKCU|HKLM)\Software\Classes\Python.File\open\command has
the value '[path]python.exe "%1" %*'. The %* part should
arrange for arguments being passed.

----------------------------------------------------------------------

Comment By: Christoph Conrad (cconrad)
Date: 2006-01-16 11:59

Message:
Logged In: YES 
user_id=21338

> On windows, you should be able to just invoke the_script.py
> (i.e. without a preceding python.exe). Does this not work
> for you?

It works - but command line args are not given to the called
script. If i prepend python.exe, command line args are
transferred correctly.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-01-14 19:34

Message:
Logged In: YES 
user_id=21627

On windows, you should be able to just invoke the_script.py
(i.e. without a preceding python.exe). Does this not work
for you?

----------------------------------------------------------------------

Comment By: Christoph Conrad (cconrad)
Date: 2005-12-15 23:00

Message:
Logged In: YES 
user_id=21338

i meant the windows operating system.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 22:40

Message:
Logged In: YES 
user_id=1188172

I don't know... if the script is in the PATH, isn't it
normally executable too?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 13:15:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 04:15:43 -0800
Subject: [ python-Bugs-1323369 ] getwindowsversion() constants in sys module
Message-ID: <E1FB9x9-0006ig-DC@sc8-sf-web2.sourceforge.net>

Bugs item #1323369, was opened at 2005-10-10 23:44
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323369&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: getwindowsversion() constants in sys module

Initial Comment:
In the documentation for the sys.getwindowsversion()
function, it says that the 'platform' value may be one
of four constants (specifying them by name).

However, these constants are not in the sys module
(they are in win32con from pywin32).

It would be better if either the documentation said
that the constants were available in win32con if
pywin32 is installed, or if the constants were added to
the sys module.

I personally think the latter is better since it's a
single line of code, and makes the getwindowsversion()
function more useful, but I'm not sure whether people
will want to clutter the sys module with four constants.

I'm happy to provide a patch for either behaviour, if
an appropriate developer will choose one.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 12:15

Message:
Logged In: YES 
user_id=849994

I added the numeric values to the docs in rev. 42516, 42517.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323369&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 13:58:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 04:58:08 -0800
Subject: [ python-Bugs-1013800 ] No documentation for PyFunction_* (C-Api)
Message-ID: <E1FBAcC-0005jB-PU@sc8-sf-web5.sourceforge.net>

Bugs item #1013800, was opened at 2004-08-22 14:10
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Henning G?nther (der_eq)
>Assigned to: Georg Brandl (gbrandl)
Summary: No documentation for PyFunction_* (C-Api)

Initial Comment:
I'm missing documentation for the PyFunction_*
api-calls. They don't appear in the documentation but
in
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/funcobject.c?rev=2.66&view=log

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 12:58

Message:
Logged In: YES 
user_id=849994

Added to the docs in rev. 42519.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:26 -0800
Subject: [ python-Bugs-1102649 ] pickle files should be opened in binary mode
Message-ID: <E1FBAq2-0008Gv-Dw@sc8-sf-web6.sourceforge.net>

Bugs item #1102649, was opened at 2005-01-14 21:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Machin (sjmachin)
>Assigned to: Georg Brandl (gbrandl)
Summary: pickle files should be opened in binary mode

Initial Comment:
pickle (and cPickle):

At _each_ mention of the pickle file, the docs should say 
that it should be opened with 'wb' or 'rb' mode as 
appropriate, so that a pickle written on one OS can be 
read reliably on another.

The example code at the end of the section should be 
updated to use the 'b' flag.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 13:12

Message:
Logged In: YES 
user_id=849994

Added a note to the docs in rev. 42520, 42521.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-24 20:08

Message:
Logged In: YES 
user_id=21627

sjmachin, it seems pretty clear what to do now. Would you
volunteer to come up with a patch yourself?

----------------------------------------------------------------------

Comment By: John Machin (sjmachin)
Date: 2005-01-19 13:51

Message:
Logged In: YES 
user_id=480138

Re Fred's question:
Refer to thread starting at 
http://mail.python.org/pipermail/python-dev/2003-
February/033362.html

Looks like the story is like this:

For pickle mode 1 or higher, always use binary mode for 
reading/writing.

For pickle mode 0, either (a) read/write in text mode and if 
moving to another OS, do so in text mode i.e. convert the line 
endings where necessary or (b) as for pickle mode 1+, stick 
with binary throughout.

Also should add a generalisation of Tim's comment re 
NotePad, e.g. something like """A file written with pickle mode 
0 and file mode 'wb' will contain lone linefeeds as line 
terminators. This will cause it to "look funny" when viewed on 
Windows or MacOS as a text file by editors like Notepad that 
do not understand this format."""

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-01-19 13:45

Message:
Logged In: YES 
user_id=31435

Yes, binary mode should always be used, regardless of 
protocol.  Else pickles aren't portable across boxes (in 
particular, Unix can't read a protocol 0 pickle produced on 
Windows if the latter was written to a text-mode file).  "text 
mode" was a horrible name for protocol 0.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-19 05:09

Message:
Logged In: YES 
user_id=3066

In response to irmin's comment:

freopen() is only an option for real file objects; pickles
are often stored or read from other sources.  These other
sources are usually binary to begin with, fortunately,
though this issue probably deserves some real coverage in
the documentation either way.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-19 05:06

Message:
Logged In: YES 
user_id=3066

Is this true in all cases?  Shouldn't files containing text
pickles (protocol 0) be opened in text mode?  (A problem,
given that all protocols should be readable without prior
knowledge of the protocol used to write the pickle.)

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2005-01-16 15:07

Message:
Logged In: YES 
user_id=129426

Can't the pickle code just freopen() the file itself, using
binary mode?

Or is this against Python's rule "explicit is better than
implicit"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:56 -0800
Subject: [ python-Bugs-1395597 ] module os, very small doc inconsistency
Message-ID: <E1FBAqW-0008H9-S0@sc8-sf-web6.sourceforge.net>

Bugs item #1395597, was opened at 2006-01-02 21:58
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&group_id=5470

Please note that this 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: Not a Bug
Status: Closed
Resolution: Fixed
Priority: 1
Submitted By: tiissa (tiissa)
>Assigned to: Georg Brandl (gbrandl)
Summary: module os, very small doc inconsistency

Initial Comment:
In the description of function mknod of module os, the 
name of the node is called "filename", whereas the 
argument of mknod in the prototype is called "path".

I join a patch changing path in filename (to be 
consistent with the inline doc).

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-02 22:07

Message:
Logged In: YES 
user_id=1188172

I love priority 1 bugs!

Corrected in revision 41881, 41882.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:57 -0800
Subject: [ python-Bugs-1306449 ] PyString_AsStringAndSize() return value
	documented wrong
Message-ID: <E1FBAqX-0008HO-8Z@sc8-sf-web6.sourceforge.net>

Bugs item #1306449, was opened at 2005-09-28 03:37
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Gregory Bond (gnbond)
>Assigned to: Georg Brandl (gbrandl)
Summary: PyString_AsStringAndSize() return value documented wrong

Initial Comment:
The C/C++ API document (latest version from docs.python.org) has:

	int PyString_AsStringAndSize(	PyObject *obj, char **buffer, int 
*length)
	[snip]

 	If string is not a string object at all, PyString_AsString() returns NULL 
and raises TypeError.

But the code returns -1 (Objects/stringobject.c line 728ff in my 2.3.4 
source):

                {
                        PyErr_Format(PyExc_TypeError,
                                     "expected string or Unicode object, "
                                     "%.200s found", obj->ob_type->tp_name);
                        return -1;
                }


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-28 12:53

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/api/concrete.tex r1.67,
1.58.2.4.

----------------------------------------------------------------------

Comment By: Gregory Bond (gnbond)
Date: 2005-09-28 06:05

Message:
Logged In: YES 
user_id=293157

Fix the summary!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:57 -0800
Subject: [ python-Bugs-1281408 ] Py_BuildValue k format units don\'t work with
	big values
Message-ID: <E1FBAqX-0008HT-DT@sc8-sf-web6.sourceforge.net>

Bugs item #1281408, was opened at 2005-09-03 22:12
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Py_BuildValue k format units don\'t work with big values

Initial Comment:
Python 2.4 on Windows XP SP2

Consider this code:

unsigned long x = 0xaabbccdd;
PyObject* v = Py_BuildValue("k", x);
unsigned long y = PyLong_AsUnsignedLong(v);

y will be equal with -1 because PyLong_AsUnsignedLong
will raise an OverflowError since Py_BuildValue doesn't
create a long for the "k" format unit, but an int which
will be interpreted as a negative number.

The K format seems to have the same error,
PyLong_FromLongLong is used instead of
PyLong_FromUnsignedLongLong.

The do_mkvalue function from mod_support.c must be
fixed to use PyLong_FromUnsignedLong instead of
PyInt_FromLong for "k".

Also, the BHLkK  format units for Py_BuildValue should
be documented. In my Python 2.4 manual they do not appear.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-24 15:39

Message:
Logged In: YES 
user_id=1188172

Corrected patch committed in rev. 41527 and 41528 (2.4).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-11-13 10:31

Message:
Logged In: YES 
user_id=21627

The patch looks wrong: for 'I' (capital i), you va_arg
unsigned long; I think 'I' should do unsigned int instead.

A minor nit: why does it move the 'l' case (lower L)?

Apart from that, the patch looks fine.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-11 08:45

Message:
Logged In: YES 
user_id=1188172

Ping!

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-18 10:07

Message:
Logged In: YES 
user_id=1188172

Attaching patch (including doc changes). For I and k, it
creates an int if it fits, else a long.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-18 08:59

Message:
Logged In: YES 
user_id=21627

I'm not sure what it should do: the other option would be to
create an int if it fits, else a long. For 2.4.x atleast,
this would give better backwards compatibility given the
status quo.

I certainly agree that the documentation should be updated.
Patches are welcome.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-14 20:02

Message:
Logged In: YES 
user_id=1188172

I think you're right. Do you too, Martin?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:56 -0800
Subject: [ python-Bugs-1394868 ] doc errata
Message-ID: <E1FBAqW-0008HE-Vh@sc8-sf-web6.sourceforge.net>

Bugs item #1394868, was opened at 2006-01-01 16:53
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394868&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Chad Whitacre (whit537)
>Assigned to: Georg Brandl (gbrandl)
Summary: doc errata

Initial Comment:
lib/node235.html -- opened as a text files
lib/module-logging.html -- an event, an LogRecord instance
lib/typessseq-strings.html -- The length modifier may
be h, l, and L may be present
lib/bltin-file-objects.html -- possibilities include
that file may

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-01 21:36

Message:
Logged In: YES 
user_id=1188172

Thanks for pointing them out, fixed in rev. 41862/41863.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394868&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:57 -0800
Subject: [ python-Bugs-1274828 ] splitunc not documented
Message-ID: <E1FBAqX-0008HY-Gh@sc8-sf-web6.sourceforge.net>

Bugs item #1274828, was opened at 2005-08-27 21:40
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274828&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Poor Yorick (pooryorick)
>Assigned to: Georg Brandl (gbrandl)
Summary: splitunc not documented

Initial Comment:
a description of splitunc is missing from

http://docs.python.org/lib/module-os.path.html

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-14 20:42

Message:
Logged In: YES 
user_id=1188172

Interesting, since splitunc() is mentioned in the chapter
heading :)

Added a description in Doc/lib/libposixpath.tex r1.43,
r1.40.2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274828&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:57 -0800
Subject: [ python-Bugs-1266296 ] Mistakes in decimal.Context.subtract
	documentation
Message-ID: <E1FBAqX-0008Hi-Rb@sc8-sf-web6.sourceforge.net>

Bugs item #1266296, was opened at 2005-08-22 15:43
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266296&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jim Sizelove (jsizelove)
>Assigned to: Georg Brandl (gbrandl)
Summary: Mistakes in decimal.Context.subtract documentation

Initial Comment:
The subtract method of the decimal.Context object is
misspelled as
    substract
in the online html documentation for the decimal
module, section 5.6.3.


At the Python interactive prompt:
>>> import decimal
>>> help(decimal.Context.subtract)
Help on method subtract in module decimal:

subtract(self, a, b) unbound decimal.Context method
    Return the sum of the two operands.
    <snip doctest examples>

That description should read:
    Returns the difference between a and b.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-22 19:36

Message:
Logged In: YES 
user_id=1188172

Thank you for the report; fixed in 2.5 and 2.4 branches as

Doc/lib/libdecimal.tex; 1.29; 1.24.2.4
Lib/decimal.py; 1.39; 1.31.2.5
Misc/cheatsheet; 1.11; 1.10.2.1


----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-08-22 18:27

Message:
Logged In: YES 
user_id=671362

Same here ::
  ./Misc/cheatsheet:      x+y  x-y       addition, substraction

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266296&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:57 -0800
Subject: [ python-Bugs-1316162 ] Segmentation fault with invalid \"coding\"
Message-ID: <E1FBAqX-0008HJ-4N@sc8-sf-web6.sourceforge.net>

Bugs item #1316162, was opened at 2005-10-07 20:24
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&group_id=5470

Please note that this message 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: Out of Date
Priority: 7
Submitted By: Humberto Di?genes (virtualspirit)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Segmentation fault with invalid \"coding\"

Initial Comment:
Reproducing the bug:
1. Create a file with a invalid encoding such as:
# -*- coding: utf-8i -*-

2. Run it:
python wrong_coding.py

3. Enjoy your segfault... :P

Versions tested:
 - Python 2.4.2 (Ubuntu Breezy)
 - Python 2.3.5 (Debian Sarge)


Running it directly with "python -c" gives MemoryError. Strace output:

# strace python -c "# -*- coding: utf-8i -*-"
(lots of searching through modules...)
open("/usr/lib/python2.3/site-packages/ZopePageTemplates/utf_8i.
pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or 
directory)
write(2, "MemoryError", 11MemoryError)             = 11
write(2, "\n", 1
)                       = 1
rt_sigaction(SIGINT, NULL, {0x400297a0, [], SA_RESTORER, 
0x400c16f8}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
exit_group(1)                           = ?


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-10-08 16:23

Message:
Logged In: YES 
user_id=1188172

You're right, I hadn't updated my CVS lately.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-08 07:21

Message:
Logged In: YES 
user_id=33168

Are you sure you can reproduce with 2.4 CVS branch.  I just
fixed this recently (Fix segfault with invalid coding. in
Misc/NEWS).  I can't reproduce on 2.4 CVS.  I expect this
probem exists in 2.4.2 and earlier. Checked in around
2005/10/02 at 01:48:49, bug #772896.

The memory error was fixed in CVS, but not backported. 
That's up to Anthony (release manager).

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-10-08 06:24

Message:
Logged In: YES 
user_id=1188172

Reproducable here with 2.4.2 and the 2.4 CVS branch. It
seems fixed in HEAD.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:57 -0800
Subject: [ python-Bugs-1266283 ] lexists() is not exported from os.path
Message-ID: <E1FBAqX-0008Hn-Ut@sc8-sf-web6.sourceforge.net>

Bugs item #1266283, was opened at 2005-08-22 15:21
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266283&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Blais (blais)
>Assigned to: Georg Brandl (gbrandl)
Summary: lexists() is not exported from os.path

Initial Comment:
I'm not quite sure if this is desired, but looking at
posixpath.py it looks like a bug:  lexists() is not in
__all__, and so

from os.path import *
...
lexists(...)

does not work.



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-22 18:08

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in 2.5 and 2.4 branches as

Lib/macpath.py; 1.52; 1.50.2.1
Lib/ntpath.py; 1.63; 1.61.2.1
Lib/os2emxpath.py; 1.15; 1.13.2.1
Lib/posixpath.py; 1.75; 1.73.2.2



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266283&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:57 -0800
Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning
Message-ID: <E1FBAqX-0008Hd-LX@sc8-sf-web6.sourceforge.net>

Bugs item #1274069, was opened at 2005-08-26 14:25
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Georg Brandl (gbrandl)
Summary: bz2module.c compiler warning

Initial Comment:
On Python HEAD, there's a new warning while 
compiling bz2module.c (MSVC 7.1):

python\Modules\bz2module.c(1095) : warning 
C4244: '=' :
   conversion from 'Py_off_t' to 'int', possible loss of data

Looks like a legitimate complaint to me.  The line in 
question:

	readsize = offset-bytesread;

Those have types int, Py_off_t, and int respectively.  Is 
it true that offset-bytesread _necessarily_ fits in an int?  
If so, a comment should explain why, and a cast should 
be added to squash the warning.  Or If the difference 
doesn't necessarily fit in an int, the code is wrong.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-03 07:50

Message:
Logged In: YES 
user_id=1188172

Applied the newest patch. The warnings should be gone now.
bz2module.c r1.26, 1.23.2.3.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-27 17:52

Message:
Logged In: YES 
user_id=80475

The new patch works fine on this end.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-08-27 17:13

Message:
Logged In: YES 
user_id=31435

Raymond, did you read the error output and verify that you're 
not suffering from the sample3.bz2 problem it explains?

"""
All six of the fc's should find no differences.
If fc finds an error on sample3.bz2, this could be
because WinZip's 'TAR file smart CR/LF conversion'
is too clever for its own good. Disable this option.
The correct size for sample3.ref is 120,244. If it
is 150,251, WinZip has messed it up.
"""

Since the error you saw did come from sample3.bz2, that 
would be a good thing to check ;-)

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-27 17:02

Message:
Logged In: YES 
user_id=1188172

Tackled the two warnings (tell() should return a long int if
64 bits) with new patch.

I can't see the error in your output.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-27 16:31

Message:
Logged In: YES 
user_id=80475

The latest patch gives me the following:

--------------------Configuration: bz2 - Win32
Debug--------------------
Compiling...
bz2module.c
C:\py25\Modules\bz2module.c(1143) : warning C4244:
'function' : conversion from '__int64 ' to 'long ', possible
loss of data
C:\py25\Modules\bz2module.c(1143) : warning C4761: integral
size mismatch in argument; conversion supplied
 lib /out:libbz2.lib blocksort.obj   huffman.obj    
crctable.obj    randtable.obj   compress.obj   
decompress.obj  bzlib.obj
Microsoft (R) Library Manager Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
 cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2
bzip2.c libbz2.lib setargv.obj
bzip2.c
 cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o
bzip2recover bzip2recover.c
bzip2recover.c
 type words1
Doing 6 tests (3 compress, 3 uncompress) ...
If there's a problem, things might stop at this point.
 
 .\\bzip2 -1  < sample1.ref > sample1.rb2
 .\\bzip2 -2  < sample2.ref > sample2.rb2
 .\\bzip2 -3  < sample3.ref > sample3.rb2
 .\\bzip2 -d  < sample1.bz2 > sample1.tst
 .\\bzip2 -d  < sample2.bz2 > sample2.tst
 .\\bzip2 -ds < sample3.bz2 > sample3.tst
All six of the fc's should find no differences.
If fc finds an error on sample3.bz2, this could be
because WinZip's 'TAR file smart CR/LF conversion'
is too clever for its own good. Disable this option.
The correct size for sample3.ref is 120,244. If it
is 150,251, WinZip has messed it up.
 fc sample1.bz2 sample1.rb2
Comparing files sample1.bz2 and sample1.rb2
FC: no differences encountered
 fc sample2.bz2 sample2.rb2
Comparing files sample2.bz2 and sample2.rb2
FC: no differences encountered
 fc sample3.bz2 sample3.rb2
Comparing files sample3.bz2 and sample3.rb2
****** sample3.bz2
BZh31AY&SY??3?
??uU???`??2     ???I%@?
??????^??1 ????????????)????al?Dh3H???\mIL?hii??B?R?

****** sample3.rb2
BZh31AY&SY???>
?#
?A?J3?????z???7U?{??C2 
?l
}???
******
 fc sample1.tst sample1.ref
Comparing files sample1.tst and sample1.ref
FC: no differences encountered
 fc sample2.tst sample2.ref
Comparing files sample2.tst and sample2.ref
FC: no differences encountered
 fc sample3.tst sample3.ref
Comparing files sample3.tst and sample3.ref
FC: no differences encountered
Linking...

bz2_d.pyd - 1 error(s), 2 warning(s)


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-27 14:36

Message:
Logged In: YES 
user_id=1188172

Okay, next try. Someone with Windows should check this
before I check in.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-08-27 12:55

Message:
Logged In: YES 
user_id=21627

As Tim says: the cast deserves a comment, explaining why it
cannot overflow. Even when readsize is size_t, it might
still overflow, since Py_off_t might be wider than size_t.

Apart from that, the patch looks good - but I can't check
whether it silences the warning on Windows.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-27 12:27

Message:
Logged In: YES 
user_id=1188172

Attaching patch for f->pos and f->size as Py_off_t.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-08-27 10:30

Message:
Logged In: YES 
user_id=21627

Clearly, the difference is bound by buffersize (since, if it
is larger, readsize is set to buffersize). buffersize is
initialized to SMALLCHUNK, which is 8192, and never changed,
so yes, the difference fits to an int an all supported
platforms.

OTOH, the condition of the if statement is bogus:

    if ((size_t)offset-bytesread > buffersize)

offset is of type Py_off_t, which is a 64-bit type on most
platforms. Casting it to size_t causes truncation on 32-bit
platforms.

Furthermore, I think self->pos should be of type Py_off_t,
as it will wrap around for files larger >2GB on 32-bit
platforms; the same for self->size.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-26 15:05

Message:
Logged In: YES 
user_id=1188172

I think declaring readsize as size_t should fix the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:58 -0800
Subject: [ python-Bugs-1262320 ] minidom.py alternate newl support is broken
Message-ID: <E1FBAqY-0008Hs-3F@sc8-sf-web6.sourceforge.net>

Bugs item #1262320, was opened at 2005-08-17 17:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262320&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: John Whitley (jwhitley)
>Assigned to: Georg Brandl (gbrandl)
Summary: minidom.py alternate newl support is broken

Initial Comment:
In minidom.py, class Document and a few other nodes
have hardcoded newlines ('\n') remaining, causing the
"newl" parameter to potentially produce a file with
mixed line endings, e.g. if newl is set to Windows line
endings ("\r\n" ).
A diff follows which fixes all instances of the problem
of which I'm aware.

*** /usr/lib/python2.4/xml/dom/minidom.py.orig	Tue Aug
16 17:38:40 2005
--- /usr/lib/python2.4/xml/dom/minidom.py.new	Tue Aug
16 17:38:40 2005
***************
*** 1286,1292 ****
              writer.write(" [")
              writer.write(self.internalSubset)
              writer.write("]")
!         writer.write(">\n")
  
  class Entity(Identified, Node):
      attributes = None
--- 1286,1292 ----
              writer.write(" [")
              writer.write(self.internalSubset)
              writer.write("]")
!         writer.write(">%s" % newl)
  
  class Entity(Identified, Node):
      attributes = None
***************
*** 1739,1747 ****
      def writexml(self, writer, indent="",
addindent="", newl="",
                   encoding = None):
          if encoding is None:
!             writer.write('<?xml version="1.0" ?>\n')
          else:
!             writer.write('<?xml version="1.0"
encoding="%s"?>\n' % encoding)
          for node in self.childNodes:
              node.writexml(writer, indent, addindent,
newl)
  
--- 1739,1747 ----
      def writexml(self, writer, indent="",
addindent="", newl="",
                   encoding = None):
          if encoding is None:
!             writer.write('<?xml version="1.0" ?>%s' %
newl)
          else:
!             writer.write('<?xml version="1.0"
encoding="%s"?>%s' % (encoding,newl))
          for node in self.childNodes:
              node.writexml(writer, indent, addindent,
newl)
  


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 22:14

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Lib/xml/dom/minidom.py
r1.53, 1.52.4.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262320&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:58 -0800
Subject: [ python-Bugs-1261229 ] __new__ is class method
Message-ID: <E1FBAqY-0008Hx-8A@sc8-sf-web6.sourceforge.net>

Bugs item #1261229, was opened at 2005-08-16 18:53
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mike Orr (hierro)
>Assigned to: Georg Brandl (gbrandl)
Summary: __new__ is class method

Initial Comment:
Section 3.3.1 of the Language Reference says,
" __new__() is a static method"

But it's actually a class method since it's first
argument is the class.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-26 12:56

Message:
Logged In: YES 
user_id=1188172

Okay, reverted in Doc/ref/ref3.tex 1.128, 1.121.2.7.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-08-26 09:47

Message:
Logged In: YES 
user_id=6656

Argh!  Confusing as it is, __new__ really *is* a static method:

>>> class C(object):
...  def __new__(cls, name, bases, ns):
...   pass
... 
>>> C.__dict__['__new__']
<staticmethod object at 0x2de9d0>

so please revert this.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 21:57

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/ref/ref3.tex r1.127,
1.121.2.6.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:58 -0800
Subject: [ python-Bugs-1250306 ] incorrect description of range function
Message-ID: <E1FBAqY-0008I2-C9@sc8-sf-web6.sourceforge.net>

Bugs item #1250306, was opened at 2005-08-02 15:01
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250306&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: John Gleeson (jgleeson)
>Assigned to: Georg Brandl (gbrandl)
Summary: incorrect description of range function

Initial Comment:
The description of the behavior of the range function

http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-56

for negative values of step appears to be incorrect:

"if step is negative, the last element is the largest start + i * step 
greater than stop."

This implies that the last element is 'start'.  I think it should say 
'smallest' instead of 'largest'. 

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-03 07:18

Message:
Logged In: YES 
user_id=1188172

Correct. Committed as Doc/lib/libfuncs.tex r1.186, r1.175.2.6.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250306&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:58 -0800
Subject: [ python-Bugs-1243288 ] Misuse of \"it\'s\"  
Message-ID: <E1FBAqY-0008IC-Ke@sc8-sf-web6.sourceforge.net>

Bugs item #1243288, was opened at 2005-07-22 19:19
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243288&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Joanne Bogart (jrbogart)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Misuse of \"it\'s\"  

Initial Comment:
In section 2.3.2 of the Python online reference manual
(http://docs.python.org/ref/id-classes.html)

the text

These names are defined by the interpreter and it's
implementation 

should read

These names are defined by the interpreter and its
implementation.

General rule:  if you can't replace "it's"  by "it is"
and preserve meaning, then "it's" is wrong.

This is so trivial I hesitate to submit it.  On the
other hand, it's a shame that such generally excellent
documentation should be marred by this kind of thing.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-22 19:48

Message:
Logged In: YES 
user_id=1188172

This was already corrected in CVS HEAD. Committed to
r24-maint as ref2.tex r1.56.2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243288&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:58 -0800
Subject: [ python-Bugs-1243192 ] Incorrect documentation of re.UNICODE
Message-ID: <E1FBAqY-0008IH-Ng@sc8-sf-web6.sourceforge.net>

Bugs item #1243192, was opened at 2005-07-22 16:20
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243192&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nik Haldimann (nhaldimann)
>Assigned to: Georg Brandl (gbrandl)
Summary: Incorrect documentation of re.UNICODE

Initial Comment:
The effects of the re.UNICODE flag are incorrectly
documented in the library reference. Currently it says
(Section 4.2.3):

<snip>
U
UNICODE
Make \w, \W, \b, and \B dependent on the Unicode
character properties database. New in version 2.0.
</snip>

But this flag in fact also affects \d, \D, \s, and \S
at least since Python 2.1 (I have checked 2.1.3 on
Linux, 2.2.3, 2.3.5 and 2.4 on OS X and the source of
_sre.c makes this obvious). Proof:

Python 2.4 (#1, Feb 13 2005, 18:29:12) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on
darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> not re.match(r"\d", u"\u0966")
True
>>> re.match(r"\d", u"\u0966", re.UNICODE)
<_sre.SRE_Match object at 0x36ee20>
>>> not re.match(r"\s", u"\u2001")
True
>>> re.match(r"\s", u"\u2001", re.UNICODE)
<_sre.SRE_Match object at 0x36ee20>

\u0966 is some Indian digit, \u2001 is an em space.

I propose to change the docs to:

<snip>
U
UNICODE
Make \w, \W, \b, \B, \d, \D, \s, and \S dependent on
the Unicode character properties database. New in
version 2.0.
</snip>

Maybe the documentation of \d, \D, \s, and \S in
section 2.4.1 of the library reference should also be
adapted.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-02 10:30

Message:
Logged In: YES 
user_id=1188172

Thanks! Committed as Doc/lib/libre.tex r1.114, r1.112.2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243192&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:58 -0800
Subject: [ python-Bugs-1238170 ] threading.Thread uses {} as default argument
Message-ID: <E1FBAqY-0008IM-SU@sc8-sf-web6.sourceforge.net>

Bugs item #1238170, was opened at 2005-07-14 12:37
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&group_id=5470

Please note that this 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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
>Assigned to: Georg Brandl (gbrandl)
Summary: threading.Thread uses {} as default argument

Initial Comment:
threading.Thread.__init__ uses {} as default argument
for kwargs,
shouldn't this be the usual
def __init__(...,kwargs=None,...)
....if kwargs is None:
........kwargs = {}

In normal cases, this is probably not a problem but it
makes it possible to f*ck things up.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-15 09:13

Message:
Logged In: YES 
user_id=1188172

Committed as Lib/threading.py r1.49.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-15 08:57

Message:
Logged In: YES 
user_id=80475

This seems reasonable to me.

Reinhold, would you like to do the honors (2.5 only)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:59 -0800
Subject: [ python-Bugs-1234979 ] Lock.acquire treats only 1 as True
Message-ID: <E1FBAqZ-0008IV-7a@sc8-sf-web6.sourceforge.net>

Bugs item #1234979, was opened at 2005-07-08 21:25
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470

Please note that this 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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Chris Perkins (cperkins)
>Assigned to: Georg Brandl (gbrandl)
Summary: Lock.acquire treats only 1 as True

Initial Comment:
Lock.acquire takes an argument indicating whether or
not to block.

On Windows, an argument of 1 (or True) is treated as
True, and any other number is treated as False.

The problem is in PyThread_acquire_lock, in thread_nt.h.

Although I haven't tried it on any other platform,
looking at a random sample (thread_pthread.h and
thread_solaris.h), it looks to me like other platforms
do it right.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-09 15:27

Message:
Logged In: YES 
user_id=1188172

I see. Fixed as Python/thread_wince.h r2.8, r2.7.30.1.

----------------------------------------------------------------------

Comment By: Chris Perkins (cperkins)
Date: 2005-07-09 14:43

Message:
Logged In: YES 
user_id=1142368

It looks like thread_wince.h suffers from the same problem.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-08 22:26

Message:
Logged In: YES 
user_id=1188172

Okay. Committed as Python/thread_nt.h r2.23.10.1, r2.24.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-07-08 22:10

Message:
Logged In: YES 
user_id=31435

birkenfeld, yes we should:  lock.acquire(waitflag) has been 
documented for more than a decade as treating any non-zero 
value as true, so this is a clear bug in thread_nt.h -- if 
someone was, e.g., relying on lock.acquire(2) acting like 
lock.acquire(0) on Windows, tough luck for them.  I'd even 
include this patch in a bugfix release, since the current 
meaning of lock.acquire(2) varies across platforms because 
of this bug, and that's a potentially serious problem.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-08 21:59

Message:
Logged In: YES 
user_id=1188172

Attaching a patch fixing that. Of course, the change is
slightly backwards-incompatible, so should we do that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:59 -0800
Subject: [ python-Bugs-1228904 ] weakref example broken
Message-ID: <E1FBAqZ-0008Ig-GM@sc8-sf-web6.sourceforge.net>

Bugs item #1228904, was opened at 2005-06-28 10:32
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: paolo veronelli (paolo_veronelli)
>Assigned to: Georg Brandl (gbrandl)
Summary: weakref example broken

Initial Comment:
Surely the example in python2.4/lib/weakref-objects.html
 is untested .Bad story.

Attached a working version which I suppose correct it .

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-02 17:49

Message:
Logged In: YES 
user_id=80475

It would be useful to add a testcase cover the examples in
the docs.  See test_itertools.py for an example of how that
is done.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-02 10:45

Message:
Logged In: YES 
user_id=1188172

Fixed in Doc/lib/libweakref.py r1.28, r1.27.4.1.

----------------------------------------------------------------------

Comment By: Peter van Kampen (pterk)
Date: 2005-06-29 19:46

Message:
Logged In: YES 
user_id=174455

I can confirm this (in 2.5a0). It seems untested as it
contains several small errors. I have submitted a doc-patch
with working code that is also a simplified version. See
patch #1229935.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:59 -0800
Subject: [ python-Bugs-1217513 ] Omission in docs for smtplib.SMTP.sendmail()
Message-ID: <E1FBAqZ-0008Iq-MK@sc8-sf-web6.sourceforge.net>

Bugs item #1217513, was opened at 2005-06-09 12:32
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
>Assigned to: Georg Brandl (gbrandl)
Summary: Omission in docs for smtplib.SMTP.sendmail()

Initial Comment:
In Library Reference 11.12.1 SMTP Objects, the
description of the to_addrs parameter to
SMTP.sendmail() is, "a list of RFC 822 to-address strings".

In fact sendmail() also allows a single string to be
passed as to_addrs. The comment in smtplib.py says,
"to_addrs: A list of addresses to send this mail to.  A
barestring will be treated as a list with 1 address."

I suggest the Library Reference be changed to say, "a
list of RFC 822 to-address strings or a single
to-address string"


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 18:25

Message:
Logged In: YES 
user_id=1188172

Fixed by accepting patch #1227442.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:59 -0800
Subject: [ python-Bugs-1225705 ] os.environ documentation should mention
	unsetenv
Message-ID: <E1FBAqZ-0008Il-JQ@sc8-sf-web6.sourceforge.net>

Bugs item #1225705, was opened at 2005-06-22 18:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Brian Wellington (bwelling)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.environ documentation should mention unsetenv

Initial Comment:
The (current) documentation for os.environ says:

---
If the platform supports the putenv() function, this
mapping may be used to modify the environment as well
as query the environment. putenv() will be called
automatically when the mapping is modified.
---

Some platforms (Solaris 8 and 9, at least) have
putenv() but not unsetenv(), which means that setting
environment variables by assigning values in os.environ
works, but unsetting them by deleting from os.environ
doesn't.  This is confusing, and should at least be
documented (if for no other reason than no one else
should waste several hours figuring this out).  This
was tested with Python 2.4.1 and earlier versions.

I'd suggest documenting os.unsetenv() in 6.1.1 (Process
Parameters) of the manual, and modifying the above text
to say something like:

---
If the platform supports the putenv() and unsetenv()
functions, this mapping may be used to modify the
environment as well as query the environment. putenv()
will be called automatically when an entry in the
mapping is added or changed, and unsetenv() will be
called automatically when an entry is deleted.
---

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 18:47

Message:
Logged In: YES 
user_id=1188172

Fixed as Doc/lib/libos.tex r1.158, r1.146.2.4. Thanks for
the report!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:59 -0800
Subject: [ python-Bugs-1235266 ] debug info file descriptor of tarfile is
	inconsistent
Message-ID: <E1FBAqZ-0008IR-1V@sc8-sf-web6.sourceforge.net>

Bugs item #1235266, was opened at 2005-07-09 16:24
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Georg Brandl (gbrandl)
Summary: debug info file descriptor of tarfile is inconsistent

Initial Comment:
"7.19.1 TarFile Objects" says
  The messages are written to sys.stdout.
but they are actually written to sys.stderr ::

  def _dbg(self, level, msg):
      """Write debugging output to sys.stderr.
      """
      if level <= self.debug:
          print >> sys.stderr, msg

There are 2 options:
(a) change document from stdout to stderr.
(b) rewrite the code to use stdout.

Given this is debug messages and most other modules 
use stdout for debug printing(gc is one of the few 
exceptions?), I'm +1 on (b).

[*] http://docs.python.org/lib/tarfile-objects.html


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 07:29

Message:
Logged In: YES 
user_id=1188172

Okay. Checked in Doc/lib/libtarfile.tex r1.10, r1.7.2.1.

And when will be some day?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-12 03:06

Message:
Logged In: YES 
user_id=80475

Just change the docs to match the actual behavior.  Let's
leave the implementation alone.

There is no great need to have tarfile's implementation
match zipfile.  Someday, all of the modules will generate
messages via the logging module and you'll trivially be able
to mask them or redirect them in a consistent manner.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-11 06:19

Message:
Logged In: YES 
user_id=1188172

Attaching patches for both tarfile and zipfile. For tarfile,
the docs are changed to stderr, for zipfile, both docs and
implementation are changed to stderr.

Since I don't assume that someone actually uses the debug
info in some automated way, I think we can correct this in 2.5.

Raymond, please review.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-07-10 16:26

Message:
Logged In: YES 
user_id=671362

OK. I tested some GNU compression/decompression tools 
and comfirmed that they write debugging messages
(displayed in verbose mode(-v)) to stderr.

Now I'm leaning toward Reinhold's idea.

> What about zipfile? 
> Should we print debug info to stderr there, too?

Maybe yes.  I'd be happy to volunteer for that patch.


----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2005-07-10 08:00

Message:
Logged In: YES 
user_id=642936

This is a documentation error. Debug messages must go to
stderr because that's what stderr is for. Think of a script
that writes a tar archive to stdout for use in a unix shell
pipeline. If debug messages went to stdout, too, it would
produce unusable output, because archive data and debug
messages would be mixed.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-09 17:04

Message:
Logged In: YES 
user_id=1188172

The documentation seems to be borrowed from zipfile, where
the statement is true: debug info is written to stdout.

I'm in favour of changing the docs to stderr for tarfile.
What about zipfile? Should we print debug info to stderr
there, too?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:00 -0800
Subject: [ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks
Message-ID: <E1FBAqa-0008J0-0Q@sc8-sf-web6.sourceforge.net>

Bugs item #1213894, was opened at 2005-06-03 00:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ilya Sandler (isandler)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.path.realpath() cannot handle symlinks

Initial Comment:

To reproduce:

Create a link, say to /tmp:

  bagira:~/python> ls -l xxx
  lrwxrwxrwx    1 ilya     ilya            4 2005-06-02
17:09 xxx -> /tmp/

And now:
 
  bagira:~/python> python2.4
  Python 2.4.1 (#2, May  5 2005, 11:32:06) 
  [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
  Type "help", "copyright", "credits" or "license" for
more    
   information.
   >>> import os.path
   >>> os.path.realpath("xxx")
   '/home/ilya/python/xxx'

I'd expect realpath() to return "/tmp"

Note: This bug was reported earlier (e.g bug  990669)
but it was closed as fixed



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 14:32

Message:
Logged In: YES 
user_id=1188172

Fixed, thanks for the report.

Lib/posixpath.py r1.74 r1.73.2.1
Lib/test/test_posixpath.py r1.13 r1.12.2.1

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 11:27

Message:
Logged In: YES 
user_id=80475

Run the full testsuite, then
go ahead an apply the patch.
Be sure to add an entry to Misc/NEWS.



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 08:17

Message:
Logged In: YES 
user_id=1188172

Attaching new test case for this problem.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 07:58

Message:
Logged In: YES 
user_id=1188172

Confirmed. Only occurs when the symlink is the first
directory part of the argument. Attaching fix, assigning to
Raymond to check in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:58 -0800
Subject: [ python-Bugs-1248199 ] shelve .sync operation not documented
Message-ID: <E1FBAqY-0008I7-F3@sc8-sf-web6.sourceforge.net>

Bugs item #1248199, was opened at 2005-07-31 02:53
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248199&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Georg Brandl (gbrandl)
Summary: shelve .sync operation not documented

Initial Comment:
The shelve documentation doesn't describe how to flush
updates out to the disc file.  Without that, a
long-running server could go for months without writing
out any updates.  A server crash would then lose every
update.  I asked on clpy whether shelve really had such
a severe deficiency.  Thanks to Robert Kern for
mentioning the .sync() method, which does what is
needed.  The doc should definitely mention this. 
Shelve is much less useful without it.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 22:40

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/lib/libshelve.py r1.23,
1.20.16.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248199&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:00 -0800
Subject: [ python-Bugs-1210001 ] Typo in \"Differences from mimelib\"
Message-ID: <E1FBAqa-0008J5-46@sc8-sf-web6.sourceforge.net>

Bugs item #1210001, was opened at 2005-05-27 16:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Zumi (zumi001)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Typo in \"Differences from mimelib\"

Initial Comment:
In the online manual:
http://www.python.org/doc/2.4/lib/node577.html
"12.2.12 Differences from mimelib" there's a typo:

"The methodgetmaintype() was renamed to get_main_type()."

Suggestion: a space after the word "method".

So something like this:
"The method getmaintype() was renamed to get_main_type()."

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 10:01

Message:
Logged In: YES 
user_id=1188172

Thanks for the report; committed as Doc/lib/email.tex r1.19,
r1.18.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:59 -0800
Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow
Message-ID: <E1FBAqZ-0008Iv-Ry@sc8-sf-web6.sourceforge.net>

Bugs item #1215928, was opened at 2005-06-06 19:19
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tom Emerson (tree)
>Assigned to: Georg Brandl (gbrandl)
Summary: Large tarfiles cause overflow

Initial Comment:
I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 
million documents. I have a script which opens this file with "r:bz2" 
and is simply iterating over the contents using next(). With 2.4.1 I 
still get an Overflow error (originally tried with 2.3.5 as packaged in 
Mac OS 10.4.1):

Traceback (most recent call last):
  File "extract_part.py", line 47, in ?
    main(sys.argv)
  File "extract_part.py", line 39, in main
    pathnames = find_valid_paths(argv[1], 1024, count)
  File "extract_part.py", line 13, in find_valid_paths
    f = tf.next()
  File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next
    self.fileobj.seek(self.offset)
OverflowError: long int too large to convert to int


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 13:11

Message:
Logged In: YES 
user_id=1188172

I just realized that I accidentally committed the patch
together with the fix for #1191043.

Modules/bz2module r1.25, r1.23.2.2.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-08-25 11:24

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

As for generalising Py_off_t: there are some issues which I
keep forgetting. fpos_t is not guaranteed to be an integral
type, and indeed, on Linux, it is not. I'm not quite
completely sure why this patch works; I think that on all
platforms where fpos_t is not integral, off_t happens to be
large enough. The only case where off_t is not large enough
is (IIRC) Windows, where fpos_t can be used.

So this is all somewhat muddy, and if this gets generalized,
a more elaborate comment seems to be in order.

----------------------------------------------------------------------

Comment By: Viktor Ferenczi (complex)
Date: 2005-06-20 23:44

Message:
Logged In: YES 
user_id=142612

The bug has been reproduced with a 90Mbytes bz2 file containing more than 4Gbytes of fairly similar documents. I've diagnosed the same problem with large offsets. Thanks for the patch.

Platform: WinXP Intel P4, Python 2.4.1

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-18 22:05

Message:
Logged In: YES 
user_id=80475

Martin, please look at this when you get a chance.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-18 21:26

Message:
Logged In: YES 
user_id=1188172

I looked into this a bit further, and noticed the following:

The modules bz2, cStringIO and mmap all use plain integers
to represent file offsets given to or returned by seek(),
tell() and truncate().

They should be corrected to use a 64-bit type when having
large file support. fileobject.c defines an own type for
that, Py_off_t, which should be shared among the other modules.

Conditional compile is needed since different
macros/functions must be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-13 01:32

Message:
Logged In: YES 
user_id=80475

Is there a way to write a test for this?
Can it be done without a conditional compile?
Is the problem one that occurs in other code outside of bz?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-10 11:45

Message:
Logged In: YES 
user_id=1188172

Attaching corrected patch.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-09 20:31

Message:
Logged In: YES 
user_id=1188172

Attaching a patch which mimics the behaviour of normal file
objects. This should resolve the issue on platforms with
large file support.

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2005-06-07 13:23

Message:
Logged In: YES 
user_id=642936

A quick look at the problem reveals that this is a bug in
bz2.BZ2File. The seek() method does not allow position
values >= 2GiB.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:00 -0800
Subject: [ python-Bugs-1202475 ] httplib docs mentioning
	HTTPConnection.getreply
Message-ID: <E1FBAqa-0008JP-QL@sc8-sf-web6.sourceforge.net>

Bugs item #1202475, was opened at 2005-05-15 20:53
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Georg Brandl (gbrandl)
>Assigned to: Georg Brandl (gbrandl)
Summary: httplib docs mentioning HTTPConnection.getreply

Initial Comment:
... instead of getresponse in the description of send().

Also, a general note or explanation like that could be
given before the description of send():

"""
You can send requests in two ways: either using the
request() method as described above, which combines all
request parameters, or using a sequence of
putrequest(), zero or more times addheader(),
endheaders() and then send().
"""

It is sort of confusing in its current state.

Oh yes, and while you're at it ;), you could add a note
that the response object must be read completely before
a new request can be sent.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 19:17

Message:
Logged In: YES 
user_id=1188172

Fixed in Doc/lib/libhttplib.tex r1.39, r1.38.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:00 -0800
Subject: [ python-Bugs-1204734 ] __getattribute__ documentation error?
Message-ID: <E1FBAqa-0008JK-MU@sc8-sf-web6.sourceforge.net>

Bugs item #1204734, was opened at 2005-05-19 05:21
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: John Eikenberry (zhar)
>Assigned to: Georg Brandl (gbrandl)
Summary: __getattribute__ documentation error?

Initial Comment:
>From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html

"Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)."

But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux.

class A(object):

    def __getattr__(self,key):
        print '__getattr__',key
        raise AttributeError,key

    def __getattribute__(self,key):
        print '__getattribute__',key
        raise AttributeError,key

a = A()
a.foo

$ python test.py
__getattribute__ foo
__getattr__ foo
Traceback (most recent call last):
  File "test.py", line 14, in ?
    a.foo
  File "test.py", line 7, in __getattr__
    raise AttributeError(key)
AttributeError: foo

It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't.



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-02 10:30

Message:
Logged In: YES 
user_id=1188172

Checked in my patch as Doc/ref/ref3.tex r1.125, r1.121.2.4.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 10:03

Message:
Logged In: YES 
user_id=1188172

Attached a documentation patch, following Terry's wording.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 17:42

Message:
Logged In: YES 
user_id=593130

If I understand correctly, this revision of the consequent of the 
second sentence (after ',') matches the implementation.

[If the class also defines __getattr__, ]
the latter will not be called unless __getattribute__ either calls it 
explicitly or raises an AttributeError.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-05-26 16:18

Message:
Logged In: YES 
user_id=6380

The implementation works as expected.

The documentation is flawed.

----------------------------------------------------------------------

Comment By: John Eikenberry (zhar)
Date: 2005-05-26 15:52

Message:
Logged In: YES 
user_id=322022

Terry, I started with a much longer subject but decided I
didn't want to overload it to much. Guess I went to far the
other way. I'll try to strike a better balance next time.

Thanks.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 15:43

Message:
Logged In: YES 
user_id=593130

John E: A general title like 'Documentation Error?' discourages 
attention from people with the specialized knowledge needed to 
answer such a question.  I have taken the liberty of trying to 
add '__getattribute__'.  We'll see if the edit works when I, not the 
OP, submits it.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 15:33

Message:
Logged In: YES 
user_id=593130

If the default __getattribute__ explicitly calls __getattr__ (but I 
don't know which source file to check), then the second 
sentence above *would* make some sense.

Guido (or deputy): what is your design intention?

Note: if the second sentence is kept, replacing 'it' with 'the latter' 
would make it clearer. I first read 'it' as referring to 
__getattribute__.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-05-24 09:08

Message:
Logged In: YES 
user_id=4771

I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work.  The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations.  As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called.

----------------------------------------------------------------------

Comment By: John Eikenberry (zhar)
Date: 2005-05-23 18:43

Message:
Logged In: YES 
user_id=322022

Please specify in the documentation whether this is how it
is supposed to work or whether this is a side-effect of the
implementation. To make explicit if you can write code
relying on this 'feature' and not have it break at some point.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-05-23 14:28

Message:
Logged In: YES 
user_id=4771

Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError.  This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class.  This let me think that the error is really in the documentation, which should mention this logic.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:01 -0800
Subject: [ python-Bugs-1192315 ] \'clear -1\' in pdb
Message-ID: <E1FBAqb-0008Jj-Cs@sc8-sf-web6.sourceforge.net>

Bugs item #1192315, was opened at 2005-04-29 10:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Pechkin (mpech)
>Assigned to: Georg Brandl (gbrandl)
>Summary: \'clear -1\' in pdb

Initial Comment:
Delete breakpoints like in %subj% is great feature, but
wrong.
Add additional check like in do_enable()
if not (0 <= i < len(bdb.Breakpoint.bpbynumber)):

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 09:04

Message:
Logged In: YES 
user_id=1188172

Okay, committed as Lib/pdb.py 1.74, 1.73.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 05:04

Message:
Logged In: YES 
user_id=80475

For the print statement, I would have used something simpler:

  print 'No breakpoint numbered', i


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 10:11

Message:
Logged In: YES 
user_id=1188172

Attached patch which implements the check.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:00 -0800
Subject: [ python-Bugs-1196315 ] WeakValueDictionary.__init__ is backwards
Message-ID: <E1FBAqa-0008JU-Uk@sc8-sf-web6.sourceforge.net>

Bugs item #1196315, was opened at 2005-05-06 01:59
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Pavel Pergamenshchik (ppergame)
>Assigned to: Georg Brandl (gbrandl)
Summary: WeakValueDictionary.__init__ is backwards

Initial Comment:
>>> from weakref import WeakValueDictionary as wvd
>>> class A:
...     pass
... 
>>> wvd({1:A()})
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/weakref.py", line 46, in
__init__
    UserDict.UserDict.__init__(self, *args, **kw)
  File "/usr/lib/python2.4/UserDict.py", line 7, in
__init__
    self.update(dict)
  File "/usr/lib/python2.4/weakref.py", line 161, in update
    d[key] = KeyedRef(o, self._remove, key)
AttributeError: WeakValueDictionary instance has no
attribute '_remove'


WeakValueDictionary.__init__ calls UserDict.__init__
first and sets self._remove second. It should do it the
other way around. This is a regression from 2.3.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 09:21

Message:
Logged In: YES 
user_id=1188172

Thanks for the report. Committed as Lib/weakref.py r1.27
r1.26.2.1.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 07:19

Message:
Logged In: YES 
user_id=1188172

Okay to checkin?

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2005-05-11 19:23

Message:
Logged In: YES 
user_id=34901

I would agree that the order is definitely broken.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-05-10 03:36

Message:
Logged In: YES 
user_id=80475

Fred, I believe this was your change (1.23).
The OP's request apprears correct to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:00 -0800
Subject: [ python-Bugs-1207379 ] class property fset not working
Message-ID: <E1FBAqa-0008JF-Fr@sc8-sf-web6.sourceforge.net>

Bugs item #1207379, was opened at 2005-05-23 22:02
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: MartinKirst (master_jaf)
>Assigned to: Georg Brandl (gbrandl)
Summary: class property fset not working

Initial Comment:
Classes which are not instantiated from 'object',
containing properties, are not working as expected. The
GET method is working but not the SET method. Tested
with python 2.4.1 und 2.3.5.
See sample code file.

----------------------------------------------------------------------

Comment By: MartinKirst (master_jaf)
Date: 2005-08-21 20:55

Message:
Logged In: YES 
user_id=1140154

I agree with rhettinger, that there is no need to put
advanced things like properties in the tutorial.

But I still think, that the property explanation in "Python
Lib. Ref."
could be a bit more precise.
IMHO it's not enough to say "Return a property attribute for
new-style classes..." because it does not prohibit
explicitly the usage in "old style classes".

Suggestion:

"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc]]]])
  [....]
New in Python 2.2. Properties only can be applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-21 14:17

Message:
Logged In: YES 
user_id=1188172

What am I to do? Correct the patch and apply, or close this
as Rejected?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 11:35

Message:
Logged In: YES 
user_id=80475

Stay close to the definition in the tutorial's glossary:

"""
new-style class 
Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods. 
"""

Also, the 2.2 comment should be in standard form markup: 
\versionadded{}

"classes" ==> "class"

Overall, -0 on the update.  Ideally, the tutorial should be
kept free of the more advanced concepts like properties,
static methods, descriptors, and whatnot.  

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 10:27

Message:
Logged In: YES 
user_id=1188172

Attaching a patch for the Tutorial. It adds the following
sentence:

+Note that with Python 2.2, a new kind of classes was
introduced:
+A class deriving from \class{object} is called a
\emph{new-style class}.
+The differences to classic classes are mostly internal, but
there are
+some features (like properties and static methods) that are
only
+available for new-style classes.
+


----------------------------------------------------------------------

Comment By: MartinKirst (master_jaf)
Date: 2005-05-26 18:59

Message:
Logged In: YES 
user_id=1140154

>From my point of view (I'm just learning Python) there is only a
simple difference between old and new style classes, just the
(object) while defining a class.
For sure, we can close this. My questions were answered :-)

So my suggestions for adding info to the documentation:

"Python Tutorial": Chap. 9.3., ex.
With Python 2.2 new style classes were introduced. These new 
style classes are inherited from 'object' base class and
supporting
newer features like properties, slots etc.. It is
recommended to use
new style classes.

"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc]]]])
  [....]
New in Python 2.2. Properties only can applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 16:37

Message:
Logged In: YES 
user_id=593130

For people who learned Python with old-style classes, it 
is 'obvious' that properties are a new addition that came with and 
work with new-style classes.  Can you suggest specific places in 
the docs where clarification could be made?  Or should be close 
this?

(I suspect that setting is more complicated than getting but would 
not have expected even the get method to work.)

----------------------------------------------------------------------

Comment By: MartinKirst (master_jaf)
Date: 2005-05-24 12:27

Message:
Logged In: YES 
user_id=1140154

After reading some more documentation I've found at Python
Tutorial "D. Glossary" more hints.
&lt;cite&gt;
Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods.
&lt;/cite&gt;
Fine. OK, understood..
I'm tending to agree with mwh's opinion, that this is a
documentation bug, although I don't fully understand why the
GET descriptor is working but unlikly not the SET descriptor.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-05-24 07:58

Message:
Logged In: YES 
user_id=6656

At the very limit, this is a documentation bug.  Why did you think 
properties could be attached to old-style classes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:01 -0800
Subject: [ python-Bugs-1190563 ] os.waitpid docs don\'t specify return value
	for WNOHANG
Message-ID: <E1FBAqb-0008Jt-S8@sc8-sf-web6.sourceforge.net>

Bugs item #1190563, was opened at 2005-04-26 20:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190563&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: jls (apjenkins)
>Assigned to: Georg Brandl (gbrandl)
>Summary: os.waitpid docs don\'t specify return value for WNOHANG

Initial Comment:
The library documentation for os.waitpid() does not
specify what the return value should be if the
os.WNOHANG flag is given, and the process still hasn't
exited.  

p, v = os.waitpid(pid, os.WNOHANG)

Through trial and error I discovered that in this case,
os.waitpid returns the tuple (0, 0) if pid is still
running.  This should be in the documentation for
os.waitpid().



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 19:55

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/lib/libos.tex r1.160,
r1.146.2.6.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190563&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:02 -0800
Subject: [ python-Bugs-1190204 ] 3.29 site is confusing re site-packages on
	Windows
Message-ID: <E1FBAqc-0008Jy-0x@sc8-sf-web6.sourceforge.net>

Bugs item #1190204, was opened at 2005-04-26 12:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
>Assigned to: Georg Brandl (gbrandl)
Summary: 3.29 site is confusing re site-packages on Windows

Initial Comment:
Library Reference 3.29 site seems to say that
site-packages is only searched on Unix and Mac. The
relevant sentence is in the third paragraph: "For the
tail part, it uses the empty string (on Windows) or it
uses first lib/python2.4/site-packages and then
lib/site-python (on Unixand Macintosh)."

A clearer and more accurate wording would be "For the
tail part, it uses the empty string and lib/site-python
(on Windows) or it uses first
lib/python2.4/site-packages and then lib/site-python
(on Unixand Macintosh)."

The relevant code is line 187 in site.py.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 07:32

Message:
Logged In: YES 
user_id=1188172

Okay, committed as Doc/lib/libsite.tex 1.28, 1.26.4.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 05:10

Message:
Logged In: YES 
user_id=80475

Before you check in doc changes, be sure to spellcheck and use:

    python -m texcheck libsite.tex


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 18:24

Message:
Logged In: YES 
user_id=1188172

Fix attached; okay to checkin?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:02 -0800
Subject: [ python-Bugs-1186072 ] tempnam doc doesn\'t include link to tmpfile
Message-ID: <E1FBAqc-0008K3-6z@sc8-sf-web6.sourceforge.net>

Bugs item #1186072, was opened at 2005-04-19 15:49
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186072&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ian Bicking (ianbicking)
>Assigned to: Georg Brandl (gbrandl)
>Summary: tempnam doc doesn\'t include link to tmpfile

Initial Comment:
Both tmpnam and tempnam include references to tmpfile
(as a preferred way of using temporary files). 
However, they don't include a link to the page where
tmpfile is documented, and it is documented in a
different (non-obvious) section of the ``os`` page.  A
link to the section containing tmpfile would be helpful.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 20:44

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/lib/libos.tex r1.161,
r1.146.2.7.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186072&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:12:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:12:59 -0800
Subject: [ python-Bugs-1232768 ] Mistakes in online docs under \"5.3 Pure
	Embedding\"
Message-ID: <E1FBAqZ-0008Ib-Cq@sc8-sf-web6.sourceforge.net>

Bugs item #1232768, was opened at 2005-07-05 14:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matt Smart (mcsmart)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Mistakes in online docs under \"5.3 Pure Embedding\"

Initial Comment:
I'm looking at the "5.3 Pure Embedding" page:
  http://python.org/doc/2.4.1/ext/pure-embedding.html

1.
  pFunc = PyDict_GetItemString(pDict, argv[2]);
- /* pFun: Borrowed reference */
+ /* pFunc: Borrowed reference */

2.
The code snippet in the section starting with "After initializing the 
interpreter," does not follow the code in the example.  It uses 
PyObject_GetAttrString() instead of PyObject_GetItemString(), 
which creates a new reference instead of borrowing one, and 
therefore needs a Py_XDEREF(pFunc) call that is also not in the 
initial example.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 13:18

Message:
Logged In: YES 
user_id=1188172

Okay. Fixed as Doc/ext/run-func.c r1.4.20.1, r1.5.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 13:12

Message:
Logged In: YES 
user_id=1188172

I thought the same when I first read this report. On this
HTML page, there's the large code sample at the top, and
below are explanations. In the large sample the code with
GetItemString and without Py_XDECREF. Both are OK, but
different, and that's what the reporter's problem was.

But thanks to your digging in the CVS history, I can tell
that the intended code is the second version with GetAttrString.

----------------------------------------------------------------------

Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 12:57

Message:
Logged In: YES 
user_id=174455

Reinhold, I must confess I am confused. I'm trying to
unravel  what goes in in CVS with all the branches. It seems
this was corrected in rev. 1.5 of embedding.tex (from
2002!?). Looking at cvs (HEAD) I also see:

python/dist/src/Doc/ext/embedding.tex (line ~180):

\begin{verbatim}
    pFunc = PyObject_GetAttrString(pModule, argv[2]);
    /* pFunc is a new reference */

    if (pFunc && PyCallable_Check(pFunc)) {
        ...
    }
    Py_XDECREF(pFunc);
\end{verbatim}

This seems to fix the problem? Also looking at 
http://python.org/doc/2.4.1/ext/pure-embedding.html *today*
I don't see 'Borrowed  reference' and but 'a new reference'
and including a PyXDEREF. Am I totally missing the point of
the bug-report or is the time-machine flying again?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 11:35

Message:
Logged In: YES 
user_id=1188172

Only the first part has been fixed. The second is beyond my
decision and must be considered by someone other.

----------------------------------------------------------------------

Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 10:59

Message:
Logged In: YES 
user_id=174455

These seem to have been fixed already in CVS (although I
can't find a duplicate report). Suggest closing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:02 -0800
Subject: [ python-Bugs-1175848 ] poorly named variable in urllib2.py
Message-ID: <E1FBAqc-0008KG-Ou@sc8-sf-web6.sourceforge.net>

Bugs item #1175848, was opened at 2005-04-03 15:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&group_id=5470

Please note that this message 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: Fixed
Priority: 5
Submitted By: Roy Smith (roysmith)
>Assigned to: Georg Brandl (gbrandl)
Summary: poorly named variable in urllib2.py

Initial Comment:
This is kind of trivial, but in urllib2.OpenerDirector.__init__, the local 
variable "server_version" is poorly named.  The name makes it 
sound like it's the version of the HTTP (or whatever) server we're 
talking to.  How about client_version or library_version or 
module_version?


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 22:01

Message:
Logged In: YES 
user_id=1188172

Fixed as of Lib/urllib2.py r1.82.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2005-05-19 19:10

Message:
Logged In: YES 
user_id=261020

My, you're picky. ;-)

Yes, that does seem a poor name, +1 on changing it to
client_version.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:01 -0800
Subject: [ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty
	$HOME
Message-ID: <E1FBAqb-0008Je-9n@sc8-sf-web6.sourceforge.net>

Bugs item #1193849, was opened at 2005-05-02 15:02
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Wummel (calvin)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.path.expanduser documentation wrt. empty $HOME

Initial Comment:
If $HOME is unset, an initial "~" should not be
expanded according to the documentation. But instead it
somehow is expanded, perhaps through the pwd module:

$ env -u HOME python -c "import os.path; print
os.path.expanduser('~/foo')"
/home/calvin/foo

The result should be "~/foo" instead of "/home/calvin/foo".

I suggest adjusting the documentation to state the also
a single "~" is looked up in the pwd module, not only
"~user".

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 07:28

Message:
Logged In: YES 
user_id=1188172

Okay, committed as Doc/lib/libposixpath.py 1.42, 1.40.2.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 05:16

Message:
Logged In: YES 
user_id=80475

Strike the comma before the final "or".

After you post this, put a note on your todo list to check
its appearance in the HTML docs whenever Fred runs an update:
   
    http://www.python.org/dev/doc/devel/


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-05 12:29

Message:
Logged In: YES 
user_id=1188172

Attached a patch which fixes the docs. Okay to checkin?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:01 -0800
Subject: [ python-Bugs-1191043 ] bz2 RuntimeError when decompressing file
Message-ID: <E1FBAqb-0008Jo-NU@sc8-sf-web6.sourceforge.net>

Bugs item #1191043, was opened at 2005-04-27 14:34
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Chris AtLee (catlee)
>Assigned to: Georg Brandl (gbrandl)
Summary: bz2 RuntimeError when decompressing file

Initial Comment:
The following code:
echo -n Testing123 | bzip2 > test.bz2
python -c "import bz2; lines =
bz2.BZ2File('test.bz2').readlines()"

produces this output:
Traceback (most recent call last):
  File "<string>", line 1, in ?
RuntimeError: wrong sequence of bz2 library commands used

Tested on Python 2.4.1 (debian unstable - April 1
2005), and Python 2.3.5 (debian unstable - May 26 2005)

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-21 14:19

Message:
Logged In: YES 
user_id=1188172

Fixed, also for xreadlines(). Problem was that the code, if
there were no newlines in a chunk read from the file,
assumed that the buffer was too small.

Modules/bz2module.c r1.25
Lib/test/test_bz2.py r1.18

Please review the fix!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 12:03

Message:
Logged In: YES 
user_id=80475

Reinhold, do you want to take this one?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-14 14:55

Message:
Logged In: YES 
user_id=11375

Calling .readline() works fine, though.  The problem wasn't
apparent with a quick look at the readlines() code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 12:14

Message:
Logged In: YES 
user_id=80475

Okay, I see.  Will look into it.

----------------------------------------------------------------------

Comment By: Chris AtLee (catlee)
Date: 2005-04-28 12:00

Message:
Logged In: YES 
user_id=186532

How is test.bz2 not a valid bz2 file?  The command line tool
"bzcat" or "bunzip2" can operate properly on it.  Using
BZ2File("test.bz2").read() works properly, it's just the
readlines() call that breaks.

Try this out:
import bz2
bz2.BZ2File("test.bz2","w").write("testing123")

# This works fine
assert bz2.BZ2File("test.bz2").read() == "testing123"

# This raises a RuntimeError
assert bz2.BZ2File("test.bz2").readlines() == ["testing123"]

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 07:06

Message:
Logged In: YES 
user_id=80475

The looks like correct behavior to me.  The test.bz2 file is
not in a valid bz2 format.  I suspect that you've misread
the BZ2File API which is intended for reading and writing
uncompressed data to and from a file in a bz2 format (where
the data is stored in compressed form).

If this interpretation of the bug report is correct, please
mark as not-a-bug and close.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:03 -0800
Subject: [ python-Bugs-1168746 ] frame.f_exc_type,value,traceback
Message-ID: <E1FBAqd-0008KX-6Q@sc8-sf-web6.sourceforge.net>

Bugs item #1168746, was opened at 2005-03-22 23:07
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&group_id=5470

Please note that this 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: 4
Submitted By: Armin Rigo (arigo)
>Assigned to: Georg Brandl (gbrandl)
Summary: frame.f_exc_type,value,traceback

Initial Comment:
The frame object attributes f_exc_type, f_exc_value, f_exc_traceback are misdocumented.  They are not the last exception caught by the frame, nor the one currently handled, or anything reasonable like that.

They give the last exception raised in the parent frame, and only if another exception was ever raised in the current frame (in all other cases they are None).

I very much doubt this is useful to anyone, so maybe un-publishing the attributes would be sensible, but in any case the doc needs a small fix (ref/types.html and the doc about and in inspect.py).

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-02 10:29

Message:
Logged In: YES 
user_id=1188172

Okay, checked in patch #1230615 as Doc/ref/ref3.tex r1.125,
r1.121.2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:02 -0800
Subject: [ python-Bugs-1175022 ] property example code error
Message-ID: <E1FBAqc-0008KN-Tf@sc8-sf-web6.sourceforge.net>

Bugs item #1175022, was opened at 2005-04-01 20:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175022&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: John Ridley (ojokimu)
>Assigned to: Georg Brandl (gbrandl)
Summary: property example code error

Initial Comment:
The example code for 'property' in lib/built-in-funcs.html may 
produce an error if run "as is": 
 
Python 2.4.1 (#1, Mar 31 2005, 21:33:58) 
[GCC 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)] on linux2 
>>> class C(object): 
...     def getx(self): return self.__x 
...     def setx(self, value): self.__x = value 
...     def delx(self): del self.__x 
...     x = property(getx, setx, delx, "I'm the 'x' property.") 
... 
>>> c=C() 
>>> c.x 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "<stdin>", line 2, in getx 
AttributeError: 'C' object has no attribute '_C__x' 
 
The same goes for 'del c.x' (although not 'c.x = 0', of course). 
 
A more "typical" way of defining managed attributes would be to 
include an 'init' as follows: 
 
class C(object): 
    def __init__(self): self.__x = None 
    def getx(self): return self.__x 
    def setx(self, value): self.__x = value 
    def delx(self): del self.__x 
    x = property(getx, setx, delx, "I'm the 'x' property.") 
 
 

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 20:08

Message:
Logged In: YES 
user_id=1188172

Thanks for the report; fixed as Doc/lib/libfuncs.tex r1.184,
r1.175.2.4.

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2005-04-06 03:33

Message:
Logged In: YES 
user_id=81797

I agree, adding the __init__ to set a value would be useful.  +1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175022&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:03 -0800
Subject: [ python-Bugs-1166582 ] IterableUserDict not in docs
Message-ID: <E1FBAqd-0008Kc-BA@sc8-sf-web6.sourceforge.net>

Bugs item #1166582, was opened at 2005-03-19 18:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166582&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
>Assigned to: Georg Brandl (gbrandl)
Summary: IterableUserDict not in docs

Initial Comment:
There is no mention of UserDict.IterableUserDict in the
docs (3.7 UserDict). Here is a suggested rewrite:

class UserDict(     [initialdata])
    Class that simulates a dictionary. The instance's
contents are kept in a regular dictionary, which is
accessible via the data attribute of UserDict
instances. If initialdata is provided, data is
initialized with its contents; note that a reference to
initialdata will not be kept, allowing it be used for
other purposes. Note: For backward compatibility,
instances of UserDict are not iterable.

class IterableUserDict( [initialdata])
    Subclass of UserDict that supports direct iteration
(e.g. "for key in myDict").

In addition to supporting the methods and operations of
mappings (see section 2.3.8), UserDict and
IterableUserDict instances provide the following attribute:

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 21:04

Message:
Logged In: YES 
user_id=1188172

Thanks for the report; fixed as Doc/lib/libuserdict.tex
r1.27, r1.24.4.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166582&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:03 -0800
Subject: [ python-Bugs-1172785 ] doctest.script_from_examples() result
	sometimes un-exec-able
Message-ID: <E1FBAqd-0008KS-2R@sc8-sf-web6.sourceforge.net>

Bugs item #1172785, was opened at 2005-03-29 20:50
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172785&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jonathan E. Guyer (jguyer)
>Assigned to: Georg Brandl (gbrandl)
Summary: doctest.script_from_examples() result sometimes un-exec-able

Initial Comment:
doctest.script_from_examples() can sometimes return results that 
cannot be passed to exec. The docstring for script_from_examples() 
itself is an example:

guyer% python2.4
Python 2.4 (#1, Mar 10 2005, 18:08:38) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> text = '''
...     Here are examples of simple math.
...         Python has super accurate integer addition
...         >>> 2 + 2
...         5
... 
...         And very friendly error messages:
... 
...         >>> 1/0
...         To Infinity 
...         And
...         Beyond
... 
...         You can use logic if you want:
... 
...         >>> if 0:
...         ...    blay 
...         ...    blah
...         ...
... 
...         Ho hum
...         '''
>>> exec doctest.script_from_examples(text)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 21
    #     Ho hum
              ^
SyntaxError: invalid syntax


The issue seems to be the lack of trailing '\n', which is documented 
as required by compile(), although not for exec. 

We never saw a problem with this in Python 2.3's doctest, probably 
because comment lines, such as "Ho hum", were stripped out and 
apparently adequate '\n' were appended.

Python 2.4 on Mac OS X 10.3.8

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 22:24

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, this is fixed as of Lib/doctest.py
r1.123, r1.120.2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172785&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:01 -0800
Subject: [ python-Bugs-1194181 ] bz2.BZ2File doesn\'t handle modes correctly
Message-ID: <E1FBAqb-0008JZ-5D@sc8-sf-web6.sourceforge.net>

Bugs item #1194181, was opened at 2005-05-03 02:39
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470

Please note that this message 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: 8
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Georg Brandl (gbrandl)
>Summary: bz2.BZ2File doesn\'t handle modes correctly

Initial Comment:
I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will 
erase my file.  That's bad.  Specifying 'rU' works as expected.  
Basically, it assumes that you want a writable file unless it sees an 
'r' in the mode, or no mode is given.  Ugh.

I've attached a patch that fixes this on CVS HEAD, it looks like it 
should apply cleanly to 2.4 as well.  This is a backport candidate if 
I've ever seen one.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 19:47

Message:
Logged In: YES 
user_id=1188172

Ok, checked in as

Modules/bz2module.c r1.24 r1.23.2.1
Lib/test/test_bz2.py r1.17 r1.16.2.1


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-06-03 18:23

Message:
Logged In: YES 
user_id=139309

It should still be OK to check in.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 18:16

Message:
Logged In: YES 
user_id=1188172

Okay to check in?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:00 -0800
Subject: [ python-Bugs-1209560 ] spurious blank page in dist.pdf
Message-ID: <E1FBAqa-0008JA-7n@sc8-sf-web6.sourceforge.net>

Bugs item #1209560, was opened at 2005-05-27 00:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Georg Brandl (gbrandl)
Summary: spurious blank page in dist.pdf

Initial Comment:
In the US Letter sized version of dist.pdf in the
current download zip (Python 2.4.1), the third page of
the file (the one immediately preceding the table of
contents, which starts with roman numeral "i") is
blank.  That means that page "i" of the table of
contents, and page "1" of the actual document, begin on
even-numbered pages in the file.  This is bad because
if you print on a duplex printer, page 1 comes out on
the back of page ii, page 3 comes out on the back of
page 2, etc.  You want odd numbered pages to be on the
front and even numbered pages to be on the back, so
page 2 should be on the back of page 1, etc.

This is probably a problem with the latex extension
that made the pdf file and so it probably affects the
other pdfs as well as dist.pdf, but that's the only one
I printed.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-18 20:12

Message:
Logged In: YES 
user_id=1188172

Thanks for the report! 
Checked in as Doc/dist/dist.tex rev 1.95, 1.86.2.5.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 11:12

Message:
Logged In: YES 
user_id=1188172

This indeed happens only in dist.pdf. Attaching a patch
which includes the copyright, as in all other documents, and
magically, the paging is right.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:04 -0800
Subject: [ python-Bugs-1072853 ] thisid not intialized in pindent.py script
Message-ID: <E1FBAqe-0008L2-Gw@sc8-sf-web6.sourceforge.net>

Bugs item #1072853, was opened at 2004-11-24 23:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Niraj Bajpai (nbajpai)
>Assigned to: Georg Brandl (gbrandl)
Summary: thisid not intialized in pindent.py script

Initial Comment:
Hi there,

I am using python version 2.3.4.

For some cases when using pindent.py with -c and -e 
option as follows, the variable "thisid" does not gets 
initialized before it hits line #310 ( current, firstkw, 
lastkw, topid = indent, thiskw, thiskw, thisid), this is 
traced all the way back to line #268 (for my case it fell 
in this else clause ... didn't try to look the exact 
scenario causing this) ... adding 

thisid = '' help fix the code for my scenario. 

If this fix is good for all scenario, please roll this over to 
main line code.

Regards,
Niraj

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 20:23

Message:
Logged In: YES 
user_id=1188172

Fixed in CVS Tools/scripts/pindent.py r1.13, r1.12.12.1.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-12-19 22:32

Message:
Logged In: YES 
user_id=31435

ann says that because rev 1.10 mechanically converted the 
whole file from tab indents to 4-space indents.  I've never 
looked at this code, and never even used it.  I care about 
reindent.py, but not pindent.py (it's Guido's baby, BTW).  
Unassigned myself.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:12

Message:
Logged In: YES 
user_id=80475

Tim, cvs ann says this is your code.

----------------------------------------------------------------------

Comment By: Niraj Bajpai (nbajpai)
Date: 2004-11-25 02:50

Message:
Logged In: YES 
user_id=1165734

I am running on solaris-8 and command I used is as follows:
pindent.py -c -e <file_name>

This is for some special cases (I do not know, haven't digged 
into) and does not happen for all the mis-formatted files.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:04 -0800
Subject: [ python-Bugs-1100201 ] Cross-site scripting on BaseHTTPServer
Message-ID: <E1FBAqe-0008Kx-61@sc8-sf-web6.sourceforge.net>

Bugs item #1100201, was opened at 2005-01-11 15:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100201&group_id=5470

Please note that this 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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Paul Johnston (paj28)
>Assigned to: Georg Brandl (gbrandl)
Summary: Cross-site scripting on BaseHTTPServer

Initial Comment:
Hi,

There is a minor XSS flaw in BaseHTTPServer, in the
default error message, if you try connecting with a bad
method name, e.g.:

pugsley:/srv/www/htdocs # telnet risk 8000
Trying 192.168.3.52...
Connected to risk.
Escape character is '^]'.
<SCRIPT>alert('hello')</SCRIPT> / HTTP/1.0

HTTP/1.0 501 Unsupported method
("<SCRIPT>alert('hello')</SCRIPT>")
Server: SimpleHTTP/0.6 Python/2.3.4
Date: Tue, 11 Jan 2005 15:02:48 GMT
Content-Type: text/html
Connection: close

<head>
<title>Error response</title>
</head>
<body>
<h1>Error response</h1>
<p>Error code 501.
<p>Message: Unsupported method
("<SCRIPT>alert('hello')</SCRIPT>").
<p>Error code explanation: 501 = Server does not
support this operation.
</body>
Connection closed by foreign host.

This is not likely to be a major security risk, but
ideally it should be fixed. In addition it may be that
other error messages exhibit this flaw, I haven't done
a code audit.

Credit for discovery: Richard Moore

Best wishes,

Paul

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 21:35

Message:
Logged In: YES 
user_id=1188172

Thanks for the report. This is fixed as of
Lib/BaseHTTPServer.py r1.30, r1.29.4.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100201&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:04 -0800
Subject: [ python-Bugs-1108948 ] Cookie.py produces invalid code
Message-ID: <E1FBAqe-0008Ks-1H@sc8-sf-web6.sourceforge.net>

Bugs item #1108948, was opened at 2005-01-25 09:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108948&group_id=5470

Please note that this 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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
>Assigned to: Georg Brandl (gbrandl)
Summary: Cookie.py produces invalid code

Initial Comment:
The code in js_output in the Morsel class in Cookie.py
produces invalid code, the scripting language should be
specified by mimetype and not by language as per
http://www.w3.org/TR/html401/interact/scripts.html

also, the javascript line is missing an ending semi-colon

attached a "patch" (new version of the function in
question)

present at least in 2.3 but still broken in current cvs 

A related matter: the existing documentation is poor,
only after a substantial amount of code reading and
googling I found out how to set attributes such as
expires and path.



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 21:03

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed as of Lib/Cookie.py r1.18.

I do not backport this as some code might rely on the
language HTML attribute.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108948&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:03 -0800
Subject: [ python-Bugs-1155638 ] self.length shield exception in httplib
Message-ID: <E1FBAqd-0008Ki-Kr@sc8-sf-web6.sourceforge.net>

Bugs item #1155638, was opened at 2005-03-03 07:22
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Andrew P. Lentvorski, Jr. (bsder)
>Assigned to: Georg Brandl (gbrandl)
Summary: self.length shield exception in httplib

Initial Comment:
Under certain conditions (I'm trying to open a
Shoutcast stream), I wind up with the following
exception from httplib:

 Traceback (most recent call last):
  File "/home/devel/lib/python2.4/threading.py", line
442, in __bootstrap
    self.run()
  File "avalanche.py", line 86, in run
    streamData = streamResponse.read(256)
  File "/home/devel/lib/python2.4/httplib.py", line
478, in read
    self.length -= len(s)
TypeError: unsupported operand type(s) for -=: 'str'
and 'int'

Normally, self.length has many shields of the form "if
self.length is None:"; however, self.length gets
initialize to _UNKNOWN which is the string "UNKNOWN"
rather than None.  As such, all of the shields are useless.

Am I using a deprecated library or something?  I'm
really surprised no one else has bumped into this.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 22:07

Message:
Logged In: YES 
user_id=1188172

Thanks for the report! This is fixed as of Lib/httplib.py
r1.95, r1.94.2.1.

----------------------------------------------------------------------

Comment By: Yusuke Shinyama (euske)
Date: 2005-05-10 02:46

Message:
Logged In: YES 
user_id=385990

I did bump into the same problem.
Apparently when I got HTTP/0.9 connection, self.length is
not initialized.
Inserting a line into l.362 at httplib.py (v2.4) seems to
solve this problem. I will also post a patch:

        if self.version == 9:
            self.chunked = 0
            self.will_close = 1
            self.msg = HTTPMessage(StringIO())
+            self.length = None
            return


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:04 -0800
Subject: [ python-Bugs-1061920 ] \"k\" specifier in PyArg_ParseTuple
	incomplete documentated
Message-ID: <E1FBAqe-0008L7-Of@sc8-sf-web6.sourceforge.net>

Bugs item #1061920, was opened at 2004-11-07 14:28
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061920&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Gustavo J. A. M. Carneiro (gustavo)
>Assigned to: Georg Brandl (gbrandl)
>Summary: \"k\" specifier in PyArg_ParseTuple incomplete documentated

Initial Comment:
Documentation for python 2.3 says:

"k" (integer) [unsigned long]
    Convert a Python integer to a C unsigned long
without overflow checking. New in version 2.3.

However I was told -- and tested to be true -- that "k"
also accepts python long as argument.  This should be
mentioned in the documentation, otherwise programmers
will assume "k" only accepts values in the range
0-2^31, thus not allowing the full 'unsigned long' range.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 20:05

Message:
Logged In: YES 
user_id=1188172

Fixed as Doc/api/utilities.tex r1.22, r1.20.2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061920&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:02 -0800
Subject: [ python-Bugs-1177468 ] random.py/os.urandom robustness
Message-ID: <E1FBAqc-0008KD-JT@sc8-sf-web6.sourceforge.net>

Bugs item #1177468, was opened at 2005-04-06 01:03
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470

Please note that this message 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: Accepted
Priority: 5
Submitted By: Fazal Majid (majid)
>Assigned to: Georg Brandl (gbrandl)
Summary: random.py/os.urandom robustness

Initial Comment:
Python 2.4.1 now uses os.urandom() to seed the random
number generator. This is mostly an improvement, but
can lead to subtle regression bugs.

os.urandom() will open /dev/urandom on demand, e.g.
when random.Random.seed() is called, and keep it alive
as os._urandomfd.

It is standard programming practice for a daemon
process to close file descriptors it has inherited from
its parent process, and if it closes the file
descriptor corresponding to os._urandomfd, the os
module is blissfully unaware and the next time
os.urandom() is called, it will try to read from a
closed file descriptor (or worse, a new one opened
since), with unpredictable results.

My recommendation would be to make os.urandom() open
/dev/urandom each time and not keep a persistent file
descripto. This will be slightly slower, but more
robust. I am not sure how I feel about a standard
library function steal a file descriptor slot forever,
specially when os.urandom() is probably going to be
called only once in the lifetime of a program, when the
random module is seeded.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-04 17:17

Message:
Logged In: YES 
user_id=1188172

Committed as Lib/os.py r1.87, r1.83.2.3.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-07-04 15:54

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply - both to the trunk and to 2.4. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-04 14:56

Message:
Logged In: YES 
user_id=80475

I'm on Windows so cannot be of much use on the patch review.
 It looks fine to me and I agree that something ought to be
done.  MvL reviewed and posted the original patch so he may
be better able to comment on this patch.  Alternatively,
Peter A. can review/approve it.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-04 14:26

Message:
Logged In: YES 
user_id=1188172

Attaching a patch for Lib/os.py, fixing this on Unix.

On Windows, a completely different method is used for
urandom, so I think it is not relevant here.

Please review.

----------------------------------------------------------------------

Comment By: Peter ?strand (astrand)
Date: 2005-07-04 13:01

Message:
Logged In: YES 
user_id=344921

This bug is a major problem for us as well. This bug also
breaks the subprocess module. Try, for example:

subprocess.Popen(["ls"], close_fds=1, preexec_fn=lambda:
os.urandom(4))

I agree with lcaamano; the library should NOT cache a file
descriptor by default. Correctness and robustness is more
important than speed. 

Has anyone really been able to verify that the performance
with opening /dev/urandom each time is a problem? If it is,
we could add a new function to the os module that activates
the fd caching. If you have been calling this function, you
have indicated that you are aware of the problem and will
not close the cached fd. Legacy code will continue to function. 


----------------------------------------------------------------------

Comment By: pocket_aces (pocket_aces)
Date: 2005-06-08 22:10

Message:
Logged In: YES 
user_id=1293510

We ran across this problem when we upgraded to 2.4.  We use
python embedded in a multi-threaded C++ process and use
multiple subinterpreters.  When a subinterpreter shuts down
and the os module unloads, os._urandomfd is not closed
because it is not a file object but rather just an integer.
 As such, after a while, our process had hundreds of
dangling open file descriptors to /dev/urandom.

I would think, at the very least, if this were a file
object, it would be closed when the module was unloaded (the
deallocator for fileobject closes the file).  However, that
doesn't make it any easier for those who are forking
processes.  Probably the best bet is to close it after
reading the data.  If you need a "high performance, multiple
seek" urandom, just open /dev/urandom yourself.

Either way, this bug is not invalid and needs to be addressed.

My 2 cents..
 --J

----------------------------------------------------------------------

Comment By: Luis P Caamano (lcaamano)
Date: 2005-04-20 13:17

Message:
Logged In: YES 
user_id=279987

Here's a reference:

 http://tinyurl.com/b8mk3

The relevant post:

============================================

On 25 Feb 2001 10:48:22 GMT Casper H.S. Dik - Network 
Security Engineer <Casper.... at holland.sun.com> wrote: 

| 


Solaris at various times used a cached /dev/zero fd both for 
mapping 
| thread stacks and even one for the runtime linker. 
| The runtime linker was mostly fine, but the thread library did 
have 
| problems with people closing fds.  We since added 
MAP_ANON and no 
| longer require open("/dev/zero") .  THe caaching of fds was 
gotten 
| rid of before that. 
| 
| There are valid reasons to close all fds; e.g., if you really don't 
| want to inherit and (you're a daemon and don't care). 
| 
| In most cases, though, the "close all" stuff performed by shells 
| and such at statup serves no purpose.  (Other than causing 
more bugs 


) 

So the dilemma is that closing fds can cause problems and 
leaving 
them open can cause problems, when a forked child does this.  
This 
seems to tell me that hiding fds in libraries and objects is a bad 
idea because processes need to know what is safe to close 
and/or 
what needs to be left open. 

======================================


If the python library had some module or global list of opened file 
descriptors, then it would be OK to expect programs to keep 
those open across fork/exec.  Something like:

 from os import opened_fds

And then it would be no problem to skip those when closing fds.  
Otherwise, your nice daemon code that deals with _urandom_fd 
will break later on when somebody caches another fd 
somewhere else in the standard library.

Also, the proposed os.daemonize() function that knows about its 
own fds would also work.

Still, the most robust solution is not to cache open fds in the 
library or perhaps catch the EBADF exception and reopen.

There are several solutions but closing this bug as invalid doesn't 
seem an appropriate one.




----------------------------------------------------------------------

Comment By: Luis P Caamano (lcaamano)
Date: 2005-04-20 12:04

Message:
Logged In: YES 
user_id=279987

I don't think so.  One of the rules in libc, the standard C library, 
is that it cannot cache file descriptors for that same reason.  This 
is not new.




----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2005-04-20 02:49

Message:
Logged In: YES 
user_id=81797

Conversely, I would say that it's unreasonable to expect
other things not to break if you go through and close file
descriptors that the standard library has opened.

----------------------------------------------------------------------

Comment By: Luis P Caamano (lcaamano)
Date: 2005-04-20 02:31

Message:
Logged In: YES 
user_id=279987

Clearly broken?  Hardly.

Daemonization code is not the only place where it's recommend 
and standard practice to close file descriptors.

It's unreasonable to expect python programs to keep track of all 
the possible file descriptors the python library might cache to 
make sure it doesn't close them in all the daemonization 
routines ... btw, contrary to standard unix programming practices.

Are there any other file descriptors we should know about?



----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2005-04-19 22:27

Message:
Logged In: YES 
user_id=81797

Perhaps the best way to resolve this would be for the
standard library to provide code that either does the
daemonize process, or at least does the closing of the
sockets that may be done as part of the daemonize, that way
it's clear what the "right" way is to do it.  Thoughts?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-04-19 20:05

Message:
Logged In: YES 
user_id=6380

I recommend to close this as invalid. The daemonization code
is clearly broken.

----------------------------------------------------------------------

Comment By: Fazal Majid (majid)
Date: 2005-04-19 17:49

Message:
Logged In: YES 
user_id=110477

Modifying the system os.py is not a good idea. A better
work-around is to skip the /dev/urandom fd when you are
closing all fds. This is the code we use:

def close_fd():
  # close all inherited file descriptors
  start_fd = 3
  # Python 2.4.1 and later use /dev/urandom to seed the
random module's RNG
  # a file descriptor is kept internally as os._urandomfd
(created on demand
  # the first time os.urandom() is called), and should not
be closed
  try:
    os.urandom(4)
    urandom_fd = getattr(os, '_urandomfd', None)
  except AttributeError:
    urandom_fd = None
  if '-close_fd' in sys.argv:
    start_fd = int(sys.argv[sys.argv.index('-close_fd') + 1])
  for fd in range(start_fd, 256):
    if fd == urandom_fd:
      continue
    try:
      os.close(fd)
    except OSError:
      pass


----------------------------------------------------------------------

Comment By: Luis P Caamano (lcaamano)
Date: 2005-04-19 16:53

Message:
Logged In: YES 
user_id=279987

We're facing this problem.  We're thinking of patching our os.py 
module to always open /dev/urandom on every call.  Does 
anybody know if this would have any bad consequences other 
than the obvious system call overhead?

BTW, here's the traceback we get.  As you probably can guess, 
something called os.urandom before we closed all file descriptors 
in the daemonizing code and it then failed when os.urandom 
tried to use the cached fd.

 Traceback (most recent call last):
   File  "/opt/race/share/sw/common/bin/dpmd", line 27, in ?
 dpmd().run()
   File  "Linux/CommandLineApp.py", line 336, in run
   File  "Linux/daemonbase.py", line 324, in main
   File  "Linux/server.py", line 61, in addServices
   File  "Linux/dpmd.py", line 293, in __init__
   File  "Linux/threadutils.py", line 44, in start
   File  "Linux/xmlrpcd.py", line 165, in createThread
   File  "Linux/threadutils.py", line 126, in __init__
   
File  "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t
empfile.py", line 423, in NamedTemporaryFile
 dir = gettempdir()
   
File  "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t
empfile.py", line 262, in gettempdir
 tempdir =  _get_default_tempdir()
   
File  "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t
empfile.py", line 185, in _get_default_tempdir
 namer =  _RandomNameSequence()
   
File  "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t
empfile.py", line 121, in __init__
 self.rng = _Random()
   
File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r
andom.py", line 96, in __init__
 self.seed(x)
   
File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r
andom.py", line 110, in seed

 a =  long(_hexlify(_urandom(16)), 16)

   
File  "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/
os.py", line  728, in urandom 
 bytes +=  read(_urandomfd, n - len(bytes))

 OSError : [Errno 9] Bad file  descriptor



----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2005-04-06 09:04

Message:
Logged In: YES 
user_id=81797

The child is a copy of the parent.  Therefore, if in the
parent you open a few file descriptors, those are the ones
you should close in the child.  That is exactly what I've
done in the past when I forked a child, and it has worked
very well.

I suspect Stevens would make an exception to his guideline
in the event that closing a file descriptor results in
library routine failures.

----------------------------------------------------------------------

Comment By: Fazal Majid (majid)
Date: 2005-04-06 07:27

Message:
Logged In: YES 
user_id=110477

Unfortunately, catching exceptions is not sufficient - the
file descriptor may have been reassigned. Fortunately in my
case, to a socket which raised ENOSYS, but if it had been a
normal file, this would have been much harder to trace
because reading from it would cause weird errors for readers
of the reassigned fd without triggering an exception in
os.urandom() itself.

As for not closing file descriptors you haven't opened
yourself, if the process is the result of a vfork/exec (in
my case Python processes started by a cluster manager, sort
of like init), the child process has no clue what file
descriptors, sockets or the like it has inherited from its
parent process, and the safest course is to close them all.
Indeed, that's what W. Richard Stevens recommends in
"Advanced Programming for the UNIX environment".

As far as I can tell, os.urandom() is used mostly to seed
the RNG in random.py, and thus is not a high-drequency
operation. It is going to be very hard to document this
adequately for coders to defend against - in my case, the
problem was being triggered by os.tempnam() from within
Webware's PSP compiler. There are so many functions that
depend on random (sometimes in non-obvious ways), you can't
flag them all so their users know they should use
urandomcleanup.

One possible solution would be for os.py to offer a
go_daemon() function that implements the fd closing, signal
masking, process group and terminal disassociation required
by true daemons. This function could take care of internal
book-keeping like calling urandomcleanup.

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2005-04-06 07:20

Message:
Logged In: YES 
user_id=81797

Yeah, I was thinking the same thing.  It doesn't address the
consumed file handle, but it does address the "robustness"
issue.  It complicates the code, but should work.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-04-06 07:11

Message:
Logged In: YES 
user_id=21627

To add robustness, it would be possible to catch read errors
from _urandomfd, and try reopening it if it got somehow closed.

----------------------------------------------------------------------

Comment By: Sean Reifschneider (jafo)
Date: 2005-04-06 03:11

Message:
Logged In: YES 
user_id=81797

Just providing some feedback:

I'm able to reproduce this.  Importing random will cause
this file descriptor to be called.  Opening urandom on every
call could lead to unacceptable syscall overhead for some. 
Perhaps there should be a "urandomcleanup" method that
closes the file descriptor, and then random could get the
bytes from urandom(), and clean up after itself?

Personally, I only clean up the file descriptors I have
allocated when I fork a new process.  On the one hand I
agree with you about sucking up a fd in the standard
library, but on the other hand I'm thinking that you just
shouldn't be closing file descriptors for stuff you'll be
needing.  That's my two cents on this bug.

----------------------------------------------------------------------

Comment By: Fazal Majid (majid)
Date: 2005-04-06 01:06

Message:
Logged In: YES 
user_id=110477

There are many modules that have a dependency on random, for
instance os.tempnam(), and a program could well
inadvertently use it before closing file descriptors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:03 -0800
Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently
Message-ID: <E1FBAqd-0008Kn-TH@sc8-sf-web6.sourceforge.net>

Bugs item #1119418, was opened at 2005-02-09 16:57
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Martin Blais (blais)
>Assigned to: Georg Brandl (gbrandl)
Summary: xrange() builtin accepts keyword arg silently

Initial Comment:
Calling ``xrange(10, 100, step=10)`` results in a
xrange(10, 100) iterator silently.  In contrast,
``range(10, 100, step=10)`` raises an exception.  See
test program below.

Two possible fixes:
1. fix xrange() so that it returns a xrange(10, 100,
10) iterator
2. make sure that xrange() raises an exception too.



#!/usr/bin/env python

def foo( min_, max_, step=1 ):
    print min_, max_, step

print '===================='
foo(10, 100, 10)
foo(10, 100, step=10)

print '===================='
print xrange(10, 100, 10)
print xrange(10, 100, step=10)

print '===================='
print range(10, 100, 10)
print range(10, 100, step=10)





elbow:/usr/.../lib/python2.4$ /tmp/a.py
====================
10 100 10
10 100 10
====================
xrange(10, 100, 10)
xrange(10, 100)
====================
[10, 20, 30, 40, 50, 60, 70, 80, 90]
Traceback (most recent call last):
  File "/tmp/a.py", line 16, in ?
    print range(10, 100, step=10)
TypeError: range() takes no keyword arguments

> /tmp/a.py(16)?()
-> print range(10, 100, step=10)
(Pdb) 
elbow:/usr/.../lib/python2.4$ 


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-26 06:45

Message:
Logged In: YES 
user_id=1188172

Committed. Must the new API function be somehow documented?

Commit report follows:

Checking in Python/getargs.c;
new revision: 2.106; previous revision: 2.105
Checking in Include/modsupport.h;
new revision: 2.42; previous revision: 2.41
Checking in Objects/rangeobject.c;
new revision: 2.55; previous revision: 2.54
Checking in Objects/setobject.c;
new revision: 1.56; previous revision: 1.55
Checking in Objects/bufferobject.c;
new revision: 2.27; previous revision: 2.26
Checking in Objects/sliceobject.c;
new revision: 2.23; previous revision: 2.22
Checking in Modules/arraymodule.c;
new revision: 2.99; previous revision: 2.98
Checking in Modules/itertoolsmodule.c;
new revision: 1.41; previous revision: 1.40
Checking in Modules/operator.c;
new revision: 2.31; previous revision: 2.30
Checking in Modules/_randommodule.c;
new revision: 1.8; previous revision: 1.7
Checking in Modules/zipimport.c;
new revision: 1.19; previous revision: 1.18
Checking in Modules/collectionsmodule.c;
new revision: 1.39; previous revision: 1.38

Checking in Python/getargs.c;
new revision: 2.102.2.3; previous revision: 2.102.2.2
Checking in Include/modsupport.h;
new revision: 2.41.4.1; previous revision: 2.41
Checking in Objects/rangeobject.c;
new revision: 2.53.2.1; previous revision: 2.53
Checking in Objects/setobject.c;
new revision: 1.31.2.4; previous revision: 1.31.2.3
Checking in Objects/bufferobject.c;
new revision: 2.26.2.1; previous revision: 2.26
Checking in Objects/sliceobject.c;
new revision: 2.22.4.1; previous revision: 2.22
Checking in Modules/arraymodule.c;
new revision: 2.97.2.1; previous revision: 2.97
Checking in Modules/itertoolsmodule.c;
new revision: 1.39.2.1; previous revision: 1.39
Checking in Modules/operator.c;
new revision: 2.29.4.1; previous revision: 2.29
Checking in Modules/_randommodule.c;
new revision: 1.7.4.1; previous revision: 1.7
Checking in Modules/zipimport.c;
new revision: 1.18.2.1; previous revision: 1.18
Checking in Modules/collectionsmodule.c;
new revision: 1.36.2.1; previous revision: 1.36


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 20:21

Message:
Logged In: YES 
user_id=1188172

Attaching a huge patch.

It introduces the function you described, and calls it in
the constructors of xrange, set, frozenset, buffer and slice.

Moreover, I found it to be necessary in objects in the
following modules:
- array (array)
- itertools (cycle, dropwhile, takewhile, islice, imap,
chain, ifilter, count, izip, repeat)
- operator (attrgetter, itemgetter)
- _random (Random)
- zipimport (zipimporter)
- collections (deque)


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-25 14:35

Message:
Logged In: YES 
user_id=80475

xrange() needs to be kept closely parallel with range() . 
Accordingly, it should not sprout keyword arguments.

For all of these, I think the solution is to raise a
TypeError when keyword arguments are supplied to
functions/types that don't handle them.

Encapsulate the logic in a new internal API function:

int
 _PyArg_NoKeywords(char *funcname, PyObject *kwds)
{
    if (kwds == NULL) return 1;
    if (!PyDict_CheckExact(kwds)){
         bad internal call
         return 0;
    }
    if (PyDict_Size(kwds) == 0)
         return 1;
    set_exc_typeerror(funcname does not take kw args)
    return 0;
}


Then go through the code finding all the type constructors
(grep for PyTypeObject) and add the error check if the kwds
arg is being ignored).  For example:

range_new(PyTypeObject *type, PyObject *args, PyObject *kw)
{
   if (!_PyArg_NoKeywords("xrange", kw))
         return NULL;
    . . .


Be sure to add test cases for every constructor that gets
changed.  Also, go ahead an backport to Py2.4.2.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 13:20

Message:
Logged In: YES 
user_id=1188172

Please review. Should I work on a patch to buffer, set and
slice, too?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-09 21:04

Message:
Logged In: YES 
user_id=1188172

I delved deeper into this, and it seems that the difference
is caused by range being a method (of bltinmodule, defined
as METH_VARARGS), while xrange is a constructor for a
rangeobject.

Such constructor functions get three arguments (the type
object, the args and the kw args), and when the kw args are
not checked like in str(), they can pass freely and are ignored.

I have attached a patch which changes the range object
constructor (xrange) to accept keyword arguments.

Other builtin types that need such a correction include
buffer, set, slice.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-02-16 22:21

Message:
Logged In: YES 
user_id=593130

Functions coded in C generally do not take keyword 
arguments.  (Special coding is required to achieve 
otherwise.)  In 2.2, range and xrange both followed this rule:

>>> xrange(1,20,step=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: xrange() takes no keyword arguments

>>> range(1,20,step=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: range() takes no keyword arguments

So, removal of the error message by 2.4 seem to be a bug.

Surprise:
>>> str(object=1)
'1'
>>> str(i=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'i' is an invalid keyword argument for this function

There is nothing in the doc(Lib Ref) or doc string of str vs. 
range and xrange that would lead me to expect this.

I looked around CVS a bit to see if the past or possible future 
change was something simple, but I could not find source of 
error message in bltinmodule.c, ceval.c, getargs.c,  
rangeobject.c, or typeobject.c, so I will leave this to 
someone else.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:02 -0800
Subject: [ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c
Message-ID: <E1FBAqc-0008K8-BT@sc8-sf-web6.sourceforge.net>

Bugs item #1185883, was opened at 2005-04-19 12:07
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470

Please note that this message 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
Submitted By: Kristj?n Valur (krisvale)
>Assigned to: Georg Brandl (gbrandl)
Summary: PyObject_Realloc bug in obmalloc.c

Initial Comment:
obmalloc.c:835
If the previous block was not handled by obmalloc, and 
the realloc is for growing the block, this memcpy may 
cross a page boundary and cause a segmentation 
fault.  This scenario can happen if a previous allocation 
failed to successfully allocate from the obmalloc pools, 
due to memory starvation or other reasons, but was 
successfully allocated by the c runtime.

The solution is to query the actual size of the allocated 
block, and copy only so much memory.  Most modern 
platforms provide size query functions complementing 
the malloc()/free() calls.  on Windows, this is the _msize
() function.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-11 06:03

Message:
Logged In: YES 
user_id=1188172

Done. Misc/NEWS r1.1193.2.61, Objects/obmalloc.c r2.53.4.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-10 23:07

Message:
Logged In: YES 
user_id=80475

Reinhold, would you like to do the backport?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-07-10 22:33

Message:
Logged In: YES 
user_id=31435

Repaired, in

Misc/NEWS 1.1312
Objects/obmalloc.c 2.54

Should be backported to 2.4 maint.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-05-27 09:35

Message:
Logged In: YES 
user_id=6656

Ping!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-04-19 15:34

Message:
Logged In: YES 
user_id=31435

krisvale:  Thank you for the very clear explanation.  Even I 
understand this now <wink>.

We won't use _msize here -- Python has to run under dozens 
of compilers and C libraries, and it's saner to give up on 
this "optimization" completely than to introduce a rat's nest 
of #ifdefs here.  IOW, I expect the entire "if (nbytes <= 
SMALL_REQUEST_THRESHOLD)" block will go away, so 
that the platform realloc() gets called in every case obmalloc 
doesn't control the incoming block.

BTW, note that there's no plan to do another release in the 
Python 2.3 line.

----------------------------------------------------------------------

Comment By: Kristj?n Valur (krisvale)
Date: 2005-04-19 15:22

Message:
Logged In: YES 
user_id=1262199

The platform is windows 2000/2003 server, single threaded C 
runtime.  I have only had the chance to do postmortem 
debugging on this but it would appear to be as you describe:  
The following page is not mapped in.  Windows doesn?t use 
the setbrk() method of heap management and doesn?t 
automatically move the break.  Rather they (the multiple 
heaps) requests pages as required.   A malloc may have 
succeeded from a different page and copying to much from 
the old block close to the boundary caused an exception 
_at_ the page boundary.
Fyi, old block was 68 bytes at 0x6d85efb8.  This block ends 
at -effc.   The new size requested was 108 bytes.  Reading 
108 bytes from this address caused an exception at address 
0x6d85f000.  As you know, reading past a malloc block 
results in undefined behaviour and sometimes this can mean 
a crash.
I have patched python locally to use MIN(nbytes, _msize(p)) 
in stead and we are about to run the modified version on our 
server cluster.  Nodes were dying quite regularly because of 
this.  I'll let you know if this changes anyting in that aspect.

Btw, I work for ccp games, and we are running the MMORPG 
eve online (www.eveonline.com)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-04-19 15:00

Message:
Logged In: YES 
user_id=31435

mwh:  Umm ... I don't understand what the claim is.  For 
example, what HW does Python run on where memcpy 
segfaults just because the address range crosses a page 
boundary?  If that's what's happening, sounds more like a 
bug in the platform memcpy.  I can memcpy blocks spanning 
thousands of pages on my box -- and so can you <wink>.

krisvale:  which OS and which C are you using?

It is true that this code may try to access a bit of memory 
that wasn't allocated.  If that's at the end of the address 
space, then I could see a segfault happening.  If it is, I doubt 
there's any portable way to fix it short of PyObject_Realloc 
never trying to take over small blocks it didn't control to begin 
with.  Then the platform realloc() will segfault instead <wink>.


----------------------------------------------------------------------

Comment By: Kristj?n Valur (krisvale)
Date: 2005-04-19 14:39

Message:
Logged In: YES 
user_id=1262199

I can only say that I?ve been seeing this happeing with our 
software.  Admittedly it's because we are eating up all 
memory due to other reasons, but we would like to deal with 
that with a MemoryError rather than a crash.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-04-19 14:30

Message:
Logged In: YES 
user_id=6656

Tim, what do you think?

This is a pretty unlikely scenario, it seems to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:23 -0800
Subject: [ python-Bugs-1016880 ] urllib.urlretrieve silently truncates
	downloads
Message-ID: <E1FBAqx-0008LK-8f@sc8-sf-web6.sourceforge.net>

Bugs item #1016880, was opened at 2004-08-26 13:58
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Georg Brandl (gbrandl)
Summary: urllib.urlretrieve silently truncates downloads

Initial Comment:
The following script appears to be unreliable on all 
versions of Python we can find.  The file being 
downloaded is approximately 34 MB.  Browsers such as 
IE and Mozilla have no problem downloading the whole 
thing.

----

import urllib
import os

os.chdir('/tmp')
urllib.urlretrieve
('http://cvs.sourceforge.net/cvstarballs/boost-
cvsroot.tar.bz2',
                  'boost-cvsroot.tar.bz2')


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 18:49

Message:
Logged In: YES 
user_id=1188172

Fixed wrt patch #1062060.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-12-24 14:30

Message:
Logged In: YES 
user_id=129426

Suggested addition to the doc of urllib (liburllib.tex, if
I'm not mistaken):

"""

urlretrieve will raise IOError when it detects that the
amount of data available 
was less than the expected amount (which is the size
reported by a Content-Length
header). This can occur, for example, when the download is
interrupted.

The Content-Length is treated as a lower bound (just like
tools such as wget and 
Ffirefox appear to do): if there's more data to read,
urlretrieve reads more data, but 
if less data is available, it raises IOError.

If no Content-Length header was supplied, urlretrieve can
not check the size
of the data it has downloaded, and just returns it. In this
case you
just have to assume that the download was successful.
"""

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 20:17

Message:
Logged In: YES 
user_id=129426

a patch is at 1062060 (raises IOError when download is
incomplete)

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 19:47

Message:
Logged In: YES 
user_id=129426

Confirmed here (mandrakelinux 10.0, python 2.4b2)
However, I doubt it is a problem in urllib.urlretrieve,
because I tried downloading the file with wget, and got the
following:

[irmen at isengard tmp]$ wget -S
http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2
--20:38:11-- 
http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2
           => `boost-cvsroot.tar.bz2.1'
Resolving cvs.sourceforge.net... 66.35.250.207
Connecting to cvs.sourceforge.net[66.35.250.207]:80...
connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Date: Sun, 07 Nov 2004 19:38:15 GMT
 3 Server: Apache/2.0.40 (Red Hat Linux)
 4 Last-Modified: Sat, 06 Nov 2004 15:11:39 GMT
 5 ETag: "b63d5b-25c3808-687d80c0"
 6 Accept-Ranges: bytes
 7 Content-Length: 39598088
 8 Content-Type: application/x-bzip2
 9 Connection: close

31% [=======================>                              
                      ] 12,665,616    60.78K/s    ETA 03:55

20:40:07 (111.60 KB/s) - Connection closed at byte 12665616.
Retrying.

--20:40:08-- 
http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2
  (try: 2) => `boost-cvsroot.tar.bz2.1'
Connecting to cvs.sourceforge.net[66.35.250.207]:80...
connected.
HTTP request sent, awaiting response...

....... so the remote server just closed the connection
halfway trough! I suspect that a succesful download is sheer
luck.

Also, the download loop in urllib looks fine to me. It only
stops when the read() returns an empty result, and that
means EOF. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-26 20:04

Message:
Logged In: YES 
user_id=80475

Followed the same procedure (no chdir, add a hook) but
bombed out at 9.1Mb:

 . . .
(1117, 8192, 34520156)
('boost-cvsroot.tar.bz2', <httplib.HTTPMessage instance at
0x00B1E4B8>)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-26 18:52

Message:
Logged In: YES 
user_id=31435

Hmm.  I don't know anything about this, but thought I'd just 
try it.  Didn't chdir(), did add a reporthook:

def hook(*args):
    print args

WinXP Pro SP1, current CVS Python, cable modem over a 
wireless router.  Output looked like this:

(0, 8192, 34520156)
(1, 8192, 34520156)
(2, 8192, 34520156)
...
(4213, 8192, 34520156)
(4214, 8192, 34520156)
(4215, 8192, 34520156)

Had the whole file when it ended:

> wc boost-cvsroot.tar.bz2
 125368  765656 34520156 boost-cvsroot.tar.bz2

*Maybe* adding the reporthook changed timing in some 
crucial way.  Don't know.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-26 17:09

Message:
Logged In: YES 
user_id=80475

Confirmed.  On Py2.4 (current CVS), I got 12.7 Mb before the
connection closed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:23 -0800
Subject: [ python-Bugs-1016563 ] urllib2 bug in proxy auth
Message-ID: <E1FBAqx-0008LP-EE@sc8-sf-web6.sourceforge.net>

Bugs item #1016563, was opened at 2004-08-26 07:14
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470

Please note that this message 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: 6
Submitted By: Christoph Mussenbrock (mussenbrock)
>Assigned to: Georg Brandl (gbrandl)
Summary: urllib2 bug in proxy auth

Initial Comment:
in urllib2.py:

line 502 should be:
... user_pass = base64.encodestring('%s:%s' % (unquote
(user), unquote(password))).strip()

the '.strip()' is missing in the current version ("2.1").

this makes an additonal '\n' at the end of user_pass.
So there will be an empty line in the http header, which 
is buggy.

(see also line 645, where the .strip() is right in place!).

Best regards,

Christoph

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 20:33

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, committed as Lib/urllib2.py r1.85,
r1.77.2.2.

----------------------------------------------------------------------

Comment By: Pieter Van Dyck (pietervd)
Date: 2005-06-14 15:39

Message:
Logged In: YES 
user_id=1240437

I've run into the same bug so allow me to comment.

client environment: windows XP
target: Apache/1.3.33 (Unix)

checked on: python 2.3.4, 2.3.5, 2.4.1

To reproduce:

# from urllib2 import ...
proxy = {"http":"http://user:pwd at proxy:port"}
opener =build_opener(ProxyHandler(proxy))
install_opener( opener )

req = Request(coolurl)
# construct 
base64string = base64.encodestring('%s:%s' % (site_user,
site_pwd))[:-1]
authheader =  "Basic %s" % base64string
req.add_header("Authorization", authheader)
urlopen( req )

Symptoms: authentication failed on coolurl (HTTPError 401)
Fix: Applying the patch solves the problem for me

It appears as if the receiving server treats the empty line
as the end of the header even though it strictly shouldn't.

HTH
Pieter

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2005-01-29 21:50

Message:
Logged In: YES 
user_id=113328

The change was introduced by revision 1.32 of the file, from
patch 527518. There's no mention of removing strip() there,
so I suspect it was an accident.

The strip() is still missing in CVS HEAD. I can see the
problem, in theory (base64.encodestring returns a string
with a terminating newline). However, I cannot reproduce the
problem.

Can the original poster provide a means of verifying the
problem? It may be useful as a test case.

Regardless, the change seems harmless, and can probably be
applied. I attach a patch against CVS HEAD:

--- urllib2.py.orig	2005-01-09 05:51:49.000000000 +0000
+++ urllib2.py	2005-01-29 21:31:49.000000000 +0000
@@ -582,7 +582,8 @@
             if ':' in user_pass:
                 user, password = user_pass.split(':', 1)
                 user_pass = base64.encodestring('%s:%s' %
(unquote(user),
-                                                          
unquote(password)))
+                                                          
unquote(password))
+							   ).strip()
                 req.add_header('Proxy-authorization',
'Basic ' + user_pass)
         host = unquote(host)
         req.set_proxy(host, type)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:23 -0800
Subject: [ python-Bugs-1007046 ] os.startfile() doesn\'t accept Unicode
	filenames
Message-ID: <E1FBAqx-0008LZ-Lr@sc8-sf-web6.sourceforge.net>

Bugs item #1007046, was opened at 2004-08-11 06:47
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470

Please note that this 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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthias Huening (huening)
>Assigned to: Georg Brandl (gbrandl)
>Summary: os.startfile() doesn\'t accept Unicode filenames

Initial Comment:
WinXP, Python 2.3.4

os.startfile() seems to have problems with Unicode
filenames. Example:

>>> import tkFileDialog
>>> import os
>>> f = tkFileDialog.askopenfilename()
>>> type(f)
<type 'unicode'>
>>> os.startfile(f)

Traceback (most recent call last):
  File "<pyshell#10>", line 1, in -toplevel-
    os.startfile(f)
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 14-16: ordinal not in range(128)
>>> 



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-14 20:52

Message:
Logged In: YES 
user_id=1188172

Checked this in now. posixmodule.c r2.340, r2.329.2.4.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-09-01 08:27

Message:
Logged In: YES 
user_id=38388

The path looks OK, but I can't test it on Windows
(os.startfile() is only available on Windows).

A note on style: you should always try to keep lines shorter
than 80 characters, e.g.:

--- CVS-Python/Modules/posixmodule.c    2005-08-15
10:15:27.000000000 +0200
+++ Dev-Python/Modules/posixmodule.c    2005-09-01
10:23:06.555633134 +0200
@@ -7248,7 +7248,8 @@
 {
        char *filepath;
        HINSTANCE rc;
-       if (!PyArg_ParseTuple(args, "s:startfile", &filepath))
+       if (!PyArg_ParseTuple(args, "et:startfile",
+                             Py_FileSystemDefaultEncoding,
&filepath))
                return NULL;
        Py_BEGIN_ALLOW_THREADS
        rc = ShellExecute((HWND)0, NULL, filepath, NULL,
NULL, SW_SHOWNORMAL);



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 05:18

Message:
Logged In: YES 
user_id=80475

I'm unicode illiterate.  Passing to MAL for review.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 21:24

Message:
Logged In: YES 
user_id=1188172

Attaching a patch which should fix that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:23 -0800
Subject: [ python-Bugs-1015140 ] \"article id\" in description of NNTP objects
Message-ID: <E1FBAqx-0008LU-IZ@sc8-sf-web6.sourceforge.net>

Bugs item #1015140, was opened at 2004-08-24 10:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Felix Wiemann (felixwiemann)
>Assigned to: Georg Brandl (gbrandl)
>Summary: \"article id\" in description of NNTP objects

Initial Comment:
lib/nntp-objects.html uses the term "article id"
several times.  This term is ambiguous though.  Either
"article number" or "message id" should be used.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 20:27

Message:
Logged In: YES 
user_id=1188172

Corrected in docs and docstrings as
Lib/nntplib.py r1.40, r1.39.2.1
Doc/lib/libnntplib.tex r1.33, r1.32.2.1

----------------------------------------------------------------------

Comment By: Felix Wiemann (felixwiemann)
Date: 2004-08-30 20:13

Message:
Logged In: YES 
user_id=1014490

> Patches are welcome.

I don't have enough time (and I don't care enough) to write
a patch for this, currently.

> If you have a link to authoritive
> guidance, that would be nice also.

The only occurence of the case-insensitive regex
'article.id' in all RFCs is in RFC 977, which says:

223 n a article retrieved - request text separately
        (n = article number, a = unique article id)

(Here, it probably means message-id.)

There are frequent occurences of 'article number' and
'message-id' in the NNTP related RFCs 977 and 2980.

So 'article id' probably should be avoided, as it is
ambiguous.  (The docs sometimes use it in the sense of
'message-id' and sometimes as 'article number', from what I
could see.)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-29 08:20

Message:
Logged In: YES 
user_id=80475

Patches are welcome.  If you have a link to authoritive
guidance, that would be nice also.

----------------------------------------------------------------------

Comment By: Felix Wiemann (felixwiemann)
Date: 2004-08-29 08:11

Message:
Logged In: YES 
user_id=1014490

Same problem for the docstrings in the source file
Lib/nntplib.py.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:23 -0800
Subject: [ python-Bugs-999767 ] Setup.local ignored by setup.py
Message-ID: <E1FBAqx-0008Le-Pe@sc8-sf-web6.sourceforge.net>

Bugs item #999767, was opened at 2004-07-28 22:06
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stephan A. Terre (sfiedler)
>Assigned to: Georg Brandl (gbrandl)
Summary: Setup.local ignored by setup.py

Initial Comment:
This applies to Python 2.2.x, 2.3.x, and 2.4a1.

Platforms seem to be all Unix flavors.

I have zlib, readline, and Tk in an unusual location.
There are also often older versions in the usual
locations (/usr/local/lib, etc.). I put -L and -I flags
pointing to the desired location of these libraries in
entries for the appropriate extension modules in
Setup.local, per the README. I specify all three
extension modules as *shared* .

When I build, the extension modules I specify in
Setup.local get built twice: once directly from the
Makefile, with the flags I request in Setup.local, then
again from setup.py's build_ext phase, with the default
flags. The second build is what's installed, so I end
up using the wrong version of libz, libreadline, and
libtk .

The problem appears to be around line 152 of setup.py
(CVS revision 1.190). There is code to ignore modules
defined in Modules/Setup, but not modules defined in
Modules/Setup.local .

I'm not familiar with the text_file.TextFile class, so
there may be a better way to do this, but one the fix
is to loop over ['Modules/Setup',
'Modules/Setup.local'] rather than only reading
Modules/Setup.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-27 18:24

Message:
Logged In: YES 
user_id=1188172

Fixed in rev. 41837/41838.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-12-27 18:17

Message:
Logged In: YES 
user_id=21627

I agree; go ahead and make that change.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-27 17:38

Message:
Logged In: YES 
user_id=1188172

I think that's reasonable. Martin?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:23 -0800
Subject: [ python-Bugs-969757 ] function and method objects confounded in
	Tutorial
Message-ID: <E1FBAqx-0008Lj-Tu@sc8-sf-web6.sourceforge.net>

Bugs item #969757, was opened at 2004-06-09 16:59
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969757&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mark Jackson (mjackson)
>Assigned to: Georg Brandl (gbrandl)
Summary: function and method objects confounded in Tutorial

Initial Comment:
In Section 9.3.2 (Class Objects) we find, right after
the MyClass example code:

"then MyClass.i and MyClass.f are valid attribute
references, returning an integer and a method object,
respectively."

However, at the end of Section 9.3.3 (Instance Objects)
we find, referring to the same example:

"But x.f is not the same thing as MyClass.f - it is a
method object, not a function object."

There are references to MyClass.f as a function or
function object in Section 9.3.4 as well.  Although
Python terminology doesn't seem to be completely
consistent around this point (in the Python 2.1.3
interpreter MyClass.f describes itself as an "unbound
method") iit seems clear that calling MyClass.f a
method object in Section 9.3.2 is, in this context, an
error.  Should be changed to "function object."

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-08 21:37

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed as Doc/tut/tut.tex r1.275,
r1.261.2.10.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969757&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:24 -0800
Subject: [ python-Bugs-872769 ] os.access() documentation should stress race
	conditions
Message-ID: <E1FBAqy-0008M6-Bm@sc8-sf-web6.sourceforge.net>

Bugs item #872769, was opened at 2004-01-08 01:40
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872769&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: seth arnold (setharnold)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.access() documentation should stress race conditions

Initial Comment:
Every version of the documentation I've seen associated
with the os.access() function neglects to mention that
its use is almost always a security vulnerability.

For the versions of python that are still maintained,
I'd like to see the documentation for this function
expanded to include a paragraph very similar to the
warning given in my system's access(2) manpage:

Using access to check if a user is authorized to e.g.,
open a file before actually doing so using open(2)
creates a security hole, because the user might exploit
the short time interval between checking and opening
the file to manipulate it.

(This paragraph comes from a Debian system; if it is
more work to validate the license on this manpage for
including this paragraph here, I'd be happy to write
some new content under whatever license is required to
get a warning included.)

Of course, there are web-based documents derived from
the module's built-in documentation. It'd be keen if
whoever fixes this in the module could poke the website
document maintainer and ask them to regenerate the content.

Thanks!

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 21:10

Message:
Logged In: YES 
user_id=1188172

Thanks for the suggestion. Committed as Doc/lib/libos.tex
r1.163, r1.146.2.9.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872769&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:24 -0800
Subject: [ python-Bugs-957505 ] SocketServer module documentation misleading
Message-ID: <E1FBAqy-0008Lo-32@sc8-sf-web6.sourceforge.net>

Bugs item #957505, was opened at 2004-05-20 16:42
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957505&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jon Giddy (jongiddy)
>Assigned to: Georg Brandl (gbrandl)
Summary: SocketServer module documentation misleading

Initial Comment:
The Python Library Reference page for the SocketServer
module refers to RequestHandlerClass as though it was
the name of an actual class. Actually, it should be
either "request handler class" or "BaseRequestHandler".

Secondly, in the second para of the BaseRequestHandler
handle() method description, StreamRequestHandler and
DatagramRequestHandler are referred to as mix-in
classes when they are in fact subclasses of
BaseRequestHandler.

This error is also present in the comments at the start
of the module.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-18 07:39

Message:
Logged In: YES 
user_id=1188172

Thanks for the suggestions. Your first point has already
been clarified by adding more explanation to the docs, the
second point I have corrected in
Doc/lib/libsocksvr.tex r1.20, r1.18.4.2, Lib/SocketServer.py
r1.40, r1.37.4.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957505&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:23 -0800
Subject: [ python-Bugs-1021621 ] use first_name, not first, in code samples
Message-ID: <E1FBAqx-0008LF-0u@sc8-sf-web6.sourceforge.net>

Bugs item #1021621, was opened at 2004-09-03 05:27
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Feature Request
Status: Closed
Resolution: Fixed
Priority: 1
Submitted By: Steve R. Hastings (steveha)
>Assigned to: Georg Brandl (gbrandl)
Summary: use first_name, not first, in code samples

Initial Comment:
Low priority documentation request.


I'm studying the documentation on how to write a C module.

http://docs.python.org/ext/node22.html

Please update the sample code in the documentation to
use "first_name" rather than "first" and "last_name"
rather than "last".

When I first studied the code and saw "first" and
"last" members in a structure, I thought those were for
a linked list of some sort.  Much later in the code I
realized that the object was supposed to have a first
name and a last name, and there was no linked list at all.

"first_name" would be much more self-documenting than
"first".  An acceptable alternative would be a comment
after the "first" declaration, saying: /* first name */

This is a small point, but I think it would be an
improvement to the documentation.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 21:20

Message:
Logged In: YES 
user_id=1188172

While mwh's new docs are in the making, I added the comments
you suggested as Doc/ext/noddy2.c r1.5.4.1, r1.6.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-09-03 10:59

Message:
Logged In: YES 
user_id=6656

FWIW, I agree.  I'm attempting to rewrite the extending and 
embedding manual, and yes, this is one of the things I've changed.

I've just uploaded my latest draft to

   http://starship.python.net/crew/mwh/toext/

which gets a little way into the area of defining new types.  I'd 
really appreciate your comments! (to mwh at python.net, please).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:24 -0800
Subject: [ python-Bugs-869197 ] setgroups rejects long integer arguments
Message-ID: <E1FBAqy-0008MC-GK@sc8-sf-web6.sourceforge.net>

Bugs item #869197, was opened at 2004-01-02 09:38
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Feature Request
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Paul Jarc (prjsf)
>Assigned to: Georg Brandl (gbrandl)
Summary: setgroups rejects long integer arguments

Initial Comment:
os.setgroups ought to accept long integer arguments,
just as os.setgid does.  I think this worked in an
earlier version of Python - or maybe it was that
string.atol used to return a non-long integer if the
number was small enough, so I didn't encounter long
integers at all.

>>> import os
>>> os.setgid(1L)
>>> os.setgroups((1L,))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: groups must be integers
>>> import sys
>>> print sys.version
2.3.3 (#1, Dec 30 2003, 22:52:56) 
[GCC 3.2.3]


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-22 19:31

Message:
Logged In: YES 
user_id=1188172

Committed in revs 41514 and 41515 (2.4).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-11-13 10:16

Message:
Logged In: YES 
user_id=21627

The patch looks fine, please apply. Please remove the unused
variable check, though.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-11 08:44

Message:
Logged In: YES 
user_id=1188172

Adding enhanced patch.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-10-02 08:52

Message:
Logged In: YES 
user_id=21627

Would that be the time to check that the value fits into a
gid_t? 

I think the strategy would be this:
- assign the value to grouplist[i]
- read it back again
- check if this is still the same value



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-29 20:36

Message:
Logged In: YES 
user_id=1188172

Attaching patch against CVS head. Please review.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:24 -0800
Subject: [ python-Bugs-890010 ] Odd warning behaviors
Message-ID: <E1FBAqy-0008Lt-98@sc8-sf-web6.sourceforge.net>

Bugs item #890010, was opened at 2004-02-03 22:25
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Please note that this message 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
Submitted By: Tim Peters (tim_one)
>Assigned to: Georg Brandl (gbrandl)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
     if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
     raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > <string>(1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-18 18:38

Message:
Logged In: YES 
user_id=1188172

I fixed warnings inbetween, see revision 42028.

So I guess this can be closed.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-01-17 21:53

Message:
Logged In: YES 
user_id=31435

No, it's certainly not OK for range(1.0) to raise either
DeprecationWarning or TypeError depending on what __name__
happens to be.  But I may not understand what you mean. 
This is a screen scrape from current SVN trunk, on Windows:

>>> __name__ = None; range(1.0)
None:1: DeprecationWarning: integer argument expected, got float
[0]

I don't see TypeError there, so I'm not sure what

"""
In current SVN heads, range(1.0) gives DeprecationWarning and 
__name__=None; range(1.0) gives TypeError.
"""

means.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:28

Message:
Logged In: YES 
user_id=1188172

In current SVN heads, range(1.0) gives DeprecationWarning and 
__name__=None; range(1.0) gives TypeError.

Is this okay?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:51

Message:
Logged In: YES 
user_id=31435

I'm listening, but with half of part of one ear.  Have to agree 
convertsimple() was wrong in these cases, but can't make 
time for more than that.  Reassigned to Jeremy, partly at 
random (his is one of the names that shows up as a recent 
getargs.c changer).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-12 14:09

Message:
Logged In: YES 
user_id=6656

Is anyone listening?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 15:05

Message:
Logged In: YES 
user_id=6656

Oops, wrong file.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 15:03

Message:
Logged In: YES 
user_id=6656

How's this?  It's horrible, but I'm not sure that can be avoided.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 13:22

Message:
Logged In: YES 
user_id=6656

OK, the problem is that returning NULL from 
getargs.c:convertsimple indicates *success* (argh!).

Fixing that provokes weird errors from handle_range_longs.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 12:10

Message:
Logged In: YES 
user_id=6656

Might this be specific to range()?

[mwh at pc150 build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb  3 2004, 19:23:25) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> range(5.0)
[]

range()'s argument handling is somewhat odd

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:24 -0800
Subject: [ python-Bugs-868706 ] Calling builtin function \'eval\' from C
	causes seg fault.
Message-ID: <E1FBAqy-0008MH-MB@sc8-sf-web6.sourceforge.net>

Bugs item #868706, was opened at 2004-01-01 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=868706&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Zac Evans (karadoc)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Calling builtin function \'eval\' from C causes seg fault.

Initial Comment:
Using C to get the eval function from builtins then call it 
causes a Seg-Fault.
I've tried calling it using
PyObject_CallObject, "_CallFunction, "_CallFunctionObjArg
s.
All cause the same problem.
Other builtin functions seem to work correctly.
and eval seems to work correctly from python 
(obviously).
It's just calling eval from C which causes the crash.

Attached is some sample code which demonstrates the 
problem.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-15 10:47

Message:
Logged In: YES 
user_id=1188172

I fixed this; eval() now raises a TypeError when called from
C without globals/locals.

Committed in Python/bltinmodule.c r2.325, r2.318.2.3.

----------------------------------------------------------------------

Comment By: Zac Evans (karadoc)
Date: 2004-01-02 03:04

Message:
Logged In: YES 
user_id=117625

In my opinion, the 'bug' isn't really a big problem. If it is nicer 
for the internals of Python if the bug isn't fixed, than that 
would be fine. Although, it would be a good thing to 
document somewhere. Ideally, the call should raise an 
expection saying what the problem is. That's always nicer 
than a seg-fault.

Also, on an almost unrelated note, why are
PyEval_EvalCode() and a whole lot of other PyEval_* 
functions missing from the Python/C API index in the docs 
(http://www.python.org/doc/current/api/genindex.html)?

And that's about all I have to say about that.
Thank you for you time and quick reponse.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-01-01 21:52

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem, but I'm not sure this
should be applied.  Partially because I'm not sure it's the
best solution.  I'm also not sure if your use should be
considered correct.  I'm not sure if this is documented. 
Perhaps that should be changed?

I understand your complaint, however, you can fix the
problem my passing a dictionary for globals.  You can also
call PyEval_EvalCode or PyEval_EvalCodeEx.  But in both of
those cases you will need to supply globals.

I believe the reason for the segfault is that globals is
NULL since there is no frame.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868706&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:24 -0800
Subject: [ python-Bugs-850238 ] unclear documentation/missing command?
Message-ID: <E1FBAqy-0008MM-Pn@sc8-sf-web6.sourceforge.net>

Bugs item #850238, was opened at 2003-11-27 13:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850238&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Andreas Kostyrka (yacc143)
>Assigned to: Georg Brandl (gbrandl)
Summary: unclear documentation/missing command?

Initial Comment:
Hi!

The documentation of \declaremodule
(http://www.python.org/doc/2.3.2/doc/module-markup.html)
misses one important thing:

It only works as such if you use one \section per module.
(I had some fun LaTeX debugging to find it)

It should also be noted, that perhaps an extra command
to call \py at reset, something like \endmodule, this way the
author could specify which part of the file pertains to
certain module.

Alternativly, perhaps \declaremodule should flush out
any module info that is already entered?

Andreas

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-18 08:05

Message:
Logged In: YES 
user_id=1188172

Added a remark that each module should be documented in its
own \section.

Doc/doc/doc.tex r1.94, 1.90.2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850238&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:24 -0800
Subject: [ python-Bugs-839151 ] attempt to access sys.argv when it doesn\'t
	exist
Message-ID: <E1FBAqy-0008Ma-Uq@sc8-sf-web6.sourceforge.net>

Bugs item #839151, was opened at 2003-11-10 10:56
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470

Please note that this message 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: Fixed
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
>Assigned to: Georg Brandl (gbrandl)
>Summary: attempt to access sys.argv when it doesn\'t exist

Initial Comment:
When using Python as an extension to another program,
giving a warning message attempts to access sys.argv
while it doesn't exist.

The problem can be reproduced with Vim when compiled
with Python 2.3.  Use these two commands:
    :py import sys
    :py print sys.maxint + 1

The problem is caused by the warnings module.  In line
53 it accesses sys.argv[0], but for an embedded
interpreter this doesn't exist.

The suggested fix does an explicit test for the
existence of sys.argv.  That seems to be the cleanest
solution to me.

This problem also existed in Python 2.2.  I didn't try
other versions.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 22:55

Message:
Logged In: YES 
user_id=1188172

Thanks for the report; this is fixed as of Lib/warnings.py
r1.27, r1.24.2.2.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-11-19 05:23

Message:
Logged In: NO 

Much simplier test:

&gt;&gt;&gt; import sys
&gt;&gt;&gt; del sys.argv
&gt;&gt;&gt; sys.maxint+1
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;D:\development\python22\lib\warnings.py&quot;, line 38,
in warn
    filename = sys.argv[0]
AttributeError: 'module' object has no attribute 'argv'


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-11-19 05:22

Message:
Logged In: NO 

Much simplier test:

&gt;&gt;&gt; import sys
&gt;&gt;&gt; del sys.argv
&gt;&gt;&gt; sys.maxint+1
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;D:\development\python22\lib\warnings.py&quot;, line 38,
in warn
    filename = sys.argv[0]
AttributeError: 'module' object has no attribute 'argv'


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-11-10 15:02

Message:
Logged In: YES 
user_id=33168

Just to provide a reference, 839200 was a duplicate of this
report.  I closed 839200.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:25 -0800
Subject: [ python-Bugs-755617 ] os module: Need a better description of &quot;
	mode&quot; 
Message-ID: <E1FBAqz-0008Mf-4m@sc8-sf-web6.sourceforge.net>

Bugs item #755617, was opened at 2003-06-17 00:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
>Assigned to: Georg Brandl (gbrandl)
Summary: os module: Need a better description of &quot;mode&quot;

Initial Comment:
The page &lt;http://www.python.
org/doc/current/lib/os-file-dir.html&gt; says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The &quot;mode&quot; values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-18 08:17

Message:
Logged In: YES 
user_id=1188172

Added this note to the chmod docs:

Although Windows supports chmod, you can only set the
file's read-only flag with this function (via the
\code{S_IWRITE}
and \code{S_IREAD} constants or a corresponding integer value).
All other bits are ignored.

Doc/lib/libos.tex r1.164, r1.146.2.10.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-05 18:28

Message:
Logged In: YES 
user_id=1188172

I think the wording suggested by logistix would be a good
addition to the docs.

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2003-06-17 19:31

Message:
Logged In: YES 
user_id=699438

Something like:

&quot;NOTE: Although Windows supports chmod, it incorporates 
much different functionality than a typical Unix user would 
expect.  Please refer to Microsoft?s documentation for more 
details.&quot;

would be nice.

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 15:18

Message:
Logged In: YES 
user_id=531881

Tim-

I captured what Matthew Shomphe recommended into patch 755677
(http://www.python.org/sf/755677).  Hope this helps.

-c

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 14:49

Message:
Logged In: YES 
user_id=31435

Then please suggest the actual text you want to see in the 
docs.  I can't do it for you (for example, chmod has always 
done exactly what I've wanted it to do on Windows -- but 
then I've never wanted to do anything with it on Windows 
beyond fiddling the readonly bit).

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2003-06-17 05:35

Message:
Logged In: YES 
user_id=699438

All I'm saying is that although chmod is valid windows call, it 
will not produce the effect that most users expect.  There's 
no harm in calling it, but it's not going to accomplish what 
most users want it to do.  This information is more important 
to a user than other inconsistencies in the Windows 
implementation.  (i.e. os.stat returning a value that is 
different than chmod set)

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 03:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 03:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2003-06-17 02:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I'd start with os.popen
(&quot;cacls ...&quot;)  Even win32security requires some serious 
programming just to get started with manipulating ACLs.

Typical security looks something like this:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\grant&gt;xcacls &quot;\Program files&quot;
C:\Program Files BUILTIN\Users:R
                 BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                           GENERIC_READ
                                           GENERIC_EXECUTE

                 BUILTIN\Power Users:C
                 BUILTIN\Power Users:(OI)(CI)(IO)C
                 BUILTIN\Administrators:F
                 BUILTIN\Administrators:(OI)(CI)(IO)F
                 NT AUTHORITY\SYSTEM:F
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                 BUILTIN\Administrators:F
                 CREATOR OWNER:(OI)(CI)(IO)F


C:\Documents and Settings\grant&gt;

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-06-17 02:05

Message:
Logged In: YES 
user_id=716326

Here's my first pass at some additional documentation.  My 
HTML skills are not up to par, but I've tried :)  I've attached 
the document separately.

m@

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-17 01:06

Message:
Logged In: YES 
user_id=33168

Could you try to produce a patch to improve the
documentation?  Or perhaps suggest better wording?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:25 -0800
Subject: [ python-Bugs-754016 ] urlparse goes wrong with IP:port without scheme
Message-ID: <E1FBAqz-0008Mk-9D@sc8-sf-web6.sourceforge.net>

Bugs item #754016, was opened at 2003-06-13 15:15
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470

Please note that this message 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
Submitted By: Thomas Kr?ger (kruegi)
>Assigned to: Georg Brandl (gbrandl)
Summary: urlparse goes wrong with IP:port without scheme

Initial Comment:
urlparse doesnt work if IP and port are given without 
scheme:

&gt;&gt;&gt; urlparse.urlparse('1.2.3.4:80','http')
('1.2.3.4', '', '80', '', '', '')

should be:

&gt;&gt;&gt; urlparse.urlparse('1.2.3.4:80','http')
('http', '1.2.3.4', '80', '', '', '')

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 13:22

Message:
Logged In: YES 
user_id=1188172

Will look into it. Should be easy to fix.

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 21:55

Message:
Logged In: YES 
user_id=752496

The problem is still present in Py2.3.4.

IMO, it should support dirs without the "http://" or raise
an error if it's not present (never fail silently!).

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-14 04:18

Message:
Logged In: YES 
user_id=589306

Ok, I researched this a bit, and the situation isn't as
simple as it first appears. The RFC that urlparse tries to
follow is at http://www.faqs.org/rfcs/rfc1808.html and
notice specifically sections 2.1 and 2.2.

It seems to me that the source code follows rfc1808
religiously, and in that sense it does the correct thing.
According to the RFC, the netloc should begin with a '//',
and since your example didn't include one then it technical
was an invalid URL. Here is another example where it seems
Python fails to do the right thing:

&gt;&gt;&gt; urlparse.urlparse('python.org')
('', '', 'python.org', '', '', '')
&gt;&gt;&gt; urlparse.urlparse('python.org', 'http')
('http', '', 'python.org', '', '', '')

Note that it is putting 'python.org' as the path and not the
netloc. So the problem isn't limited to just when you use a
scheme parameter and/or a port number. Now if we put '//' at
the beginning, we get:

&gt;&gt;&gt; urlparse.urlparse('//python.org')
('', 'python.org', '', '', '', '')
&gt;&gt;&gt; urlparse.urlparse('//python.org', 'http')
('http', 'python.org', '', '', '', '')

So here it does the correct thing.

There are two problems though. First, it is common for
browsers and other software to just take a URL without a
scheme and '://' and assume it is http for the user. While
the URL is technically not correct, it is still common
usage. Also, urlparse does take a scheme parameter. It seems
as though this parameter should be used with a scheme-less
URL to give it a default one like web browsers do.

So somebody needs to make a decision. Should urlparse follow
the RFC religiously and require '//' in front of netlocs? If
so, I think the documentation should give an example showing
this and showing how to use the 'scheme' parameter. Or
should urlparse use the more commonly used form of a URL
where '//' is omitted when the scheme is omitted? If so,
urlparse.py will need to be changed. Or maybe another
fuction should be added to cover whichever behaviour
urlparse doesn't cover.

In any case, you can temporarily solve your problem by
making sure that URL's without a scheme have '//' at the
front. So your example becomes:

&gt;&gt;&gt; urlparse.urlparse('//1.2.3.4:80', 'http')
('http', '1.2.3.4:80', '', '', '', '')



----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-14 02:39

Message:
Logged In: YES 
user_id=589306

Sorry, previous comment got cut off...

urlparse.urlparse takes a url of the format:
    &lt;scheme&gt;://&lt;netloc&gt;/&lt;path&gt;;&lt;params&gt;?&lt;query&gt;#&lt;fragment&gt;

And returns a 6-tuple of the format:
    (scheme, netloc, path, params, query, fragment).

An example from the library refrence takes:
    urlparse('http://www.cwi.nl:80/%7Eguido/Python.html')

And produces:
    ('http', 'www.cwi.nl:80', '/%7Eguido/Python.html', '',
'', '')

--------------------------------

Note that there isn't a field for the port number in the
6-tuple. Instead, it is included in the netloc. Urlparse
should handle your example as:

&gt;&gt;&gt; urlparse.urlparse('1.2.3.4:80','http') 
('http', '1.2.3.4:80', '', '', '', '')

Instead, it gives the incorrect output as you indicated.


----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2003-06-14 02:26

Message:
Logged In: YES 
user_id=589306

urlparse.urlparse takes a url of the format:
    &lt;scheme&gt;://&lt;netloc&gt;/&lt;path&gt;;&lt;params&gt;?&lt;query&gt;#&lt;fragment&gt;

And returns a 6-tuple of the format:
    (scheme, netloc, path, params, query, fragment).

An example from the library refrence takes:


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:25 -0800
Subject: [ python-Bugs-729103 ] Cannot retrieve name of super object
Message-ID: <E1FBAqz-0008Mu-HG@sc8-sf-web6.sourceforge.net>

Bugs item #729103, was opened at 2003-04-28 18:47
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470

Please note that this 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.3
Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: Michele Simionato (michele_s)
>Assigned to: Georg Brandl (gbrandl)
Summary: Cannot retrieve name of super object

Initial Comment:
I see that in Python 2.3b1 many problems of super
have been fixed, but this one is still there:
I cannot retrieve the __name__ of a super object.
This generates problems with pydoc, for instance:

&gt;&gt;&gt; class C(B):
...     sup=super(B)
&gt;&gt;&gt; help(C)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;/usr/local/lib/python2.3/site.py&quot;, line 293, in
__call__
    return pydoc.help(*args, **kwds)
  File &quot;/usr/local/lib/python2.3/pydoc.py&quot;, line 1539,
in __call__
    self.help(request)
  File &quot;/usr/local/lib/python2.3/pydoc.py&quot;, line 1575,
in help
    else: doc(request, 'Help on %s:')
  File &quot;/usr/local/lib/python2.3/pydoc.py&quot;, line 1368,
in doc
    pager(title % desc + '\n\n' + text.document(object,
name))
  File &quot;/usr/local/lib/python2.3/pydoc.py&quot;, line 279,
in document
    if inspect.isclass(object): return
self.docclass(*args)
  File &quot;/usr/local/lib/python2.3/pydoc.py&quot;, line 1122,
in docclass
    lambda t: t[1] == 'method')
  File &quot;/usr/local/lib/python2.3/pydoc.py&quot;, line 1057,
in spill
    name, mod, object))
  File &quot;/usr/local/lib/python2.3/pydoc.py&quot;, line 280,
in document
    if inspect.isroutine(object): return
self.docroutine(*args)
  File &quot;/usr/local/lib/python2.3/pydoc.py&quot;, line 1145,
in docroutine
    realname = object.__name__
AttributeError: 'super' object has no attribute
'__name__'

P.S. I seem to remember I already submitted this
bug (or feature request, as you wish ;) but I don't
find it in bugtracker and I had no feedback; maybe
it wasn't sent at all due to some connection problem.
If not, please accept my apologies.

    Michele Simionato

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-10-01 16:34

Message:
Logged In: YES 
user_id=1188172

Fixed in Lib/pydoc.py r1.107, 1.100.2.5.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-08-28 00:18

Message:
Logged In: YES 
user_id=357491

The patch was applied.  It's possible one of the subsequent 
patches broke it.

Opening patch again.

----------------------------------------------------------------------

Comment By: Michele Simionato (michele_s)
Date: 2003-08-19 00:23

Message:
Logged In: YES 
user_id=583457

I've just checked today with Python 2.3 (pydoc
revision 1.86):

class B(object):
    pass

class C(B):
    sup=super(B)

help(C)

still gives the same error!

What happened? Did you forgot to add the patch to 
the standard distribution? The bug is not close!


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-11 23:39

Message:
Logged In: YES 
user_id=357491

Patched pydoc (revision 1.84) to try an object as &quot;other&quot; if what 
inspect identifies it as does not work based on its assumptions.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 23:44

Message:
Logged In: YES 
user_id=357491

The issue is inspect.isroutine is saying that the instance is a 
callable object since it is also a non-data descriptor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:25 -0800
Subject: [ python-Bugs-735248 ] urllib2 parse_http_list wrong return
Message-ID: <E1FBAqz-0008Mp-CW@sc8-sf-web6.sourceforge.net>

Bugs item #735248, was opened at 2003-05-09 14:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735248&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Georg Brandl (gbrandl)
Summary: urllib2 parse_http_list wrong return

Initial Comment:
parse_http_list should split a string on commas, unless 
the commas are within a quoted-string.  (It allows only 
the &quot;&quot; quote, and not the single-quote, but this seems to 
follow the RFC.)

If there are not quoted-strings, it repeats the first tokens 
as part of subsequent tokens.

parse_http_list ('a,b') =&gt; ['a','a,b']
It should return ['a','b']

parse_http_list ('a,b,c') =&gt; ['a','a,b','a,b,c']
It should return ['a','b','c']


Patch:  On (cvs version) line 882, when no quote is found 
and inquote is false, reset the start position to after the 
comma.

        if q == -1:
            if inquote:
                raise ValueError, &quot;unbalanced quotes&quot;
            else:
                list.append(s[start:i+c])
                i = i + c + 1
                start = i            #New line
                continue



----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 22:21

Message:
Logged In: YES 
user_id=1188172

Fixed the algorithm in Lib/urllib2.py r1.86, 1.77.2.3
Added testcase in Lib/test/test_urllib2.py r1.22, 1.19.2.1

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-11-09 23:53

Message:
Logged In: YES 
user_id=261020

This function doesn't deal with quoting of characters inside 
quoted-strings, either.  In particular, it doesn't deal with \&quot;, \\, 
and \, (see RFC 2616, section 2.2, quoted-pair). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735248&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:13:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:13:25 -0800
Subject: [ python-Bugs-728515 ] mmap\'s resize method resizes the file in
	win32 but not unix
Message-ID: <E1FBAqz-0008Mz-Ml@sc8-sf-web6.sourceforge.net>

Bugs item #728515, was opened at 2003-04-27 17:44
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Myers Carpenter (myers_carpenter)
>Assigned to: Georg Brandl (gbrandl)
>Summary: mmap\'s resize method resizes the file in win32 but not unix

Initial Comment:
In the resize method under win32 you have something
like this:

	/* Move to the desired EOF position */
        SetFilePointer (self-&gt;file_handle,
                new_size, NULL, FILE_BEGIN);
        /* Change the size of the file */
        SetEndOfFile (self-&gt;file_handle);

Which resizes the file

Under Unix you need to call 

   ftruncate(self-&gt;fileno, new_size)

before calling remap() to make it do the same thing.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 07:19

Message:
Logged In: YES 
user_id=1188172

Okay, committed as
Modules/mmapmodule.c; 2.50; 2.48.4.1
Lib/test/test_mmap.py; 1.33; 1.30.18.1
Doc/lib/libmmap.tex; 1.12; 1.9.4.2


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 20:50

Message:
Logged In: YES 
user_id=1188172

Attaching patch which duplicates the file handle under UNIX
too (btw, the size() method was broken too), mimics Windows
behaviour with resize(), adds a testcase for this and
clarifies the docs.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 20:12

Message:
Logged In: YES 
user_id=1188172

This is not trivial since the filehandle can be closed at
the time the ftruncate() would be necessary.

The Windows specific code duplicates the filehandle upon
mmap creation, perhaps the UNIX code should do this too?
Then, the ftruncate call can be inserted.

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 23:51

Message:
Logged In: YES 
user_id=752496

Reopened as posted that still is a bug.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-30 23:32

Message:
Logged In: YES 
user_id=341410

The problem still persists in Python 2.3 and 2.4.  A quick
read of mmapmodule.c shows that ftruncate() is not being
called within the non-windows portion of mmap_resize_method().

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 18:59

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:55

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-05-04 12:36

Message:
Logged In: YES 
user_id=21627

Would you like to contribute a patch? Please make sure to
include changes to the documentation and test suite.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 14:14:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 05:14:29 -0800
Subject: [ python-Feature Requests-1216944 ] Add Error Code Dictionary to
	urllib2
Message-ID: <E1FBAs1-0008N9-Rn@sc8-sf-web6.sourceforge.net>

Feature Requests item #1216944, was opened at 2005-06-08 09:45
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470

Please note that this message 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: Accepted
Priority: 5
Submitted By: Mike Foord (mjfoord)
>Assigned to: Georg Brandl (gbrandl)
Summary: Add Error Code Dictionary to urllib2

Initial Comment:
In order to properly handle 'HTTPError's from 
urllib2.urlopen you need to map error codes to an error 
message.

I suggest the addition of the following dictionary to do 
that  :

    # Table mapping response codes to messages; 
entries have the
    # form {code: (shortmessage, longmessage)}.
    httpresponses = {
        100: ('Continue', 'Request received, please 
continue'),
        101: ('Switching Protocols',
              'Switching to new protocol; obey Upgrade 
header'),

        200: ('OK', 'Request fulfilled, document follows'),
        201: ('Created', 'Document created, URL follows'),
        202: ('Accepted',
              'Request accepted, processing continues off-
line'),
        203: ('Non-Authoritative Information', 'Request 
fulfilled from cache'),
        204: ('No response', 'Request fulfilled, nothing 
follows'),
        205: ('Reset Content', 'Clear input form for further 
input.'),
        206: ('Partial Content', 'Partial content follows.'),

        300: ('Multiple Choices',
              'Object has several resources -- see URI list'),
        301: ('Moved Permanently', 'Object moved 
permanently -- see URI list'),
        302: ('Found', 'Object moved temporarily -- see URI 
list'),
        303: ('See Other', 'Object moved -- see Method 
and URL list'),
        304: ('Not modified',
              'Document has not changed since given time'),
        305: ('Use Proxy',
              'You must use proxy specified in Location to 
access this '
              'resource.'),
        307: ('Temporary Redirect',
              'Object moved temporarily -- see URI list'),

        400: ('Bad request',
              'Bad request syntax or unsupported method'),
        401: ('Unauthorized',
              'No permission -- see authorization schemes'),
        402: ('Payment required',
              'No payment -- see charging schemes'),
        403: ('Forbidden',
              'Request forbidden -- authorization will not 
help'),
        404: ('Not Found', 'Nothing matches the given URI'),
        405: ('Method Not Allowed',
              'Specified method is invalid for this server.'),
        406: ('Not Acceptable', 'URI not available in 
preferred format.'),
        407: ('Proxy Authentication Required', 'You must 
authenticate with '
              'this proxy before proceeding.'),
        408: ('Request Time-out', 'Request timed out; try 
again later.'),
        409: ('Conflict', 'Request conflict.'),
        410: ('Gone',
              'URI no longer exists and has been 
permanently removed.'),
        411: ('Length Required', 'Client must specify 
Content-Length.'),
        412: ('Precondition Failed', 'Precondition in 
headers is false.'),
        413: ('Request Entity Too Large', 'Entity is too 
large.'),
        414: ('Request-URI Too Long', 'URI is too long.'),
        415: ('Unsupported Media Type', 'Entity body in 
unsupported format.'),
        416: ('Requested Range Not Satisfiable',
              'Cannot satisfy request range.'),
        417: ('Expectation Failed',
              'Expect condition could not be satisfied.'),

        500: ('Internal error', 'Server got itself in trouble'),
        501: ('Not Implemented',
              'Server does not support this operation'),
        502: ('Bad Gateway', 'Invalid responses from 
another server/proxy.'),
        503: ('Service temporarily overloaded',
              'The server cannot process the request due to 
a high load'),
        504: ('Gateway timeout',
              'The gateway server did not receive a timely 
response'),
        505: ('HTTP Version not supported', 'Cannot fulfill 
request.'),
        }

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-14 06:41

Message:
Logged In: YES 
user_id=1188172

Okay. Checked in (without the second field) as
* Lib/urllib2.py r1.83
* Lib/test/test_urllib2.py r1.20
* Doc/lib/liburllib2.tex r1.23
* Misc/NEWS r1.1314

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-13 22:24

Message:
Logged In: YES 
user_id=80475

Reinfeld, you are welcome to put this in.

Pay attention to the little details.  Look-up the http
protocol spec and use the exact spelling and exact
upper/lower letter case.  

Only include the second field of the tuple if it is
standard.  I quickly looked at a couple of different sources
and found that the "meaning" field was worded diffferently.
 If there is not a standard word-for-word official
definition, then leave that part out and just have a simple
mapping:  {500: "Internal Error", 501: "Not Implemented, ...}.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-08 16:38

Message:
Logged In: YES 
user_id=1188172

+1. This would simplify delivering messages to users.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 16:24:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 07:24:53 -0800
Subject: [ python-Bugs-810887 ] os.stat returning a time = -1
Message-ID: <E1FBCuD-0006DD-8R@sc8-sf-web5.sourceforge.net>

Bugs item #810887, was opened at 2003-09-22 23:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810887&group_id=5470

Please note that this message 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.2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat returning a time = -1

Initial Comment:
(WIN32)  copystat's call to os.stat sometimes returns a
time
value = -1, on which the following call to os.utime
bombs.  
A temporary work-around is attached.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:24

Message:
Logged In: YES 
user_id=849994

Closing as the OP didn't upload his patch.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 11:01

Message:
Logged In: YES 
user_id=29957

There's no file attached! You have to upload the file and
check the  little box.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810887&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 16:27:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 07:27:15 -0800
Subject: [ python-Bugs-758504 ] test_sax fails on python 2.2.3 &amp;
	patch for regrtest.py
Message-ID: <E1FBCwV-0006DO-BV@sc8-sf-web5.sourceforge.net>

Bugs item #758504, was opened at 2003-06-21 18:50
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470

Please note that this message 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.2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: PieterB (pieterb)
Assigned to: Martin v. L??wis (loewis)
Summary: test_sax fails on python 2.2.3 &amp; patch for regrtest.py

Initial Comment:
Hi,

1) testing using the FreeBSD ports version of Python 
2.2.3 fails (both on FreeBSD 5 and FreeBSD 4.8). The 
test test_sax.py fails, because test_sax seems to 
require expat2 (?), which isn't available by default on 
FreeBSD).

2) I've also patched regrtest.py so that it works on 
FreeBSD 4/5
(Chimp at IRC tested it on FreeBSD4.8), can somebody
apply the patches from regrtest.py to CVS?
Source: http://www.gewis.nl/~pieterb/python/bugs-
2.2.3/

In detail:

1) testing using the FreeBSD ports version of Python 
2.2.3 failed
==========================================
========================

Using Python 2.2.3 from recent FreeBSD ports
&quot;cd /usr/ports/lang/python ; make ; cd work/Python-
2.2.3 ; make test&quot;
gives:

174 tests OK.
1 test failed:
    test_sax
18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on freebsd5.
*** Error code 1

Stop in /usr/ports/lang/python/work/Python-2.2.3.

----------------------------------------------------

cd /usr/ports/lang/python/work/Python-2.2.3/Lib/test
../../python test_sax.py
gives:
test_support.TestFailed: 3 of 40 tests failed

...
Expected:
[('start', ('http://xml.python.org/1', 'abc'), 'abc'),
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/1', u'abc'), None),
 ('start', (u'http://xml.python.org/2', u'def'), None),
 ('end', (u'http://xml.python.org/2', u'def'), None),
 ('start', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'abc'), None)]
Failed test_expat_nsdecl_pair_diff
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'),
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('start', (u'http://xml.python.org/', u'def'), None),
 ('end', (u'http://xml.python.org/', u'def'), None),
 ('start', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_pair_same
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'abc'),
 ('end', ('http://xml.python.org/', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_single

I managed to fixed this by patching test_sax.py,
see http://gewis.nl/~pieterb/python/bugs-2.2.3/

2) i've patched regrtest.py so that it works on FreeBSD 
4/5
==========================================
=================
This make it possible to run 'make test' on Python.
It will give the following output:
  175 tests OK.
  18 tests skipped:
    test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
    test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
    test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
    test_unicode_file test_winreg test_winsound
  Those skips are all expected on freebsd5.

Can anybody confirm that it's ok to skip those tests.  
Can anybody
download the patched version of regrtest.py from the 
URL above check
it into Python CVS?

Thanks to Chimp at IRC for testing it on FreeBSD4.8
Thanks to itz at irc and others at IRC:#python for their 
help.

PieterB

--
http://zwiki.org/PieterB





----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:27

Message:
Logged In: YES 
user_id=849994

Expectations for FreeBSD 5 have been added to regrtest.py.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-23 10:09

Message:
Logged In: YES 
user_id=250749

I haven't looked to see what the port is doing, but just
using configure, I find with 2.2.3 on FreeBSD 4.8:-
- test_locale fails becuase &quot;en_US&quot; is not a supported
locale; the test would have to use one of &quot;en_US.US-ASCII&quot;,
&quot;en_US.ISO8859-1&quot; or &quot;en_US.ISO8859-15&quot; (I have no idea
which would be most appropriate).

- test_nis will fail if it can't find a NIS master for any
NIS map.

- test_socket_ssl &amp; test_socketserver will be skipped if the
network resource is not enabled.

- test_sax &amp; test_pyexpat both pass.

FreeBSD has its own expat package (which is using expat
1.95.6 on both 4.8 &amp; 5.1).  pyexpat is a separately
selectable package/port.  If you haven't installed the
pyexpat package, or built same from the port, then test_sax
&amp; test_pyexpat are both going to be skipped.

I'm still looking at a couple of other issues with building
on 5.1.

Given that FreeBSD 5.0 was a technology preview not intended
for production use, and a STABLE branch will not be declared
until at least after 5.2 is released, it will not be trivial
to keep track of build issues until release of 5.2.  I am
not in a position to track the FreeBSD 5.x CVS, but I will
try and keep up with releases.

I'm not sure whether anyone has yet stepped in to take Alan
Eldridge's place as maintainer of FreeBSD's ports of Python
&amp; various modules. IMO, many of the issues here should have
been taken up with the Python port maintainer, rather than
being dealt with in Python's tracker (I tried to contact
AlanE about some of this not long before he died).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-06-22 17:11

Message:
Logged In: YES 
user_id=21627

I'm unsure why test_locale, test_nis, and test_socket_ssl
would be skipped. 

I'm also surprised test_pyexpat is skipped when test_minidom
is executed. This is impossible.

----------------------------------------------------------------------

Comment By: PieterB (pieterb)
Date: 2003-06-21 19:00

Message:
Logged In: YES 
user_id=458461

See also: http://sourceforge.net/tracker/?
group_id=5470&amp;atid=105470&amp;func=detail&amp;aid=621579

a search on &quot;test_sax&quot; indicates that isn't running on quite a 
lot of other platforms.

PieterB
--
http://zwiki.org/PieterB

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 16:30:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 07:30:59 -0800
Subject: [ python-Bugs-820953 ] dbm Error
Message-ID: <E1FBD07-0002v6-Mv@sc8-sf-web1.sourceforge.net>

Bugs item #820953, was opened at 2003-10-09 23:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&group_id=5470

Please note that this 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.2.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Jim Gifford (giffordj)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbm Error

Initial Comment:
Receive the following error during make install of python 
2.3.2. Any suggestions or is it safe to ignore.

building 'dbm' extension
gcc -pthread -DNDEBUG -g -march=pentium2 -mmmx -
O2 -pipe -Wall -Wstrict-prototypes -fPIC -fno-strict-
aliasing -DHAVE_NDBM_H -I. -I/usr/src/Python-
2.3.2/./Include -I/usr/local/include -I/usr/src/Python-
2.3.2/Include -I/usr/src/Python-2.3.2 -
c /usr/src/Python-2.3.2/Modules/dbmmodule.c -o 
build/temp.linux-i686-2.3/dbmmodule.o
gcc -pthread -shared build/temp.linux-i686-
2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686-
2.3/dbm.so
*** WARNING: renaming &quot;dbm&quot; since importing it failed: 
build/lib.linux-i686-2.3/dbm.so: undefined symbol: 
dbm_firstkey
running build_scripts


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:30

Message:
Logged In: YES 
user_id=849994

Do you still have problems with 2.4?

----------------------------------------------------------------------

Comment By: Jim Gifford (giffordj)
Date: 2003-10-12 07:42

Message:
Logged In: YES 
user_id=492775

Upon further research, when this error occurs installation 
does continue, but libpython2.3.a is never created.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 16:39:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 07:39:04 -0800
Subject: [ python-Bugs-856841 ] a exception ocurrs when compiling a Python file
Message-ID: <E1FBD7w-0006zs-LH@sc8-sf-web3.sourceforge.net>

Bugs item #856841, was opened at 2003-12-09 12:57
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470

Please note that this 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.2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Pablo Yabo (pablo_yabo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a exception ocurrs when compiling a Python file

Initial Comment:
a exception ocurrs when compiling some big python files 
(more than 250kb) using the debug library 
(python22_d.dll).
When using the release library in the release version of 
my application the files compile succesfully. 
Attached is the stack trace.



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:39

Message:
Logged In: YES 
user_id=849994

This is likely to be resolved with the new AST compiler in 2.5.

If not, please open another bug report then.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-12-16 15:37

Message:
Logged In: YES 
user_id=593130

If, by 'exception', PY indeed means a system crash rather 
than a Python exception, then I agree that more graceful 
termination would be desireable.  However, I believe someone 
once pointed out on Py-Dev list that memory failures may 
make interpreter operation, even to produce a Python stack 
trace, impossible.  In any case, the details of system 
software and hardware, including memory, needed to even 
discuss this, are still missing.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-12-15 10:04

Message:
Logged In: YES 
user_id=45365

I agree with the original poster that this is a bug. While it may not 
be fixable (and definitely not in the general case) you should get a 
decent error message from Python (at the very least a 
MemoryError), not a crash of the interpreter.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-12-15 04:26

Message:
Logged In: YES 
user_id=593130

I do not believe this is a compiler bug.  While compiler input 
may by theoretically unbounded, all practical compilers have 
practical limitations that often depend, in part, on the 
amount of memory on your particular system.  This is one 
reason for import and include mechanisms.

As I understand the stack trace, the exception occured 
during an attempt to reallocate memory (ie, move an object 
to a larger block).  (Including Python's exception trace would 
make this clearer).  I presume debug mode uses more memory 
so you hit the limit sooner with that mode.

Your solutions are to either 1) add more memory to your 
computer (should probably work) or try on a system with 
more memory or 2) break your source into more modules 
(certain to work if the problem is, indeed, simply running out 
of memory).  250K is not merely big but huge.  The largest 
file in the standard lib is under 100K and the median is around 
10K.

Unless you have more reason to think this a bug, please 
withdraw or close.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 16:40:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 07:40:33 -0800
Subject: [ python-Bugs-877121 ] configure detects incorrect compiler
	optimization
Message-ID: <E1FBD9N-0006FJ-Qt@sc8-sf-web5.sourceforge.net>

Bugs item #877121, was opened at 2004-01-14 21:05
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=877121&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Georg Schwarz (gschwarz)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure detects incorrect compiler optimization

Initial Comment:
the configure script checks whether $CC compiles with -OPT:Olimit=0. For IRIX 5.3's cc, for example, although it is not supported, it only gives a warning and compiles nonetheless:

cc -OPT:Olimit=0 c.c
cc: Warning: -OPT options are ignored

The configure script tests do not check for this, so they do use that option. It's not so much of a problem that we constantly get respective warnings while
compiling; what's more of a problem (and therefore I call it a bug) is that python's configure does not go on checking for other optimizations. Therefore, on IRIX 5.3 with cc the -Olimit=1500 option, which would be needed, is not being configured.

Suggestion: also check whether there's anything on stderr while compiling the test code, and if so, don't use that particular option. Assuming make uses some /bin/sh you might use cc -OPT:Olimit=0 c.c 2>&1 >/dev/null and check whether there's any output (or maybe there are more elegant solutions).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=877121&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 16:44:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 07:44:43 -0800
Subject: [ python-Bugs-877124 ] configure links unnecessary library libdl
Message-ID: <E1FBDDP-0006Fo-5p@sc8-sf-web5.sourceforge.net>

Bugs item #877124, was opened at 2004-01-14 21:08
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=877124&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Georg Schwarz (gschwarz)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure links unnecessary library libdl

Initial Comment:
Python's configure adds -ldl to LIBS on irix5. This is not needed, and it produces compiler warnings that this lib did not resolve any symbols and can be removed. Possibly it's adding an unnecessary dependence on that lib.
If I understand the configure script correctly it checks whether the following code is compiled and linked correctly with -ldl:

char dlopen();

int main() {
dlopen()
; return 0; }

Now this code compiles and links on IRIX 5.3 without any specific library. With -ldl you get a warning

lorenz 12% cc x.c 
lorenz 13% cc x.c -ldl
ld:
The shared object /usr/lib/libdl.so did not resolve any symbols.
        You may want to remove it from your link line.
lorenz 14% cat x.c
char dlopen();

int main() {
dlopen()
; return 0; }
lorenz 15% 

probably the configure script should check for any output to stderr when doing the compiling/linking attempt with the sample code.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-01-18 00:41

Message:
Logged In: YES 
user_id=21627

Georg Schwarz indicated in private mail that he is not able
to implement that change.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-01-17 23:58

Message:
Logged In: YES 
user_id=21627

Would you like to contribute a patch for that? configure
should check whether -ldl is needed to find dlopen.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=877124&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 18:17:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 09:17:18 -0800
Subject: [ python-Bugs-518846 ] exception cannot be new-style class
Message-ID: <E1FBEf0-0006Va-SQ@sc8-sf-web5.sourceforge.net>

Bugs item #518846, was opened at 2002-02-17 20:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470

Please note that this 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
Submitted By: Magnus Heino (magnusheino)
Assigned to: Guido van Rossum (gvanrossum)
Summary: exception cannot be new-style class

Initial Comment:
[magnus at gills magnus]$ python2.2
Python 2.2 (#1, Jan 26 2002, 14:27:24)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more information.
&gt;&gt;&gt; class foo(object):
...     pass
...
&gt;&gt;&gt; raise foo()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not foo
&gt;&gt;&gt;


----------------------------------------------------------------------

Comment By: Robey Pointer (robey1)
Date: 2004-12-17 20:46

Message:
Logged In: YES 
user_id=1179122

(I wish we could do this in email instead of cluttering up
an already-messy bug...)

Forget about throwing non-Exception-based objects: it's a
red herring.  The bug to focus on is the title: "exception
cannot be new-style class".

Bottom line:  This subclass of Exception can not be raised
in python 2.3:

class MyException (Exception, object): pass

pje's comment below from (2002-07-11 13:12) is a nice
summary of how to solve it.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-12-16 13:00

Message:
Logged In: YES 
user_id=21627

This statement, as literally made, is incorrect:

>>> class X(Exception):
...   pass
...
>>> e=X()
>>> type(e)
<type 'instance'>
>>> raise e
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
__main__.X: <__main__.X instance at 0x401f2b4c>

In this example, type(e) works, and x is an object which has
Exception among its base classes. Still, I can throw x,
despite your claim that I cannot.

Even if I interpret your statement more literally (i.e. that
you are talking about objects for which type(e) is a
new-style class): Why do you think this statement explains
there is a bug?

As for why it is a new feature: it currently doesn't work,
and anybody trying it will quickly find out that it doesn't
work. The language reference says it doesn't work. The
TypeError you get says it doesn't work. So that it doesn't
work is clearly intentional; changing it will be a new feature.

Notice that it is very difficult to implement this feature,
as something needs to happen with strings and subtypes of
str. Currently, string exceptions are caught by identity. If
arbitrary objects can be used as exceptions, then strings
should also be caught by type, not by identity; this is a
backwards-incompatible change.

A clean solution would be to deprecate string exceptions in
2.5, completely ban them in 2.6, and allow arbitrary objects
to act as exceptions in 2.7. 

Please do read the entire thread of this RFE.

----------------------------------------------------------------------

Comment By: Robey Pointer (robey1)
Date: 2004-12-15 23:39

Message:
Logged In: YES 
user_id=1179122

Let me try to rephrase the problem so that it's obvious that
this is a bug, and not a feature:

'type(e)' on an exception will not work in 2.3, and cannot
be made to work from within python code.  There's no way to
throw an exception (ie an object with Exception in its
ancestor list) that 'type(e)' will work on. :(


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-12-15 21:59

Message:
Logged In: YES 
user_id=21627

Whatever the solution to this problem, it is for sure that
2.4.x won't see it, because it will be a new feature.

----------------------------------------------------------------------

Comment By: Robey Pointer (robey1)
Date: 2004-12-15 21:08

Message:
Logged In: YES 
user_id=1179122

This caused me an hour of debugging a few nights ago.  When
using unified types, it's very confusing to find that not
only does Exception not follow new-style object semantics,
but it *can't*.  Doing the obvious hack:

class MyException (Exception, object):
    pass

does not work!  The interpreter (2.3) refuses to let you
raise a unified-type object.  And if you subclass
exclusively from Exception, type(obj) returns 'instance'
instead of the class (due to being an old-style object).

Please fix this for 2.4!


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-25 02:05

Message:
Logged In: YES 
user_id=752496

Reproduced the bug in Py2.3. I think that this is a bug, at
least because we "encourage" users to derive exceptions from
Exception, so they should be able to not do it.

The moment we say that they "must" derive from Exception,
this can be closed (of course, this is my *very* personal
opinion, ;)

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-07-11 20:12

Message:
Logged In: YES 
user_id=56214

Just to make things even more interesting, the current
'raise' code *will* let you raise a new-style instance that
derives from 'tuple'...  of course, what it actually raises
is the first element of said tuple-like thing.

It seems to me that the very first thing that should be
checked is whether the first argument to 'raise' is an
instance of Exception, and if so, take its type and go from
there.  This would support both old and new-style instances
of Exception subclasses, and I believe is the recommended
approach to using 'raise'.  (I.e., raise an instance of
something that subclasses Exception.)  All the other items
like strings, tuples, etc., should be checked *after* a
check for the &quot;standard&quot; approach, yes?


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2002-07-11 17:07

Message:
Logged In: YES 
user_id=89016

test.py is a little script that executes various test cases.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2002-07-11 16:12

Message:
Logged In: YES 
user_id=89016

What about the following patch (diff.txt):

It allows new style objects as exceptions and makes catching
exceptions by basetype possible:
    class newint(int):
        pass
    try:
        raise newint(42)
    except int, exc:
        print exc

With this patch subinstances of str become raisable and will
be caught be type not identity. This could be changed to
explicitely forbid str subinstances.

And
  raise type(None), None
becomes ambiguous: It is interpreted as
  raise type(None)
i.e. it raises the type(None) object as an exception, not
the object None (which is of type type(None))

As soon as Exception is a new style class we could limit the
allowed objects to (sub)instances of Exception.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-06 00:07

Message:
Logged In: YES 
user_id=6380

Sorry, HEAPTYPE is not the proper way to check for a
new-style class; it would exclude any new-style classes
defined by C code.  I also think that if you want to do this
it should done properly, and allow &quot;raise C, C()&quot; as well.

At best there's agreement that it's not worth trying to fix
Python to allow new-style classes as exceptions when we're
also trying to encourage that exceptions derive from
Exception.

If your module declares its exceptions as deriving from
Exception, a __metaclass__ = type should not have any effect
on the exceptions you declare.  So I'm not sure what your
problem is?

Here's another idea for a patch: a new-style class is
allowed as long as it also inherits from Exception.  (This
is possible!)

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 23:49

Message:
Logged In: YES 
user_id=31392

I don't realize there was agreement on this.  (I didn't 
follow the discussion closely.)  I don't understand why 
exceptions need to pass an isinstance() test on Exception.  
It didn't used to be this way, and it makes it hard to 
convert a module using __metaclass__ = type.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2002-04-05 23:44

Message:
Logged In: YES 
user_id=21627

I thought the agreement was that this is not a bug: You
cannot really expect exceptions to work unless you inherit
from Exception.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 23:38

Message:
Logged In: YES 
user_id=31392

Martin, I think the attached patch is sufficient.  It checks
object type's for Py_TPFLAGS_HEAPTYPE.  I believe this is
the current way to spell &quot;new-style class&quot; although the
spelling is odd if that's the meaning &lt;0.2 wink&gt;.

If this patch makes sense to you, I'll flesh it out with
some test cases and check it in.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2002-02-17 23:44

Message:
Logged In: YES 
user_id=21627

Interesting. I think we need to deprecate, then remove
string exception before allowing arbitrary objects as
exceptions. Or we could allow strings to be caught either by
__builtin__.str, or by an identical string.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 18:19:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 09:19:34 -0800
Subject: [ python-Bugs-613222 ] memory leaks when importing posix module
Message-ID: <E1FBEhC-0006WK-9U@sc8-sf-web5.sourceforge.net>

Bugs item #613222, was opened at 2002-09-23 14:27
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613222&group_id=5470

Please note that this message 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: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: memory leaks when importing posix module

Initial Comment:
The attached program which calls
Py_Initialize/Py_Finalize in a loop demonstrates a
program which grows quite quickly.  This bug effects
2.2.1+ and 2.3.  valgrind reports that the memory is
still reachable, but it seems like a memory leak and
the process definitely grows.

Compile the program with libpython, and run (./mem-test
100000).  Make sure it can import site (which imports
posix module).  While the program is running, do a ps
and watch it grow.  If import site fails, the process
will not grow.

site.py can be as simple as import posix.
I believe the problem is related to
PyStructSequence_Fields for statfs.  But haven't
completely diagnosed the problem.  As I learn more, I
will add comments.

To simply importing or not importing site, mem-test
takes an optional 2nd argument which will
enable/disable loading of site.py.  ./mem-test 100000 1
will prevent import site.

I hope this is understandable, even though the
description wasn't clear.

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 18:04

Message:
Logged In: YES 
user_id=752496

Changed to 2.3 group.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-26 15:16

Message:
Logged In: YES 
user_id=6380

I expect I will have no time to look into this further any
time soon. But if you have fixes that clearly fix leaks,
please check them in!

(Shouldn't this be in the 2.3 group?)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-25 00:37

Message:
Logged In: YES 
user_id=33168

I'm mostly stuck.  I haven't solved the problem, but I do
have some more information.  Attached is a patch to
Object/structseq.c which fixes some problems if memory
allocation fails.  Also, I changed a PyInt_FromLong(1) to
Py_True for __safe_for_unpickling__.  Py_True could also be
used in compile.c::
symtable_load_symbols replacing the variable: implicit.

Some fields which I believe are leaking from the
PyTypeObject are:  tp_members, tp_dict, and tp_bases. 
However, there are more leaks.  I think all the remaining
leaks come from PyType_Ready().  For example, from
add_operators(), PyDescr_NewWrapper().  I thought DECREFing
tp_dict would free these, but it didn't seem to have any effect.

Part of the problem is how should these values be cleaned
up.  Putting cleanup in PyStructSequence_InitType would
guarantee the problem is fixed for all structseqs, but that
doesn't seem like a good idea.  This would assume the
PyTypeObject passed in is initialized.  This is true for
static variables, but not for any other variables.  If
there's a new API for cleanup, all the users of structseq
will need to use it.  Perhaps, this is only an issue in the
core.  I don't know about extension modules.

Finally, I suspect there may be more leaks outside of posix
too.  These seem to mostly come from _Py_ReadyTypes() called
in pythonrun.c::Py_Initialize().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-23 16:32

Message:
Logged In: YES 
user_id=6380

This is a good use of your time.  Thanks for looking into
this! Assign back to me when you have a fix for review or a
stumbling block.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613222&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 18:21:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 09:21:12 -0800
Subject: [ python-Bugs-756842 ] Ms VC 2003 not supported
Message-ID: <E1FBEim-0006Wv-Qa@sc8-sf-web5.sourceforge.net>

Bugs item #756842, was opened at 2003-06-18 21:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470

Please note that this 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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Paolo Invernizzi (darkarathorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ms VC 2003 not supported

Initial Comment:
The current msvccompiler.py has no support for Ms
Visual Studio NET 2003 release.
The registry keys are different than the original
VS.NET and NET Framework

File
&quot;d:\repositories\python\dist\src\lib\distutils\msvccompiler.py&quot;,
line 114, in set_macro
    self.macros[&quot;$(%s)&quot; % macro] = d[key]
KeyError: 'sdkinstallroot'


---
Paolo Invernizzi

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 17:21

Message:
Logged In: YES 
user_id=849994

The preferred compiler is now MS VC 2003, so closing this.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-24 20:07

Message:
Logged In: YES 
user_id=31392

Paolo mentioned this recipe in private email.

The problems are some little changes is some keys in registry...
The MSVS is reported as 7.1, and at line 118 is turned to:
- vsbase = r&quot;Software\Microsoft\VisualStudio\%s.0&quot; % version
+ vsbase = r&quot;Software\Microsoft\VisualStudio\%s.1&quot; % version

The .NET framework is the 1.1,  and line 123 is:
- self.set_macro(&quot;FrameworkSDKDir&quot;, net, &quot;sdkinstallroot&quot;)
+ self.set_macro(&quot;FrameworkSDKDir&quot;, net, &quot;sdkinstallrootv1.1&quot;)

Note that the installation of VC71 *wants* this SDK, not the
old 1.0, so 
there is no confusion...
VC7 -&gt; SDK 1.0
VC71 -&gt; SDK 1.1


----------------------------------------------------------------------

Comment By: Paolo Invernizzi (darkarathorn)
Date: 2003-06-23 07:58

Message:
Logged In: YES 
user_id=172594

__revision__ = &quot;$Id: msvccompiler.py,v 1.56 2003/05/14
19:48:57 lemburg Exp $&quot;


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-06-21 13:48

Message:
Logged In: YES 
user_id=21627

What version of msvccompiler.py are you using? Specifically,
what is its __revision__?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756842&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 18:38:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 09:38:16 -0800
Subject: [ python-Bugs-713601 ] site.py breaks if prefix is empty
Message-ID: <E1FBEzI-0003MB-Ks@sc8-sf-web1.sourceforge.net>

Bugs item #713601, was opened at 2003-04-01 23:40
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470

Please note that this message 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: Fixed
Priority: 5
Submitted By: Lalo Martins (lalo)
Assigned to: Nobody/Anonymous (nobody)
Summary: site.py breaks if prefix is empty

Initial Comment:
verified in 2.3a1 and 2.2.2:

prefixes = [sys.prefix]
if sys.exec_prefix != sys.prefix:
    prefixes.append(sys.exec_prefix)
for prefix in prefixes:
    if prefix:
        # do stuff - in particular, define the
&quot;sitedir&quot; variable
        # and add site-packages to the path
del prefix, sitedir

if sys.prefix == sys.exec_prefix and both are empty
(which is the case if you compile with --prefix=/ as
for the
Gnu OS for example), this will have two unfortunate
results:

1. site-packages will not be added to the path.

2. site.py will abort with a NameError (it tries to del
sitedir
which isn't defined)

The fix seems to be as simple as removing the &quot;if prefix&quot;
line.  From mailing list archives, it seems to have been
added to cope with unusual loading environments related
to windows and COM - in this case, there is probably a
safer way to check for this condition.  If the prefix is
empty, this just means it's the root, and no further
assumptions should be made.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 17:38

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 42522, 42523.

----------------------------------------------------------------------

Comment By: Daniel Goertzen (goertzen)
Date: 2004-08-09 21:38

Message:
Logged In: YES 
user_id=843814

Refer to patch 931938.  Incidentally someone else just
complained that I forgot to actually upload the file, so I
just put it there today.  

The patch fixes the prefix search as described in step 3 in
the comments of getpath.c.  Looking at the code that the
patch fixes, it should be pretty easy to see how the
reduce() function can chop the path down to an empty string
when prefix and exec_prefix are the root directory.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-09 20:47

Message:
Logged In: YES 
user_id=357491

The 2.3 maintenance branch is the CVS version of the 2.3 tree.  But if 
you tried this against 2.3.4 chances are that is close enough.

Unfortunately under OS X I get '/' for sys.prefix and not an empty string 
so I can't debug this.

----------------------------------------------------------------------

Comment By: Daniel Goertzen (goertzen)
Date: 2004-08-09 15:03

Message:
Logged In: YES 
user_id=843814

Not too sure what you mean by maintenance branch, but 2.3.4
and today's CVS python/dist/src tree still produced an empty
string for sys.prefix when configured with --prefix=/

FYI, I install my root pefix python into a separate
directory by running "make install prefix=mydir".  "mydir"
is the root filesystem for an embedded device that we make.
 For testing, I chroot to mydir and can run python.  The
overall procedure is:

./configure --prefix=/
make
make install prefix=mydir
chroot mydir
python

I don't think the install and chroot shenanigans make any
difference, but I thought I'd mention it in case I'm doing
something dumb.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-07 21:39

Message:
Logged In: YES 
user_id=357491

I just tried compiling on the 2.3 maintenance branch with --prefix=/ and 
I had sys.prefix be set to '/'.  Can you check to see if you are still having 
sys.prefix set to an empty string?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-07 19:58

Message:
Logged In: YES 
user_id=357491

The NameError problem has been fixed.

----------------------------------------------------------------------

Comment By: Daniel Goertzen (goertzen)
Date: 2004-04-08 19:09

Message:
Logged In: YES 
user_id=843814

See this patch:
931938	prefix and exec_prefix as root dir bug

----------------------------------------------------------------------

Comment By: Daniel Goertzen (goertzen)
Date: 2004-04-08 16:01

Message:
Logged In: YES 
user_id=843814

Just ran into the same problem when I configure with --prefix=/

The problem is in getpath.c.  Before trying to find your
lib/python dir based on what you submitted in configure, it
performs a search based on the python execution path
(probably /bin).  It keeps chopping the path down with the
reduce() function and then adds "/lib/python" and sees if a
landmark file is there.  The problem is that reduce() will
freely chop away the last / leaving your prefix as a null
string.

I'm going to try tweaking reduce() so it doesn't hack off
the last / if its the last one.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 22:54

Message:
Logged In: YES 
user_id=357491

Why is sys.prefix == '' if it is set to '/' as the command-line 
argument?  Checking Modules/getpath.c there appears a few 
places where things could go awry if an enviroment variable is 
set that causes the code to think it has already found the 
location before it reaches what the Makefile set PREFIX and 
EXEC_PREFIX to.  The steps used are in the initial comment of 
the file.  Any of those a possible reason for your problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 18:39:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 09:39:52 -0800
Subject: [ python-Bugs-595105 ] AESend on Jaguar
Message-ID: <E1FBF0q-0003MJ-4S@sc8-sf-web1.sourceforge.net>

Bugs item #595105, was opened at 2002-08-14 16:02
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Alexandre Parenteau (aubonbeurre)
Assigned to: Jack Jansen (jackjansen)
Summary: AESend on Jaguar

Initial Comment:
I wonder how many of you guys played with Jaguar 
(OSX 10.2). It is also my
first glance at gcc 3.1 that comes with 10.2. Everything 
was fine for
building Python, except for waste which has an 
obsolete libWaste.a (even in
August 1st Waste 2.1b1) which won't compile with 
gcc3.1. After I recompiled
waste with CodeWarrior 8.2 (MPTP: early access), it 
came OK.

I then run into some problems of checked out files 
because I'm using MacCvs
(see earlier message). I used the 'make 
frameworkinstall' scheme.

Now I'm experiencing the nice new architecture. I 
mostly use python from the
command line to invoke CodeWarrior thru AppleScripts, 
so I almost immeditly
run into a hanging problems of python :

        _err = AESend(&amp;_self-&gt;ob_itself,
                      &amp;reply,
                      sendMode,
                      sendPriority,
                      timeOutInTicks,
                      0L/*upp_AEIdleProc*/,
                      (AEFilterUPP)0);

I had to comment out upp_AEIdleProc (I tried several 
things, but that is the
only thing which helped). Jack, you might want to 
remember this one if the
problem is still in Jaguar. It hangs and finally times out. 
I've looked
inside this function and I can see the signal handling, 
but I'm not sure
what it is for.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-06-05 21:58

Message:
Logged In: YES 
user_id=11375

Jack, any movement on this bug?  Should it simply be closed?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-11-27 21:23

Message:
Logged In: YES 
user_id=45365

Apple are aware of the bug and looking at it. Their bug ID is 3097709.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 11:47

Message:
Logged In: YES 
user_id=45365

The problem turns out to be that under Jaguar you must *not* pass an 
idle routine if you haven't done all the correct toolbox initializations yet.

To verify this, do something like &quot;import EasyDialogs; 
EasyDialogs.Message(&quot;There we go&quot;)&quot; at the start of your script. 
Everything now works fine.

Somehow, if you haven't initialized, the idle routine will be called with 
random garbage, and it will be called continuously.

The question is: what's the best way to fix this? I noticed that even a 
simple Carbon.Evt.WaitNextEvent(0,0) in your test script is enough to 
make it work. Should we call this in the init_AE() routine? in AESend()?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-19 14:45

Message:
Logged In: YES 
user_id=45365

Alexandre,
I tried a few simple things with the AE module (talking to CodeWarrior) 
on Jaguar, but I can't get it to hang.

Could you give me an example script that shows the problem?

Also: I've been using MachoPython from the CVS HEAD, I assume 
you're using the same, right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 18:41:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 09:41:10 -0800
Subject: [ python-Bugs-504152 ] rfc822 long header continuation broken
Message-ID: <E1FBF26-0007Sw-MN@sc8-sf-web3.sourceforge.net>

Bugs item #504152, was opened at 2002-01-16 01:31
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470

Please note that this message 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
Submitted By: Richard Jones (richard)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: rfc822 long header continuation broken

Initial Comment:
I don't believe this is fixed in 2.1.2 or 2.2, but
haven't checked.

The code in rfc822.Message.readheaders incorrectly
unfolds long message headers. The relevant information
from rfc2822 is in section 2.2.3. In short:

&quot;&quot;&quot;
The process of moving from this folded multiple-line
representation of a header field to its single line
representation is called &quot;unfolding&quot;. Unfolding is
accomplished by simply removing any CRLF that is
immediately followed by WSP.  Each header field should
be treated in its unfolded form for further syntactic
and semantic evaluation.
&quot;&quot;&quot;

This means that the code in readheaders:

            if headerseen and line[0] in ' \t':
                # It's a continuation line.
                list.append(line)
                x = (self.dict[headerseen] + &quot;\n &quot; +
line.strip())
                self.dict[headerseen] = x.strip()
                continue

should be:

            if headerseen and line[0] in ' \t':
                # It's a continuation line.
                list.append(line)
                x = self.dict[headerseen] + line
                self.dict[headerseen] = x.strip()
                continue

ie. no stripping of the leading whitespace and no
adding the newline.


----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2003-11-10 22:28

Message:
Logged In: YES 
user_id=6405

OK, I've sent a message, but I don't have the time to sign up to the list. 

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-10 22:04

Message:
Logged In: YES 
user_id=12800

Since this was never addressed in the email package either,
perhaps you'd like to bring it up in the email-sig?


----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2003-11-10 21:35

Message:
Logged In: YES 
user_id=6405

Hurm. This issue has been lost to the void, but it's as valid today as it 
ever was. I've just had another user of Roundup run into the same thing: 
 
 RE: [issue51] Mails being delayed 
[assignedto=stuartm;priority=medium]  
 
(that should be one long line) became 
 
 RE: [issue51] Mails being delayed [assignedto=stuartm;priority=me 
dium] 
 
when sent by Outlook. Note that the current code reconstructs that line 
as &quot;me\ndium&quot; which is about as wrong as it can get, as there's no way 
for my code to determine whether that *should* be &quot;me dium&quot; or 
&quot;medium&quot; since the other whitespace has been stripped (so just stripping 
out the newline, as my code currently does, doesn't help). 
 
I stand by my original post, requesting that the code be fixed as stated. 
 

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-15 17:28

Message:
Logged In: YES 
user_id=12800

There is some value in not unfolding long lines by default.
 FWIW, the email package also retains the line breaks for
such multi-line headers.  The advantage to retaining this is
that message input/output can be idempotent (i.e. you get
the same thing in as you get out).  This can be useful when
using the message to generate a hash value, and for other
user-friendly reasons.

That being said, there is also some use in providing a way
to return the unfolded line.  I don't see a lot of benefit
in adding such a feature to the rfc822 module, but I could
see adding it to the email package.  Specifically, I would
propose to add it to the email.Header.Header class, either
as a separate method (e.g. Header.unfold()) or as a default
argument to the Header.encode() method (e.g.
Header.encode(self, unfold=0)).

If we did the latter, then I'd change Header.__str__() to
call .encode(unfold=1).

Assigning to Ben to get his feedback.  Ben, feel free to
comment and re-assign this bug to me.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2002-01-16 12:14

Message:
Logged In: YES 
user_id=21627

Even though it might not matter, I don't think changing it
would hurt, either, and the change brings it definitely
closer to following the word of RFC 2822. 

If no case is brought forward where it matters, fixing it
for 2.3 alone should be sufficient.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2002-01-16 12:12

Message:
Logged In: YES 
user_id=6405

Yes, we had someone submit a bug report on the roundup 
users mailing list because someone had sent a message to 
the roundup mail gateway which was split. The client was 
extra-specially broken, since it split in the middle of a 
word (which is not to spec), but the more general case of 
folding on whitespace will cause roundup problems since I 
hadn't expected there to be any newlines in the header.

I can modify roundup to strip out the newline, but it'd be 
nice to have rfc822.Message not put it in there...



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-16 02:47

Message:
Logged In: YES 
user_id=6380

Richard, have you found a situation where it matters? I
thought that usually the next phase calls for normalizing
whitespace by squashing repeated spaces/tabs and removing
them from front and back.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 18:43:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 09:43:12 -0800
Subject: [ python-Bugs-675187 ] bsddb hangs with recno/source sync
Message-ID: <E1FBF44-0006aY-H8@sc8-sf-web5.sourceforge.net>

Bugs item #675187, was opened at 2003-01-27 00:01
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675187&group_id=5470

Please note that this message 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: Pending
Resolution: None
Priority: 5
Submitted By: Magnus Lie Hetland (mlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb hangs with recno/source sync

Initial Comment:
I just tried to use bsddb with the source argument to have
flat 
backing file. Creating a database with such a backing
file as 
source was not problematic, but after I had modified
it, the 
sync() and close() method would hang.

For 
example:

from bsddb import rnopen
r = 
rnopen('test.dat', source='test.txt')
r[1] = 'foobar'
r.sync() 
# Hangs here...

After running this, test.txt will be empty 
(even though it
wasn't before). Running the code above without 
the source
argument works just fine.

I'm running 
Python 2.3 cvs version (slightly earlier than the
first alpha) on 
SunOS 5.9.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 17:43

Message:
Logged In: YES 
user_id=849994

Cannot reproduce with Python 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675187&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 18:52:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 09:52:24 -0800
Subject: [ python-Bugs-780730 ] source files using encoding ./. universal
	newlines
Message-ID: <E1FBFCy-0003P9-W2@sc8-sf-web1.sourceforge.net>

Bugs item #780730, was opened at 2003-07-31 09:16
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
>Assigned to: M.-A. Lemburg (lemburg)
>Summary: source files using encoding ./. universal newlines

Initial Comment:
Universal Newline Support doesn't work for source files
that contain encoding definition.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 05:50

Message:
Logged In: YES 
user_id=33168

I don't see a clear resolution here.  Is there something we
can/should do to fix this problem in 2.5?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-05 10:48

Message:
Logged In: YES 
user_id=45365

You misunderstand what I tried to say (or I mis-said it:-): there is 
no such thing as mode &quot;rbU&quot;, check the code in fileobject.c.

There is &quot;r&quot; == &quot;rt&quot; for text mode, &quot;rb&quot; for binary mode, 
&quot;U&quot;==&quot;rU&quot; for universal newline textmode. With &quot;rU&quot; the 
underlying file is opened in binary mode, so I don't think we'll 
have the control-Z problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-05 07:31

Message:
Logged In: YES 
user_id=38388

Thanks John.

Not sure whether any of codecs would actually use 0x1A,
but using &quot;rbU&quot;  sounds like the safer approach then.

----------------------------------------------------------------------

Comment By: John J Smith (johnjsmith)
Date: 2003-08-04 19:34

Message:
Logged In: YES 
user_id=830565

In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated
as EOF, unless the file is opened with 'rb'.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 15:57

Message:
Logged In: YES 
user_id=38388

Jack, I was just looking at the code I posted and the one
in fileobect.c. The latter enables universal newline support
whenever it sees a 'U' in the mode string, so I throught that
adding a 'U' to the mode would be enough.

The only system where 'b' does make a difference that I'm
aware of is Windows, so you may want to check whether it
makes a difference there.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-04 08:24

Message:
Logged In: YES 
user_id=45365

There's no such things as &quot;rbU&quot;, I think, but simply &quot;rU&quot; should 
work. As far as I know the only difference between &quot;r&quot; and &quot;rb&quot; is 
newline conversion, right? If there are C libraries that do more 
then we should implement &quot;rbU&quot;.

About 2.3.1 compatibility: technically we could break workarounds 
people have done themselves, but I think the chances are slim. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 08:21

Message:
Logged In: YES 
user_id=38388

Uhm, we don't impose Universal readline support on the codecs.
They would just get a stream object that happens to know
about universal newlines and work with it. That's completely
in line with the codec spec.

I'm +1 on adding this to 2.3.1.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 20:22

Message:
Logged In: YES 
user_id=21627

That would work indeed. The question is whether we can
impose support for universal newlines on all codecs &quot;out
there&quot;, for Python 2.3.1, when 2.3 makes no such requirement.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-03 19:31

Message:
Logged In: YES 
user_id=38388

I'm not sure this is correct: unless the codecs implement
their own .readline() implementation, the one in codecs.py
is used and that simply delegates the readline request to
the underlying stream object.

Now. since the stream object in the source code reader is
a plain Python file object, currently opened in &quot;rb&quot; mode,
changing the mode to &quot;rbU&quot; should be enough to get
universal readline support for all such codecs.

The relevant code is in Parser/tokenizer.c:fp_setreadl():

static int
fp_setreadl(struct tok_state *tok, const char* enc)
{
	PyObject *reader, *stream, *readline;

	/* XXX: constify filename argument. */
	stream = PyFile_FromFile(tok-&gt;fp, (char*)tok-&gt;filename,
&quot;rb&quot;, NULL);
	if (stream == NULL)
		return 0;

	reader = PyCodec_StreamReader(enc, stream, NULL);
	Py_DECREF(stream);
	if (reader == NULL)
		return 0;

	readline = PyObject_GetAttrString(reader, &quot;readline&quot;);
	Py_DECREF(reader);
	if (readline == NULL)
		return 0;

	tok-&gt;decoding_readline = readline;
	return 1;
}


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 19:19

Message:
Logged In: YES 
user_id=21627

The only way to implement that would be to add 'U' support
for all codecs, and open the codec with the 'U' flag. As
this will also affect codecs not part of Python, we cannot
fix this bug in Python 2.3, but have to defer a solution to
Python 2.4.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-01 09:45

Message:
Logged In: YES 
user_id=45365

The submitter isn't calling open explicitly, but PEP278 is also about 
the implicit opening of sourcefiles by the interpreter.

My guess (but I don't know the PEP263 implementation at all) is 
that when you specify an encoding the normal code that the 
interpreter uses to read sourcefiles is bypassed, and replaced by 
something that does the encoding magic. Apparently this code 
does not do universal newline conversion, which it should.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 08:22

Message:
Logged In: YES 
user_id=21627

I see. This is not about PEP 278, though, as you are not
calling any open() function, and passing no 'U' argument to
it - cross-platform newlines should work independent of that
PEP.

----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2003-08-01 07:35

Message:
Logged In: YES 
user_id=463672

Attached file has encoding definition and it's newline is '\r'.
Executing this script on Windows 2000, I got following error.
But it runs fine if I remove encoding definition. 

C:\Python23&gt;python .\test.py
  File &quot;.\test.py&quot;, line 2
a() print 'hi'
            ^
SyntaxError: invalid syntax


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 07:04

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is: Source code files
and universal newline support have nothing to do with each
other.

Can you attach a small example that demonstrates the problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 19:00:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 10:00:14 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FBFKY-0003QW-Uj@sc8-sf-web1.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 16:29
Message generated for change (Comment added) made by qbarnes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 9
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

>Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-20 12:00

Message:
Logged In: YES 
user_id=288734

I didn't write new code that causes this problem by calling
ioctl with a string that needed to be null terminated.  It
was already in Python code itself.  See Lib/pty.py for the
code.

I reworked the patch as discussed below and retested it.
All built-in tests passed.

I've attached it.  I hae no idea of Python coding
conventions or style.  Hopefully I didn't violate them
too badly.

(This was weird.  SF rejected the text above when I
submitted it, but it took the patch file.  The patch
file shows up as "nobody".  Resubmitting this text.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-20 04:54

Message:
Logged In: YES 
user_id=6656

Seeing as some of this is my code...

Guido, the ioctl docstring *does* mention mutate_arg.  I agree that the 
documentation should have been updated for 2.4 and 2.5... and the situation 
is a mess, yes, but one that I couldn't see a better way around when the 
feature was added (it was much discussed in the bug report at the time).

It certainly never occurred to me that you might need/want to pass a NULL 
terminated string to ioctl. 

I don't think this is a priority 9 report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 23:04

Message:
Logged In: YES 
user_id=6380

Sorry for the confusion. I was in part responding to an
off-line discussion I had with Neal Norwitz, to which you
weren't a party. You can ignore my comments about safety and
crashing.

The difference in marshalling Python data to C data for
ioctl(), compared to the many other places where (indeed)
this problem has been solved before, is that almost
everywhere else, we *know* what the data is supposed to
mean.  C has many more data types than Python, and the
choice of how to convert a string, or an int, to C data
depends on what is expected by the receiver of the C data. 
Unfortunately for ioctl we don't know the required C data
type because it's defined by the kernel module that handles
the particular ioctl opcode.  Some of these (like the one
you apparently ran into when porting the pty code to
Solaris) require a null-terminated string; others (like the
classic tty ioctls) require a C structure, which in Python
can be created by using the struct module.  Both return
Python strings.

I tend to agree with your conclusion that we should extend
the buffer to 1025 bytes and not bother null-terminating
non-string data.  Would you like to attempt another patch?

----------------------------------------------------------------------

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-19 18:31

Message:
Logged In: YES 
user_id=288734

I've practically never used python.  I just found
this bug in the interpreter while porting the
tool to the current Solaris compiler release, so please
keep that in mind about my lack of python knowledge.
I also have no idea who's who as well in the python
world so forgive me if I've stepped on anyone's
toes.

I don't follow the remark about "making ioctl
'safe'".  I never said anything about making it
"safe".  It's about a bug.

I also never said anything about the interpreter
crashing.  The interpreter never crashed.  The
pty test just simply failed since the module
name passed to the OS's ioctl was corrupted.

Are you sure you responded to the right bug
report with these remarks?

Anyways...

This problem should be reduced to a classic
data marshaling problem between python data
space and C data space which should have already
been addressed in many contexts many times before
in the interpreter.  How are python strings
converted for use by C in similar situations?

This problem I encountered is either a bug in
the code that passed the string to the ioctl
service by not putting an explicit '\0' on the
end of the "ptem" string, or it is a bug in the
fcntlmodule.c which should have done it for it.
Which is it?

If a python code isn't expected to put a literal
null at the end of their string when passing to
a C service, then ioctl needs to be fixed similar
to the way in my patch.

As for null-terminating other raw data, I don't
see the point other than a defensive programming
practice.

The problem I ran across is limited to just
a data marshaling problem.  The patch only
touched the case when the type of data passed
to ioctl is known to be a string.

As for the buffer vs. documentation, the
buffer could be changed to 1025 for the string
case, or the documentation could be updated
to clarify that, unlike raw data, strings are
limited to 1023 to leave room for the
requisite null that conversion to a C string
requires.  I don't think anyone would care
either way as long as it is qualified.

Since python strings serve dual roles of being
both raw data and being just textual containers,
one can't assume that a string passed to ioctl
is always meant to be just a textual string.  Going
the 1025 route is probably a 'better' approach due to
python string's duality.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 14:03

Message:
Logged In: YES 
user_id=6380

One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way.  Whether null-terminating it makes
sense or not depends on the particular operation code.

I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied.  A quick code review reveals a
few more issues:

- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)

- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense!  Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.

- In the first branch of the function, this line:

    if (mutate_arg && (len < sizeof buf)) {

ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use

    if (mutate_arg && arg == buf) {

- If it's important to null-terminate the data in the buffer
when a string is passed in, shouldn't we null-terminate it
also when a writable buffer-interface object is passed in? 
If not in the latter case, why if a string is passed?  One
could argue that a string with an explicit \0 (visible to
Python code) at the end ought to be passed in if the
semantics of the op code requires a null-terminated argument
(which most ioctl op codes don't -- the typical argument is
a C struct).

- The proposed patch reduces the maximum buffer size to
1023, which violates the docs. (Yes the docs explicitly
mention 1024.)

- The best we can do seems to be: increase the buffer size
to 1025; null-pad it in all cases; change the code for
mutable buffers to test for sizeof buf - 1.  This still
leaves the case where the buffer isn't used because a
mutable buffer is passed that's longer than 1024.  Which
suggests that we can't completely fix this -- it will always
be possible to crash Python using this function by passing
an op code that encodes a buffer length > 1024 while passing
a shorter argument, so the internal buffer is used.  I guess
we could do the null-padding as long as we document it and
document that when a mutable buffer is passed we don't
guarantee it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 01:14

Message:
Logged In: YES 
user_id=33168

Thomas, could this have caused the flakiness that you just
fixed with test_pty?  This patch seems correct to me and I
think it should be applied.  (If you want I can do that, but
I wanted you to see this first.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 19:17:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 10:17:58 -0800
Subject: [ python-Bugs-777597 ] socketmodule.c connection handling incorect on
	windows
Message-ID: <E1FBFbi-0003WM-0Q@sc8-sf-web1.sourceforge.net>

Bugs item #777597, was opened at 2003-07-25 15:01
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth Bushell (garth42)
>Assigned to: Tim Peters (tim_one)
Summary: socketmodule.c connection handling incorect on windows

Initial Comment:
The socketmodule.c code does not handle connection
refused correctly. This is due to a different of
operation on windows of select. The offending code is
in internal_connect in the MS_WINDOWS ifdef. The code
in should test  exceptfds to check for connecttion
refused. If this is so itshould call
getsockopt(SOL_SOCKET, SO_ERROR,..) to get the error
status. (Source microsoft Platform SDK)
The suggested fix is shown below (untested)

#ifdef MS_WINDOWS

f (s-&gt;sock_timeout &gt; 0.0) {
    if (res &lt; 0 &amp;&amp; WSAGetLastError() == WSAEWOULDBLOCK) {
	/* This is a mess.  Best solution: trust select */
	fd_set exfds;
	struct timeval tv;
	tv.tv_sec = (int)s-&gt;sock_timeout;
	tv.tv_usec = (int)((s-&gt;sock_timeout - tv.tv_sec) * 1e6);
	FD_ZERO(&amp;exfds);
	FD_SET(s-&gt;sock_fd, &amp;exfds);
	/* Platform SDK says so */
	res = select(s-&gt;sock_fd+1, NULL, NULL, &amp;exfds, &amp;tv);
	if (res &gt; 0) { 
	    if( FD_ISSET( &amp;exfds ) ) {
		/* Get the real reason */
	
getsockopt(s-&gt;sock_fd,SOL_SOCKET,SO_ERROR,(char*)&amp;res,sizeof(res));
	    } else {
		/* God knows how we got here */
		res = 0;
	    }
	} else if( res == 0 ) {
	    res = WSAEWOULDBLOCK;
	} else
	{ 
	    /* Not sure we should return the erro from select? */
	    res =  WSAGetLastError();
	}
    }
} else if (res &lt; 0)
    res = WSAGetLastError();

#else

----------------------------------------------------------------------

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-08 08:48

Message:
Logged In: YES 
user_id=32863

http://python.org/sf/965036 has been updated with a fixed
and tested patch. Could somebody review and apply it? Thanks!


----------------------------------------------------------------------

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-02 13:59

Message:
Logged In: YES 
user_id=32863

I have turned Garth's code into a patch versus Python 2.3.4.
I don't believe the fix is correct and complete, but it
should serve as a starting point. Patch is in
http://python.org/sf/965036


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-28 22:00

Message:
Logged In: YES 
user_id=33168

Garth could you produce a patch against 2.3c2 with your
selected change and test it?  It would help us a lot as we
are all very overloaded.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 19:32:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 10:32:57 -0800
Subject: [ python-Bugs-837577 ] cryptic os.spawnvpe() return code 
Message-ID: <E1FBFqD-0006l8-5f@sc8-sf-web5.sourceforge.net>

Bugs item #837577, was opened at 2003-11-06 23:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837577&group_id=5470

Please note that this message 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
Submitted By: Clinton Roy (clintonroy)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: cryptic os.spawnvpe() return code 

Initial Comment:
Hellos,

If a non string value is passed along in an environment
mapping to os.spawnvpe() it cryptically returns 127,
which doesn't help discover the problem at all.

I think an exception should be raised, much like
attempting to set something in os.environ to a non string.

thanks,

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 18:32

Message:
Logged In: YES 
user_id=849994

This is hard to fix because of backwards compatibility. Neal?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837577&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 19:34:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 10:34:21 -0800
Subject: [ python-Bugs-1257687 ] Solaris 8 declares gethostname().
Message-ID: <E1FBFrZ-0003Zr-6Z@sc8-sf-web1.sourceforge.net>

Bugs item #1257687, was opened at 2005-08-12 15:00
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Hans Deragon (deragon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris 8 declares gethostname().

Initial Comment:
In portpy.h line 377, we find:

#ifdef SOLARIS
/* Unchecked */
extern int gethostname(char *, int);
#endif

Well, on Solaris 8, that function is declared in
/usr/include/unistd.h, thus a conflict.  In unistd.h,
there are a few #ifdef prior the declaration, so there
might be some situation where the function is not declared.

Of course, I cannot copy and paste the relevant section
of unistd.h because of copyright.  You might want to
ask Sun Microsystem a copy of this file to patch this
problem.

My work around was to comment the above code in portpy.h.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 18:34

Message:
Logged In: YES 
user_id=849994

This is a duplicate of #837046.

----------------------------------------------------------------------

Comment By: Hans Deragon (deragon)
Date: 2005-08-14 10:35

Message:
Logged In: YES 
user_id=148726

When compiling beecrypt, it complained that gethostname()
was declared twice.  Seams that beecrypt was compiling
something for python and thus included pyport.h.  At the
same time, it was including unistd.h.  That cause beecrypt
compilation to halt with an error.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-08-13 14:05

Message:
Logged In: YES 
user_id=21627

What precise problem does this cause?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 19:34:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 10:34:40 -0800
Subject: [ python-Bugs-837046 ] pyport.h redeclares gethostname() if SOLARIS
	is defined
Message-ID: <E1FBFrs-0006lQ-JS@sc8-sf-web5.sourceforge.net>

Bugs item #837046, was opened at 2003-11-06 08:09
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837046&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: James Bostock (jbostock)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h redeclares gethostname() if SOLARIS is defined

Initial Comment:
The file pyport.h contains the lines:

#ifdef SOLARIS
/* Unchecked */
extern int gethostname(char *, int);
#endif

However, Solaris already defines gethostname() 
in /usr/include/unistd.h [I only have access to Solaris 
2.6 and 2.8 so I can't vouch for other versions].

This in iteself is not a problem. However, under 
Python2.3, pyconfig.h defines _XOPEN_SOURCE and 
_XOPEN_SOURCE_EXTENDED which cause (indirectly) 
the following prototype to be selected from unitstd.h:

extern int gethostname(char *, size_t);

Since size_t is an unsigned char, a compiler error 
message is generated (both by the native compiler and 
gcc) saying that the function has been redefined.
This means that no python program can be compiled if 
SOLARIS is #defined.

I imagine that the above code from pyport.h is only 
applicable to an earlier version of Solaris than 2.6, and 
so should either be removed or qualified somehow.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 18:34

Message:
Logged In: YES 
user_id=849994

Closed #1257687 as a duplicate.

----------------------------------------------------------------------

Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 21:19

Message:
Logged In: YES 
user_id=6606

I can verify this issue on Solaris 10 (SunOS 5.10).  Not
only does this code seem unnecessary, but there is no
configury nor make magic which _can_ ever set the SOLARIS
preprocessor define.  If I run 'make' as follows, I can
trigger a hard compilation error:

[Python-2.4.2]$ make CFLAGS='$(BASECFLAGS) $(OPT)
-DSOLARIS=true'
...
In file included from ./Include/Python.h:55,
                 from Objects/complexobject.c:8:
./Include/pyport.h:382: error: conflicting types for
'gethostname'
/usr/include/unistd.h:319: error: previous declaration of
'gethostname' was here./Include/pyport.h:382: error:
conflicting types for 'gethostname'
/usr/include/unistd.h:319: error: previous declaration of
'gethostname' was here*** Error code 1
make: Fatal error: Command failed for target
`Objects/complexobject.o'

I recommend removing this snippet from pyport.h:

--- Include/pyport.h	(revision 41772)
+++ Include/pyport.h	(working copy)
@@ -372,11 +372,6 @@
 in platform-specific #ifdefs.
 **************************************************************************/
 
-#ifdef SOLARIS
-/* Unchecked */
-extern int gethostname(char *, int);
-#endif
-
 #ifdef __BEOS__
 /* Unchecked */
 /* It's in the libs, but not the headers... - [cjh] */


----------------------------------------------------------------------

Comment By: James Bostock (jbostock)
Date: 2003-11-26 18:43

Message:
Logged In: YES 
user_id=902503

&quot;Since size_t is an unsigned char&quot; should read &quot;Since size_t is 
an unsigned int&quot;.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837046&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 19:40:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 10:40:52 -0800
Subject: [ python-Bugs-831271 ] httplib.HTTPConnection._send_request header
	parsing bug
Message-ID: <E1FBFxs-0007qN-I3@sc8-sf-web2.sourceforge.net>

Bugs item #831271, was opened at 2003-10-27 19:57
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831271&group_id=5470

Please note that this message 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: Fixed
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Alex Martelli (aleax)
Summary: httplib.HTTPConnection._send_request header parsing bug

Initial Comment:
The test on lines 730-731 of httplib.py as released with 
Python 2.3.2 doesn't do what it's intended to do.

Consider
&gt;&gt;&gt; headers = { 'hoST': 'www.someplace.org' }
&gt;&gt;&gt; 'Host' in ( headers or [k for k in headers.iterkeys() if 
k.lower() == 'host' ] )
False

This sample code demonstrates that the code in httplib 
at line 730 doesn't work as intended (it should return 
true for any dict who's keys include 'host' of any case).

Clearly the 'or' syntax has confused someone here, 
because the portion after the or (if executed) is always 
an empty list.  I recommend instead

        if 'host' in map( str.lower, headers.keys() ):

Or a better general solution might be to force all header 
keys to be case-insensitive strings by overriding str and 
dict to new case-insensitive versions, something like the 
attached.  This idea, however, is just a suggestion, and 
probably needs to be thought through more thoroughly.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 18:40

Message:
Logged In: YES 
user_id=849994

"Host" shouldn't be None anyway... closing.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-24 15:53

Message:
Logged In: YES 
user_id=80475

Can this be closed?

----------------------------------------------------------------------

Comment By: Kaj J. Niemi (kajtzu)
Date: 2004-02-17 23:06

Message:
Logged In: YES 
user_id=978076

Won't this fail if Host is None? Reason I'm asking is that
this changed between python 2.3.2 and 2.3.3 and broke
something :)

  File "/usr/lib/python2.3/httplib.py", line 718, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python2.3/httplib.py", line 730, in
_send_request
    if 'host' in [k.lower() for k in headers]:
AttributeError: 'NoneType' object has no attribute 'lower'

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112590>

----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2003-11-02 16:51

Message:
Logged In: YES 
user_id=60314

You're certainly right that lines 730-731 cannot be correct, for exactly the reason you specify; and that forcing case-insensitive header dicts may be a cool idea but it's too invasive for such a simple fix.  I've done some timing and I think the simplest and fastest way to check is:
if 'host' in [k.lower() for k in headers]:
accordingly, I have committed this change to the 2.3 branch in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831271&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 19:44:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 10:44:41 -0800
Subject: [ python-Bugs-812376 ] Problem with ftplib on HP-UX11i
Message-ID: <E1FBG1Z-00017C-Ab@sc8-sf-web6.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 11:10
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Please note that this message 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: Fixed
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).

import ftplib
f = ftplib.FTP()
f.connect('hostname', 21)

this raises:

socket.gaierror: (8, 'host nor service provided, or not 
known')

In FTP.connect() it is the call to socket.getaddrinfo() 
that is raising the exception.

The same code works OK on Python 2.2.1

If I pass an IP address instead of a hostname, the code 
runs OK on Python 2.3



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 18:44

Message:
Logged In: YES 
user_id=849994

Closing then.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-03-24 16:55

Message:
Logged In: YES 
user_id=200117

I have just tested this on Python 2.3.3 (sorry about the 
delay) and now it runs with no errors!


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-10-01 10:11

Message:
Logged In: YES 
user_id=200117

I tried dropping different versions of socketmodule.c &amp; 
socketmodule.h into Python-2.3.1 and re-building.

The earliest version of socketmodule.c I could build &amp; run was 
1.219 and this does raise the exception for a hostname that 
needs to be resolved via NIS.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 14:48

Message:
Logged In: YES 
user_id=29957

Darn. There's probably something Not Quite Right with how
socketmodule.c interacts with HP/UX's NIS, then. I'm not
sure what the problem would be, and I don't have access to a
HP/UX box that uses NIS for hostnames, so I'm not able to
help... 

As previously mentioned, there's a _lot_ of changes been
made to socketmodule.c between 2.2 and 2.3. If you're
CVS-savvy, you might like to try checking out different
versions between 2.200 (the version in 2.2) and 2.270 (the
version in 2.3) to narrow down exactly when the module stops
working.

One thing - &quot;_&quot; isn't supposed to be legal in domain names,
I don't know if that's related (although the other name has
no underscores...)


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 13:56

Message:
Logged In: YES 
user_id=200117

The hostnames I have tried are 'tate_mod' and 'rosalind'.
Lookup is by NIS. I can ping and remote login to these 
workstations using their hostnames.

I have since discovered that if I add an entry to /etc/hosts 
specifying a different hostname 'fred' and rosalind's IP 
address, then f.connect('fred', 21) doesn't give the error.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 13:01

Message:
Logged In: YES 
user_id=29957

Hm. What's the actual hostname you're trying? I can't get
this failure on HP/UX 11.11, using the HP testdrive box. 

Are you using NIS or some other non-standard method of
hostname lookup? The problem is that there's a fair bit
changed between 2.2 and 2.3's socket module (there was 71
different checkins).


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 12:21

Message:
Logged In: YES 
user_id=200117

Apologies for not being clear.

I actually used the real hostname (in quotes) of a workstation 
on our local network in place of 'hostname'.

If I use 'localhost' or the hostname of the workstation the 
application is running on, I don't get the error.

If I use the hostname of any other workstation on the local 
network, I do get the error.

Running exactly the same code on Python 2.2.1 works OK for 
all hostnames.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 09:44

Message:
Logged In: YES 
user_id=29957

Using the HP testdrive system
HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user
license

I did the following with 2.3.2c1:
&gt;&gt;&gt; import ftplib
&gt;&gt;&gt; f = ftplib.FTP()
&gt;&gt;&gt; f.connect('localhost', 21)
'220 spe169.testdrive.hp.com FTP server (Version
1.1.214.4(PHNE_27765) Wed Sep  4 05:59:34 GMT 2002) ready.'
&gt;&gt;&gt; 

Ah. In your example, you have 'hostname'. Is that
_literally_ what you typed? If so, it's looking for a
machine called 'hostname'. I tried that, and got the same
error you got. 

Try it without the single quotes around 'hostname'. 


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 17:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's
obviously something else going on entirely. Damn. I will try
to grab some time on one of the HP test boxes to see if I
can figure what's going on...


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 17:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd
work for 2.3 and not 2.3.1, unless 2.3.1's script was
generated with a newer version of autoconf - aha. Yes, it was. 
If you could check if the fix in 
https://sourceforge.net/tracker/?func=detail&amp;atid=105470&amp;aid=811160&amp;group_id=5470
&quot;makes it all better&quot;, that would be great. Put aclocal.m4
alongside configure &amp;c, re-run autoconf, then ./configure ; make


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-26 17:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.

I don't think configure was broken with Python 2.3 - and it 
was with 2.3 that I first noticed the problem.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 17:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.
Can you apply the workaround from
http://www.python.org/2.3.1/bugs.html and see if the problem
is fixed?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 20:05:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 11:05:30 -0800
Subject: [ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run after
	test_openpty
Message-ID: <E1FBGLi-0001BW-CV@sc8-sf-web6.sourceforge.net>

Bugs item #713169, was opened at 2003-03-31 23:35
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_pty fails on HP-UX and AIX when run after test_openpty

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src &gt; ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File &quot;Lib/test/test_pty.py&quot;, line 58, in ?
    test_basic_pty()
  File &quot;Lib/test/test_pty.py&quot;, line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File &quot;Lib/test/test_pty.py&quot;, line 50, in handle_sig
    raise TestFailed, &quot;isatty hung&quot;
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-20 11:05

Message:
Logged In: YES 
user_id=33168

Can you test with the patch in bug report: 
https://sourceforge.net/tracker/index.php?func=detail&aid=1433877&group_id=5470&atid=105470
?  I wonder if that fixes the problem.  Though I'm not sure
the same code is executed or not.

----------------------------------------------------------------------

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-01-25 08:29

Message:
Logged In: YES 
user_id=987664

This happens with Python 2.4 on Tru64Unix V5.1 when
compiling using gcc-3.4.3, but not if you use the vendor cc.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 01:30

Message:
Logged In: YES 
user_id=200117

This still happens with Python-2.4.0a1 on HP-UX11i


----------------------------------------------------------------------

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 09:22

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 08:31

Message:
Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 08:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 02:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 20:08:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 11:08:43 -0800
Subject: [ python-Bugs-813449 ] locale.getdefaultlocale doesnt handle all
	locales gracefully
Message-ID: <E1FBGOp-0006sl-Fn@sc8-sf-web5.sourceforge.net>

Bugs item #813449, was opened at 2003-09-27 08:54
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813449&group_id=5470

Please note that this 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.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getdefaultlocale doesnt handle all locales gracefully

Initial Comment:
[forwarded from http://bugs.debian.org/185776]

$ LC_ALL=en_ZA python
Python 2.3.1 (#2, Sep 24 2003, 11:39:14) 
[GCC 3.3.2 20030908 (Debian prerelease)] on linux2
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for
more information.
&gt;&gt;&gt; import locale
&gt;&gt;&gt; locale.getdefaultlocale()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;/usr/lib/python2.3/locale.py&quot;, line 346, in
getdefaultlocale
    return _parse_localename(localename)
  File &quot;/usr/lib/python2.3/locale.py&quot;, line 280, in
_parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_ZA

Note that locale.getlocale correctly returns (None, None)

locale.getdefaultlocale() calls _parse_localename,
which throws a ValueError if normalize e.g. does not
return an encoding.

If this behaviour in python is &quot;as it should be&quot;,
locale.getdefaultlocale should document it as such, to
make it clear to apps using getdefaultlocale that they
*must indeed* handle such an exception gracefully. (In
this case, it could probably be a &quot;normal&quot; bug, then
the &quot;important&quot; bug belongs with apt-listchanges.)

The problem might be (depending on &quot;specifications&quot;)
either getlocale returning ValueError in the &quot;unknown&quot;
case, or it could be because locale_alias does not
contain an entry for en_ZA...


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 19:08

Message:
Logged In: YES 
user_id=849994

Closing as duplicate of #504219.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-08 18:59

Message:
Logged In: YES 
user_id=469548

http://python.org/sf/504219 seems to be the same bug.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-10-04 08:06

Message:
Logged In: YES 
user_id=21627

This is a known limitation: getdefaultlocale should not be
used in new code.

If the intention is to compute the locale's encoding,
locale.getpreferredencoding should be used instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813449&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 20:21:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 11:21:20 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FBGb2-0007wm-UJ@sc8-sf-web2.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 14:29
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-20 10:00

Message:
Logged In: YES 
user_id=288734

I didn't write new code that causes this problem by calling
ioctl with a string that needed to be null terminated.  It
was already in Python code itself.  See Lib/pty.py for the
code.

I reworked the patch as discussed below and retested it.
All built-in tests passed.

I've attached it.  I hae no idea of Python coding
conventions or style.  Hopefully I didn't violate them
too badly.

(This was weird.  SF rejected the text above when I
submitted it, but it took the patch file.  The patch
file shows up as "nobody".  Resubmitting this text.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-20 02:54

Message:
Logged In: YES 
user_id=6656

Seeing as some of this is my code...

Guido, the ioctl docstring *does* mention mutate_arg.  I agree that the 
documentation should have been updated for 2.4 and 2.5... and the situation 
is a mess, yes, but one that I couldn't see a better way around when the 
feature was added (it was much discussed in the bug report at the time).

It certainly never occurred to me that you might need/want to pass a NULL 
terminated string to ioctl. 

I don't think this is a priority 9 report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 21:04

Message:
Logged In: YES 
user_id=6380

Sorry for the confusion. I was in part responding to an
off-line discussion I had with Neal Norwitz, to which you
weren't a party. You can ignore my comments about safety and
crashing.

The difference in marshalling Python data to C data for
ioctl(), compared to the many other places where (indeed)
this problem has been solved before, is that almost
everywhere else, we *know* what the data is supposed to
mean.  C has many more data types than Python, and the
choice of how to convert a string, or an int, to C data
depends on what is expected by the receiver of the C data. 
Unfortunately for ioctl we don't know the required C data
type because it's defined by the kernel module that handles
the particular ioctl opcode.  Some of these (like the one
you apparently ran into when porting the pty code to
Solaris) require a null-terminated string; others (like the
classic tty ioctls) require a C structure, which in Python
can be created by using the struct module.  Both return
Python strings.

I tend to agree with your conclusion that we should extend
the buffer to 1025 bytes and not bother null-terminating
non-string data.  Would you like to attempt another patch?

----------------------------------------------------------------------

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-19 16:31

Message:
Logged In: YES 
user_id=288734

I've practically never used python.  I just found
this bug in the interpreter while porting the
tool to the current Solaris compiler release, so please
keep that in mind about my lack of python knowledge.
I also have no idea who's who as well in the python
world so forgive me if I've stepped on anyone's
toes.

I don't follow the remark about "making ioctl
'safe'".  I never said anything about making it
"safe".  It's about a bug.

I also never said anything about the interpreter
crashing.  The interpreter never crashed.  The
pty test just simply failed since the module
name passed to the OS's ioctl was corrupted.

Are you sure you responded to the right bug
report with these remarks?

Anyways...

This problem should be reduced to a classic
data marshaling problem between python data
space and C data space which should have already
been addressed in many contexts many times before
in the interpreter.  How are python strings
converted for use by C in similar situations?

This problem I encountered is either a bug in
the code that passed the string to the ioctl
service by not putting an explicit '\0' on the
end of the "ptem" string, or it is a bug in the
fcntlmodule.c which should have done it for it.
Which is it?

If a python code isn't expected to put a literal
null at the end of their string when passing to
a C service, then ioctl needs to be fixed similar
to the way in my patch.

As for null-terminating other raw data, I don't
see the point other than a defensive programming
practice.

The problem I ran across is limited to just
a data marshaling problem.  The patch only
touched the case when the type of data passed
to ioctl is known to be a string.

As for the buffer vs. documentation, the
buffer could be changed to 1025 for the string
case, or the documentation could be updated
to clarify that, unlike raw data, strings are
limited to 1023 to leave room for the
requisite null that conversion to a C string
requires.  I don't think anyone would care
either way as long as it is qualified.

Since python strings serve dual roles of being
both raw data and being just textual containers,
one can't assume that a string passed to ioctl
is always meant to be just a textual string.  Going
the 1025 route is probably a 'better' approach due to
python string's duality.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 12:03

Message:
Logged In: YES 
user_id=6380

One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way.  Whether null-terminating it makes
sense or not depends on the particular operation code.

I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied.  A quick code review reveals a
few more issues:

- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)

- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense!  Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.

- In the first branch of the function, this line:

    if (mutate_arg && (len < sizeof buf)) {

ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use

    if (mutate_arg && arg == buf) {

- If it's important to null-terminate the data in the buffer
when a string is passed in, shouldn't we null-terminate it
also when a writable buffer-interface object is passed in? 
If not in the latter case, why if a string is passed?  One
could argue that a string with an explicit \0 (visible to
Python code) at the end ought to be passed in if the
semantics of the op code requires a null-terminated argument
(which most ioctl op codes don't -- the typical argument is
a C struct).

- The proposed patch reduces the maximum buffer size to
1023, which violates the docs. (Yes the docs explicitly
mention 1024.)

- The best we can do seems to be: increase the buffer size
to 1025; null-pad it in all cases; change the code for
mutable buffers to test for sizeof buf - 1.  This still
leaves the case where the buffer isn't used because a
mutable buffer is passed that's longer than 1024.  Which
suggests that we can't completely fix this -- it will always
be possible to crash Python using this function by passing
an op code that encodes a buffer length > 1024 while passing
a shorter argument, so the internal buffer is used.  I guess
we could do the null-padding as long as we document it and
document that when a mutable buffer is passed we don't
guarantee it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-17 23:14

Message:
Logged In: YES 
user_id=33168

Thomas, could this have caused the flakiness that you just
fixed with test_pty?  This patch seems correct to me and I
think it should be applied.  (If you want I can do that, but
I wanted you to see this first.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 20:33:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 11:33:31 -0800
Subject: [ python-Bugs-815999 ] ImportError: No module named _socket
Message-ID: <E1FBGmp-0006xC-8Z@sc8-sf-web5.sourceforge.net>

Bugs item #815999, was opened at 2003-10-01 17:21
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470

Please note that this 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.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Peter Stauffert (stauffert)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportError: No module named _socket

Initial Comment:
Hi

There is a problem during the installation of python 2.3.1:

I used configure with the following options:
./configure --enable-shared=yes --with-signal-
module=yes --with-cxx=/usr/freeware/bin/c++

make runs to the end, only warning messages are 
displayed.

Running &quot;make test&quot; on a SGI Origin200, IRIX 6.5-18 I 
got the following error message:
test test___all__ failed -- Traceback (most recent call 
last):
  File &quot;/install/fw/Python-2.3.1/Lib/test/test___all__.py&quot;, 
line 54, in test_all
    import _socket
ImportError: No module named _socket

This looks like the python bug 565710 reported for 
python 2.2.1 which was solved by modifications of 
setup.py in the top level directory.

But setup.py was modified in python 2.3.1 and I could 
not apply the old patch to the new version.

Could you help me with this problem?

Thanks a lot

Peter Stauffert


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 19:33

Message:
Logged In: YES 
user_id=849994

OP: Do you still experience problems with 2.4?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-10-13 21:27

Message:
Logged In: YES 
user_id=21627

jemfinch, I very much doubt that you have the same problem
as the submitter of this report, and your Usenet message
gives hardly enough detail to analyse the problem; for
example, the linker error you report has a truncated error
message. Please submit a separate report, and report
precisely what you did, the complete output that you got,
and what exactly isn't working the way you expect it to work.

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-10-13 14:33

Message:
Logged In: YES 
user_id=99508

If you don't mind, I'll just link you to my comp.lang.python
post about it:

http://groups.google.com/groups?q=group:comp.lang.python+solaris+7&amp;hl=en&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;selm=698f09f8.0310100915.359b2e09%40posting.google.com&amp;rnum=9

That has the exact compilation error.  I've tried passing
the --disable-IPV6 option to configure (as MvL mentioned)
and it seemed to compile, but I still don't have access to
the _socket library, probably due to the second error I
mentioned.  I tried the fix in the bug #565710 (adding
runtime_library_dirs to setup.py) but to no avail.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-13 05:51

Message:
Logged In: YES 
user_id=29957

Works for me on Solaris 2.6, 7 and 8. What compiler, what
version, what error did you get during the build of
socketmodule?


----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-10-11 11:35

Message:
Logged In: YES 
user_id=99508

I have this same bug on Solaris 7 with 2.3.2.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-04 00:24

Message:
Logged In: YES 
user_id=29957

Does the patch available from www.python.org/bugs.html fix
this problem?

Which compiler did you use? From the configure line, above,
it looks like you might be using gcc?


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-10-03 13:28

Message:
Logged In: YES 
user_id=21627

Can you please attach the build log? In particular, it would
be importing to see whether building _socket was attempted,
and failed.

Maybe your compiler just doesn't work???

----------------------------------------------------------------------

Comment By: casey dunn (caseyd)
Date: 2003-10-01 19:53

Message:
Logged In: YES 
user_id=878394

I have seen this on Solaris as well, recent and old vintages.

Casey Dunn

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 20:53:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 11:53:51 -0800
Subject: [ python-Bugs-847024 ] NotImplemented return value misinterpreted in
	new classes
Message-ID: <E1FBH6V-00081R-3n@sc8-sf-web2.sourceforge.net>

Bugs item #847024, was opened at 2003-11-22 02:39
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847024&group_id=5470

Please note that this 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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Dubner (dubnerm)
Assigned to: Michael Hudson (mwh)
Summary: NotImplemented return value misinterpreted in new classes

Initial Comment:
Following program:
------------------------------ notimpl.py
class CClassic:
  def __add__(self, other):
    return NotImplemented
  def __mul__(self, other):
    return NotImplemented
class CNew(object):
  def __add__(self, other):
    return NotImplemented
  def __mul__(self, other):
    return NotImplemented

a=CClassic()
try:
  print a+2
except Exception, e:
  print e
try:
  print a*2
except Exception, e:
  print e
a=CNew()
try:
  print a+2
except Exception, e:
  print e
try:
  print a*2
except Exception, e:
  print e
--------------------------------
Output following (correct) under Python 2.2:

unsupported operand types for +: 'instance' and 'int'
unsupported operand type(s) for *: 'instance' and 'int'
unsupported operand types for +: 'CNew' and 'int'
unsupported operand type(s) for *: 'CNew' and 'int'

And following (wrong) under Python 2.3[.2]:

unsupported operand type(s) for +: 'instance' and 'int'
unsupported operand type(s) for *: 'instance' and 'int'
unsupported operand type(s) for +: 'CNew' and 'int'
NotImplemented


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 19:53

Message:
Logged In: YES 
user_id=849994

This now seems to be fixed in 2.5 HEAD and 2.4 branch. Cheers!

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-10-01 13:38

Message:
Logged In: YES 
user_id=1188172

I could reproduce with all my Pythons. I looked around a bit
but couldn't find any cause of this. Michael, do you have
more luck?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847024&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 21:03:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 12:03:22 -0800
Subject: [ python-Bugs-872736 ] Python 2.3.3 urllib proxy support fails
Message-ID: <E1FBHFi-0007vz-NN@sc8-sf-web3.sourceforge.net>

Bugs item #872736, was opened at 2004-01-08 00:20
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872736&group_id=5470

Please note that this message 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: Pending
Resolution: None
Priority: 5
Submitted By: Eric Johnson (eggsy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3.3 urllib proxy support fails

Initial Comment:
Using Python 2.3.3 on Win2K and Win98 the urllib module
does not seem to support proxies as described in the
documentation.

I have the http_proxy environment variable set and
urllib2.urlopen can successfully access the web via the
proxy.
Trying urllib.urlopen results in a
IOError: [Errno socket error] (7, 'getaddrinfo failed')
exception which suggests that it is not using the proxy.
This occurs both with an explicit proxy defined and
when using the environment variable.

See attached file for an example script.

I could not see any reference to proxies in the urllib
test script so I wonder whether this has been tested.

I have not (yet) tried to investigate why this does not
work.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 20:03

Message:
Logged In: YES 
user_id=849994

Proxy support has recently been improved in urllib. Can you
test whether it works now?

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-01-08 15:33

Message:
Logged In: YES 
user_id=764593

Do you need to authenticate to your proxy?

The default getpass will fail instead of asking for a password if 
it thinks there is an eavesdropper - and idle counts as an 
eavesdropper.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872736&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 21:06:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 12:06:32 -0800
Subject: [ python-Bugs-860515 ] fileinput does not use universal input
Message-ID: <E1FBHIm-0003o1-2E@sc8-sf-web1.sourceforge.net>

Bugs item #860515, was opened at 2003-12-15 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=860515&group_id=5470

Please note that this message 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: Fixed
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: fileinput does not use universal input

Initial Comment:
In Python 2.3.0 the fileinput module does not appear to use universal line ending mode for reading files. I found this using MacPython 2.3 (via the binary installer) but looking at the module it appears to be vanilla code. I confess I didn't see where the files were opened, so I cannot suggest a fix.

Sample code:

import fileinput
for line in fileinput.input():
	print line[0:20]

try this with text files that have some other platform's line endings. For me, it works on MacOS X for files with unix line endings, but fails if the file(s) have Mac line endings.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 20:06

Message:
Logged In: YES 
user_id=849994

Patch #1212287 was now committed, so closing this.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-05-31 21:42

Message:
Logged In: YES 
user_id=1188172

See patch #1212287.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860515&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 21:30:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 12:30:08 -0800
Subject: [ python-Bugs-1210377 ] Cursors not correctly closed after exception.
Message-ID: <E1FBHfc-0001Uf-S5@sc8-sf-web6.sourceforge.net>

Bugs item #1210377, was opened at 2005-05-28 12:48
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210377&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ragnar Ouchterlony (ragnar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cursors not correctly closed after exception.

Initial Comment:
If an exception occurs when going through a database,
the cursors will not be correctly reset.

If I manually set the cursor to None (by doing db.dbc =
None) it will work fine.

>>> db = bsddb.btopen('/tmp/test.db', 'c')
>>> db.first()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/bsddb/__init__.py", line
264, in first
    rv = self.dbc.first()
_bsddb.DBNotFoundError: (-30990, 'DB_NOTFOUND: No
matching key/data pair found')
>>> db['foo'] = 'bar'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/bsddb/__init__.py", line
217, in __setitem__
    self._closeCursors()
  File "/usr/lib/python2.4/bsddb/__init__.py", line
192, in _closeCursors
    self.saved_dbc_key = c.current(0,0,0)[0]
bsddb._db.DBInvalidArgError: (22, 'Invalid argument --
Cursor position must be set before performing this
operation')

Here, I first open a new database. Since it is empty,
db.first() will fail. When I after that try to add a
key/value pair to the database it fails, since it tries
to close an invalid cursor.

>>> db = bsddb.btopen('/tmp/test.db', 'c')
>>> db.first()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/bsddb/__init__.py", line
264, in first
    rv = self.dbc.first()
_bsddb.DBNotFoundError: (-30990, 'DB_NOTFOUND: No
matching key/data pair found')
>>> db.dbc = None
>>> db['foo'] = 'bar'
>>> db
{'foo': 'bar'}

Here I do "db.dbc = None" after the exception and now
it works just fine.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 20:30

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 42525, 42526.

----------------------------------------------------------------------

Comment By: Ragnar Ouchterlony (ragnar)
Date: 2005-05-30 07:59

Message:
Logged In: YES 
user_id=1394

The bugreport refers to bsddb. I did not make that entirely
clear.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210377&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 21:52:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 12:52:43 -0800
Subject: [ python-Bugs-1229380 ] No struct.pack exception for some out of
	range integers
Message-ID: <E1FBI1T-0001YZ-9P@sc8-sf-web6.sourceforge.net>

Bugs item #1229380, was opened at 2005-06-28 23:30
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: No struct.pack exception for some out of range integers

Initial Comment:
struct.pack("B", -1) generates an OverflowError
exception since the B format corresponds to the
"unsigned char" type which can have values between 0
and 255.

But struct.pack("I", -1) and struct.pack("L", -1) do
not generate these errors, even if struct.pack("I",
-1L) and struct.pack("L", -1L) do (notice the final L).


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 20:52

Message:
Logged In: YES 
user_id=849994

Attaching patch, raises struct.error. Neal, please look over it.

Note that I find struct's error handling confusing: it's not
clear from the docs in which cases OverflowError is raised,
and in which struct.error.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 21:52:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 12:52:44 -0800
Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated,
	includes fix
Message-ID: <E1FBI1U-0003z4-8h@sc8-sf-web1.sourceforge.net>

Bugs item #1433877, was opened at 2006-02-17 17:29
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-20 15:52

Message:
Logged In: YES 
user_id=6380

mwh: Sorry about the docstring gripe -- I read the fcntl()
docstring which is right above the ioctl() implementation
and never realized that this particular C module places the
doc strings *after* the functions. (I think that's bad style
but there it is.)

I think the priority was set to 9 by Neal to get Thomas'
attention.

gbarnes: We'll decide this one at PyCon.

----------------------------------------------------------------------

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-20 13:00

Message:
Logged In: YES 
user_id=288734

I didn't write new code that causes this problem by calling
ioctl with a string that needed to be null terminated.  It
was already in Python code itself.  See Lib/pty.py for the
code.

I reworked the patch as discussed below and retested it.
All built-in tests passed.

I've attached it.  I hae no idea of Python coding
conventions or style.  Hopefully I didn't violate them
too badly.

(This was weird.  SF rejected the text above when I
submitted it, but it took the patch file.  The patch
file shows up as "nobody".  Resubmitting this text.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-20 05:54

Message:
Logged In: YES 
user_id=6656

Seeing as some of this is my code...

Guido, the ioctl docstring *does* mention mutate_arg.  I agree that the 
documentation should have been updated for 2.4 and 2.5... and the situation 
is a mess, yes, but one that I couldn't see a better way around when the 
feature was added (it was much discussed in the bug report at the time).

It certainly never occurred to me that you might need/want to pass a NULL 
terminated string to ioctl. 

I don't think this is a priority 9 report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-20 00:04

Message:
Logged In: YES 
user_id=6380

Sorry for the confusion. I was in part responding to an
off-line discussion I had with Neal Norwitz, to which you
weren't a party. You can ignore my comments about safety and
crashing.

The difference in marshalling Python data to C data for
ioctl(), compared to the many other places where (indeed)
this problem has been solved before, is that almost
everywhere else, we *know* what the data is supposed to
mean.  C has many more data types than Python, and the
choice of how to convert a string, or an int, to C data
depends on what is expected by the receiver of the C data. 
Unfortunately for ioctl we don't know the required C data
type because it's defined by the kernel module that handles
the particular ioctl opcode.  Some of these (like the one
you apparently ran into when porting the pty code to
Solaris) require a null-terminated string; others (like the
classic tty ioctls) require a C structure, which in Python
can be created by using the struct module.  Both return
Python strings.

I tend to agree with your conclusion that we should extend
the buffer to 1025 bytes and not bother null-terminating
non-string data.  Would you like to attempt another patch?

----------------------------------------------------------------------

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-19 19:31

Message:
Logged In: YES 
user_id=288734

I've practically never used python.  I just found
this bug in the interpreter while porting the
tool to the current Solaris compiler release, so please
keep that in mind about my lack of python knowledge.
I also have no idea who's who as well in the python
world so forgive me if I've stepped on anyone's
toes.

I don't follow the remark about "making ioctl
'safe'".  I never said anything about making it
"safe".  It's about a bug.

I also never said anything about the interpreter
crashing.  The interpreter never crashed.  The
pty test just simply failed since the module
name passed to the OS's ioctl was corrupted.

Are you sure you responded to the right bug
report with these remarks?

Anyways...

This problem should be reduced to a classic
data marshaling problem between python data
space and C data space which should have already
been addressed in many contexts many times before
in the interpreter.  How are python strings
converted for use by C in similar situations?

This problem I encountered is either a bug in
the code that passed the string to the ioctl
service by not putting an explicit '\0' on the
end of the "ptem" string, or it is a bug in the
fcntlmodule.c which should have done it for it.
Which is it?

If a python code isn't expected to put a literal
null at the end of their string when passing to
a C service, then ioctl needs to be fixed similar
to the way in my patch.

As for null-terminating other raw data, I don't
see the point other than a defensive programming
practice.

The problem I ran across is limited to just
a data marshaling problem.  The patch only
touched the case when the type of data passed
to ioctl is known to be a string.

As for the buffer vs. documentation, the
buffer could be changed to 1025 for the string
case, or the documentation could be updated
to clarify that, unlike raw data, strings are
limited to 1023 to leave room for the
requisite null that conversion to a C string
requires.  I don't think anyone would care
either way as long as it is qualified.

Since python strings serve dual roles of being
both raw data and being just textual containers,
one can't assume that a string passed to ioctl
is always meant to be just a textual string.  Going
the 1025 route is probably a 'better' approach due to
python string's duality.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 15:03

Message:
Logged In: YES 
user_id=6380

One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way.  Whether null-terminating it makes
sense or not depends on the particular operation code.

I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied.  A quick code review reveals a
few more issues:

- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)

- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense!  Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.

- In the first branch of the function, this line:

    if (mutate_arg && (len < sizeof buf)) {

ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use

    if (mutate_arg && arg == buf) {

- If it's important to null-terminate the data in the buffer
when a string is passed in, shouldn't we null-terminate it
also when a writable buffer-interface object is passed in? 
If not in the latter case, why if a string is passed?  One
could argue that a string with an explicit \0 (visible to
Python code) at the end ought to be passed in if the
semantics of the op code requires a null-terminated argument
(which most ioctl op codes don't -- the typical argument is
a C struct).

- The proposed patch reduces the maximum buffer size to
1023, which violates the docs. (Yes the docs explicitly
mention 1024.)

- The best we can do seems to be: increase the buffer size
to 1025; null-pad it in all cases; change the code for
mutable buffers to test for sizeof buf - 1.  This still
leaves the case where the buffer isn't used because a
mutable buffer is passed that's longer than 1024.  Which
suggests that we can't completely fix this -- it will always
be possible to crash Python using this function by passing
an op code that encodes a buffer length > 1024 while passing
a shorter argument, so the internal buffer is used.  I guess
we could do the null-padding as long as we document it and
document that when a mutable buffer is passed we don't
guarantee it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 02:14

Message:
Logged In: YES 
user_id=33168

Thomas, could this have caused the flakiness that you just
fixed with test_pty?  This patch seems correct to me and I
think it should be applied.  (If you want I can do that, but
I wanted you to see this first.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:00:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:00:11 -0800
Subject: [ python-Bugs-944396 ] urllib2 doesn't handle username/password in url
Message-ID: <E1FBI8h-00040J-DQ@sc8-sf-web1.sourceforge.net>

Bugs item #944396, was opened at 2004-04-29 11:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944396&group_id=5470

Please note that this 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: Duplicate
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 doesn't handle username/password in url

Initial Comment:
>>> urllib2.urlopen('http://username:password at server')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\PYTHON23\lib\urllib2.py", line 129, in urlopen
    return _opener.open(url, data)
  File "C:\PYTHON23\lib\urllib2.py", line 326, in open
    '_open', req)
  File "C:\PYTHON23\lib\urllib2.py", line 306, in
_call_chain
    result = func(*args)
  File "C:\PYTHON23\lib\urllib2.py", line 901, in http_open
    return self.do_open(httplib.HTTP, req)
  File "C:\PYTHON23\lib\urllib2.py", line 860, in do_open
    h = http_class(host) # will parse host:port
  File "C:\Python23\lib\httplib.py", line 1009, in __init__
    self._setup(self._connection_class(host, port, strict))
  File "C:\Python23\lib\httplib.py", line 507, in __init__
    self._set_hostport(host, port)
  File "C:\Python23\lib\httplib.py", line 518, in
_set_hostport
    raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
httplib.InvalidURL: nonnumeric port: 'password at server'

cheers,

Chris

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:00

Message:
Logged In: YES 
user_id=849994

This is also reported by #979407.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-05-05 21:22

Message:
Logged In: YES 
user_id=43607

I don't know (nor care) about RFC 1738, but it's successor
RFC 2396 *does* mention <userinfo>@<host>:<port> as a
possible "server".  See section 3.2.2.  I admit, it also
says that it is not recommended, but it does specifically
allow username + password in the URI.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2004-05-05 21:01

Message:
Logged In: YES 
user_id=24723

However, given that the original urllib supported this, it
is suprising that urllib2 doesn't.

----------------------------------------------------------------------

Comment By: Andrew Langmead (langmead)
Date: 2004-05-05 20:34

Message:
Logged In: YES 
user_id=119306

Although allowing a username and password in the URL is a 
common client extension, it is not part of the standard <http://
rfc.net/rfc1738.html#s3.3.>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944396&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:00:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:00:32 -0800
Subject: [ python-Bugs-979407 ] urllib2 digest auth totally broken
Message-ID: <E1FBI92-00086Q-6p@sc8-sf-web3.sourceforge.net>

Bugs item #979407, was opened at 2004-06-25 01:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979407&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 digest auth totally broken

Initial Comment:
The urllib2 digest auth handler is totally broken. 

1. It looks for an "Authorization" header instead of "WWW-
Authenticate" (Authorization is the header you send back).

2.  It  thinks passwords in the URL are port names.

3. Even if you get around all that, it just doesn't work. It seems 
to encrypt the thing wrongly and get itself into an infinite loop 
sending the wrong answer back again and again, being rejected 
each time.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:00

Message:
Logged In: YES 
user_id=849994

For discussion about number 2 above, see #944396.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979407&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:02:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:02:52 -0800
Subject: [ python-Bugs-1075427 ] urllib2.HTTPBasicAuthHandler problem with
	[HOST]:[PORT]
Message-ID: <E1FBIBI-00040Y-QF@sc8-sf-web1.sourceforge.net>

Bugs item #1075427, was opened at 2004-11-29 18:06
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075427&group_id=5470

Please note that this 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
Submitted By: O-Zone (o-zone2004)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.HTTPBasicAuthHandler problem with [HOST]:[PORT]

Initial Comment:
I've encountered problems authenticating to an host
with this piece of code:

       passman =
urllib2.HTTPPasswordMgrWithDefaultRealm()      
        passman.add_password(None, theurl, username,
password)      
        authhandler =
urllib2.HTTPBasicAuthHandler(passman)                 
        opener = urllib2.build_opener(authhandler)    
                             
        urllib2.install_opener(opener)
        req = urllib2.Request(theurl)
        try:
            handle = urllib2.urlopen(req)

if i specify an URL like: http://[MyHostIP]:[Port] auth
helper never authorize me on the host. 

It work perfectly if i don't specify ANY port in the URL.

Regards, Michele "O-Zone" Pinassi

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:02

Message:
Logged In: YES 
user_id=849994

Closing, as the patch #974757 was committed.

----------------------------------------------------------------------

Comment By: MM Zeeman (mmzeeman)
Date: 2004-12-09 10:33

Message:
Logged In: YES 
user_id=350634

This is actually the same problem as reported in bug 974757,
which has a 
patch attached to it. 

The problem is that with basic authentication only the 
hostname + portnumber is passed to find_user_password. This
method 
works if there is no port number when a netloc is used. 

It looks like the answer from reduce_uri is wrong when port
numbers are used.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075427&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:26:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:26:43 -0800
Subject: [ python-Bugs-947571 ] urllib.urlopen() fails to raise exception
Message-ID: <E1FBIYN-0008AT-Ev@sc8-sf-web3.sourceforge.net>

Bugs item #947571, was opened at 2004-05-04 09:57
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen() fails to raise exception

Initial Comment:
I've come across a strange problem: even though
the docs say that urllib.urlopen() should raise an IOError
for server errors (e.g. 404s), all versions of Python that
I've tested (1.5.2 - 2.3) fail to do so.

Example:
>>> import urllib
>>> f =
urllib.urlopen('http://www.example.net/this-url-does-not-exist/')
>>> print f.read()
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /this-url-does-not-exist/ was not
found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.27 Server at www.example.com Port
80</ADDRESS>
</BODY></HTML>

Either the docs are wrong or the implementation has a
really long standing bug or I am missing something.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:26

Message:
Logged In: YES 
user_id=849994

Committed an addition to the docs in rev. 42527, 42528.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 19:20

Message:
Logged In: YES 
user_id=371366

I suggest closing as Won't Fix or Not A Bug, but change the 
documentation for urllib.urlopen() to read:

    """urlopen(url [, data]) -> open file-like object
    using urllib._urlopener, which will be an instance of
    FancyURLopener if not already set."""

The onus is still on the user to notice in the docs that 
FancyURLopener will ignore HTTP error responses for which it 
does not have an explicit handler, but at least this way they'll 
at least be pointed in the right direction.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-10 19:08

Message:
Logged In: YES 
user_id=261020

Seems a mistake to change this now.  The current behaviour
should be documented, though, of course.


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 18:39

Message:
Logged In: YES 
user_id=371366

I suppose I could've made that example a little simpler:

class ErrorRecognizingURLopener(urllib.FancyURLopener):
    http_error_default = urllib.URLopener.http_error_default

urllib._urlopener = ErrorRecognizingURLopener()


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 18:25

Message:
Logged In: YES 
user_id=371366

In urllib.FancyURLopener, which is the class used by 
urllib.urlopen(), there is this override of URLopener's 
http_error_default:

    def http_error_default(self, url, fp, errcode, errmsg, 
headers):
        """Default error handling -- don't raise an exception."""
        return addinfourl(fp, headers, "http:" + url)

I don't see how this is really all that desirable, but 
nevertheless it appears to be quite deliberate.

It looks like the intent in urlopen is that if you want to use 
some other opener besides an instance of FancyURLopener, 
you can set urllib._urlopener. This seems to work:

>>> import urllib
>>> class MyUrlOpener(urllib.FancyURLopener):
...     def http_error_default(*args, **kwargs):
...         return urllib.URLopener.http_error_default(*args, 
**kwargs)
... 
>>> urllib._urlopener = MyUrlOpener()
>>> urllib.urlopen('http://www.example.com/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib.py", line 76, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.3/urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.3/urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.3/urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File "<stdin>", line 3, in http_error_default
  File "/usr/local/lib/python2.3/urllib.py", line 329, in 
http_error_default
    raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 404, 'Not Found', <httplib.HTTPMessage 
instance at 0x836298c>)

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 18:29

Message:
Logged In: YES 
user_id=89016

This seems to work with urllib2:
>>> import urllib2
>>> f = urllib2.urlopen('http://www.example.net/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib2.py", line 129, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.3/urllib2.py", line 326, in open
    '_open', req)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 901, in 
http_open
    return self.do_open(httplib.HTTP, req)
  File "/usr/local/lib/python2.3/urllib2.py", line 895, in do_open
    return self.parent.error('http', req, fp, code, msg, hdrs)
  File "/usr/local/lib/python2.3/urllib2.py", line 352, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 412, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 404: Not Found

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:30:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:30:17 -0800
Subject: [ python-Bugs-1178141 ] urllib.py overwrite HTTPError code with 200
Message-ID: <E1FBIbp-00044e-2H@sc8-sf-web1.sourceforge.net>

Bugs item #1178141, was opened at 2005-04-06 22:48
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178141&group_id=5470

Please note that this message 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: Pending
Resolution: None
Priority: 5
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.py overwrite HTTPError code with 200

Initial Comment:
I found this bug while trying to understand why a 404
Not Found error was reported as a 200 Not Found.

Turns out the HTTPError's self.code is overwritten with
200 after
the 404 was correctly assigned.

The attached patch fixes the problem.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:30

Message:
Logged In: YES 
user_id=849994

I cannot see the point of the patch and cannot reproduce the
error.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-04-08 16:18

Message:
Logged In: YES 
user_id=764593

Please reattach (SF didn't catch the file)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178141&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:37:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:37:16 -0800
Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263
	encoding bug
Message-ID: <E1FBIia-0001gY-K6@sc8-sf-web6.sourceforge.net>

Bugs item #1115379, was opened at 2005-02-03 13:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

Please note that this 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: 6
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Built-in compile function with PEP 0263 encoding bug

Initial Comment:
a = 'print "Hello, World"'
u = '# -*- coding: utf-8 -*-\n' + a

print compile(a, '<string>', 'exec') # ok
print compile(u, '<string>', 'exec') # ok
print compile(unicode(a), '<string>', 'exec') # ok
print compile(unicode(u), '<string>', 'exec') # error

# The last line gives a SystemError.
# Think this is a bug.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:37

Message:
Logged In: YES 
user_id=849994

This even aborts the interpreter in 2.5 HEAD with a failing
assertion.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-09-28 05:48

Message:
Logged In: YES 
user_id=21627

If you load the files manually, why is it that you want to
decode them to Unicode before compile()ing them? Couldn't
you just pass the bytes you read from the file to compile()?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-28 04:29

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: V?gv?lgyi Attila (wigy)
Date: 2005-09-28 04:20

Message:
Logged In: YES 
user_id=156682

If this special case is a feature, not a bug, than it breaks
some symmetry for sure.

If I run a script having utf-8 encoding from a file with

  python script.py

then it has to have an encoding declaration. Now if I would
like to load the same file manually, decode it to a unicode
object, I also have to remove the encoding declaration at
the beginning of the file before I can give it to the
compile() function.

What special advantage comes from the fact that the compiler
does not simply ignore encoding declaration nodes from
unicode objects? Does this error message catch some possible
errors or does it make the compiler code simpler?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-10 00:37

Message:
Logged In: YES 
user_id=21627

There is a bug somewhere, certainly. However, I believe it
is in PEP 263, which should point out that unicode strings
in compile are only legal if they do *not* contain an
encoding declaration, as such strings are implicitly encoded
as UTF-8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:42:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:42:20 -0800
Subject: [ python-Bugs-780730 ] source files using encoding ./. universal
	newlines
Message-ID: <E1FBInU-0001iA-OU@sc8-sf-web6.sourceforge.net>

Bugs item #780730, was opened at 2003-07-31 11:16
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: M.-A. Lemburg (lemburg)
Summary: source files using encoding ./. universal newlines

Initial Comment:
Universal Newline Support doesn't work for source files
that contain encoding definition.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-20 22:42

Message:
Logged In: YES 
user_id=89016

The changes to the codecs done in Python 2.4 added support
for universal newlines:

Python 2.4.1 (#2, Mar 31 2005, 00:05:10) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> open("foo.py", "wb").write("# -*- coding: iso-8859-1
-*-\rprint 17\rprint 23\r")
>>> import foo
17
23
>>> 


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 07:50

Message:
Logged In: YES 
user_id=33168

I don't see a clear resolution here.  Is there something we
can/should do to fix this problem in 2.5?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-05 12:48

Message:
Logged In: YES 
user_id=45365

You misunderstand what I tried to say (or I mis-said it:-): there is 
no such thing as mode &quot;rbU&quot;, check the code in fileobject.c.

There is &quot;r&quot; == &quot;rt&quot; for text mode, &quot;rb&quot; for binary mode, 
&quot;U&quot;==&quot;rU&quot; for universal newline textmode. With &quot;rU&quot; the 
underlying file is opened in binary mode, so I don't think we'll 
have the control-Z problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-05 09:31

Message:
Logged In: YES 
user_id=38388

Thanks John.

Not sure whether any of codecs would actually use 0x1A,
but using &quot;rbU&quot;  sounds like the safer approach then.

----------------------------------------------------------------------

Comment By: John J Smith (johnjsmith)
Date: 2003-08-04 21:34

Message:
Logged In: YES 
user_id=830565

In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated
as EOF, unless the file is opened with 'rb'.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 17:57

Message:
Logged In: YES 
user_id=38388

Jack, I was just looking at the code I posted and the one
in fileobect.c. The latter enables universal newline support
whenever it sees a 'U' in the mode string, so I throught that
adding a 'U' to the mode would be enough.

The only system where 'b' does make a difference that I'm
aware of is Windows, so you may want to check whether it
makes a difference there.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-04 10:24

Message:
Logged In: YES 
user_id=45365

There's no such things as &quot;rbU&quot;, I think, but simply &quot;rU&quot; should 
work. As far as I know the only difference between &quot;r&quot; and &quot;rb&quot; is 
newline conversion, right? If there are C libraries that do more 
then we should implement &quot;rbU&quot;.

About 2.3.1 compatibility: technically we could break workarounds 
people have done themselves, but I think the chances are slim. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 10:21

Message:
Logged In: YES 
user_id=38388

Uhm, we don't impose Universal readline support on the codecs.
They would just get a stream object that happens to know
about universal newlines and work with it. That's completely
in line with the codec spec.

I'm +1 on adding this to 2.3.1.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 22:22

Message:
Logged In: YES 
user_id=21627

That would work indeed. The question is whether we can
impose support for universal newlines on all codecs &quot;out
there&quot;, for Python 2.3.1, when 2.3 makes no such requirement.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-03 21:31

Message:
Logged In: YES 
user_id=38388

I'm not sure this is correct: unless the codecs implement
their own .readline() implementation, the one in codecs.py
is used and that simply delegates the readline request to
the underlying stream object.

Now. since the stream object in the source code reader is
a plain Python file object, currently opened in &quot;rb&quot; mode,
changing the mode to &quot;rbU&quot; should be enough to get
universal readline support for all such codecs.

The relevant code is in Parser/tokenizer.c:fp_setreadl():

static int
fp_setreadl(struct tok_state *tok, const char* enc)
{
	PyObject *reader, *stream, *readline;

	/* XXX: constify filename argument. */
	stream = PyFile_FromFile(tok-&gt;fp, (char*)tok-&gt;filename,
&quot;rb&quot;, NULL);
	if (stream == NULL)
		return 0;

	reader = PyCodec_StreamReader(enc, stream, NULL);
	Py_DECREF(stream);
	if (reader == NULL)
		return 0;

	readline = PyObject_GetAttrString(reader, &quot;readline&quot;);
	Py_DECREF(reader);
	if (readline == NULL)
		return 0;

	tok-&gt;decoding_readline = readline;
	return 1;
}


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 21:19

Message:
Logged In: YES 
user_id=21627

The only way to implement that would be to add 'U' support
for all codecs, and open the codec with the 'U' flag. As
this will also affect codecs not part of Python, we cannot
fix this bug in Python 2.3, but have to defer a solution to
Python 2.4.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-01 11:45

Message:
Logged In: YES 
user_id=45365

The submitter isn't calling open explicitly, but PEP278 is also about 
the implicit opening of sourcefiles by the interpreter.

My guess (but I don't know the PEP263 implementation at all) is 
that when you specify an encoding the normal code that the 
interpreter uses to read sourcefiles is bypassed, and replaced by 
something that does the encoding magic. Apparently this code 
does not do universal newline conversion, which it should.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 10:22

Message:
Logged In: YES 
user_id=21627

I see. This is not about PEP 278, though, as you are not
calling any open() function, and passing no 'U' argument to
it - cross-platform newlines should work independent of that
PEP.

----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2003-08-01 09:35

Message:
Logged In: YES 
user_id=463672

Attached file has encoding definition and it's newline is '\r'.
Executing this script on Windows 2000, I got following error.
But it runs fine if I remove encoding definition. 

C:\Python23&gt;python .\test.py
  File &quot;.\test.py&quot;, line 2
a() print 'hi'
            ^
SyntaxError: invalid syntax


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 09:04

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is: Source code files
and universal newline support have nothing to do with each
other.

Can you attach a small example that demonstrates the problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:46:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:46:39 -0800
Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses
	Qt moc utility
Message-ID: <E1FBIrf-0008MY-Qp@sc8-sf-web2.sourceforge.net>

Bugs item #1086854, was opened at 2004-12-17 05:07
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470

Please note that this 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
Submitted By: Jeremy Friesner (jfriesne)
>Assigned to: Georg Brandl (birkenfeld)
Summary: "slots" member variable in object.h confuses Qt moc utility

Initial Comment:
This isn't really a Python bug per se, but it's easy to fix so I'm 
filing a bug report anyway.  The problem is with the line  
 
PyObject *name, *slots; 
 
in the definition of struct _heaptypeobject at line 343 of 
Include/object.h.  I'm embedding Python into my app that uses 
the TrollTech Qt GUI, and Qt has a preprocessor program 
named "moc" that looks for certain non-standard keywords.  
 
One of these keywords is the word "slots"... so having a 
member variable named "slots" in Include/object.h confuses 
moc and causes my app to have a build error.  I was able to 
fix the problem by renaming the "slots" member variable to 
"xslots" in the Python source, but it would be nicer if it was 
renamed in the official Python distribution so that the problem 
doesn't come up for the next guy. 
 

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-02-20 22:46

Message:
Logged In: YES 
user_id=21627

Sure!

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:29

Message:
Logged In: YES 
user_id=1188172

Assigning you again, Martin: should I change the names for 2.5?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-10-02 09:46

Message:
Logged In: YES 
user_id=21627

I would assume that the changes are necessary *only* in
header files, which means that only heaptype is to be changed.

I don't know what happened to the old principle of
protecting struct members against name collisions; I think
if they are to be renamed, their names should be ht_type,
ht_name, ht_slots. (I never understood the rationale for
this convention until this report: there always might be a
collision with a macro name).

Unfortunately, such a change is not so easy as it may sound:
it may break existing applications. Still, I think it should
be done, but only for 2.5.

Unassigning myself.

----------------------------------------------------------------------

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-30 17:38

Message:
Logged In: YES 
user_id=383828

On second thought, I believe mwh is right; most of those
changes are unnecessary.  (I made the changes a long time
ago, so when I grepped for them the other day the memory for
their motivation wasn't fresh).  The Python .c files aren't
fed to moc, so references to 'signals' and 'slots' in the .c
files should compile okay.  It's just the references to
those identifiers in the Python .h files that cause a
problem, if the .h files are #included in a Qt-using C++
program, after #including a Qt header.  So I think probably
just the original three changes are sufficient.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-09-30 10:44

Message:
Logged In: YES 
user_id=6656

I'm not particularly convinced that this is a great idea.  Python uses 'new' 
and 'class' as C identifiers which mean you can't compile it as C++ -- but 
Python isn't written in C++, so this is fine.  Similarly, Python isn't designed 
to be fed to moc -- so why feed it to moc?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-29 22:50

Message:
Logged In: YES 
user_id=1188172

Ah, okay. However, I can't decide whether this will be done,
assigning to Martin for this case.

----------------------------------------------------------------------

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-29 22:48

Message:
Logged In: YES 
user_id=383828

Unfortunately, yes,  When compiling with Qt, the words "signals" 
and "slots" become essentially reserved keywords, and any use of 
them as variable names causes a compile error. 

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-29 22:37

Message:
Logged In: YES 
user_id=1188172

Okay. Most of your replacements are function parameters or
function local variables, do they have to be replaced too?

----------------------------------------------------------------------

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-28 18:59

Message:
Logged In: YES 
user_id=383828

Here is a file containing grep output showing all the lines
where I changed 'slots' to 'xslots' in my codebase:

http://www.lcscanada.com/jaf/xslots.zip

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-28 15:02

Message:
Logged In: YES 
user_id=1188172

I can find 3 occurences in typeobject.c where the variable
would have to be renamed. Can you find any other?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:48:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:48:16 -0800
Subject: [ python-Bugs-780730 ] source files using encoding ./. universal
	newlines
Message-ID: <E1FBItE-0007L3-Gs@sc8-sf-web5.sourceforge.net>

Bugs item #780730, was opened at 2003-07-31 09:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: M.-A. Lemburg (lemburg)
Summary: source files using encoding ./. universal newlines

Initial Comment:
Universal Newline Support doesn't work for source files
that contain encoding definition.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:48

Message:
Logged In: YES 
user_id=849994

So this is resolved now?

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-20 21:42

Message:
Logged In: YES 
user_id=89016

The changes to the codecs done in Python 2.4 added support
for universal newlines:

Python 2.4.1 (#2, Mar 31 2005, 00:05:10) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> open("foo.py", "wb").write("# -*- coding: iso-8859-1
-*-\rprint 17\rprint 23\r")
>>> import foo
17
23
>>> 


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 05:50

Message:
Logged In: YES 
user_id=33168

I don't see a clear resolution here.  Is there something we
can/should do to fix this problem in 2.5?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-05 10:48

Message:
Logged In: YES 
user_id=45365

You misunderstand what I tried to say (or I mis-said it:-): there is 
no such thing as mode &quot;rbU&quot;, check the code in fileobject.c.

There is &quot;r&quot; == &quot;rt&quot; for text mode, &quot;rb&quot; for binary mode, 
&quot;U&quot;==&quot;rU&quot; for universal newline textmode. With &quot;rU&quot; the 
underlying file is opened in binary mode, so I don't think we'll 
have the control-Z problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-05 07:31

Message:
Logged In: YES 
user_id=38388

Thanks John.

Not sure whether any of codecs would actually use 0x1A,
but using &quot;rbU&quot;  sounds like the safer approach then.

----------------------------------------------------------------------

Comment By: John J Smith (johnjsmith)
Date: 2003-08-04 19:34

Message:
Logged In: YES 
user_id=830565

In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated
as EOF, unless the file is opened with 'rb'.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 15:57

Message:
Logged In: YES 
user_id=38388

Jack, I was just looking at the code I posted and the one
in fileobect.c. The latter enables universal newline support
whenever it sees a 'U' in the mode string, so I throught that
adding a 'U' to the mode would be enough.

The only system where 'b' does make a difference that I'm
aware of is Windows, so you may want to check whether it
makes a difference there.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-04 08:24

Message:
Logged In: YES 
user_id=45365

There's no such things as &quot;rbU&quot;, I think, but simply &quot;rU&quot; should 
work. As far as I know the only difference between &quot;r&quot; and &quot;rb&quot; is 
newline conversion, right? If there are C libraries that do more 
then we should implement &quot;rbU&quot;.

About 2.3.1 compatibility: technically we could break workarounds 
people have done themselves, but I think the chances are slim. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 08:21

Message:
Logged In: YES 
user_id=38388

Uhm, we don't impose Universal readline support on the codecs.
They would just get a stream object that happens to know
about universal newlines and work with it. That's completely
in line with the codec spec.

I'm +1 on adding this to 2.3.1.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 20:22

Message:
Logged In: YES 
user_id=21627

That would work indeed. The question is whether we can
impose support for universal newlines on all codecs &quot;out
there&quot;, for Python 2.3.1, when 2.3 makes no such requirement.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-03 19:31

Message:
Logged In: YES 
user_id=38388

I'm not sure this is correct: unless the codecs implement
their own .readline() implementation, the one in codecs.py
is used and that simply delegates the readline request to
the underlying stream object.

Now. since the stream object in the source code reader is
a plain Python file object, currently opened in &quot;rb&quot; mode,
changing the mode to &quot;rbU&quot; should be enough to get
universal readline support for all such codecs.

The relevant code is in Parser/tokenizer.c:fp_setreadl():

static int
fp_setreadl(struct tok_state *tok, const char* enc)
{
	PyObject *reader, *stream, *readline;

	/* XXX: constify filename argument. */
	stream = PyFile_FromFile(tok-&gt;fp, (char*)tok-&gt;filename,
&quot;rb&quot;, NULL);
	if (stream == NULL)
		return 0;

	reader = PyCodec_StreamReader(enc, stream, NULL);
	Py_DECREF(stream);
	if (reader == NULL)
		return 0;

	readline = PyObject_GetAttrString(reader, &quot;readline&quot;);
	Py_DECREF(reader);
	if (readline == NULL)
		return 0;

	tok-&gt;decoding_readline = readline;
	return 1;
}


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 19:19

Message:
Logged In: YES 
user_id=21627

The only way to implement that would be to add 'U' support
for all codecs, and open the codec with the 'U' flag. As
this will also affect codecs not part of Python, we cannot
fix this bug in Python 2.3, but have to defer a solution to
Python 2.4.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-01 09:45

Message:
Logged In: YES 
user_id=45365

The submitter isn't calling open explicitly, but PEP278 is also about 
the implicit opening of sourcefiles by the interpreter.

My guess (but I don't know the PEP263 implementation at all) is 
that when you specify an encoding the normal code that the 
interpreter uses to read sourcefiles is bypassed, and replaced by 
something that does the encoding magic. Apparently this code 
does not do universal newline conversion, which it should.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 08:22

Message:
Logged In: YES 
user_id=21627

I see. This is not about PEP 278, though, as you are not
calling any open() function, and passing no 'U' argument to
it - cross-platform newlines should work independent of that
PEP.

----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2003-08-01 07:35

Message:
Logged In: YES 
user_id=463672

Attached file has encoding definition and it's newline is '\r'.
Executing this script on Windows 2000, I got following error.
But it runs fine if I remove encoding definition. 

C:\Python23&gt;python .\test.py
  File &quot;.\test.py&quot;, line 2
a() print 'hi'
            ^
SyntaxError: invalid syntax


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 07:04

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is: Source code files
and universal newline support have nothing to do with each
other.

Can you attach a small example that demonstrates the problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:48:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:48:58 -0800
Subject: [ python-Bugs-1345313 ] Python 2.4 and 2.3.5 won't build on OpenBSD
	3.7
Message-ID: <E1FBItu-0008Mx-L0@sc8-sf-web2.sourceforge.net>

Bugs item #1345313, was opened at 2005-11-01 22:37
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dan (catdude)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 and 2.3.5 won't build on OpenBSD 3.7

Initial Comment:
Both Python 2.3.5 and 2.4 fail to build, and both
report the same errors. The output of configure and of
make are attached.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-02-20 22:48

Message:
Logged In: YES 
user_id=21627

Python now has a work-around for that, and also one for
OpenBSD 3.8. So closing it as fixed.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:32

Message:
Logged In: YES 
user_id=1188172

I assume this is not Python specific, then?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-11-02 05:10

Message:
Logged In: YES 
user_id=21627

Please report this as a bug to the OpenBSD developers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:50:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:50:56 -0800
Subject: [ python-Bugs-830261 ] __mul__ taken as __rmul__ for mul-by-int only
Message-ID: <E1FBIvo-0007LR-7f@sc8-sf-web5.sourceforge.net>

Bugs item #830261, was opened at 2003-10-25 21:57
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830261&group_id=5470

Please note that this message 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
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: __mul__ taken as __rmul__ for mul-by-int only

Initial Comment:
Tiniest way to reproduce:
&gt;&gt;&gt; class X(object):
...   def __mul__(self, other): return '%r???' % other
...
&gt;&gt;&gt; x=X()
&gt;&gt;&gt; 23*x
'23???'
&gt;&gt;&gt; 2.3*x
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
TypeError: can't multiply sequence to non-int
&gt;&gt;&gt;

weird error message hints at cause: Objects/typeobject.c sets sq_repeat slot indifferently for both __mul__ AND __rmul__, then Objects/abstract.c function PyNumber_Multiply checks both operands for sq_repeats, finds it in the RHO and thus calls
sequence_repeat which erroneously succeeds when the LHO
is 23 and fails w/weird error message when it's 2.3.

I'm leaving this unassigned because it's anything but obvious to me what the fix should be!  If anybody HAS obvious fixes to
suggest I'll be glad to implement and commit them, though.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:50

Message:
Logged In: YES 
user_id=849994

It's now fixed in the branch too, thanks to a patch by Armin
I guess.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:20

Message:
Logged In: YES 
user_id=1188172

This appears to be fixed in 2.5 HEAD, but not in the 2.4 branch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830261&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:52:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:52:43 -0800
Subject: [ python-Bugs-837242 ] id() for large ptr should return a long
Message-ID: <E1FBIxX-0004AG-2E@sc8-sf-web1.sourceforge.net>

Bugs item #837242, was opened at 2003-11-06 15:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Martin v. L??wis (loewis)
Summary: id() for large ptr should return a long

Initial Comment:
Under something like Redhat 10 the address space is
messed about with to &quot;prevent stack smash attacks&quot; or
some such. This means that you sometimes get addresses
in the high half of a 32 bit int. Since Python ints are
signed, this means we return a negative number from
id(). For 2.4, we should probably return a long. 

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:52

Message:
Logged In: YES 
user_id=849994

Ping!

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-13 17:24

Message:
Logged In: YES 
user_id=1188172

You're making changes to PyLong_FromVoidPtr, doesn't
PyLong_AsVoidPtr have to be changed too?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-01-11 22:39

Message:
Logged In: YES 
user_id=21627

How about the attached patch?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:21

Message:
Logged In: YES 
user_id=1188172

Perhaps, for 2.5?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-11-06 20:54

Message:
Logged In: YES 
user_id=21627

Would there anything be wrong with making that change right
away?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:53:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:53:20 -0800
Subject: [ python-Bugs-1178141 ] urllib.py overwrite HTTPError code with 200
Message-ID: <E1FBIy8-0004Ar-2I@sc8-sf-web1.sourceforge.net>

Bugs item #1178141, was opened at 2005-04-06 18:48
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178141&group_id=5470

Please note that this message 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: Pending
Resolution: None
Priority: 5
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.py overwrite HTTPError code with 200

Initial Comment:
I found this bug while trying to understand why a 404
Not Found error was reported as a 200 Not Found.

Turns out the HTTPError's self.code is overwritten with
200 after
the 404 was correctly assigned.

The attached patch fixes the problem.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-20 16:53

Message:
Logged In: YES 
user_id=764593

Barry -- Are you sure that the original status code wasn't 
204?  If so, then this patch makes more sense.

Georg -- any unrecognized response status NXX should be 
treated as N00.  Since 204 (and 298, for that matter) aren't 
recognized by the urllib opener, they should be treated as 
200, which the patch does.  

Whether the patch makes it harder to treat 204 separately 
when it is recognized is another issue.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 16:30

Message:
Logged In: YES 
user_id=849994

I cannot see the point of the patch and cannot reproduce the
error.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-04-08 12:18

Message:
Logged In: YES 
user_id=764593

Please reattach (SF didn't catch the file)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178141&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 22:54:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 13:54:43 -0800
Subject: [ python-Bugs-942706 ] Python crash on
	__init__/__getattr__/__setattr__ interaction
Message-ID: <E1FBIzT-0008Gn-01@sc8-sf-web3.sourceforge.net>

Bugs item #942706, was opened at 2004-04-26 23:39
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470

Please note that this message 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: Pending
Resolution: None
Priority: 5
Submitted By: has (hhas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python crash on __init__/__getattr__/__setattr__ interaction

Initial Comment:
The following code causes [Mac]Python 2.3 process to crash 
(Bad!) rather than raise an error (good) when creating a new 
instance of Foo:

class Foo:
	def __init__(self):
		self.x = 1
	
	def __getattr__(self, name):
		if self.x:
			pass # etc...
	
	def __setattr__(self, name, val):
		if self.x:
			pass # etc...


(See <http://freespace.virgin.net/hamish.sanderson/
HTMLTemplate-0.4.0.tar.gz> for a working example plus general 
solution to the referencing-instance-var-before-it's-created 
paradox that threw up this bug in the first place.)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:54

Message:
Logged In: YES 
user_id=849994

OP: Any further insights?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 21:56

Message:
Logged In: YES 
user_id=1188172

To the OP: Is there still a crash with newest Python 2.4?

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 19:17

Message:
Logged In: YES 
user_id=89016

Assigning to self.x in __init__() calls __setattr__(), which 
checks self.x, which calls __getattr__() which checks self.x, 
which leads to endless recursion. This usually leads to 
a "RuntimeError: maximum recursion depth exceeded". In what 
way does Python 2.3 crash?

To avoid the recursion access the instance dictionary directly:
class Foo:
   def __init__(self):
      self.x = 1

   def __getattr__(self, name):
      if "x" in self.__dict__ and self.__dict__["x"]:
         pass # etc...

   def __setattr__(self, name, val):
      if self.x:
         pass # etc...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 23:06:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 14:06:10 -0800
Subject: [ python-Bugs-780730 ] source files using encoding ./. universal
	newlines
Message-ID: <E1FBJAY-0008SC-4L@sc8-sf-web2.sourceforge.net>

Bugs item #780730, was opened at 2003-07-31 11:16
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: M.-A. Lemburg (lemburg)
Summary: source files using encoding ./. universal newlines

Initial Comment:
Universal Newline Support doesn't work for source files
that contain encoding definition.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-20 23:06

Message:
Logged In: YES 
user_id=89016

It looks to me that way.

Any comments from the OP?


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 22:48

Message:
Logged In: YES 
user_id=849994

So this is resolved now?

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-20 22:42

Message:
Logged In: YES 
user_id=89016

The changes to the codecs done in Python 2.4 added support
for universal newlines:

Python 2.4.1 (#2, Mar 31 2005, 00:05:10) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> open("foo.py", "wb").write("# -*- coding: iso-8859-1
-*-\rprint 17\rprint 23\r")
>>> import foo
17
23
>>> 


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 07:50

Message:
Logged In: YES 
user_id=33168

I don't see a clear resolution here.  Is there something we
can/should do to fix this problem in 2.5?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-05 12:48

Message:
Logged In: YES 
user_id=45365

You misunderstand what I tried to say (or I mis-said it:-): there is 
no such thing as mode &quot;rbU&quot;, check the code in fileobject.c.

There is &quot;r&quot; == &quot;rt&quot; for text mode, &quot;rb&quot; for binary mode, 
&quot;U&quot;==&quot;rU&quot; for universal newline textmode. With &quot;rU&quot; the 
underlying file is opened in binary mode, so I don't think we'll 
have the control-Z problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-05 09:31

Message:
Logged In: YES 
user_id=38388

Thanks John.

Not sure whether any of codecs would actually use 0x1A,
but using &quot;rbU&quot;  sounds like the safer approach then.

----------------------------------------------------------------------

Comment By: John J Smith (johnjsmith)
Date: 2003-08-04 21:34

Message:
Logged In: YES 
user_id=830565

In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated
as EOF, unless the file is opened with 'rb'.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 17:57

Message:
Logged In: YES 
user_id=38388

Jack, I was just looking at the code I posted and the one
in fileobect.c. The latter enables universal newline support
whenever it sees a 'U' in the mode string, so I throught that
adding a 'U' to the mode would be enough.

The only system where 'b' does make a difference that I'm
aware of is Windows, so you may want to check whether it
makes a difference there.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-04 10:24

Message:
Logged In: YES 
user_id=45365

There's no such things as &quot;rbU&quot;, I think, but simply &quot;rU&quot; should 
work. As far as I know the only difference between &quot;r&quot; and &quot;rb&quot; is 
newline conversion, right? If there are C libraries that do more 
then we should implement &quot;rbU&quot;.

About 2.3.1 compatibility: technically we could break workarounds 
people have done themselves, but I think the chances are slim. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 10:21

Message:
Logged In: YES 
user_id=38388

Uhm, we don't impose Universal readline support on the codecs.
They would just get a stream object that happens to know
about universal newlines and work with it. That's completely
in line with the codec spec.

I'm +1 on adding this to 2.3.1.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 22:22

Message:
Logged In: YES 
user_id=21627

That would work indeed. The question is whether we can
impose support for universal newlines on all codecs &quot;out
there&quot;, for Python 2.3.1, when 2.3 makes no such requirement.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-03 21:31

Message:
Logged In: YES 
user_id=38388

I'm not sure this is correct: unless the codecs implement
their own .readline() implementation, the one in codecs.py
is used and that simply delegates the readline request to
the underlying stream object.

Now. since the stream object in the source code reader is
a plain Python file object, currently opened in &quot;rb&quot; mode,
changing the mode to &quot;rbU&quot; should be enough to get
universal readline support for all such codecs.

The relevant code is in Parser/tokenizer.c:fp_setreadl():

static int
fp_setreadl(struct tok_state *tok, const char* enc)
{
	PyObject *reader, *stream, *readline;

	/* XXX: constify filename argument. */
	stream = PyFile_FromFile(tok-&gt;fp, (char*)tok-&gt;filename,
&quot;rb&quot;, NULL);
	if (stream == NULL)
		return 0;

	reader = PyCodec_StreamReader(enc, stream, NULL);
	Py_DECREF(stream);
	if (reader == NULL)
		return 0;

	readline = PyObject_GetAttrString(reader, &quot;readline&quot;);
	Py_DECREF(reader);
	if (readline == NULL)
		return 0;

	tok-&gt;decoding_readline = readline;
	return 1;
}


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 21:19

Message:
Logged In: YES 
user_id=21627

The only way to implement that would be to add 'U' support
for all codecs, and open the codec with the 'U' flag. As
this will also affect codecs not part of Python, we cannot
fix this bug in Python 2.3, but have to defer a solution to
Python 2.4.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-01 11:45

Message:
Logged In: YES 
user_id=45365

The submitter isn't calling open explicitly, but PEP278 is also about 
the implicit opening of sourcefiles by the interpreter.

My guess (but I don't know the PEP263 implementation at all) is 
that when you specify an encoding the normal code that the 
interpreter uses to read sourcefiles is bypassed, and replaced by 
something that does the encoding magic. Apparently this code 
does not do universal newline conversion, which it should.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 10:22

Message:
Logged In: YES 
user_id=21627

I see. This is not about PEP 278, though, as you are not
calling any open() function, and passing no 'U' argument to
it - cross-platform newlines should work independent of that
PEP.

----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2003-08-01 09:35

Message:
Logged In: YES 
user_id=463672

Attached file has encoding definition and it's newline is '\r'.
Executing this script on Windows 2000, I got following error.
But it runs fine if I remove encoding definition. 

C:\Python23&gt;python .\test.py
  File &quot;.\test.py&quot;, line 2
a() print 'hi'
            ^
SyntaxError: invalid syntax


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 09:04

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is: Source code files
and universal newline support have nothing to do with each
other.

Can you attach a small example that demonstrates the problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 23:06:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 14:06:41 -0800
Subject: [ python-Bugs-991196 ] An inconsistency with nested scopes
Message-ID: <E1FBJB3-0008SJ-GM@sc8-sf-web2.sourceforge.net>

Bugs item #991196, was opened at 2004-07-14 21:30
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991196&group_id=5470

Please note that this message 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
Submitted By: Nick Jacobson (nickjacobson)
Assigned to: Nobody/Anonymous (nobody)
Summary: An inconsistency with nested scopes

Initial Comment:
There's an inconsistency with nested scopes.

>From the Python Ref. Manual:

"If [a local variable] definition occurs in a function block, 
the scope extends to any blocks contained within the 
defining one..."

i.e. So as long as code is not on the module level, 
scopes are extended.  Therefore this works:

def main():
	y = 3
	def execfunc():
		print y
	execfunc()

if __name__ == '__main__':
	main()

In addition, if code IS on the module level, its variables 
go in globals().  So this works too:

y = 3
def execfunc():
	print y
execfunc()

However, (here's the inconsistency) the following code 
fails, saying that y is undefined:

def main():
	s = \
"""
y = 3
def execfunc():
	print y
execfunc()
"""
	d = {}
	e = {}
	exec s in d, e

if __name__ == '__main__':
	main()

In this case, the code in s is treated like it's on the 
module level, and the nested scope treatment of y 
doesn't occur.  BUT, unlike normal code on the module 
level, y doesn't go in globals().  I think globals() is 
locked or something?


Conclusion:

The latter piece of code should work; that is, y should 
be nested and therefore recognized by execfunc().


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 22:06

Message:
Logged In: YES 
user_id=849994

Closed #1167300 as a duplicate.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-08-07 21:59

Message:
Logged In: YES 
user_id=4771

The behavior you get can be explained quite easy, but it seems nevertheless inconsistent with the documentation: in my opinion it is a serious bug.

The reason the "exec"ed code doesn't work like the same code put at the global module level is that code that runs at the module level always runs with the same dictionary for its globals and locals, whereas in your example you use two different dictionaries.

Assignments always go to the locals; that's why 'y' goes into the dictionary 'e'.  Now a function can only see its own locals and the surrounding globals; that's why execfunc() misses the value of 'y'.  This is the old way Python worked.  In recent versions, a special trick was added so that functions defined inside another function find variable bindings from the enclosing function.  I think you found a case where this trick fails to apply.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-07-22 16:55

Message:
Logged In: YES 
user_id=341410

>>> def f():
...     y = 5
...     print 'y' in globals(), 'y' in locals()
...     def i():
...         print 'y' in globals(), 'y' in locals()
...     i()
...
>>> f()
False True
False False
>>>
>>> def g():
...     gl = {};lo={}
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals()
... def i():
...     print 'y' in globals(), 'y' in locals()
... i()
... ''' in gl, lo
...
>>> g()
False True
False False

That looks constant...but what if we print out 'y'?

>>> def s():
...     y = 5
...     print 'y' in globals(), 'y' in locals(), y
...     def i():
...         print 'y' in globals(), 'y' in locals(), y
...     i()
...
>>> s()
False True 5
False True 5
>>>
>>> def t():
...     gl = {};lo = {}
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals(), y
... def i():
...     print 'y' in globals(), 'y' in locals(), y
... i()
... ''' in gl, lo
...
>>> t()
False True 5
False False
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in t
  File "<string>", line 5, in ?
  File "<string>", line 4, in i
NameError: global name 'y' is not defined

Now why did 'y' stick itself into the locals() of i() in
s()?  Is this another bug?

What if we remove the namespaces gl and lo?

>>> def u():
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals(), y
... def i():
...     print 'y' in globals(), 'y' in locals(), y
... i()
... '''
...
>>> u()
False True 5
False False
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 2, in u
  File "<string>", line 5, in ?
  File "<string>", line 4, in i
NameError: global name 'y' is not defined

Nope, still dies.  It does seem to be a bug in exec.  I'm
still curious why 'y' was placed into i()'s local namespace
in s().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991196&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 23:06:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 14:06:42 -0800
Subject: [ python-Bugs-1167300 ] Error "exec"ing python code
Message-ID: <E1FBJB4-0001nb-Pw@sc8-sf-web6.sourceforge.net>

Bugs item #1167300, was opened at 2005-03-21 05:35
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error "exec"ing python code

Initial Comment:
I'm trying to 'exec'ing the following code:

class Foo: pass
class Bar:
    f = Foo
    
The error appears when using 'exec f in {}, {}':

>>> f = ''.join(open('/home/stefan/t.py').readlines())
>>> exec f in {}, {}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 2, in ?
  File "<string>", line 3, in Bar
NameError: name 'Foo' is not defined

I tested on python 2.3 and python 2.4, both show the same
behavior.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 22:06

Message:
Logged In: YES 
user_id=849994

This seems like a duplicate of #991196.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 21:11

Message:
Logged In: YES 
user_id=593130

I got a similar NameError in 2.2.1, so this is not due to a recent 
change.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2005-03-30 12:40

Message:
Logged In: YES 
user_id=99874

I can confirm this... it appears that things which are set
in the global scope within an "exec ... in {}, {}" are not
then correctly accessed in the global scope when being read.
The following two examples illustrate the problem:

>>> exec """\
... x = 3
... def f():
...     global x
...     print x
... f()
... """ in {}, {}
3

... and again without the global definition:

>>> exec """\
... x = 3
... def f():
...     print x
... f()
... """ in {}, {}
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 4, in ?
  File "<string>", line 3, in f
NameError: global name 'x' is not defined

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 23:10:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 14:10:05 -0800
Subject: [ python-Bugs-1263635 ] type() and isinstance() do not call
	__getattribute__
Message-ID: <E1FBJEL-0001o0-Oz@sc8-sf-web6.sourceforge.net>

Bugs item #1263635, was opened at 2005-08-19 02:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263635&group_id=5470

Please note that this message 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: Wont Fix
Priority: 5
Submitted By: Per Vognsen (pervognsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: type() and isinstance() do not call __getattribute__

Initial Comment:
The built-in functions type() and isinstance() do not call 
__getattribute__ for instances of user-defined classes. 
Thus, for instance,

x.__class__ == sometype

and

type(x) == sometype

can give inconsistent results.

I ran into this problem in writing a transparent 
persistence system, where instances of proxy classes 
are used as stand-ins for unloaded objects and the 
proxy does just-in-time loading by overloading 
__getattribute__ and __setattr__ (which changes 
__class__).

(This applies to 2.4.1.)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 22:10

Message:
Logged In: YES 
user_id=849994

Closing as I feel Raymond's right.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-26 08:48

Message:
Logged In: YES 
user_id=80475

I don't think this is going to change.  A number of builtins
directly access an object's structure and do not respect
overrides via __getattribute__.  This is somewhat intrinsic
the Python's current design.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263635&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 23:11:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 14:11:26 -0800
Subject: [ python-Bugs-780730 ] source files using encoding ./. universal
	newlines
Message-ID: <E1FBJFe-0001oU-GP@sc8-sf-web6.sourceforge.net>

Bugs item #780730, was opened at 2003-07-31 09:16
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: M.-A. Lemburg (lemburg)
Summary: source files using encoding ./. universal newlines

Initial Comment:
Universal Newline Support doesn't work for source files
that contain encoding definition.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-20 22:06

Message:
Logged In: YES 
user_id=89016

It looks to me that way.

Any comments from the OP?


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:48

Message:
Logged In: YES 
user_id=849994

So this is resolved now?

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-20 21:42

Message:
Logged In: YES 
user_id=89016

The changes to the codecs done in Python 2.4 added support
for universal newlines:

Python 2.4.1 (#2, Mar 31 2005, 00:05:10) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> open("foo.py", "wb").write("# -*- coding: iso-8859-1
-*-\rprint 17\rprint 23\r")
>>> import foo
17
23
>>> 


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 05:50

Message:
Logged In: YES 
user_id=33168

I don't see a clear resolution here.  Is there something we
can/should do to fix this problem in 2.5?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-05 10:48

Message:
Logged In: YES 
user_id=45365

You misunderstand what I tried to say (or I mis-said it:-): there is 
no such thing as mode &quot;rbU&quot;, check the code in fileobject.c.

There is &quot;r&quot; == &quot;rt&quot; for text mode, &quot;rb&quot; for binary mode, 
&quot;U&quot;==&quot;rU&quot; for universal newline textmode. With &quot;rU&quot; the 
underlying file is opened in binary mode, so I don't think we'll 
have the control-Z problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-05 07:31

Message:
Logged In: YES 
user_id=38388

Thanks John.

Not sure whether any of codecs would actually use 0x1A,
but using &quot;rbU&quot;  sounds like the safer approach then.

----------------------------------------------------------------------

Comment By: John J Smith (johnjsmith)
Date: 2003-08-04 19:34

Message:
Logged In: YES 
user_id=830565

In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated
as EOF, unless the file is opened with 'rb'.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 15:57

Message:
Logged In: YES 
user_id=38388

Jack, I was just looking at the code I posted and the one
in fileobect.c. The latter enables universal newline support
whenever it sees a 'U' in the mode string, so I throught that
adding a 'U' to the mode would be enough.

The only system where 'b' does make a difference that I'm
aware of is Windows, so you may want to check whether it
makes a difference there.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-04 08:24

Message:
Logged In: YES 
user_id=45365

There's no such things as &quot;rbU&quot;, I think, but simply &quot;rU&quot; should 
work. As far as I know the only difference between &quot;r&quot; and &quot;rb&quot; is 
newline conversion, right? If there are C libraries that do more 
then we should implement &quot;rbU&quot;.

About 2.3.1 compatibility: technically we could break workarounds 
people have done themselves, but I think the chances are slim. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 08:21

Message:
Logged In: YES 
user_id=38388

Uhm, we don't impose Universal readline support on the codecs.
They would just get a stream object that happens to know
about universal newlines and work with it. That's completely
in line with the codec spec.

I'm +1 on adding this to 2.3.1.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 20:22

Message:
Logged In: YES 
user_id=21627

That would work indeed. The question is whether we can
impose support for universal newlines on all codecs &quot;out
there&quot;, for Python 2.3.1, when 2.3 makes no such requirement.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-03 19:31

Message:
Logged In: YES 
user_id=38388

I'm not sure this is correct: unless the codecs implement
their own .readline() implementation, the one in codecs.py
is used and that simply delegates the readline request to
the underlying stream object.

Now. since the stream object in the source code reader is
a plain Python file object, currently opened in &quot;rb&quot; mode,
changing the mode to &quot;rbU&quot; should be enough to get
universal readline support for all such codecs.

The relevant code is in Parser/tokenizer.c:fp_setreadl():

static int
fp_setreadl(struct tok_state *tok, const char* enc)
{
	PyObject *reader, *stream, *readline;

	/* XXX: constify filename argument. */
	stream = PyFile_FromFile(tok-&gt;fp, (char*)tok-&gt;filename,
&quot;rb&quot;, NULL);
	if (stream == NULL)
		return 0;

	reader = PyCodec_StreamReader(enc, stream, NULL);
	Py_DECREF(stream);
	if (reader == NULL)
		return 0;

	readline = PyObject_GetAttrString(reader, &quot;readline&quot;);
	Py_DECREF(reader);
	if (readline == NULL)
		return 0;

	tok-&gt;decoding_readline = readline;
	return 1;
}


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 19:19

Message:
Logged In: YES 
user_id=21627

The only way to implement that would be to add 'U' support
for all codecs, and open the codec with the 'U' flag. As
this will also affect codecs not part of Python, we cannot
fix this bug in Python 2.3, but have to defer a solution to
Python 2.4.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-01 09:45

Message:
Logged In: YES 
user_id=45365

The submitter isn't calling open explicitly, but PEP278 is also about 
the implicit opening of sourcefiles by the interpreter.

My guess (but I don't know the PEP263 implementation at all) is 
that when you specify an encoding the normal code that the 
interpreter uses to read sourcefiles is bypassed, and replaced by 
something that does the encoding magic. Apparently this code 
does not do universal newline conversion, which it should.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 08:22

Message:
Logged In: YES 
user_id=21627

I see. This is not about PEP 278, though, as you are not
calling any open() function, and passing no 'U' argument to
it - cross-platform newlines should work independent of that
PEP.

----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2003-08-01 07:35

Message:
Logged In: YES 
user_id=463672

Attached file has encoding definition and it's newline is '\r'.
Executing this script on Windows 2000, I got following error.
But it runs fine if I remove encoding definition. 

C:\Python23&gt;python .\test.py
  File &quot;.\test.py&quot;, line 2
a() print 'hi'
            ^
SyntaxError: invalid syntax


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 07:04

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is: Source code files
and universal newline support have nothing to do with each
other.

Can you attach a small example that demonstrates the problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

From noreply at sourceforge.net  Mon Feb 20 23:15:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 14:15:37 -0800
Subject: [ python-Bugs-1435487 ] Crash when decoding UTF8
Message-ID: <E1FBJJh-0008Mk-Jl@sc8-sf-web3.sourceforge.net>

Bugs item #1435487, was opened at 2006-02-20 23: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=1435487&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Crash when decoding UTF8

Initial Comment:
Python segfaults when running the attached script on  
Python 2.4.2 Windows versions (tested with Win98SE 
HUN and WinXP HUN SP1). 
 
Linux version (Debian unstable) works fine, but 
cannot encode text to latin-2, since it decodes utf-8 
BOM that cannot be encoded. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1435487&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 00:48:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 20 Feb 2006 15:48:22 -0800
Subject: [ python-Bugs-942706 ] Python crash on
	__init__/__getattr__/__setattr__ interaction
Message-ID: <E1FBKlS-0004XO-3n@sc8-sf-web1.sourceforge.net>

Bugs item #942706, was opened at 2004-04-26 23:39
Message generated for change (Comment added) made by hhas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470

Please note that this message 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
Submitted By: has (hhas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python crash on __init__/__getattr__/__setattr__ interaction

Initial Comment:
The following code causes [Mac]Python 2.3 process to crash 
(Bad!) rather than raise an error (good) when creating a new 
instance of Foo:

class Foo:
	def __init__(self):
		self.x = 1
	
	def __getattr__(self, name):
		if self.x:
			pass # etc...
	
	def __setattr__(self, name, val):
		if self.x:
			pass # etc...


(See <http://freespace.virgin.net/hamish.sanderson/
HTMLTemplate-0.4.0.tar.gz> for a working example plus general 
solution to the referencing-instance-var-before-it's-created 
paradox that threw up this bug in the first place.)

----------------------------------------------------------------------

>Comment By: has (hhas)
Date: 2006-02-20 23:48

Message:
Logged In: YES 
user_id=996627

Original test used a framework build of Python 2.3.x on Mac OS X 10.2.8; I've 
upgraded to OS 10.4.4 since and can't reproduce the problem on that - I get the 
standard recursion error as expected. I've no further insights into why I had 
problems originally and no-one else seems to have reproduced it, so probably 
best just to close it. Sorry not to be of more help.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:54

Message:
Logged In: YES 
user_id=849994

OP: Any further insights?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 21:56

Message:
Logged In: YES 
user_id=1188172

To the OP: Is there still a crash with newest Python 2.4?

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 19:17

Message:
Logged In: YES 
user_id=89016

Assigning to self.x in __init__() calls __setattr__(), which 
checks self.x, which calls __getattr__() which checks self.x, 
which leads to endless recursion. This usually leads to 
a "RuntimeError: maximum recursion depth exceeded". In what 
way does Python 2.3 crash?

To avoid the recursion access the instance dictionary directly:
class Foo:
   def __init__(self):
      self.x = 1

   def __getattr__(self, name):
      if "x" in self.__dict__ and self.__dict__["x"]:
         pass # etc...

   def __setattr__(self, name, val):
      if self.x:
         pass # etc...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 10:04:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 01:04:30 -0800
Subject: [ python-Bugs-1435487 ] Crash when decoding UTF8
Message-ID: <E1FBTRe-0005d9-S9@sc8-sf-web1.sourceforge.net>

Bugs item #1435487, was opened at 2006-02-20 14:15
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1435487&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: Viktor Ferenczi (complex)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Crash when decoding UTF8

Initial Comment:
Python segfaults when running the attached script on  
Python 2.4.2 Windows versions (tested with Win98SE 
HUN and WinXP HUN SP1). 
 
Linux version (Debian unstable) works fine, but 
cannot encode text to latin-2, since it decodes utf-8 
BOM that cannot be encoded. 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-21 01:04

Message:
Logged In: YES 
user_id=33168

2.5 raises a SyntaxError: encoding problem: utf-8.  2.4
still crashes, this is probably a duplicate of a previous
bug.  Should research and backport the fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1435487&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 10:20:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 01:20:19 -0800
Subject: [ python-Bugs-1378022 ] source utf8
Message-ID: <E1FBTgx-0003B7-7w@sc8-sf-web6.sourceforge.net>

Bugs item #1378022, was opened at 2005-12-10 22:48
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470

Please note that this 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: Fixed
Priority: 5
Submitted By: zhao (ibear)
Assigned to: Neal Norwitz (nnorwitz)
Summary: source utf8

Initial Comment:
winxp sp2(chinese or japanese) and python 2.42

i have created a utf8 source file with BOM_UTF8

if i add a '#coding: utf8' at first line and run it,
the python interpreter will crash

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-21 01:20

Message:
Logged In: YES 
user_id=33168

Committed revision 42537. (2.4)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 22:03

Message:
Logged In: YES 
user_id=33168

Thank you for the bug report.

Committed revision 41753.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 21:29

Message:
Logged In: YES 
user_id=33168

Thank you for the bug report.

Committed revision 41753.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2005-12-12 06:35

Message:
Logged In: YES 
user_id=89016

The following patch (pythonrun.diff) should fix the
segfault. However UTF-8 files with a leading BOM currently
aren't supported. There's a pending patch
(http://bugs.python.org/1177307) that adds a utf-8-sig codec
for that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 10:20:36 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 01:20:36 -0800
Subject: [ python-Bugs-1435487 ] Crash when decoding UTF8
Message-ID: <E1FBThE-0003BD-GJ@sc8-sf-web6.sourceforge.net>

Bugs item #1435487, was opened at 2006-02-20 14:15
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1435487&group_id=5470

Please note that this 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: Duplicate
Priority: 7
Submitted By: Viktor Ferenczi (complex)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Crash when decoding UTF8

Initial Comment:
Python segfaults when running the attached script on  
Python 2.4.2 Windows versions (tested with Win98SE 
HUN and WinXP HUN SP1). 
 
Linux version (Debian unstable) works fine, but 
cannot encode text to latin-2, since it decodes utf-8 
BOM that cannot be encoded. 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-21 01:20

Message:
Logged In: YES 
user_id=33168

Backported fix for bug #1435487.
Committed revision 42537. (2.4)


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-21 01:04

Message:
Logged In: YES 
user_id=33168

2.5 raises a SyntaxError: encoding problem: utf-8.  2.4
still crashes, this is probably a duplicate of a previous
bug.  Should research and backport the fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1435487&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 10:45:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 01:45:42 -0800
Subject: [ python-Bugs-780730 ] source files using encoding ./. universal
	newlines
Message-ID: <E1FBU5W-0005jR-EI@sc8-sf-web1.sourceforge.net>

Bugs item #780730, was opened at 2003-07-31 11:16
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: M.-A. Lemburg (lemburg)
Summary: source files using encoding ./. universal newlines

Initial Comment:
Universal Newline Support doesn't work for source files
that contain encoding definition.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-02-21 10:45

Message:
Logged In: YES 
user_id=38388

Closing the bug. Thanks Walter.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-20 23:06

Message:
Logged In: YES 
user_id=89016

It looks to me that way.

Any comments from the OP?


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 22:48

Message:
Logged In: YES 
user_id=849994

So this is resolved now?

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2006-02-20 22:42

Message:
Logged In: YES 
user_id=89016

The changes to the codecs done in Python 2.4 added support
for universal newlines:

Python 2.4.1 (#2, Mar 31 2005, 00:05:10) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> open("foo.py", "wb").write("# -*- coding: iso-8859-1
-*-\rprint 17\rprint 23\r")
>>> import foo
17
23
>>> 


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 07:50

Message:
Logged In: YES 
user_id=33168

I don't see a clear resolution here.  Is there something we
can/should do to fix this problem in 2.5?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-05 12:48

Message:
Logged In: YES 
user_id=45365

You misunderstand what I tried to say (or I mis-said it:-): there is 
no such thing as mode &quot;rbU&quot;, check the code in fileobject.c.

There is &quot;r&quot; == &quot;rt&quot; for text mode, &quot;rb&quot; for binary mode, 
&quot;U&quot;==&quot;rU&quot; for universal newline textmode. With &quot;rU&quot; the 
underlying file is opened in binary mode, so I don't think we'll 
have the control-Z problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-05 09:31

Message:
Logged In: YES 
user_id=38388

Thanks John.

Not sure whether any of codecs would actually use 0x1A,
but using &quot;rbU&quot;  sounds like the safer approach then.

----------------------------------------------------------------------

Comment By: John J Smith (johnjsmith)
Date: 2003-08-04 21:34

Message:
Logged In: YES 
user_id=830565

In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated
as EOF, unless the file is opened with 'rb'.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 17:57

Message:
Logged In: YES 
user_id=38388

Jack, I was just looking at the code I posted and the one
in fileobect.c. The latter enables universal newline support
whenever it sees a 'U' in the mode string, so I throught that
adding a 'U' to the mode would be enough.

The only system where 'b' does make a difference that I'm
aware of is Windows, so you may want to check whether it
makes a difference there.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-04 10:24

Message:
Logged In: YES 
user_id=45365

There's no such things as &quot;rbU&quot;, I think, but simply &quot;rU&quot; should 
work. As far as I know the only difference between &quot;r&quot; and &quot;rb&quot; is 
newline conversion, right? If there are C libraries that do more 
then we should implement &quot;rbU&quot;.

About 2.3.1 compatibility: technically we could break workarounds 
people have done themselves, but I think the chances are slim. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-04 10:21

Message:
Logged In: YES 
user_id=38388

Uhm, we don't impose Universal readline support on the codecs.
They would just get a stream object that happens to know
about universal newlines and work with it. That's completely
in line with the codec spec.

I'm +1 on adding this to 2.3.1.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 22:22

Message:
Logged In: YES 
user_id=21627

That would work indeed. The question is whether we can
impose support for universal newlines on all codecs &quot;out
there&quot;, for Python 2.3.1, when 2.3 makes no such requirement.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-03 21:31

Message:
Logged In: YES 
user_id=38388

I'm not sure this is correct: unless the codecs implement
their own .readline() implementation, the one in codecs.py
is used and that simply delegates the readline request to
the underlying stream object.

Now. since the stream object in the source code reader is
a plain Python file object, currently opened in &quot;rb&quot; mode,
changing the mode to &quot;rbU&quot; should be enough to get
universal readline support for all such codecs.

The relevant code is in Parser/tokenizer.c:fp_setreadl():

static int
fp_setreadl(struct tok_state *tok, const char* enc)
{
	PyObject *reader, *stream, *readline;

	/* XXX: constify filename argument. */
	stream = PyFile_FromFile(tok-&gt;fp, (char*)tok-&gt;filename,
&quot;rb&quot;, NULL);
	if (stream == NULL)
		return 0;

	reader = PyCodec_StreamReader(enc, stream, NULL);
	Py_DECREF(stream);
	if (reader == NULL)
		return 0;

	readline = PyObject_GetAttrString(reader, &quot;readline&quot;);
	Py_DECREF(reader);
	if (readline == NULL)
		return 0;

	tok-&gt;decoding_readline = readline;
	return 1;
}


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-03 21:19

Message:
Logged In: YES 
user_id=21627

The only way to implement that would be to add 'U' support
for all codecs, and open the codec with the 'U' flag. As
this will also affect codecs not part of Python, we cannot
fix this bug in Python 2.3, but have to defer a solution to
Python 2.4.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-01 11:45

Message:
Logged In: YES 
user_id=45365

The submitter isn't calling open explicitly, but PEP278 is also about 
the implicit opening of sourcefiles by the interpreter.

My guess (but I don't know the PEP263 implementation at all) is 
that when you specify an encoding the normal code that the 
interpreter uses to read sourcefiles is bypassed, and replaced by 
something that does the encoding magic. Apparently this code 
does not do universal newline conversion, which it should.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 10:22

Message:
Logged In: YES 
user_id=21627

I see. This is not about PEP 278, though, as you are not
calling any open() function, and passing no 'U' argument to
it - cross-platform newlines should work independent of that
PEP.

----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2003-08-01 09:35

Message:
Logged In: YES 
user_id=463672

Attached file has encoding definition and it's newline is '\r'.
Executing this script on Windows 2000, I got following error.
But it runs fine if I remove encoding definition. 

C:\Python23&gt;python .\test.py
  File &quot;.\test.py&quot;, line 2
a() print 'hi'
            ^
SyntaxError: invalid syntax


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2003-08-01 09:04

Message:
Logged In: YES 
user_id=21627

It's not clear to me what the problem is: Source code files
and universal newline support have nothing to do with each
other.

Can you attach a small example that demonstrates the problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 11:39:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 02:39:55 -0800
Subject: [ python-Bugs-595105 ] AESend on Jaguar
Message-ID: <E1FBUvz-0000Wl-FJ@sc8-sf-web5.sourceforge.net>

Bugs item #595105, was opened at 2002-08-14 18:02
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Alexandre Parenteau (aubonbeurre)
Assigned to: Jack Jansen (jackjansen)
Summary: AESend on Jaguar

Initial Comment:
I wonder how many of you guys played with Jaguar 
(OSX 10.2). It is also my
first glance at gcc 3.1 that comes with 10.2. Everything 
was fine for
building Python, except for waste which has an 
obsolete libWaste.a (even in
August 1st Waste 2.1b1) which won't compile with 
gcc3.1. After I recompiled
waste with CodeWarrior 8.2 (MPTP: early access), it 
came OK.

I then run into some problems of checked out files 
because I'm using MacCvs
(see earlier message). I used the 'make 
frameworkinstall' scheme.

Now I'm experiencing the nice new architecture. I 
mostly use python from the
command line to invoke CodeWarrior thru AppleScripts, 
so I almost immeditly
run into a hanging problems of python :

        _err = AESend(&amp;_self-&gt;ob_itself,
                      &amp;reply,
                      sendMode,
                      sendPriority,
                      timeOutInTicks,
                      0L/*upp_AEIdleProc*/,
                      (AEFilterUPP)0);

I had to comment out upp_AEIdleProc (I tried several 
things, but that is the
only thing which helped). Jack, you might want to 
remember this one if the
problem is still in Jaguar. It hangs and finally times out. 
I've looked
inside this function and I can see the signal handling, 
but I'm not sure
what it is for.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2006-02-21 11:39

Message:
Logged In: YES 
user_id=45365

I don't fully remember the bug (it's been a while:-) but the Apple bug report has 
been closed, so let's assume this has been fixed for Python too.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-06-05 23:58

Message:
Logged In: YES 
user_id=11375

Jack, any movement on this bug?  Should it simply be closed?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-11-27 22:23

Message:
Logged In: YES 
user_id=45365

Apple are aware of the bug and looking at it. Their bug ID is 3097709.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 13:47

Message:
Logged In: YES 
user_id=45365

The problem turns out to be that under Jaguar you must *not* pass an 
idle routine if you haven't done all the correct toolbox initializations yet.

To verify this, do something like &quot;import EasyDialogs; 
EasyDialogs.Message(&quot;There we go&quot;)&quot; at the start of your script. 
Everything now works fine.

Somehow, if you haven't initialized, the idle routine will be called with 
random garbage, and it will be called continuously.

The question is: what's the best way to fix this? I noticed that even a 
simple Carbon.Evt.WaitNextEvent(0,0) in your test script is enough to 
make it work. Should we call this in the init_AE() routine? in AESend()?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-19 16:45

Message:
Logged In: YES 
user_id=45365

Alexandre,
I tried a few simple things with the AE module (talking to CodeWarrior) 
on Jaguar, but I can't get it to hang.

Could you give me an example script that shows the problem?

Also: I've been using MachoPython from the CVS HEAD, I assume 
you're using the same, right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 17:03:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 08:03:18 -0800
Subject: [ python-Bugs-942706 ] Python crash on
	__init__/__getattr__/__setattr__ interaction
Message-ID: <E1FBZyw-0006sS-Tn@sc8-sf-web1.sourceforge.net>

Bugs item #942706, was opened at 2004-04-26 23:39
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470

Please note that this message 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: Works For Me
Priority: 5
Submitted By: has (hhas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python crash on __init__/__getattr__/__setattr__ interaction

Initial Comment:
The following code causes [Mac]Python 2.3 process to crash 
(Bad!) rather than raise an error (good) when creating a new 
instance of Foo:

class Foo:
	def __init__(self):
		self.x = 1
	
	def __getattr__(self, name):
		if self.x:
			pass # etc...
	
	def __setattr__(self, name, val):
		if self.x:
			pass # etc...


(See <http://freespace.virgin.net/hamish.sanderson/
HTMLTemplate-0.4.0.tar.gz> for a working example plus general 
solution to the referencing-instance-var-before-it's-created 
paradox that threw up this bug in the first place.)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-21 16:03

Message:
Logged In: YES 
user_id=849994

Closing then.

----------------------------------------------------------------------

Comment By: has (hhas)
Date: 2006-02-20 23:48

Message:
Logged In: YES 
user_id=996627

Original test used a framework build of Python 2.3.x on Mac OS X 10.2.8; I've 
upgraded to OS 10.4.4 since and can't reproduce the problem on that - I get the 
standard recursion error as expected. I've no further insights into why I had 
problems originally and no-one else seems to have reproduced it, so probably 
best just to close it. Sorry not to be of more help.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:54

Message:
Logged In: YES 
user_id=849994

OP: Any further insights?

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 21:56

Message:
Logged In: YES 
user_id=1188172

To the OP: Is there still a crash with newest Python 2.4?

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 19:17

Message:
Logged In: YES 
user_id=89016

Assigning to self.x in __init__() calls __setattr__(), which 
checks self.x, which calls __getattr__() which checks self.x, 
which leads to endless recursion. This usually leads to 
a "RuntimeError: maximum recursion depth exceeded". In what 
way does Python 2.3 crash?

To avoid the recursion access the instance dictionary directly:
class Foo:
   def __init__(self):
      self.x = 1

   def __getattr__(self, name):
      if "x" in self.__dict__ and self.__dict__["x"]:
         pass # etc...

   def __setattr__(self, name, val):
      if self.x:
         pass # etc...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 22:56:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 13:56:39 -0800
Subject: [ python-Bugs-1436206 ] CGIHTTPServer doesn't handle path names with
	embeded space
Message-ID: <E1FBfUt-0005gV-Ib@sc8-sf-web6.sourceforge.net>

Bugs item #1436206, was opened at 2006-02-21 21:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436206&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Coupland (rick-eci)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer doesn't handle path names with embeded space

Initial Comment:
On Windows, if the path name of a CGI script to be run
contains one or more space characters, the path name is
split into multiple parameters causing an error.  I
have not tried not tried this on other platforms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436206&group_id=5470

From noreply at sourceforge.net  Tue Feb 21 23:43:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 14:43:30 -0800
Subject: [ python-Feature Requests-1436243 ] Extend pre-allocated integers to
	cover [0, 255]
Message-ID: <E1FBgEE-0004Ck-Tl@sc8-sf-web3.sourceforge.net>

Feature Requests item #1436243, was opened at 2006-02-21 22:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: Extend pre-allocated integers to cover [0, 255]

Initial Comment:
When the `bytes` object is introduced (successor to 
PEP 332) the full range of byte integer objects [0, 
255] are likely to be used more commonly.

Suggest extending the pre-allocated integer obejcts to 
include the full range [0, 255].

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436243&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 03:58:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 18:58:43 -0800
Subject: [ python-Feature Requests-1436346 ] yday in datetime module
Message-ID: <E1FBkDD-0004OV-Ut@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1436346, was opened at 2006-02-21 18:58
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=1436346&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Toews (mwtoews)
Assigned to: Nobody/Anonymous (nobody)
Summary: yday in datetime module

Initial Comment:
My first request is relatively simple: add a 'yday'
method to datetime.date and datetime.datetime.
Thus I could do:

>>> from datetime import *

>>> t = date.today()
>>> t.yday()
52

# rather than the less readable:
>>> t.timetuple()[7]
52

# or worse:
>>> int(t.strftime('%j'))
52


The second request is to have more alternate
constructors for date or datetime objects. There are
currently:
  * date(year,month,day)
  * date.fromtimestamp(timestamp)
  * date.fromordinal(ordinal)
  * date.today()

I would like to have:
  * date.fromtimetuple(9-item time tuple structure)
  * date.strptime(data_string,format)


As well, it would be nice to change:
  * date(year,month=None,day=None,yday=None)

e.g.,:
>>> date(2006,2,21) == date(2006,yday=52)
True

Here, a date can be formed from a year, month and day
or from just the year and the day of the year,
otherwise I have to convert using:
>>> import time
>>> year = 2006
>>> yday = 52
>>> t = time.strptime(`year`+'-'+`yday`,'%Y-%j')
>>> datetime.date(t.tm_year,t.tm_mon,t.tm_mday)
datetime.date(2006, 2, 21)

If a safer approach is desired (as to not change the
class constructor too much), then please offer an
alternate, say:
  * date.fromyday(year,yday)

or something like that.

Thanks.
+mt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436346&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 06:44:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 21:44:56 -0800
Subject: [ python-Feature Requests-1432694 ] Implement preemptive threads in
	Python
Message-ID: <E1FBmo4-0003is-1W@sc8-sf-web5.sourceforge.net>

Feature Requests item #1432694, was opened at 2006-02-16 00:11
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python

Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.

The idea behind Python is that programming should not
be a pain, right?

This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.

I apologize if this issue has already been raised before.

Cheers,
darkprokoba

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-02-21 21:44

Message:
Logged In: YES 
user_id=341410

If GUI applications are written properly, they don't need to
hang when they are doing "real work".  The applications you
are using which seem to hang are doing so not because Python
"doesn't have preemptive threads", they are doing so because
the writers of those GUI applications have no idea how to
either 1. write their programs asynchronously via generators
or callbacks or 2. use threads to do the actual work which
post GUI update events.  Talk to the writers of those
applications to get them fixed.

Note that regardless of Python's lack of preemptive
multithreading, thread context switches happen at a regular
rate, discoverable via sys.getcheckinterval(), and setable
via sys.setcheckinterval().

----------------------------------------------------------------------

Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-17 01:52

Message:
Logged In: YES 
user_id=950037

OK, let me try again :-)
The problem is in the global interpreter lock:
http://docs.python.org/api/threads.html
this basically says that you can have as many native threads
as you like but only one of them could have the global
interpreter lock and could therefore be executing python
code at a time. The only use of python's multiple threads
then is so they could release the global lock and block on
i/o operations while one lucky thread has the lock and
executes python code and accesses python objects happily.
So we have multiple native threads (e.g. pthreads) but they
pass arround the global lock in a cooperative manner. This
is not preemptive threading imho.
It's a severely limited model and has the following
potential problem: a thread may enter a time-consuming i/o
operation but forget to release the global interpreter lock
- leading to a freeze in the entire interpreter (all threads
are waiting for the global lock, while the thread that has
it waits on the i/o operation)
Are there any plans for alleviating this problem? A thread
should not voluntarily release the lock so that the rest of
the threads get a chance to execute python code. It should
be possible to preempt any thread at any time without its
consent in order to have a true preemptive threading model.
Or please correct me If I'm wrong.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-16 06:14

Message:
Logged In: YES 
user_id=6656

We _have_ preemptive threads in Python ("import threading").  Suggest you 
report a real problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 07:03:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 22:03:16 -0800
Subject: [ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Message-ID: <E1FBn5o-0004vM-M5@sc8-sf-web3.sourceforge.net>

Bugs item #1436428, was opened at 2006-02-21 22: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=1436428&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Donovan Eastman (dpeastman)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib has trouble with Windows filenames

Initial Comment:
When you pass urllib the name of a local file including
a Windows drive letter (e.g. 'C:\dir\My File.txt')
URLopener.open() incorrectly interprets the drive
letter as the scheme of a URL.  Of course, given that
there is no scheme 'C', this fails.

I have solved this in my own code by putting the
following test before calling urllib.urlopen():

if url[1] == ':' and url[0].isalpha():
    url = 'file:' + url

Although this works fine in my particular case, it
seems like urllib should just simply "do the right
thing" without having to worry about it.  Therefore I
propose that urllib should automatically assume that
any URL that begins with a single alpha followed by a
colon is a local file.

The only potential downside would be that it would
preclude the use of single letter scheme names.  I did
a little research on this.  RFC 3986 suggests, but does
not explicitly state that scheme names must be more
than one character.
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme)
.  That said, there are no currently recognized single
letter scheme names
(http://www.iana.org/assignments/uri-schemes.html) and
it seems very unlikely that there every would be.

I would gladly write the code for this myself -- but I
suspect that it would take someone longer to review and
integrate my changes than it would to just write the code.

Thanks,
Donovan


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 07:38:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 22:38:49 -0800
Subject: [ python-Feature Requests-1436243 ] Extend pre-allocated integers to
	cover [0, 255]
Message-ID: <E1FBneD-0006km-Cw@sc8-sf-web6.sourceforge.net>

Feature Requests item #1436243, was opened at 2006-02-21 17:43
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436243&group_id=5470

Please note that this 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: Accepted
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Georg Brandl (birkenfeld)
Summary: Extend pre-allocated integers to cover [0, 255]

Initial Comment:
When the `bytes` object is introduced (successor to 
PEP 332) the full range of byte integer objects [0, 
255] are likely to be used more commonly.

Suggest extending the pre-allocated integer obejcts to 
include the full range [0, 255].

----------------------------------------------------------------------

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-02-22 01:38

Message:
Logged In: YES 
user_id=593130

I decided to test out the new svn view facility ;-)

Looks like 100 in
#define NSMALLPOSINTS		100
in python/trunk/Objects/intobject.c
just needs to be upped to 257

Unlike for other builtin types, I could not find a 
Lib/test/test_int.py file or equivalent where ints are 
tested, to see if pre-allocation is tested.  What did I 
miss?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-02-21 17:47

Message:
Logged In: YES 
user_id=80475

Georg, would you take care of this one for Py2.5.
Also include the value 256.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436243&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 08:55:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 21 Feb 2006 23:55:39 -0800
Subject: [ python-Feature Requests-1432694 ] Implement preemptive threads in
	Python
Message-ID: <E1FBoqZ-0005Dl-U6@sc8-sf-web2.sourceforge.net>

Feature Requests item #1432694, was opened at 2006-02-16 10:11
Message generated for change (Comment added) made by darkprokoba
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python

Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.

The idea behind Python is that programming should not
be a pain, right?

This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.

I apologize if this issue has already been raised before.

Cheers,
darkprokoba

----------------------------------------------------------------------

>Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-22 09:55

Message:
Logged In: YES 
user_id=950037

> thread context switches happen at a regular
> rate
thanks for your response, but with enough worker threads
it's still easy to starve the GUI thread.
and the other problems of this model remain:
1) a stupid native module could forget to release the global
interpreter lock and block on I/O, freezing the entire
interpreter (i.e. GIL is a pain for native module writers)
2) poor CPU utilization on SMP machines (which are quite
mainstream now)

Python's model just doesn't cut it for me (I'm well aware
now of how it works) so my question boils down to:

Do the python authors plan to make the interpreter reentrant
and if so when can we expect to see this in a production
release?

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-02-22 07:44

Message:
Logged In: YES 
user_id=341410

If GUI applications are written properly, they don't need to
hang when they are doing "real work".  The applications you
are using which seem to hang are doing so not because Python
"doesn't have preemptive threads", they are doing so because
the writers of those GUI applications have no idea how to
either 1. write their programs asynchronously via generators
or callbacks or 2. use threads to do the actual work which
post GUI update events.  Talk to the writers of those
applications to get them fixed.

Note that regardless of Python's lack of preemptive
multithreading, thread context switches happen at a regular
rate, discoverable via sys.getcheckinterval(), and setable
via sys.setcheckinterval().

----------------------------------------------------------------------

Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-17 11:52

Message:
Logged In: YES 
user_id=950037

OK, let me try again :-)
The problem is in the global interpreter lock:
http://docs.python.org/api/threads.html
this basically says that you can have as many native threads
as you like but only one of them could have the global
interpreter lock and could therefore be executing python
code at a time. The only use of python's multiple threads
then is so they could release the global lock and block on
i/o operations while one lucky thread has the lock and
executes python code and accesses python objects happily.
So we have multiple native threads (e.g. pthreads) but they
pass arround the global lock in a cooperative manner. This
is not preemptive threading imho.
It's a severely limited model and has the following
potential problem: a thread may enter a time-consuming i/o
operation but forget to release the global interpreter lock
- leading to a freeze in the entire interpreter (all threads
are waiting for the global lock, while the thread that has
it waits on the i/o operation)
Are there any plans for alleviating this problem? A thread
should not voluntarily release the lock so that the rest of
the threads get a chance to execute python code. It should
be possible to preempt any thread at any time without its
consent in order to have a true preemptive threading model.
Or please correct me If I'm wrong.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-16 16:14

Message:
Logged In: YES 
user_id=6656

We _have_ preemptive threads in Python ("import threading").  Suggest you 
report a real problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 09:35:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 00:35:46 -0800
Subject: [ python-Feature Requests-1432694 ] Implement preemptive threads in
	Python
Message-ID: <E1FBpTO-0005K7-RO@sc8-sf-web3.sourceforge.net>

Feature Requests item #1432694, was opened at 2006-02-16 00:11
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python

Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.

The idea behind Python is that programming should not
be a pain, right?

This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.

I apologize if this issue has already been raised before.

Cheers,
darkprokoba

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-02-22 00:35

Message:
Logged In: YES 
user_id=341410

How many worker threads do you expect?  If you work the
sys.setcheckinterval() just right, you may be able to
prioritize your threads...

Any C library which does not acquire and release the GIL
when it is supposed to is broken.  Claiming that Python is
broken in relation to C libraries being broken is misplaced
blame.

Python uses a GIL because it makes interaction with Python
objects easier across threads.  There have been previous
failed efforts to make Python scalable across multiple
processors; search for "python free threading" on google to
see all of the relevant information about rewriting the
Python interpreter with multiple processors in mind.

Alternatively, you can always use one of the half-dozen
parallel processing libraries for Python to distribute your
work onto different processors, who all synchronize up with
the main GUI process.  Some are quite intuitive (check out
Kamaelia), and will work today (any effort to get a 'free
threading' idea into Python core will have to wait until at
least Python 2.6, which is at least 2 years away).

----------------------------------------------------------------------

Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-21 23:55

Message:
Logged In: YES 
user_id=950037

> thread context switches happen at a regular
> rate
thanks for your response, but with enough worker threads
it's still easy to starve the GUI thread.
and the other problems of this model remain:
1) a stupid native module could forget to release the global
interpreter lock and block on I/O, freezing the entire
interpreter (i.e. GIL is a pain for native module writers)
2) poor CPU utilization on SMP machines (which are quite
mainstream now)

Python's model just doesn't cut it for me (I'm well aware
now of how it works) so my question boils down to:

Do the python authors plan to make the interpreter reentrant
and if so when can we expect to see this in a production
release?

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-02-21 21:44

Message:
Logged In: YES 
user_id=341410

If GUI applications are written properly, they don't need to
hang when they are doing "real work".  The applications you
are using which seem to hang are doing so not because Python
"doesn't have preemptive threads", they are doing so because
the writers of those GUI applications have no idea how to
either 1. write their programs asynchronously via generators
or callbacks or 2. use threads to do the actual work which
post GUI update events.  Talk to the writers of those
applications to get them fixed.

Note that regardless of Python's lack of preemptive
multithreading, thread context switches happen at a regular
rate, discoverable via sys.getcheckinterval(), and setable
via sys.setcheckinterval().

----------------------------------------------------------------------

Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-17 01:52

Message:
Logged In: YES 
user_id=950037

OK, let me try again :-)
The problem is in the global interpreter lock:
http://docs.python.org/api/threads.html
this basically says that you can have as many native threads
as you like but only one of them could have the global
interpreter lock and could therefore be executing python
code at a time. The only use of python's multiple threads
then is so they could release the global lock and block on
i/o operations while one lucky thread has the lock and
executes python code and accesses python objects happily.
So we have multiple native threads (e.g. pthreads) but they
pass arround the global lock in a cooperative manner. This
is not preemptive threading imho.
It's a severely limited model and has the following
potential problem: a thread may enter a time-consuming i/o
operation but forget to release the global interpreter lock
- leading to a freeze in the entire interpreter (all threads
are waiting for the global lock, while the thread that has
it waits on the i/o operation)
Are there any plans for alleviating this problem? A thread
should not voluntarily release the lock so that the rest of
the threads get a chance to execute python code. It should
be possible to preempt any thread at any time without its
consent in order to have a true preemptive threading model.
Or please correct me If I'm wrong.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-02-16 06:14

Message:
Logged In: YES 
user_id=6656

We _have_ preemptive threads in Python ("import threading").  Suggest you 
report a real problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 10:45:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 01:45:17 -0800
Subject: [ python-Bugs-1436532 ] length of unicode string changes print
	behaviour
Message-ID: <E1FBqYf-0005V5-2n@sc8-sf-web2.sourceforge.net>

Bugs item #1436532, was opened at 2006-02-22 10: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=1436532&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: James (hover_boy)
Assigned to: Nobody/Anonymous (nobody)
Summary: length of unicode string changes print behaviour

Initial Comment:
Python 2.4.2 and IDLE (with Courier New font) on XP 
and the following code saved as a UTF-8 file 

if __name__ == "__main__": 
    print "??? ??? ??? ??? ??? ??? ?
? ??? ?
?" 
    print "??? ??? ??? ??? ??? ??? ?
? ??? ?
? ??? ??? "

results in...

IDLE 1.1.2 
>>> ================================ RESTART 
================================ 
>>> 
??????? ??????? ?????? ??????? ???????? ??????? ??????????? ??????? 
??? ??? ??? ??? ??? ??? ?
? ??? ?
? ??? ??? 
>>> 





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 12:30:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 03:30:41 -0800
Subject: [ python-Feature Requests-1436243 ] Extend pre-allocated integers to
	cover [0, 255]
Message-ID: <E1FBsCf-0007RY-Ln@sc8-sf-web6.sourceforge.net>

Feature Requests item #1436243, was opened at 2006-02-21 22:43
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
>Assigned to: Georg Brandl (gbrandl)
Summary: Extend pre-allocated integers to cover [0, 255]

Initial Comment:
When the `bytes` object is introduced (successor to 
PEP 332) the full range of byte integer objects [0, 
255] are likely to be used more commonly.

Suggest extending the pre-allocated integer obejcts to 
include the full range [0, 255].

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 11:30

Message:
Logged In: YES 
user_id=849994

It's test_types, and I added a test too.

Revision 42552.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-02-22 06:38

Message:
Logged In: YES 
user_id=593130

I decided to test out the new svn view facility ;-)

Looks like 100 in
#define NSMALLPOSINTS		100
in python/trunk/Objects/intobject.c
just needs to be upped to 257

Unlike for other builtin types, I could not find a 
Lib/test/test_int.py file or equivalent where ints are 
tested, to see if pre-allocation is tested.  What did I 
miss?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-02-21 22:47

Message:
Logged In: YES 
user_id=80475

Georg, would you take care of this one for Py2.5.
Also include the value 256.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436243&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 12:32:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 03:32:07 -0800
Subject: [ python-Bugs-1178141 ] urllib.py overwrite HTTPError code with 200
Message-ID: <E1FBsE3-0007SD-8n@sc8-sf-web6.sourceforge.net>

Bugs item #1178141, was opened at 2005-04-06 22:48
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178141&group_id=5470

Please note that this message 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
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.py overwrite HTTPError code with 200

Initial Comment:
I found this bug while trying to understand why a 404
Not Found error was reported as a 200 Not Found.

Turns out the HTTPError's self.code is overwritten with
200 after
the 404 was correctly assigned.

The attached patch fixes the problem.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 11:32

Message:
Logged In: YES 
user_id=849994

Okay, reopening.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-20 21:53

Message:
Logged In: YES 
user_id=764593

Barry -- Are you sure that the original status code wasn't 
204?  If so, then this patch makes more sense.

Georg -- any unrecognized response status NXX should be 
treated as N00.  Since 204 (and 298, for that matter) aren't 
recognized by the urllib opener, they should be treated as 
200, which the patch does.  

Whether the patch makes it harder to treat 204 separately 
when it is recognized is another issue.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:30

Message:
Logged In: YES 
user_id=849994

I cannot see the point of the patch and cannot reproduce the
error.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-04-08 16:18

Message:
Logged In: YES 
user_id=764593

Please reattach (SF didn't catch the file)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178141&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 19:04:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 10:04:11 -0800
Subject: [ python-Feature Requests-1436243 ] Extend pre-allocated integers to
	cover [0, 255]
Message-ID: <E1FByLT-0000L7-1V@sc8-sf-web6.sourceforge.net>

Feature Requests item #1436243, was opened at 2006-02-21 17:43
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Georg Brandl (gbrandl)
Summary: Extend pre-allocated integers to cover [0, 255]

Initial Comment:
When the `bytes` object is introduced (successor to 
PEP 332) the full range of byte integer objects [0, 
255] are likely to be used more commonly.

Suggest extending the pre-allocated integer obejcts to 
include the full range [0, 255].

----------------------------------------------------------------------

>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-02-22 13:04

Message:
Logged In: YES 
user_id=593130

Thanks for the info.  Small nit: your checkin message says
"RFE #1436243: make integers in [0..256] preallocated. "
The range is actually (now)[-5...256].
#define NSMALLNEGINTS		5
sets the lower limit (unchanged).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 06:30

Message:
Logged In: YES 
user_id=849994

It's test_types, and I added a test too.

Revision 42552.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-02-22 01:38

Message:
Logged In: YES 
user_id=593130

I decided to test out the new svn view facility ;-)

Looks like 100 in
#define NSMALLPOSINTS		100
in python/trunk/Objects/intobject.c
just needs to be upped to 257

Unlike for other builtin types, I could not find a 
Lib/test/test_int.py file or equivalent where ints are 
tested, to see if pre-allocation is tested.  What did I 
miss?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-02-21 17:47

Message:
Logged In: YES 
user_id=80475

Georg, would you take care of this one for Py2.5.
Also include the value 256.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436243&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 19:38:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 10:38:28 -0800
Subject: [ python-Bugs-1436900 ] Problem parsing cmdline parameter quoted with
	a trailing \
Message-ID: <E1FByse-0007MY-6d@sc8-sf-web2.sourceforge.net>

Bugs item #1436900, was opened at 2006-02-22 10: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=1436900&group_id=5470

Please note that this 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
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing cmdline parameter quoted with a trailing \

Initial Comment:
This problem happens in launching Python from Windows. 
A quoted pathname is used as parameter. If and only if 
the pathname is ended with a trailing \, it is treated 
as an escape character.

p.py
-------------------------------------------------------
import sys
from pprint import pprint
pprint(sys.argv)
-------------------------------------------------------

Note slash inside the quote is treated as path 
separators

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip', 'wai']


However the trailing \ is treated as an escape 
character for the quote. Only command line parameter 
is presented in sys.argv.

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip\" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip" wai']



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 21:12:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 12:12:38 -0800
Subject: [ python-Bugs-1436900 ] Problem parsing cmdline parameter quoted with
	a trailing \
Message-ID: <E1FC0Lm-0006nc-9f@sc8-sf-web5.sourceforge.net>

Bugs item #1436900, was opened at 2006-02-22 18:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

Please note that this 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
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing cmdline parameter quoted with a trailing \

Initial Comment:
This problem happens in launching Python from Windows. 
A quoted pathname is used as parameter. If and only if 
the pathname is ended with a trailing \, it is treated 
as an escape character.

p.py
-------------------------------------------------------
import sys
from pprint import pprint
pprint(sys.argv)
-------------------------------------------------------

Note slash inside the quote is treated as path 
separators

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip', 'wai']


However the trailing \ is treated as an escape 
character for the quote. Only command line parameter 
is presented in sys.argv.

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip\" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip" wai']



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 20:12

Message:
Logged In: YES 
user_id=849994

Is that Python-specific? I thought sys.argv is the cmdline
args as Python gets them from Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 21:17:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 12:17:07 -0800
Subject: [ python-Bugs-1178141 ] urllib.py overwrite HTTPError code with 200
Message-ID: <E1FC0Q7-0003pQ-OF@sc8-sf-web1.sourceforge.net>

Bugs item #1178141, was opened at 2005-04-06 23:48
Message generated for change (Comment added) made by barry-scott
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178141&group_id=5470

Please note that this message 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
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.py overwrite HTTPError code with 200

Initial Comment:
I found this bug while trying to understand why a 404
Not Found error was reported as a 200 Not Found.

Turns out the HTTPError's self.code is overwritten with
200 after
the 404 was correctly assigned.

The attached patch fixes the problem.


----------------------------------------------------------------------

>Comment By: Barry Alan Scott (barry-scott)
Date: 2006-02-22 20:17

Message:
Logged In: YES 
user_id=28665

There are two problems.
1) 200-299 are all good, not just 200
2) Setting the code in addinfourl needs to use the
   2xx code that came from the server

I have a complex http app that broken without this fix.
I'm doing partial transfers that return 206 that was being
overwritten.

This is clearly a bug. The only issue is does the patch fix
the bug and not cause other problems? In nearly a year of
running with this patch on 700 systems I've not seen a
problem.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 11:32

Message:
Logged In: YES 
user_id=849994

Okay, reopening.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-02-20 21:53

Message:
Logged In: YES 
user_id=764593

Barry -- Are you sure that the original status code wasn't 
204?  If so, then this patch makes more sense.

Georg -- any unrecognized response status NXX should be 
treated as N00.  Since 204 (and 298, for that matter) aren't 
recognized by the urllib opener, they should be treated as 
200, which the patch does.  

Whether the patch makes it harder to treat 204 separately 
when it is recognized is another issue.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 21:30

Message:
Logged In: YES 
user_id=849994

I cannot see the point of the patch and cannot reproduce the
error.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2005-04-08 17:18

Message:
Logged In: YES 
user_id=764593

Please reattach (SF didn't catch the file)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178141&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 21:34:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 12:34:59 -0800
Subject: [ python-Bugs-1436900 ] Problem parsing cmdline parameter quoted with
	a trailing \
Message-ID: <E1FC0hP-0007UL-1N@sc8-sf-web4-b.sourceforge.net>

Bugs item #1436900, was opened at 2006-02-22 18:38
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

Please note that this 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
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing cmdline parameter quoted with a trailing \

Initial Comment:
This problem happens in launching Python from Windows. 
A quoted pathname is used as parameter. If and only if 
the pathname is ended with a trailing \, it is treated 
as an escape character.

p.py
-------------------------------------------------------
import sys
from pprint import pprint
pprint(sys.argv)
-------------------------------------------------------

Note slash inside the quote is treated as path 
separators

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip', 'wai']


However the trailing \ is treated as an escape 
character for the quote. Only command line parameter 
is presented in sys.argv.

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip\" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip" wai']



----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-22 20:34

Message:
Logged In: YES 
user_id=1126061

After having a quick look it appears as though python is in
fact stripping the trailing '\'. the argv array that the
python interpreter is passed contains the backslash so it
must be doing away with it.



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 20:12

Message:
Logged In: YES 
user_id=849994

Is that Python-specific? I thought sys.argv is the cmdline
args as Python gets them from Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 21:38:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 12:38:05 -0800
Subject: [ python-Bugs-1436900 ] Problem parsing cmdline parameter quoted with
	a trailing \
Message-ID: <E1FC0kP-0007V5-4B@sc8-sf-web4-b.sourceforge.net>

Bugs item #1436900, was opened at 2006-02-22 18:38
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

Please note that this 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
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing cmdline parameter quoted with a trailing \

Initial Comment:
This problem happens in launching Python from Windows. 
A quoted pathname is used as parameter. If and only if 
the pathname is ended with a trailing \, it is treated 
as an escape character.

p.py
-------------------------------------------------------
import sys
from pprint import pprint
pprint(sys.argv)
-------------------------------------------------------

Note slash inside the quote is treated as path 
separators

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip', 'wai']


However the trailing \ is treated as an escape 
character for the quote. Only command line parameter 
is presented in sys.argv.

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip\" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip" wai']



----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-22 20:38

Message:
Logged In: YES 
user_id=1126061

Whoops, my bad. Its a windows issue, not a python one.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-22 20:34

Message:
Logged In: YES 
user_id=1126061

After having a quick look it appears as though python is in
fact stripping the trailing '\'. the argv array that the
python interpreter is passed contains the backslash so it
must be doing away with it.



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 20:12

Message:
Logged In: YES 
user_id=849994

Is that Python-specific? I thought sys.argv is the cmdline
args as Python gets them from Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 21:53:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 12:53:52 -0800
Subject: [ python-Bugs-1436900 ] Problem parsing cmdline parameter quoted with
	a trailing \
Message-ID: <E1FC0zg-0006w5-KW@sc8-sf-web5.sourceforge.net>

Bugs item #1436900, was opened at 2006-02-22 18:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

Please note that this 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
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing cmdline parameter quoted with a trailing \

Initial Comment:
This problem happens in launching Python from Windows. 
A quoted pathname is used as parameter. If and only if 
the pathname is ended with a trailing \, it is treated 
as an escape character.

p.py
-------------------------------------------------------
import sys
from pprint import pprint
pprint(sys.argv)
-------------------------------------------------------

Note slash inside the quote is treated as path 
separators

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip', 'wai']


However the trailing \ is treated as an escape 
character for the quote. Only command line parameter 
is presented in sys.argv.

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip\" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip" wai']



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 20:53

Message:
Logged In: YES 
user_id=849994

OK, closing.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-22 20:38

Message:
Logged In: YES 
user_id=1126061

Whoops, my bad. Its a windows issue, not a python one.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-22 20:34

Message:
Logged In: YES 
user_id=1126061

After having a quick look it appears as though python is in
fact stripping the trailing '\'. the argv array that the
python interpreter is passed contains the backslash so it
must be doing away with it.



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 20:12

Message:
Logged In: YES 
user_id=849994

Is that Python-specific? I thought sys.argv is the cmdline
args as Python gets them from Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 22:20:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 13:20:02 -0800
Subject: [ python-Bugs-1436226 ] fix inplace assignment for immutable sequences
Message-ID: <E1FC1P0-0000uS-KA@sc8-sf-web6.sourceforge.net>

Bugs item #1436226, was opened at 2006-02-21 22:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436226&group_id=5470

Please note that this 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: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Martin v. L??wis (loewis)
Summary: fix inplace assignment for immutable sequences

Initial Comment:
Currently:

py> tup = ([], )
py> tup[0] += [1]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment
py> tup
([1],)

With this patch, no exception will be raised when the
item one wants to assign is already there in the tuple.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 21:20

Message:
Logged In: YES 
user_id=849994

You're right with the error handling *shame*. I had written
the patch a few months ago and just posted it without
looking at it again.

Well, I don't think I'm able to come up with a new patch
only for a couple of days.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-22 01:44

Message:
Logged In: YES 
user_id=6380

I see no error handling from the PySequence_GetItem() call;
if this causes an error it should take precedence over the
TypeError we're about to raise (IOW we shouldn't raise the
TypeError).

Also, shouldn't the same fix be made for attribute assignment?

Finally -- doing this in PySequence_SetItem is too broad. 
Code like this passes without error:

t = (1, 2)
t[0] = t[0]

That can't be right!  You need to find a code path that's
only taken for += and friends.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436226&group_id=5470

From noreply at sourceforge.net  Wed Feb 22 23:13:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 14:13:17 -0800
Subject: [ python-Bugs-1437051 ] "continue" in .pdbrc has no effect
Message-ID: <E1FC2EX-00089W-W6@sc8-sf-web3.sourceforge.net>

Bugs item #1437051, was opened at 2006-02-22 17:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437051&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Coolheads Consulting (coolheads)
Assigned to: Nobody/Anonymous (nobody)
Summary: "continue" in .pdbrc has no effect

Initial Comment:
I'm using Python 2.4.2 under Debian Woody; uname -a:
Linux bruno 2.4.23 i686 GNU/Linux

The documentation for pdb says that commands in .pdbrc
will be executed just as if they were typed in at the
pdb prompt.  However, "c", "cont", and "continue" have
no effect.  It would be nice if this would work.

I discovered this problem because I need to be able to
call Python scripts from within a Makefile, and it is
convenient, when one of them goes awry (say, because of
a key error exception), to already be in the debugger
when such exceptions are raised.  However, I can't call
a Python script with the debugger from a makefile because
execution always stops at the beginning of the script,
waiting for a "continue" to be typed in at the prompt.
 I thought I could solve the problem with a "continue"
in the .pdbrc in the local directory.  However, every way I
can think of to say "continue", including aliasing it,
has no effect in the .pdbrc.  Is there another way to
accomplish what I'm trying to do?

Steve Newcomb
srn at coolheads.com


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437051&group_id=5470

From noreply at sourceforge.net  Thu Feb 23 07:11:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 22 Feb 2006 22:11:01 -0800
Subject: [ python-Bugs-1436532 ] length of unicode string changes print
	behaviour
Message-ID: <E1FC9gr-0000bG-Bb@sc8-sf-web4-b.sourceforge.net>

Bugs item #1436532, was opened at 2006-02-22 01:45
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: James (hover_boy)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: length of unicode string changes print behaviour

Initial Comment:
Python 2.4.2 and IDLE (with Courier New font) on XP 
and the following code saved as a UTF-8 file 

if __name__ == "__main__": 
    print "??? ??? ??? ??? ??? ??? ?
? ??? ?
?" 
    print "??? ??? ??? ??? ??? ??? ?
? ??? ?
? ??? ??? "

results in...

IDLE 1.1.2 
>>> ================================ RESTART 
================================ 
>>> 
??????? ??????? ?????? ??????? ???????? ??????? ??????????? ??????? 
??? ??? ??? ??? ??? ??? ?
? ??? ?
? ??? ??? 
>>> 





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470

From noreply at sourceforge.net  Thu Feb 23 18:35:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Feb 2006 09:35:51 -0800
Subject: [ python-Bugs-1436900 ] Problem parsing cmdline parameter quoted with
	a trailing \
Message-ID: <E1FCKNb-0003YI-Jd@sc8-sf-web6.sourceforge.net>

Bugs item #1436900, was opened at 2006-02-22 10:38
Message generated for change (Comment added) made by tungwaiyip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

Please note that this 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
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing cmdline parameter quoted with a trailing \

Initial Comment:
This problem happens in launching Python from Windows. 
A quoted pathname is used as parameter. If and only if 
the pathname is ended with a trailing \, it is treated 
as an escape character.

p.py
-------------------------------------------------------
import sys
from pprint import pprint
pprint(sys.argv)
-------------------------------------------------------

Note slash inside the quote is treated as path 
separators

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip', 'wai']


However the trailing \ is treated as an escape 
character for the quote. Only command line parameter 
is presented in sys.argv.

g:\usr\bin>c:\python24\python.exe  g:\usr\bin\p.py "
tung\wai\yip\" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip" wai']



----------------------------------------------------------------------

>Comment By: Wai Yip Tung (tungwaiyip)
Date: 2006-02-23 09:35

Message:
Logged In: YES 
user_id=561546

I don't completely follow your logic. But I have reproduce 
this with Java so it looks very likely that it is a Windows 
bug. In addition, a workaround is to add as extra \ at the 
end of the first argument if you know it is going to end in 
\. This is illustrated in the last example.

P.java
------------------------------------------------------------
public class P {
  public static void main(String argv[]) throws Exception {
    for (int i=0; i < argv.length; i++) {
      System.out.println("argv " + i + " " + argv[i]);
    }
  }
}
-----------------------------------------------------------
BAD
c:\>java P "tung\wai\yip\" wai
argv 0 tung\wai\yip" wai

GOOD
c:\>java P "tung\wai\yip\\" wai
argv 0 tung\wai\yip\
argv 1 wai
-----------------------------------------------------------



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 12:53

Message:
Logged In: YES 
user_id=849994

OK, closing.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-22 12:38

Message:
Logged In: YES 
user_id=1126061

Whoops, my bad. Its a windows issue, not a python one.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-22 12:34

Message:
Logged In: YES 
user_id=1126061

After having a quick look it appears as though python is in
fact stripping the trailing '\'. the argv array that the
python interpreter is passed contains the backslash so it
must be doing away with it.



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 12:12

Message:
Logged In: YES 
user_id=849994

Is that Python-specific? I thought sys.argv is the cmdline
args as Python gets them from Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470

From noreply at sourceforge.net  Thu Feb 23 19:48:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Feb 2006 10:48:01 -0800
Subject: [ python-Bugs-1437614 ] can't send files via ftp on my MacOS X 10.3.9
Message-ID: <E1FCLVR-0003VO-Me@sc8-sf-web3.sourceforge.net>

Bugs item #1437614, was opened at 2006-02-23 11:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470

Please note that this message 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
Submitted By: Li Quid (liquid333)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't send files via ftp on my MacOS X 10.3.9

Initial Comment:

When trying to do a simple ftp upload using Python
2.3's ftplib, it fails and I get a socket error.  The
exact error is (61, 'Connection refused').  This
happens to me in all my scripts that use the ftplib on
MacOS 10.3.9, but not in scripts on my Windows box. 
I've attached the small, simple source code.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470

From noreply at sourceforge.net  Thu Feb 23 20:02:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Feb 2006 11:02:49 -0800
Subject: [ python-Bugs-1194328 ] Reading from a killed shell script with
	popen* under linux
Message-ID: <E1FCLjl-0003x1-Fh@sc8-sf-web6.sourceforge.net>

Bugs item #1194328, was opened at 2005-05-03 09:44
Message generated for change (Comment added) made by boukthor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Vinz (boukthor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading from a killed shell script with popen* under linux

Initial Comment:
These are problems I've run into under linux (Mandrake
10.0 through 2006.0, Debian 3.1 and Gentoo) with python
versions ranging from 2.3.3 to 2.4:

If you run this:

import os
pout = os.popen("/bin/sleep 999")
print pout.read()
print pout.close()

and kill the "sleep", you get the desired behaviour:
the read returns an empty string when the process gets
killed and the close returns the killing signal.
However, if you put the "sleep" command in a shell
script, for example this simple "/tmp/test.sh":

#!/bin/sh
sleep 999

and run the script through popen (or one of the popen*
method of the os and popen2 module)

import os
pout = os.popen("/tmp/test.sh")
print pout.read()
print pout.close()

then kill the sh running "test.sh", the read never
returns and the shell remains as a zombie. You can get
some strange behaviour with the Popen* classes too
(whether bypassing the shell intervention or not). For
example, run this (and kill the subshell):

import popen2
sub = popen2.Popen3("/tmp/test.sh")
print sub.wait()
print sub.fromchild.read()

this time the wait correctly returns the signal that
killed the shell and removes it from the process table,
but the read hangs again.

As an added oddity, if you run the popen command from
an interactive prompt and raise a KeyboardInterrupt by
pressing Ctrl-C before trying to read from the pipe,
you kill the subprocess with the SIGINT...



I have a final suggestion: if you try reading the
output of a popen* method with a "for" statement like this:

import os
pout = os.popen("for i in $(seq 1 10); do echo $i;
sleep 1; done")
for l in pout: print l,

it waits for the subprocess to complete before going
into the loop. To get the output as it is piped, you
have to use the poll method of the Popen* classes
(which is not available under OSes other than Unix):

sub = popen2.Popen3("for i in $(seq 1 10); do echo $i;
sleep 1; done")
while (-1 == sub.poll()): print sub.fromchild.readline()

I don't know if this last behaviour can be fixed or not
but I'd suggest some mention of this in the manual if
it can't.

----------------------------------------------------------------------

>Comment By: Vinz (boukthor)
Date: 2006-02-23 19:02

Message:
Logged In: YES 
user_id=638508

This is not a bug after all...

When you run a command through a shell script, kill the
script and waiting for it to return, any subcommands of the
script get reattached to init until they complete. If these
subcommands didn't close them, they still have descriptors
to the popen pipe through which they may write data. It is
then normal that reading the pipe should block until
completion, not only of the command invoqued but of all its
subprocesses as well. Very annoying for my purpose, but
definitively not a python bug.

Oh well, I thinks I'll stop talking to myself, now. I must
say I'm a bit disappointed at the nonexistent support and
help I got from this python bugzilla, though...

----------------------------------------------------------------------

Comment By: Vinz (boukthor)
Date: 2005-08-12 13:48

Message:
Logged In: YES 
user_id=638508

The report #1180160 was only loosely related to the above
problem. In fact it is probably closer to the following :
761888	popen2.Popen3 and popen2.Popen4 leaks filedescriptors
892939	Race condition in popen2
998246	Popen3.poll race condition
1183780	Popen4 wait() fails sporadically with threads

NB : This bug is very incapacitating for me since I can't
figure any workaround and though I understand that
developers may have other priorities, I'd appreciate some
acknowledgement that somebody at least read this report...

----------------------------------------------------------------------

Comment By: Vinz (boukthor)
Date: 2005-05-03 09:49

Message:
Logged In: YES 
user_id=638508

Oops, just saw the report #1180160. I missed it because I
searched for popen, not Popen before posting. My bad. I'll
cross-reference the two.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470

From noreply at sourceforge.net  Thu Feb 23 20:05:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Feb 2006 11:05:31 -0800
Subject: [ python-Bugs-1194328 ] Reading from a killed shell script with
	popen* under linux
Message-ID: <E1FCLmN-0003xN-P8@sc8-sf-web6.sourceforge.net>

Bugs item #1194328, was opened at 2005-05-03 09:44
Message generated for change (Settings changed) made by boukthor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Vinz (boukthor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading from a killed shell script with popen* under linux

Initial Comment:
These are problems I've run into under linux (Mandrake
10.0 through 2006.0, Debian 3.1 and Gentoo) with python
versions ranging from 2.3.3 to 2.4:

If you run this:

import os
pout = os.popen("/bin/sleep 999")
print pout.read()
print pout.close()

and kill the "sleep", you get the desired behaviour:
the read returns an empty string when the process gets
killed and the close returns the killing signal.
However, if you put the "sleep" command in a shell
script, for example this simple "/tmp/test.sh":

#!/bin/sh
sleep 999

and run the script through popen (or one of the popen*
method of the os and popen2 module)

import os
pout = os.popen("/tmp/test.sh")
print pout.read()
print pout.close()

then kill the sh running "test.sh", the read never
returns and the shell remains as a zombie. You can get
some strange behaviour with the Popen* classes too
(whether bypassing the shell intervention or not). For
example, run this (and kill the subshell):

import popen2
sub = popen2.Popen3("/tmp/test.sh")
print sub.wait()
print sub.fromchild.read()

this time the wait correctly returns the signal that
killed the shell and removes it from the process table,
but the read hangs again.

As an added oddity, if you run the popen command from
an interactive prompt and raise a KeyboardInterrupt by
pressing Ctrl-C before trying to read from the pipe,
you kill the subprocess with the SIGINT...



I have a final suggestion: if you try reading the
output of a popen* method with a "for" statement like this:

import os
pout = os.popen("for i in $(seq 1 10); do echo $i;
sleep 1; done")
for l in pout: print l,

it waits for the subprocess to complete before going
into the loop. To get the output as it is piped, you
have to use the poll method of the Popen* classes
(which is not available under OSes other than Unix):

sub = popen2.Popen3("for i in $(seq 1 10); do echo $i;
sleep 1; done")
while (-1 == sub.poll()): print sub.fromchild.readline()

I don't know if this last behaviour can be fixed or not
but I'd suggest some mention of this in the manual if
it can't.

----------------------------------------------------------------------

Comment By: Vinz (boukthor)
Date: 2006-02-23 19:02

Message:
Logged In: YES 
user_id=638508

This is not a bug after all...

When you run a command through a shell script, kill the
script and waiting for it to return, any subcommands of the
script get reattached to init until they complete. If these
subcommands didn't close them, they still have descriptors
to the popen pipe through which they may write data. It is
then normal that reading the pipe should block until
completion, not only of the command invoqued but of all its
subprocesses as well. Very annoying for my purpose, but
definitively not a python bug.

Oh well, I thinks I'll stop talking to myself, now. I must
say I'm a bit disappointed at the nonexistent support and
help I got from this python bugzilla, though...

----------------------------------------------------------------------

Comment By: Vinz (boukthor)
Date: 2005-08-12 13:48

Message:
Logged In: YES 
user_id=638508

The report #1180160 was only loosely related to the above
problem. In fact it is probably closer to the following :
761888	popen2.Popen3 and popen2.Popen4 leaks filedescriptors
892939	Race condition in popen2
998246	Popen3.poll race condition
1183780	Popen4 wait() fails sporadically with threads

NB : This bug is very incapacitating for me since I can't
figure any workaround and though I understand that
developers may have other priorities, I'd appreciate some
acknowledgement that somebody at least read this report...

----------------------------------------------------------------------

Comment By: Vinz (boukthor)
Date: 2005-05-03 09:49

Message:
Logged In: YES 
user_id=638508

Oops, just saw the report #1180160. I missed it because I
searched for popen, not Popen before posting. My bad. I'll
cross-reference the two.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470

From noreply at sourceforge.net  Thu Feb 23 22:07:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Feb 2006 13:07:54 -0800
Subject: [ python-Bugs-1437699 ] robotparser crashes if robots.txt contains
	non-ASCII
Message-ID: <E1FCNgo-0003vO-BV@sc8-sf-web3.sourceforge.net>

Bugs item #1437699, was opened at 2006-02-23 16:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437699&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: robotparser crashes if robots.txt contains non-ASCII

Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError. 

More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares  the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)

I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:

AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8


A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.






----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437699&group_id=5470

From noreply at sourceforge.net  Fri Feb 24 00:59:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 23 Feb 2006 15:59:34 -0800
Subject: [ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Message-ID: <E1FCQMw-0002Zd-5t@sc8-sf-web5.sourceforge.net>

Bugs item #1437785, was opened at 2006-02-23 17:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems w/ expat 1.95.7 vs. Python 2.4

Initial Comment:
This may apply to the trunk as well...

Today I finished installing 2.4.2 and all our local libraries at work.
Trying out the main application I use I discovered Python segfaulting
when trying to import pyexpat.  It turned out that during the import
an earlier module (gtk.glade) also wanted libexpat.  Apparently pyexpat
was expecting to get Expat 1.95.8 (what's delivered with Python) but
got 1.95.7 instead (what we had installed and what was already linked
with all our other Expat-using code).

The solution was rather simple.  I just commented out those constants
in the pyexpat initialization that were marked as 1.95.8.  Fortunately
there was a comment identifying the version dependency.

Is there some way that Python's build process can detect the Expat
version and conditionally include/exclude bits that are for later
versions?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470

From noreply at sourceforge.net  Fri Feb 24 17:03:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Feb 2006 08:03:04 -0800
Subject: [ python-Bugs-1438185 ] os.renames() crashes NTFS junctions
Message-ID: <E1FCfPM-0002H6-3J@sc8-sf-web1.sourceforge.net>

Bugs item #1438185, was opened at 2006-02-24 17:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438185&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Rohlfing (damiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.renames() crashes NTFS junctions

Initial Comment:
Hello

There is a problem using os.renames() with a path, 
that was created as a ntfs junction.

You will find more information about junctions and a 
tool to create them on:
http://www.sysinternals.com/Utilities/Junction.html
The source is also available there.

Try this to reproduce the problem:

*in DOS*
mkdir C:\dir1
echo >>C:\dir1\old.txt
junction.exe C:\dir2 C:\dir1

*in Python*
>>> import os
>>> os.renames("C:\\dir2\\old.txt", "C:\\dir2
\\new.txt")

If you now look in 'dir1' you will find new.txt
thats fine, but junction 'dir2' not longer exist.

os.rename() is not affected by this problem.

My OP is Windows 2000 [Version 5.00.2195] with SP4 and 
im using Python 2.4.2

I hope you will find this information usefull.

greets from germany
Daniel Rohlfing


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438185&group_id=5470

From noreply at sourceforge.net  Sat Feb 25 06:26:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 24 Feb 2006 21:26:29 -0800
Subject: [ python-Bugs-1438480 ] shutil.move raises OSError when copystat fails
Message-ID: <E1FCrwr-000052-Tv@sc8-sf-web3.sourceforge.net>

Bugs item #1438480, was opened at 2006-02-25 05: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=1438480&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Nobody/Anonymous (nobody)
Summary: shutil.move raises OSError when copystat fails

Initial Comment:
If you are on a Linux system, and shutil.move a file
from anywhere onto a partition where you have write
permission but are not the owner, os.utime will fail
with an EPERM OSError. This can (and did) happen moving
a file on a vfat partition mounted with umask=0000, so
every user had read/write/execute but all files were
owned by root.

This happens in shutil.copystat, so shutil.move doesn't
remove the old file. The resulting error code (OSError,
EPERM) is not distinguishable from several other
permission errors that can happen during shutil.move,
even though a failure to set a utime is not fatal for
most move operations (mv(1) succeeds, for example).

I would suggest either ignoring an EPERM from copystat,
or catching it in shutil.copy2 and raising a more
specific exception so that it can be easily
distinguished from genuine failure due to permissions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438480&group_id=5470

From noreply at sourceforge.net  Sat Feb 25 10:41:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Feb 2006 01:41:06 -0800
Subject: [ python-Bugs-1438537 ] modules search in help() crashes on
	insufficient file perms
Message-ID: <E1FCvvG-00076q-L4@sc8-sf-web5.sourceforge.net>

Bugs item #1438537, was opened at 2006-02-25 09: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=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing <code>modules &lt;keyword&gt;</code>
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-----  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
    self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
    self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
    self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
    apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
    desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
    file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

From noreply at sourceforge.net  Sat Feb 25 10:44:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Feb 2006 01:44:18 -0800
Subject: [ python-Bugs-1438537 ] modules search in help() crashes on
	insufficient file perms
Message-ID: <E1FCvyM-0008NH-QQ@sc8-sf-web4-b.sourceforge.net>

Bugs item #1438537, was opened at 2006-02-25 09:41
Message generated for change (Comment added) made by hauptbeuteltier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing <code>modules &lt;keyword&gt;</code>
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-----  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
    self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
    self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
    self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
    apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
    desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
    file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

----------------------------------------------------------------------

>Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 09:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

From noreply at sourceforge.net  Sat Feb 25 13:34:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Feb 2006 04:34:59 -0800
Subject: [ python-Bugs-1438537 ] modules search in help() crashes on
	insufficient file perms
Message-ID: <E1FCydX-0004s7-8Z@sc8-sf-web1.sourceforge.net>

Bugs item #1438537, was opened at 2006-02-25 09:41
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing <code>modules &lt;keyword&gt;</code>
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-----  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
    self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
    self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
    self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
    apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
    desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
    file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-25 12:34

Message:
Logged In: YES 
user_id=1126061

Could this just be silently skipped? i.e returning None if
the user does not have the corrept permissions to access a
particular file?

Just wrap the 'file = open(filename)' in pydoc.py: line 182
in a try: except block returning None if there's an error
(such as permission denied).

I have written a patch I can supply if anyone wants it and
if this is the Right Thing To Do (TM).


----------------------------------------------------------------------

Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 09:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

From noreply at sourceforge.net  Sat Feb 25 22:59:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Feb 2006 13:59:25 -0800
Subject: [ python-Bugs-1385040 ] compiler module does not detect a syntax error
Message-ID: <E1FD7Rl-00034M-Hv@sc8-sf-web6.sourceforge.net>

Bugs item #1385040, was opened at 2005-12-19 01:58
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470

Please note that this 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
Submitted By: Harri Pasanen (harripasanen)
>Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error

Initial Comment:
import compiler 
compiler.parse("def foo(a=1,b): pass") 
 
Gives: 
 
Module(None, Stmt([Function(None, 'foo', ['a', 'b'], 
[Const(1)], 0, None, Stmt([Pass()]))])) 
 
However, the python interpreter itself barks for the 
same code: 
 
SyntaxError: non-default argument follows default 
argument 
 
 
-Harri 
 
 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 13:59

Message:
Logged In: YES 
user_id=33168

FYI.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470

From noreply at sourceforge.net  Sat Feb 25 23:00:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Feb 2006 14:00:19 -0800
Subject: [ python-Bugs-999444 ] compiler module doesn't support unicode
	characters in laiter
Message-ID: <E1FD7Sd-00034V-IF@sc8-sf-web6.sourceforge.net>

Bugs item #999444, was opened at 2004-07-28 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=999444&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
>Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module doesn't support unicode characters in laiter

Initial Comment:
I'm not positive that this is a bug.  The buit-in
compile function acepts unicode with non-ascii text in
literals:

>>> text = u"print u'''\u0442\u0435\u0441\u0442'''"
>>> exec compile(text, 's', 'exec')
?&#130;?????&#130;
>>> import compiler
>>> exec compiler.compile(text, 's', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 64, in compile
    gen.compile()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 111, in compile
    tree = self._get_tree()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 77, in _get_tree
    tree = parse(self.source, self.mode)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 10-13: ordinal not in range(128)
>>> 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 14:00

Message:
Logged In: YES 
user_id=33168

FYI

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-29 04:38

Message:
Logged In: YES 
user_id=38388

Note that the tokenizer converts the input string into UTF-8
(transcoding it as necessary if a source code encoding shebang
is found) and the compiler will assume this encoding when
creating
Unicode literals.

I'm not sure whether the compiler package is up-to-date w/r to
these internal changes in the C-based compiler.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-29 04:30

Message:
Logged In: YES 
user_id=6656

thinking about this a little harder, doing a proper job probably 
invloves mucking around in the depths of python to support 
source-as-unicode throughout.  the vile solution is this sort of 
thing:

>>> parser.suite('# coding: utf-8\n' + u"print 
u'''\u0442\u0435\u0441\u0442'''".encode('utf-8'))
<parser.st object at 0x107770>


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-29 04:19

Message:
Logged In: YES 
user_id=6656

the immediate problem is that the parser module does support 
unicode:

>>> import parser
>>> parser.suite(u"print u'''\u0442\u0435\u0441\u0442'''")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode characters in 
position 10-13: ordinal not in range(128)

there may well be more bugs lurking in Lib/compiler wrt this 
issue, but this is the first... I don't know how easy this will be to 
fix (looking at what the builtin compile() function does with 
unicode might be a good start).

----------------------------------------------------------------------

Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 07:02

Message:
Logged In: YES 
user_id=73023

Also in 2.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470

From noreply at sourceforge.net  Sat Feb 25 23:01:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Feb 2006 14:01:00 -0800
Subject: [ python-Bugs-999042 ] Compiler module doesn't handle global
	statement correctly
Message-ID: <E1FD7TI-0001Li-V7@sc8-sf-web4-b.sourceforge.net>

Bugs item #999042, was opened at 2004-07-27 15:15
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Compiler module doesn't handle global statement correctly

Initial Comment:
If we don't use the compiler module:

>>> code = 'global x\nx=1'
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}, 'x': 1}, {})

with the compiler module:

>>> code = compiler.compile('global x\nx=1', 'd', 'exec') 
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}}, {'x': 1})

global is ignored

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 14:01

Message:
Logged In: YES 
user_id=33168

FYI

----------------------------------------------------------------------

Comment By: Darek Suchojad (dsuch)
Date: 2005-04-29 15:04

Message:
Logged In: YES 
user_id=954779

Hi, I have submitted a simple fix some time ago
python.org/sf/1090482, do you think it is correct?

----------------------------------------------------------------------

Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 07:01

Message:
Logged In: YES 
user_id=73023

Also in 2.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470

From noreply at sourceforge.net  Sun Feb 26 00:02:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Feb 2006 15:02:40 -0800
Subject: [ python-Bugs-1438185 ] os.renames() crashes NTFS junctions
Message-ID: <E1FD8Qy-00027F-0p@sc8-sf-web3.sourceforge.net>

Bugs item #1438185, was opened at 2006-02-24 10:03
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438185&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Rohlfing (damiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.renames() crashes NTFS junctions

Initial Comment:
Hello

There is a problem using os.renames() with a path, 
that was created as a ntfs junction.

You will find more information about junctions and a 
tool to create them on:
http://www.sysinternals.com/Utilities/Junction.html
The source is also available there.

Try this to reproduce the problem:

*in DOS*
mkdir C:\dir1
echo >>C:\dir1\old.txt
junction.exe C:\dir2 C:\dir1

*in Python*
>>> import os
>>> os.renames("C:\\dir2\\old.txt", "C:\\dir2
\\new.txt")

If you now look in 'dir1' you will find new.txt
thats fine, but junction 'dir2' not longer exist.

os.rename() is not affected by this problem.

My OP is Windows 2000 [Version 5.00.2195] with SP4 and 
im using Python 2.4.2

I hope you will find this information usefull.

greets from germany
Daniel Rohlfing


----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-02-25 17:02

Message:
Logged In: YES 
user_id=699438

This is because 'os.rmdir' doesn't throw an exception when
deleting a junction, since it doesn't really have any files
under it.  Does look like a bug to me though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438185&group_id=5470

From noreply at sourceforge.net  Sun Feb 26 06:08:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 25 Feb 2006 21:08:13 -0800
Subject: [ python-Bugs-1438480 ] shutil.move raises OSError when copystat fails
Message-ID: <E1FDE8j-00033h-Pc@sc8-sf-web3.sourceforge.net>

Bugs item #1438480, was opened at 2006-02-25 05:26
Message generated for change (Comment added) made by piman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438480&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Nobody/Anonymous (nobody)
Summary: shutil.move raises OSError when copystat fails

Initial Comment:
If you are on a Linux system, and shutil.move a file
from anywhere onto a partition where you have write
permission but are not the owner, os.utime will fail
with an EPERM OSError. This can (and did) happen moving
a file on a vfat partition mounted with umask=0000, so
every user had read/write/execute but all files were
owned by root.

This happens in shutil.copystat, so shutil.move doesn't
remove the old file. The resulting error code (OSError,
EPERM) is not distinguishable from several other
permission errors that can happen during shutil.move,
even though a failure to set a utime is not fatal for
most move operations (mv(1) succeeds, for example).

I would suggest either ignoring an EPERM from copystat,
or catching it in shutil.copy2 and raising a more
specific exception so that it can be easily
distinguished from genuine failure due to permissions.

----------------------------------------------------------------------

>Comment By: Joe Wreschnig (piman)
Date: 2006-02-26 05:08

Message:
Logged In: YES 
user_id=796

The attached patch causes shutil.copy and shutil.copy2 (and
so copytree, and move) to ignore EACCES and EPERM from
copymode and copystat respectively. Other errors are
reraised with the original traceback. Any error copying the
file, rather than the metadata, is still considered fatal.
User calls to copymode and copystat still fail as before.

Justification: On Linux, utime(2) says the distinction
between EACCES and EPERM is blurry and "Linux is not careful
to distinguish between the EACCES and EPERM" so the patch
ignores both. In my opinion, anyone wanting to deal with
low-level details like mtimes and modes is probably not
using shutil, so ignoring is better than a new exception
(which would just result in complicated new code, and
surprise old code). It's also easy for a caller to check if
the mode/utimes were copied, if it's important to them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438480&group_id=5470

From noreply at sourceforge.net  Mon Feb 27 00:23:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Feb 2006 15:23:14 -0800
Subject: [ python-Bugs-1438185 ] os.renames() crashes NTFS junctions
Message-ID: <E1FDVEQ-0004FC-9U@sc8-sf-web3.sourceforge.net>

Bugs item #1438185, was opened at 2006-02-24 10:03
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438185&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Rohlfing (damiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.renames() crashes NTFS junctions

Initial Comment:
Hello

There is a problem using os.renames() with a path, 
that was created as a ntfs junction.

You will find more information about junctions and a 
tool to create them on:
http://www.sysinternals.com/Utilities/Junction.html
The source is also available there.

Try this to reproduce the problem:

*in DOS*
mkdir C:\dir1
echo >>C:\dir1\old.txt
junction.exe C:\dir2 C:\dir1

*in Python*
>>> import os
>>> os.renames("C:\\dir2\\old.txt", "C:\\dir2
\\new.txt")

If you now look in 'dir1' you will find new.txt
thats fine, but junction 'dir2' not longer exist.

os.rename() is not affected by this problem.

My OP is Windows 2000 [Version 5.00.2195] with SP4 and 
im using Python 2.4.2

I hope you will find this information usefull.

greets from germany
Daniel Rohlfing


----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-02-26 17:23

Message:
Logged In: YES 
user_id=699438

Patch 1439312 posted.

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-02-25 17:02

Message:
Logged In: YES 
user_id=699438

This is because 'os.rmdir' doesn't throw an exception when
deleting a junction, since it doesn't really have any files
under it.  Does look like a bug to me though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438185&group_id=5470

From noreply at sourceforge.net  Mon Feb 27 00:32:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 26 Feb 2006 15:32:18 -0800
Subject: [ python-Bugs-1438537 ] modules search in help() crashes on
	insufficient file perms
Message-ID: <E1FDVNC-0002St-Aq@sc8-sf-web5.sourceforge.net>

Bugs item #1438537, was opened at 2006-02-25 03:41
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing <code>modules &lt;keyword&gt;</code>
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-----  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
    self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
    self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
    self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
    apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
    desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
    file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-02-26 17:32

Message:
Logged In: YES 
user_id=699438

That patch sounds pretty-much right, but I think it should
print some feedback to stderr instead of silently swallowing
the exception.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-25 06:34

Message:
Logged In: YES 
user_id=1126061

Could this just be silently skipped? i.e returning None if
the user does not have the corrept permissions to access a
particular file?

Just wrap the 'file = open(filename)' in pydoc.py: line 182
in a try: except block returning None if there's an error
(such as permission denied).

I have written a patch I can supply if anyone wants it and
if this is the Right Thing To Do (TM).


----------------------------------------------------------------------

Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 03:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

From noreply at sourceforge.net  Mon Feb 27 11:51:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Feb 2006 02:51:24 -0800
Subject: [ python-Bugs-1439538 ] test -e is not portable (Solaris 2.7)
Message-ID: <E1FDfyO-0004bX-6j@sc8-sf-web4-b.sourceforge.net>

Bugs item #1439538, was opened at 2006-02-27 11:51
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=1439538&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: H??vard Tveite (havatv)
Assigned to: Nobody/Anonymous (nobody)
Summary: test -e is not portable (Solaris 2.7)

Initial Comment:
I was adviced by Barry Warsaw to file a bug on this.

I tried to install Python 2.4.2 (and 2.3.5) on Solaris
2.7, but configure failed.
The Solaris 2.7 sh does not support "test -e".
"test -e" is used two times in configure.

The use of "test -e" is not recommended for "Portable
Shell Programming":
<URL:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_10.html
>

I replaced "test -e" with "test -r", and it seems to work
(configure finishes OK, and the files are found), but
I do not know if this is the correct way to do it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470

From noreply at sourceforge.net  Mon Feb 27 15:51:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 27 Feb 2006 06:51:00 -0800
Subject: [ python-Bugs-1439659 ] file to store pickled object should be opened
	in binary mode
Message-ID: <E1FDjiG-0004u8-Me@sc8-sf-web5.sourceforge.net>

Bugs item #1439659, was opened at 2006-02-27 09:51
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=1439659&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: file to store pickled object should be opened in binary mode

Initial Comment:

Hi,

To unpickle objects on UNIX that were pickled on
windows, the file should be opened in binary mode for
read and write on windows. It will be nice to have this
mentioned in the doc. Something along these lines will
be good enough:

"Please note that if you are writing the pickled object
to a file on windows, make sure it is opened in binary
mode. Otherwise, the file may not be able to be used to
unpickle on other non-windows platforms".

Thanks,
Raghu. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470

From noreply at sourceforge.net  Tue Feb 28 16:54:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Feb 2006 07:54:30 -0800
Subject: [ python-Bugs-1438537 ] modules search in help() crashes on
	insufficient file perms
Message-ID: <E1FE7BG-0000UN-6q@sc8-sf-web6.sourceforge.net>

Bugs item #1438537, was opened at 2006-02-25 09:41
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing <code>modules &lt;keyword&gt;</code>
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-----  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
    self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
    self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
    self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
    apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
    desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
    file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-28 15:54

Message:
Logged In: YES 
user_id=1126061

Yeah, I've modified it to tell the user which file caused
the problem.

Want the patch posting to the Patch Manager?

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-02-26 23:32

Message:
Logged In: YES 
user_id=699438

That patch sounds pretty-much right, but I think it should
print some feedback to stderr instead of silently swallowing
the exception.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-25 12:34

Message:
Logged In: YES 
user_id=1126061

Could this just be silently skipped? i.e returning None if
the user does not have the corrept permissions to access a
particular file?

Just wrap the 'file = open(filename)' in pydoc.py: line 182
in a try: except block returning None if there's an error
(such as permission denied).

I have written a patch I can supply if anyone wants it and
if this is the Right Thing To Do (TM).


----------------------------------------------------------------------

Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 09:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

From noreply at sourceforge.net  Tue Feb 28 18:11:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Feb 2006 09:11:46 -0800
Subject: [ python-Bugs-1440472 ] email.Generator is not idempotent
Message-ID: <E1FE8O2-0005EF-8C@sc8-sf-web3.sourceforge.net>

Bugs item #1440472, was opened at 2006-02-28 17:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1440472&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: WonderClown (rnortman)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Generator is not idempotent

Initial Comment:
The documentation for the email.Generator module claims
that the flatten() method is idempotent (i.e., output
identical to the input, if email.Parser.Parser was used
on the input), but it is not in all cases.  The most
obvious example is that you need to disable mangle_from
and set maxheaderlen=0 to disable header wrapping. 
This could be considered common sense, but the
documentation should mention it, as both are enabled by
default.  (unixfrom can also create differences between
input and output, but is disabled by default.)  More
importantly, whitespace is not preserved in headers: if
there are extra spaces between the header name and the
header contents, it will be collapsed to a single space.

This little snippet will demonstrate the problem:

    parser = email.Parser.Parser()
    msg = parser.parse(sys.stdin)
    print msg
    gen = email.Generator.Generator(sys.stdout,
mangle_from_=False, maxheaderlen=0)
    gen.flatten(msg, unixfrom=False)

Feed it a single message with extra spaces beween field
name and field contents in one or more fields, and diff
the input and the output.

It is probably not worth actually making these routines
idempotent, as preserving whitespace is not important
in most applications and would require extra
bookkeeping.  However, as long as the documentation
claims the routines are idempotent, it is a bug not to
be.  In my particular application, it was important to
be truly idempotent, so this was a problem.  Had the
documentation not made false claims, I would have known
from the start that I needed to write my own versions
of the routines in the email module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1440472&group_id=5470

From noreply at sourceforge.net  Tue Feb 28 18:57:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Feb 2006 09:57:53 -0800
Subject: [ python-Bugs-1440472 ] email.Generator is not idempotent
Message-ID: <E1FE96f-00040w-Gk@sc8-sf-web1.sourceforge.net>

Bugs item #1440472, was opened at 2006-02-28 12:11
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1440472&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: WonderClown (rnortman)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Generator is not idempotent

Initial Comment:
The documentation for the email.Generator module claims
that the flatten() method is idempotent (i.e., output
identical to the input, if email.Parser.Parser was used
on the input), but it is not in all cases.  The most
obvious example is that you need to disable mangle_from
and set maxheaderlen=0 to disable header wrapping. 
This could be considered common sense, but the
documentation should mention it, as both are enabled by
default.  (unixfrom can also create differences between
input and output, but is disabled by default.)  More
importantly, whitespace is not preserved in headers: if
there are extra spaces between the header name and the
header contents, it will be collapsed to a single space.

This little snippet will demonstrate the problem:

    parser = email.Parser.Parser()
    msg = parser.parse(sys.stdin)
    print msg
    gen = email.Generator.Generator(sys.stdout,
mangle_from_=False, maxheaderlen=0)
    gen.flatten(msg, unixfrom=False)

Feed it a single message with extra spaces beween field
name and field contents in one or more fields, and diff
the input and the output.

It is probably not worth actually making these routines
idempotent, as preserving whitespace is not important
in most applications and would require extra
bookkeeping.  However, as long as the documentation
claims the routines are idempotent, it is a bug not to
be.  In my particular application, it was important to
be truly idempotent, so this was a problem.  Had the
documentation not made false claims, I would have known
from the start that I needed to write my own versions
of the routines in the email module.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1440472&group_id=5470

From noreply at sourceforge.net  Tue Feb 28 22:55:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 28 Feb 2006 13:55:25 -0800
Subject: [ python-Bugs-1438537 ] modules search in help() crashes on
	insufficient file perms
Message-ID: <E1FECoX-0002kA-HW@sc8-sf-web1.sourceforge.net>

Bugs item #1438537, was opened at 2006-02-25 03:41
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing <code>modules &lt;keyword&gt;</code>
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-----  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
    self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
    self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
    self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
    apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
    ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
    desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
    file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-02-28 15:55

Message:
Logged In: YES 
user_id=699438

I personally don't have commit rights, but yes, it's
generally easiest if you post the patch to Patch manager and
put a cross reference note on the bug.  Developers usually
give working patches precidence over bugs.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-28 09:54

Message:
Logged In: YES 
user_id=1126061

Yeah, I've modified it to tell the user which file caused
the problem.

Want the patch posting to the Patch Manager?

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-02-26 17:32

Message:
Logged In: YES 
user_id=699438

That patch sounds pretty-much right, but I think it should
print some feedback to stderr instead of silently swallowing
the exception.

----------------------------------------------------------------------

Comment By: splitscreen (splitscreen)
Date: 2006-02-25 06:34

Message:
Logged In: YES 
user_id=1126061

Could this just be silently skipped? i.e returning None if
the user does not have the corrept permissions to access a
particular file?

Just wrap the 'file = open(filename)' in pydoc.py: line 182
in a try: except block returning None if there's an error
(such as permission denied).

I have written a patch I can supply if anyone wants it and
if this is the Right Thing To Do (TM).


----------------------------------------------------------------------

Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 03:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

From pasquale.daloise at gatelab.com  Sat Feb 11 17:40:46 2006
From: pasquale.daloise at gatelab.com (Pasquale d'Aloise)
Date: Sat, 11 Feb 2006 16:40:46 -0000
Subject: Bug in unicode object free list?
Message-ID: <000501c62f29$e0c74c40$6d763552@wi2kpro69>

I suspect there is a bug in the way the unicode object
"free list" is managed.

In the file unicodeobject.c, I noticed the following
statements whose behaviour is a bit ambiguous for me:

unicode_freelist = *(PyUnicodeObject **)unicode;
.....
*(PyUnicodeObject **)unicode = unicode_freelist;
......
u = *(PyUnicodeObject **)u;

It seems to me that those statements assume
the first member of  PyUnicodeObject is
"_ob_next" but this is true only if Py_TRACE_REFS
is defined.
If PyTRACE_REFS is not defined, the first member
of PyUnicodeObject is "ob_refcnt" and I think the above
statements have an unexpected behaviour.

Regards.

Pasquale d'Aloise
GATE T.I. s.r.l.
Viale dei Pentri, P.zzo D'Abbraccio
86170 ISERNIA
Tel. 0865.451890