[ python-Bugs-1585135 ] Events in list return None not True on wait()
Bugs item #1585135, was opened at 2006-10-26 10:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: SpinMess (spinmess) Assigned to: Nobody/Anonymous (nobody) Summary: Events in list return None not True on wait() Initial Comment: OS: Suse Linux 10.0 Python 2.4.1 After I call e.set() for some event e, subsequent calls to e.wait() return None instead of True. This happens if & only if e is an element in a list. As a workaround, I can test for e.wait()==None instead of e.wait() itself. I've attached sample code to demonstrate the bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1585135 ] Events in list return None not True on wait()
Bugs item #1585135, was opened at 2006-10-26 10:50 Message generated for change (Comment added) made by spinmess You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: SpinMess (spinmess) Assigned to: Nobody/Anonymous (nobody) Summary: Events in list return None not True on wait() Initial Comment: OS: Suse Linux 10.0 Python 2.4.1 After I call e.set() for some event e, subsequent calls to e.wait() return None instead of True. This happens if & only if e is an element in a list. As a workaround, I can test for e.wait()==None instead of e.wait() itself. I've attached sample code to demonstrate the bug. -- >Comment By: SpinMess (spinmess) Date: 2006-10-26 11:34 Message: Logged In: YES user_id=1630682 Bah. Never mind. I mis-read the documentation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1585135 ] Events in list return None not True on wait()
Bugs item #1585135, was opened at 2006-10-26 14:50 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: SpinMess (spinmess) Assigned to: Nobody/Anonymous (nobody) Summary: Events in list return None not True on wait() Initial Comment: OS: Suse Linux 10.0 Python 2.4.1 After I call e.set() for some event e, subsequent calls to e.wait() return None instead of True. This happens if & only if e is an element in a list. As a workaround, I can test for e.wait()==None instead of e.wait() itself. I've attached sample code to demonstrate the bug. -- Comment By: SpinMess (spinmess) Date: 2006-10-26 15:34 Message: Logged In: YES user_id=1630682 Bah. Never mind. I mis-read the documentation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1585135&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1584723 ] os.tempnam fails on SUSE Linux to accept directory argument
Bugs item #1584723, was opened at 2006-10-25 22:52
Message generated for change (Comment added) made by andyfloe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tempnam fails on SUSE Linux to accept directory argument
Initial Comment:
On SUSE Linux 10.1 the function os.tempnam does not use
the "dir" argument properly. It always takes the
tmpdir, in this case "/tmp". In the example below it is
expected to get a filename of '/tmp/tmp/pref2iGGS5'
instead of '/tmp/pref2iGGS5'.
[EMAIL PROTECTED]:~> python
Python 2.5 (r25:51908, Oct 18 2006, 22:50:32)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/pref2iGGS5'
>>>
[EMAIL PROTECTED]:~> ls -l /tmp/tmp
total 0
[EMAIL PROTECTED]:~> ls -ld /tmp/tmp
drwxr-xr-x 2 auser users 48 2006-10-17 20:13 /tmp/tmp
This behavior is also the same on the Python version
which comes with SUSE Linux 10.1. On Solaris 10 the
behavior is as expected, e.g.
-bash-3.00$ python
Python 2.4.3 (#1, Sep 16 2006, 10:31:38) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/tmp/prefAAAIeaafH'
A patch for the test 'test_os.py' is attached to this
report. It has been tested on SUSE Linux 10.1.
--
>Comment By: Andreas (andyfloe)
Date: 2006-10-26 18:55
Message:
Logged In: YES
user_id=1292384
Your hint about the environment variable TMPDIR
actually solves my problem. I have overlooked the
information given in the documentation about this fact.
Thanks.
--
Comment By: Matthias Kievernagel (mkiever)
Date: 2006-10-26 02:12
Message:
Logged In: YES
user_id=1477880
This one once irritated me also.
In my case the cause was
the environment variable 'TMPDIR'.
This is the first location chosen
by os.tempnam (see 'man tempnam').
Please check again.
Matthias Kievernagel
mkiever at web dot de
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1584723 ] os.tempnam fails on SUSE Linux to accept directory argument
Bugs item #1584723, was opened at 2006-10-25 20:52
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tempnam fails on SUSE Linux to accept directory argument
Initial Comment:
On SUSE Linux 10.1 the function os.tempnam does not use
the "dir" argument properly. It always takes the
tmpdir, in this case "/tmp". In the example below it is
expected to get a filename of '/tmp/tmp/pref2iGGS5'
instead of '/tmp/pref2iGGS5'.
[EMAIL PROTECTED]:~> python
Python 2.5 (r25:51908, Oct 18 2006, 22:50:32)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/pref2iGGS5'
>>>
[EMAIL PROTECTED]:~> ls -l /tmp/tmp
total 0
[EMAIL PROTECTED]:~> ls -ld /tmp/tmp
drwxr-xr-x 2 auser users 48 2006-10-17 20:13 /tmp/tmp
This behavior is also the same on the Python version
which comes with SUSE Linux 10.1. On Solaris 10 the
behavior is as expected, e.g.
-bash-3.00$ python
Python 2.4.3 (#1, Sep 16 2006, 10:31:38) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/tmp/prefAAAIeaafH'
A patch for the test 'test_os.py' is attached to this
report. It has been tested on SUSE Linux 10.1.
--
Comment By: Andreas (andyfloe)
Date: 2006-10-26 16:55
Message:
Logged In: YES
user_id=1292384
Your hint about the environment variable TMPDIR
actually solves my problem. I have overlooked the
information given in the documentation about this fact.
Thanks.
--
Comment By: Matthias Kievernagel (mkiever)
Date: 2006-10-26 00:12
Message:
Logged In: YES
user_id=1477880
This one once irritated me also.
In my case the cause was
the environment variable 'TMPDIR'.
This is the first location chosen
by os.tempnam (see 'man tempnam').
Please check again.
Matthias Kievernagel
mkiever at web dot de
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579796 ] Wrong syntax for PyDateTime_IMPORT in documentation
Bugs item #1579796, was opened at 2006-10-18 11:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: David Faure (dfaure_kde) >Assigned to: A.M. Kuchling (akuchling) Summary: Wrong syntax for PyDateTime_IMPORT in documentation Initial Comment: http://docs.python.org/api/datetime-objects.html says "macro PyDateTime_IMPORT() must be invoked." But this doesn't compile. It's PyDateTime_IMPORT; and not PyDateTime_IMPORT(); Also it would be useful to tell if this should be done once per thread or just once per process; seeing as it modifies a static variable I guess the latter. Cheers, David (still getting crashes in PyDateTime_FromDateAndTime though but that's another topic) -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-26 15:12 Message: Logged In: YES user_id=11375 Fixed in trunk (rev 52446), 2.5-maint (rev. 52447), and 2.4-maint (rev. 52448). Thanks for your report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579796&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576241 ] functools.wraps fails on builtins
Bugs item #1576241, was opened at 2006-10-12 18:24
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kajiuma (kajiuma)
>Assigned to: Nick Coghlan (ncoghlan)
Summary: functools.wraps fails on builtins
Initial Comment:
functools.wraps assumes that the wrapped function
has a __dict__ attribute, which is not true for
builtins.
The attached patch provides an empty dictionaries
for functions that do not have the required
attributes. This will cause programs expecting an
AttributeError (if there are any) to fail.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-26 15:18
Message:
Logged In: YES
user_id=11375
The change seems reasonable, but arguably this is an API
change because of the AttributeError no longer being raised.
Nick, do you want to decide whether to make this change or
not? (I can make the edit and add a test if you agree to
apply this change.)
--
Comment By: kajiuma (kajiuma)
Date: 2006-10-12 18:33
Message:
Logged In: YES
user_id=1619773
Looks like lynx cannot send files.
The patch changed: getattr(wrapped, attr)
to: getattr(wrapped, attr, {})
At then end of line 35 of Lib/functools.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566086 ] RE (regular expression) matching stuck in loop
Bugs item #1566086, was opened at 2006-09-26 21:23 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabien Devaux (fabinator) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE (regular expression) matching stuck in loop Initial Comment: See the code: http://pastebin.ca/183613 the "finditer()" call don't seems to return. Playing with the re can bypass the problem but it looks like a bug. (I'm really sorry if I did something wrong and didn't notice) note: I can reproduce it with python2.5 -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-26 15:38 Message: Logged In: YES user_id=11375 Attaching the test script. I've modified it to save a copy of the HTML page's data so that running the example doesn't require accessing a slow web site repeatedly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566086 ] RE (regular expression) matching stuck in loop
Bugs item #1566086, was opened at 2006-09-26 21:23 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabien Devaux (fabinator) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE (regular expression) matching stuck in loop Initial Comment: See the code: http://pastebin.ca/183613 the "finditer()" call don't seems to return. Playing with the re can bypass the problem but it looks like a bug. (I'm really sorry if I did something wrong and didn't notice) note: I can reproduce it with python2.5 -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-26 15:53 Message: Logged In: YES user_id=11375 I haven't dug very far into the code, but suspect this isn't a bug in the regex code. The pattern uses lots of .*? subpatterns, and this often means the pattern takes a long time to fail if it isn't going to match. The regex engine matches the group, and then there's a .*?, followed by . The engine looks at every character and if it sees a , tries another .*?. This is O(n**2) where n is the number of character in the string being searched, and that string is 93,000 characters long. If you limit the string to 5K or so, the match fails pretty quickly. I strongly suggest working with the HTML. You could run the HTML through tidy to convert to XHTML and use ElementTree on the resulting XML. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-26 15:38 Message: Logged In: YES user_id=11375 Attaching the test script. I've modified it to save a copy of the HTML page's data so that running the example doesn't require accessing a slow web site repeatedly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1570255 ] redirected cookies
Bugs item #1570255, was opened at 2006-10-03 16:37 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: hans_moleman (hans_moleman) Assigned to: Nobody/Anonymous (nobody) Summary: redirected cookies Initial Comment: Cookies are not resend when a redirect is requested. Blurb: I've been trying to get a response off a server using Python. The response so far differs from the response using Firefox. In Python, I have set headers and cookies the way Firefox does it. I noticed that the server accepts the POST request, and redirects the client to another address with the result on it. This happens both with Python and Firefox correctly. Cookie handling differs though: The Python client, when redirected, using the standard redirect handler, does not resend its cookies to the redirected address. Firefox does resend the cookies from the original request. When I redefine the redirect handler and code it so that it adds the cookies from the original request, the response is the same as Firefox's response. This confirms then that resending cookies is required to get the server to respond correctly. Is the default Python redirection cookie policy different from Firefox's policy? Could we improve the default redirection handler to work like Firefox? Is it a bug? I noticed an old open bug report 511786, that looks very much like this problem. It suggests it is fixed. Cheers Hans Moleman. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-26 16:16 Message: Logged In: YES user_id=11375 More detail is needed to figure out if there's a problem; can you give a sample URL to exhibit the problem? can you provide your code? From the description, it's unclear if this might be a bug in the handling of redirects or in the CookieProcessor class. The bug in 511786 is still fixed; that bug includes sample code, so I could check it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Bugs item #1565525, was opened at 2006-09-26 02:58 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-26 16:48 Message: Logged In: YES user_id=11375 A quick grep of the stdlib turns up various uses of sys.exc_info that do put it in a local variable., e.g. doctest._exception_traceback, unittest._exc_info_to_string, SimpleXMLRPCServer._marshaled_dispatch. Do these all need to be fixed? -- Comment By: Tim Peters (tim_one) Date: 2006-09-27 23:48 Message: Logged In: YES user_id=31435 [Martin] > tim_one: Why do you think your proposed modification of > introducing get_traceback would help? The frame foo still > refers to s (which is an O), and s.e will still refer > to the traceback that includes foo. Sorry about that! It was an illusion, of course. I wanted to suggest a quick fix, and "tested it" too hastily in a program that didn't actually bloat with /or/ without it. For the OP, I had need last year of capturing a traceback and (possibly) displaying it later in ZODB. It never would have occurred to me to try saving away exc_info(), though. Instead I used the `traceback` module to capture the traceback output (a string), which was (possibly) displayed later, with annotations, by a different thread. No cycles, no problems. BTW, I must repeat that there is no simple-minded way to 'repair' this. That isn't based on general principle, but on knowledge of how Python is implemented. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 23:03 Message: Logged In: YES user_id=21627 I disagree that the circular reference is non-obvious. I'm not sure what your application is, but I would expect that callers of sys.exc_info should be fully aware what a traceback is, and how it refers to the current frames. I do agree that it is unavoidable; I fail to see that it is a bug because of that (something unavoidable cannot be a bug). If you are saying that it is unavoidable in your application: I have difficulties believing this. For example, you could do s.e = sys.exc_info()[:2] This would drop the traceback, and thus not create a cyclic reference. Since, in the program you present, the traceback is never used, this looks like a "legal" simplification (of course, you don't use s.e at all in this program, so I can only guess that you don't need the traceback in your real application). As for the time of cleanup not being controllable: you can certainly control frequency of gc with gc.set_threshold; no need to invoke gc explicitly. tim_one: Why do you think your proposed modification of introducing get_traceback would help? The frame foo still refers to s (which is an O), and s.e will still refer to the traceback that includes foo. -- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 17:07 Message
[ python-Bugs-1563243 ] python_d python
Bugs item #1563243, was opened at 2006-09-21 18:20 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: python_d python Initial Comment: I'v added _d to python (python_d.exe) while performing standard tests ... it dies after testInfinitRecursion without any message - just dissapears :( -- >Comment By: SourceForge Robot (sf-robot) Date: 2006-10-26 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 04:15 Message: Logged In: YES user_id=849994 "I'v added _d to python" is not clear to me. Can you give more information? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1580738 ] httplib hangs reading too much data
Bugs item #1580738, was opened at 2006-10-20 05:06 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dustin J. Mitchell (djmitche) Assigned to: Nobody/Anonymous (nobody) Summary: httplib hangs reading too much data Initial Comment: I'm building an interface to Amazon's S3, using httplib. It uses a single object for multiple transactions. What's happening is this: HTTP > PUT /unitest-temp-1161039691 HTTP/1.1 HTTP > Date: Mon, 16 Oct 2006 23:01:32 GMT HTTP > Authorization: AWS <>:KiTWRuq/ 6aay0bI2J5DkE2TAWD0= HTTP > (end headers) HTTP < HTTP/1.1 200 OK HTTP < content-length: 0 HTTP < x-amz-id-2: 40uQn0OCpTiFcX+LqjMuzG6NnufdUk/.. HTTP < server: AmazonS3 HTTP < x-amz-request-id: FF504E8FD1B86F8C HTTP < location: /unitest-temp-1161039691 HTTP < date: Mon, 16 Oct 2006 23:01:33 GMT HTTPConnection.__state before response.read: Idle HTTPConnection.__response: closed? False length: 0 reading response HTTPConnection.__state after response.read: Idle HTTPConnection.__response: closed? False length: 0 ..later in the same connection.. HTTPConnection.__state before putrequest: Idle HTTPConnection.__response: closed? False length: 0 HTTP > DELETE /unitest-temp-1161039691 HTTP/1.1 HTTP > Date: Mon, 16 Oct 2006 23:01:33 GMT HTTP > Authorization: AWS <>: a5OizuLNwwV7eBUhha0B6rEJ+CQ= HTTP > (end headers) HTTPConnection.__state before getresponse: Request-sent HTTPConnection.__response: closed? False length: 0 File "/usr/lib64/python2.4/httplib.py", line 856, in getresponse raise ResponseNotReady() If the first request does not precede it, the second request is fine. To avoid excessive memory use, I'm calling request.read(16384) repeatedly, instead of just calling request.read(). This seems to be key to the problem -- if I omit the 'amt' argument to read(), then the last line of the first request reads HTTPConnection.__response: closed? True length: 0 and the later call to getresponse() doesn't raise ResponseNotReady. Looking at the source for httplib.HTTPResponse.read, self.close() gets called in the latter (working) case, but not in the former (non-working). It would seem sensible to add 'if self.length == 0: self.close()' to the end of that function (and, in fact, this change makes the whole thing work), but this comment makes me hesitant: # we do not use _safe_read() here because this may be a .will_close # connection, and the user is reading more bytes than will be provided # (for example, reading in 1k chunks) I suspect that either (a) this is a bug or (b) the client is supposed to either call read() with no arguments or calculate the proper inputs to read(amt) based on the Content-Length header. If (b), I would think the docs should be updated to reflect that? Thanks for any assistance. -- >Comment By: Mark Hammond (mhammond) Date: 2006-10-27 12:21 Message: Logged In: YES user_id=14198 The correct answer is indeed (b) - but note that httplib will itself do the content-length magic for you, including the correct handling of 'chunked' encoding. If the .length attribute is not None, then that is exactly how many bytes you should read. If .length is None, then either chunked encoding is used (in which case you can call read() with a fixed size until it returns an empty string), or no content-length was supplied (which can be treated the same as chunked, but the connection will close at the end. Checking ob.will_close can give you some insight into that. Its not reasonable to add 'if self.length==0: self.close()' - it is perfectly valid to have a zero byte response within a keep-alive connection - we don't want to force a new (expensive) connection to the server just because a zero byte response was requested. The HTTP semantics are hard to get your head around, but I believe httplib gets it right, and a ResponseNotReady exception in particular points at an error in the code attempting to use the library. Working with connections that keep alive is tricky - you just jump through hoops to ensure you maintain the state of the httplib object correctly - in general, that means you must *always* consume the entire response (even if it is zero bytes) before attempting to begin a new request. This requirement doesn't exists for connections that close - if you fail to read the entire response it can be thrown away as the next request will happen on a new connection. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=15
[ python-Bugs-1570255 ] redirected cookies
Bugs item #1570255, was opened at 2006-10-04 09:37 Message generated for change (Comment added) made by hans_moleman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: hans_moleman (hans_moleman) Assigned to: Nobody/Anonymous (nobody) Summary: redirected cookies Initial Comment: Cookies are not resend when a redirect is requested. Blurb: I've been trying to get a response off a server using Python. The response so far differs from the response using Firefox. In Python, I have set headers and cookies the way Firefox does it. I noticed that the server accepts the POST request, and redirects the client to another address with the result on it. This happens both with Python and Firefox correctly. Cookie handling differs though: The Python client, when redirected, using the standard redirect handler, does not resend its cookies to the redirected address. Firefox does resend the cookies from the original request. When I redefine the redirect handler and code it so that it adds the cookies from the original request, the response is the same as Firefox's response. This confirms then that resending cookies is required to get the server to respond correctly. Is the default Python redirection cookie policy different from Firefox's policy? Could we improve the default redirection handler to work like Firefox? Is it a bug? I noticed an old open bug report 511786, that looks very much like this problem. It suggests it is fixed. Cheers Hans Moleman. -- >Comment By: hans_moleman (hans_moleman) Date: 2006-10-27 17:20 Message: Logged In: YES user_id=1610873 I am using this script to obtain monthly internet usage statistics from my ISP. My ISP provides a screen via HTTPS, to enter a usercode and password, after which the usage statistics are displayed on a different address. I cannot send this script with my usercode and password. My ISP might not like me doing this either. Therefore I'll try to find another server that behaves similarly, and send you that. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 09:16 Message: Logged In: YES user_id=11375 More detail is needed to figure out if there's a problem; can you give a sample URL to exhibit the problem? can you provide your code? From the description, it's unclear if this might be a bug in the handling of redirects or in the CookieProcessor class. The bug in 511786 is still fixed; that bug includes sample code, so I could check it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1580472 ] glob.glob("c:\\[ ]\*) doesn't work
Bugs item #1580472, was opened at 2006-10-19 04:44
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Koblaid (koblaid)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob.glob("c:\\[ ]\*) doesn't work
Initial Comment:
OS: Windows 2000 Service Pack 4
Python 2.5
glob.glob() doesn't work in directories named
"[ ]" (with a blank in it). Another example is a
directory named "A - [Aa-Am]"
Example:
#
C:\>md []
C:\>md "[ ]"
C:\>copy anyfile.txt []
1 Datei(en) kopiert.
C:\>copy anyfile.txt "[ ]"
1 Datei(en) kopiert.
C:\>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import glob
>>> glob.glob ("c:\\[]\*")
['c:\\[]\\anyfile.txt']
>>> glob.glob ("c:\\[ ]\*")
[]
#
The second glob should have resulted the same as the
first glob since I copied the same file to both
directories.
I may be wrong because I'm new to python. But I've
tested it a couple of times, and I think it have to be
a bug of python or a bug of windows.
Greets, Koblaid
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-26 23:14
Message:
Logged In: YES
user_id=341410
This is a known issue with the fnmatch module (what glob
uses under the covers). According to the documentation of
the translate method that converts patterns into regular
expressions... "There is no way to quote meta-characters."
The fact that "[]" works but "[ ]" doesn't work is a
convenient bug, for those who want to use "[]".
If you can come up with some similar but non-ambiguous
syntax to update the fnmatch module, I'm sure it would be
considered, but as-is, I can't see this as a "bug" per-se.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580472&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545696 ] structmember T_LONG won't accept a python long
Bugs item #1545696, was opened at 2006-08-24 07:07
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: structmember T_LONG won't accept a python long
Initial Comment:
An attribute defined as T_LONG throws a vague error
when set to a python long, even when the value is
within the range of a LONG.
TypeError: bad argument type for built-in operation
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-10-27 08:19
Message:
Logged In: YES
user_id=21627
Patch committed, so this is now fixed.
--
Comment By: Roger Upole (rupole)
Date: 2006-08-30 07:06
Message:
Logged In: YES
user_id=771074
Submitted patch 1549049.
--
Comment By: Roger Upole (rupole)
Date: 2006-08-28 04:23
Message:
Logged In: YES
user_id=771074
In the process of creating a patch for this, I came across
some more 'ugh'-liness. T_UINT's are returned via
PyInt_FromLong, so you actually get back a negative value
for large numbers. Changing it to use
PyLong_FromUnsignedLong will break backward compatibility,
but this is so wrong I can't possibly see keeping it. Your
call. (plus it makes it impossible to test T_UINT with
values larger than INT_MAX)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-25 02:52
Message:
Logged In: YES
user_id=33168
Ugh. This code is lax in checking/conversion. Do you think
you could provide a patch?
All of the int cases should call PyInt_AsLong() if this call
fails (returns -1), then that should be returned from
PyMember_SetOne. If it succeeds, there should be a range
check that ensures the value is valid. If that fails a
warning should be produced. We need to issue a warning
rather than an error for backwards compatability (at least
for 2.6).
The float/double cases can be simplified some by calling
PyFloat_AsDouble and doing similar checks as in the int cases.
--
Comment By: Roger Upole (rupole)
Date: 2006-08-24 21:56
Message:
Logged In: YES
user_id=771074
The DEVMODE object from pywintypes has attributes defined
as T_LONG via the structmember API.
>>> import pywintypes
>>> dm=pywintypes.DEVMODEType()
>>> dm.Position_x=3
>>> dm.Position_x
3
>>> dm.Position_x=long(3)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: bad argument type for built-in operation
>>>
Here's the relevant code from structmember.c
that throws the error:
case T_LONG:
if (!PyInt_Check(v)) {
PyErr_BadArgument();
return -1;
}
*(long*)addr = PyInt_AsLong(v);
break;
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 20:30
Message:
Logged In: YES
user_id=33168
Can you provide example code that demonstrates what you mean?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566140 ] T_ULONG -> double rounding in PyMember_GetOne()
Bugs item #1566140, was opened at 2006-09-27 07:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: T_ULONG -> double rounding in PyMember_GetOne() Initial Comment: Problem: Python/structmember.c's PyMember_GetOne currently handles getting T_ULONG members as follows: case T_ULONG: v = PyLong_FromDouble((double) *(unsigned long*)addr); break; On platforms with 64-bit longs, the double won't have enough precision to hold big values without rounding. The fix should be simple: v = PyLong_FromUnsignedLong(*(unsigned long*)addr); -- Piet Delport <[EMAIL PROTECTED]> -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-27 08:19 Message: Logged In: YES user_id=21627 This was fixed with said patch. -- Comment By: �iga Seilnacht (zseil) Date: 2006-09-27 10:56 Message: Logged In: YES user_id=1326842 Patch #1549049: http://www.python.org/sf/1549049 has a fix for this and some other bugs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583276 ] Different behavior when stepping through code w/ pdb
Bugs item #1583276, was opened at 2006-10-23 17:54 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior when stepping through code w/ pdb Initial Comment: The attached test case will raise a NameError when executed in pdb by stepping though the code. The issue is the EnumType name, which is both a local variable in the Enum function which is used in the lambda and the name of an attribute on the EnumValue class. Since it is a local variable used in a lambda, it's a freevar. What apparently happens is on line 5 the property() result is stored in frame->f_locals['EnumType'] but it is deleted the next time FastToLocals is invoked prior to calling back into the debugger. This happens when the freevars values are merged into the locals dictionary. The example is a stripped down version of code in turbogears. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-26 23:23 Message: Logged In: YES user_id=341410 This seems to be a duplicate of http://python.org/sf/1583276 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
