[issue2707] Tiny fix for os.walk docstring
Gregory P. Smith [EMAIL PROTECTED] added the comment: fixed in trunk r62756 and release25-maint r62757. thanks for the report. -- assignee: - gregory.p.smith keywords: +easy nosy: +gregory.p.smith resolution: - fixed status: open - closed versions: +Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2707 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2628] ftplib Persistent data connection
Gregory P. Smith [EMAIL PROTECTED] added the comment: rather than using the array.array for your three byte header with manual parsing, please use struct.unpack. Whats a good way to test that this works? It'd be nice to have a unit test (a test_ftplib_net.py perhaps?) though I realize ftplib currently has poor test coverage with no such explicit network test existing beyond things the urllib tests might do. also, could you make the appropriate documentation updates against python trunk's Doc/lib/ftplib.rst. Mention when what servers you found using this mode useful with if at all possible. -- nosy: +gregory.p.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2628 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] performance problem in socket._fileobject.read
Ralf Schmitt [EMAIL PROTECTED] added the comment: the above easy_install now works for me. thanks. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: On 2008-05-06 00:07, Guido van Rossum wrote: Guido van Rossum [EMAIL PROTECTED] added the comment: On Fri, Apr 18, 2008 at 1:46 AM, Marc-Andre Lemburg [EMAIL PROTECTED] wrote: On 2008-04-18 05:35, atsuo ishimoto wrote: atsuo ishimoto [EMAIL PROTECTED] added the comment: Is a codec which encode() returns an Unicode allowed in Python3? Sure, why not ? Actually, it is not. In Py3k, x.encode() always requires x to be a str (i.e. unicode) instance and return a bytes instance. y.decode() requires y to be a bytes instance and returns a str (i.e. unicode) instance. So you've limited the codec design to just doing Unicode-bytes conversions ? The original codec design was to have the codec decide which types to take on input and to generate on output, e.g. to escape characters in Unicode (converting Unicode to Unicode), work on compressed 8-bit strings (converting 8-bit strings to 8-bit strings), etc. I think you have to ask another question: Is repr() allowed to return a string (instead of Unicode) in Py3k ? In Py3k, strings *are* unicode. The str data type is Unicode. With strings I always refer to 8-bit strings, ie. 8-bit data that is encoded in some encoding. If you're asking about repr() possibly returning a bytes instance, definitely not. If not, then unicode_repr() will have to check the return value of the codec and convert it back to Unicode as necessary. What codec? The idea is to have a codec which takes the Unicode object and converts it to its repr()-value. Now, since you apparently cannot go the direct way anymore (ie. have the codec encode Unicode to Unicode), you'd have to first use a codec which converts the Unicode object to its repr()-value represented as bytes object and then convert the bytes object back to Unicode in unicode_repr(). With the original design, this extra step wouldn't have been necessary. I started to think codec is not nessesary, but python function is enough. That's what we currently have with unicode_repr(), but it doesn't solve the problem. I'm lost here. See my previous replies on this ticket. PS. Atsuo's PEP has now been checked in as PEP 3138. Discussion should start soon on the python-3000 list. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Antoine Pitrou [EMAIL PROTECTED] added the comment: Since nothing happened for almost one month here, perhaps it would be better to merge Alexandre's changes as they are? We'll see quickly if unexpected things happen :-) It would also allow to progress on other issues, e.g. #2523. Also, I stand by the suggestion I made about the resizing logic, but it shouldn't be a showstopper either. We can improve that later. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2756] urllib2 add_header fails with existing unredirected_header
Martin McNickle [EMAIL PROTECTED] added the comment: I decided that the user should have full control over the headers sent. Any call to add_header() or add_redirected_header() will now check if a header with that same name has been set in the Request before (in both the header and the unredirected header dictionaries), and if so overwrite it. The tests run fine with the patch installed, and also included is a patch for the urllib2 documentation. -- keywords: +patch Added file: http://bugs.python.org/file10200/add_header_complete.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2756 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2756] urllib2 add_header fails with existing unredirected_header
Changes by Martin McNickle [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10200/add_header_complete.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2756 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2756] urllib2 add_header fails with existing unredirected_header
Changes by Martin McNickle [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10201/add_header_complete.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2756 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
atsuo ishimoto [EMAIL PROTECTED] added the comment: No need to change anything, the diff is just too big for the code review tool (Rietveld), but since it consists only of numbers we don't need to review it anyway. :) I wonder why unicodename_db.h have not updated after makeunicodedata.py was modified. If new makeunicodedata.py breaks something, I should remove the chage to unicodename_db.h from this patch (My patch works whether unicodename_db.h is updated or not.). I'll post a question to python-3000 list. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Martin McNickle [EMAIL PROTECTED] added the comment: This looks good. I would suggest that the unredirected_hdrs would use the CaseInsensitiveDict too. There is still the problem (from the test documentation) that accessing .headers directly will only show a subset of headers i.e. it won't show any headers from .unredirected_hdrs. Have you any suggestions as to how they both can be accessed from the same interface? The test documentation also says: Note the case normalization of header names here, to .capitalize()-case. This should be preserved for backwards-compatibility. (In the HTTP case, normalization to .title()-case is done by urllib2 before sending headers to httplib). It suggests that capitalize() should be kept for backwards compatibility. I have tested and the headers actually sent to the server are in title()-case even though they are stored in the Request object as captitalize()-case. This would initially suggest that the case-normalization should be removed from the patch. However, as .headers would now be using a case-insensitive dictionary, this would still ensure backwards compatibily. -- nosy: +BitTorment __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2598] { +(}.format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format
Changes by Eric Smith [EMAIL PROTECTED]: -- assignee: - eric.smith nosy: +eric.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2598 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Christian Heimes [EMAIL PROTECTED] added the comment: The Python 3.0 port is going to be tricky. Can somebody with more knowledge about the code please annotate which methods accept/return bytes and/or unicode? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2750 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
New submission from Eric Smith [EMAIL PROTECTED]: Per http://mail.python.org/pipermail/python-3000/2008-April/013094.html, add a PendingDeprecationWarning to 3.0 for % formatting. The attached patch implements this for 3.0. For 2.6, it should only be a PendingDeprecationWarning if -3 warnings are turned on. I'll work on that after the 3.0 patch is accepted. I'm not wild about using a global variable to disallow recursion, but it's probably the way to go. Question: Do I need to acquire the GIL here? Another issue is that the interpreter should probably at least start up without triggering these warnings. I'll add an issue for that at a later date. -- assignee: eric.smith components: Interpreter Core files: percent_formatting_pending_deprecation.diff keywords: easy, patch, patch messages: 66313 nosy: eric.smith priority: normal severity: normal status: open title: Add PendingDeprecationWarning for % formatting versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10202/percent_formatting_pending_deprecation.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Do I need to acquire the GIL here? No, the GIL has already been acquired. The problem with the static variable is that while the main thread is PyErr_WarnEx(), another thread may gain focus. And it will not trigger the warning. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Bob Ippolito [EMAIL PROTECTED] added the comment: loads will take unicode or str. if it's str then it assumes utf-8, otherwise the explicitly specified encoding. All of the string instances generated by loads will be unicode objects (some of them may be str objects if they're all ASCII as an optimization, I'm not sure if I implemented that or not). dumps produces an ASCII str, but if you explicitly specify ensure_ascii=False then it will return a unicode object. obviously load and dump will be working on a file-like object so should be dealing with bytes... I'm not entirely sure whether semantically dumps should produce bytes or str in py3k, I guess whatever the other text-based encodings do is appropriate (e.g. base64, mime). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2750 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Eric Smith [EMAIL PROTECTED] added the comment: Right. But is it worth adding per-thread machinery to this? I was going to do that, but it seemed like overkill. Upon further reflection, however, I think you may be right. I'll remove the easy keyword! -- keywords: -easy __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2773] Wrong description of 'g' conversion type of string formatting operator %
New submission from Artur Zaprzała [EMAIL PROTECTED]: Description of 'g' and 'G' conversion types of string formatting operator at http://www.python.org/doc/2.5.2/lib/typesseq-strings.html is: Floating point format. Uses exponential format if exponent is greater than -4 or less than precision, decimal format otherwise. Should be: Floating point format. Uses exponential format if exponent is less than -4 or not less than precision, decimal format otherwise. -- assignee: georg.brandl components: Documentation messages: 66318 nosy: georg.brandl, zybi severity: normal status: open title: Wrong description of 'g' conversion type of string formatting operator % versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2773 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2774] ctypes documentation not effective
New submission from Bill Janssen [EMAIL PROTECTED]: Once again I'm reading through the ctypes documentation and finding it wildly confusing/contradictory. For instance, there's no discussion of how ctypes types interact with malloc and free. The tutorial section is discursive and rambling. The type c_size_t isn't mentioned in the section labelled Fundamental Data Types, but does show up in another section also labelled Fundamental Data Types. The reference doesn't document the use of pointers or arrays. I find it hard to see how anyone who doesn't read the ctypes code (several times) could find out how to use it from the documentation. I'd suggest getting rid of the Tutorial section, moving it to a standalone document somewhere, and finishing the writing of the Reference section. Adding a chapter discussing when to use ctypes and when to use the C API might also be a good idea. -- assignee: georg.brandl components: Documentation messages: 66319 nosy: georg.brandl, janssen priority: normal severity: normal status: open title: ctypes documentation not effective type: performance versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2774 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1674032] Make threading.Event().wait(timeout=3) return isSet
Changes by Tim Lesher [EMAIL PROTECTED]: -- assignee: - georg.brandl components: +Documentation, Library (Lib) -Interpreter Core nosy: +georg.brandl _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1674032 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2774] ctypes documentation not effective
Changes by Georg Brandl [EMAIL PROTECTED]: -- assignee: georg.brandl - theller nosy: +theller __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2774 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2630] repr() should not escape non-ASCII characters
Guido van Rossum [EMAIL PROTECTED] added the comment: On Tue, May 6, 2008 at 1:26 AM, Marc-Andre Lemburg wrote: So you've limited the codec design to just doing Unicode-bytes conversions ? Yes. This was quite a conscious decision that was not taken lightly, with lots of community input, quite a while ago. The original codec design was to have the codec decide which types to take on input and to generate on output, e.g. to escape characters in Unicode (converting Unicode to Unicode), work on compressed 8-bit strings (converting 8-bit strings to 8-bit strings), etc. Unfortunately this design made it hard to reason about the correctness of code, since (especially in Py3k, where bytes and str are more different than str and unicode were in 2.x) it's hard to write code that uses .encode() or .decode() unless it knows which codec is being used. IOW, when translated to 3.0, the design violates the general design principle that the *type* of a function's or method's return value should not depend on the *value* of one of the arguments. I think you have to ask another question: Is repr() allowed to return a string (instead of Unicode) in Py3k ? In Py3k, strings *are* unicode. The str data type is Unicode. With strings I always refer to 8-bit strings, ie. 8-bit data that is encoded in some encoding. You will have to change this habit or you will thoroughly confuse both users and developers of 3.0. String refers to the built-in str type which in Py3k is PyUnicode. For the PyString type we use the built-in type bytes. If you're asking about repr() possibly returning a bytes instance, definitely not. If not, then unicode_repr() will have to check the return value of the codec and convert it back to Unicode as necessary. What codec? The idea is to have a codec which takes the Unicode object and converts it to its repr()-value. Now, since you apparently cannot go the direct way anymore (ie. have the codec encode Unicode to Unicode), you'd have to first use a codec which converts the Unicode object to its repr()-value represented as bytes object and then convert the bytes object back to Unicode in unicode_repr(). With the original design, this extra step wouldn't have been necessary. Why does everything have to be a codec? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2773] Wrong description of 'g' conversion type of string formatting operator %
Georg Brandl [EMAIL PROTECTED] added the comment: Thanks, fixed in r62774. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2773 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2773] Wrong description of 'g' conversion type of string formatting operator %
Artur Zaprzała [EMAIL PROTECTED] added the comment: The fix is wrong. not less == greater than or equal to __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2773 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2773] Wrong description of 'g' conversion type of string formatting operator %
Georg Brandl [EMAIL PROTECTED] added the comment: Argh, fixed in r62775. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2773 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1674032] Make threading.Event().wait(timeout=3) return isSet
Georg Brandl [EMAIL PROTECTED] added the comment: Tim, you said this was a bad idea for conditions in #1175933 - is the same true for Events? -- assignee: georg.brandl - tim_one nosy: +tim_one _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1674032 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Brett Cannon [EMAIL PROTECTED] added the comment: Alexandre, you have until the end of the week to commit it or someone else will. =) I don't want this going in so close to the alphas, but it should go in almost immediately afterwards. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
New submission from Brett Cannon [EMAIL PROTECTED]: This is to keep track of who is working on what for PEP 3108 (http://www.python.org/dev/peps/pep-3108/). Once something is complete it should be denoted in the PEP itself, so always check the PEP to see what is left to be done (for both 2.6 and 3.0). -- components: Library (Lib) messages: 66326 nosy: brett.cannon priority: critical severity: normal status: open title: Implement PEP 3108 type: behavior versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Changes by Brett Cannon [EMAIL PROTECTED]: -- assignee: - brett.cannon __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Antoine Pitrou [EMAIL PROTECTED] added the comment: By the way, is someone already working on a C-accelerated TextIO? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2523] binary buffered reading is quadratic
Changes by Alexandre Vassalotti [EMAIL PROTECTED]: -- nosy: +alexandre.vassalotti __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2523 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: Patch committed in r62778. Antoine wrote: Also, I stand by the suggestion I made about the resizing logic, but it shouldn't be a showstopper either. We can improve that later. I made your suggested change to the resizing logic. Thanks again for the review! By the way, is someone already working on a C-accelerated TextIO? Yes. I was waiting to commit the C optimization for io.BytesIO, before continuing the one for io.StringIO. The implementation is mostly done---it just needs to be updated with respect to the recent changes to TextIO. -- assignee: - alexandre.vassalotti resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779700] urlparse.urljoin does not obey current uri rfc (rfc 3986)
Georg Brandl [EMAIL PROTECTED] added the comment: Closing then. -- nosy: +georg.brandl resolution: - duplicate status: open - closed superseder: - update urlparse to RFC 3986 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1779700 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Jeremy Hylton [EMAIL PROTECTED] added the comment: I'm working on the new urllib package. -- nosy: +jhylton __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2750] Add simplejson to Python 2.6/3.0 standard library
Christian Heimes [EMAIL PROTECTED] added the comment: Since dumps and loads deal with raw data they should accept/return bytes, too. I'm re-adding 2.6 as version again because I believe we should clean up the API in 2.6 first. It's also a good chance to document how to port a library to Python 2.6 and 3.0. *wink* -- versions: +Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2750 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2152] make sqlite.Row hashable correctly
Georg Brandl [EMAIL PROTECTED] added the comment: Can this be closed? -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2152 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1591035] update urlparse to RFC 3986
Changes by Georg Brandl [EMAIL PROTECTED]: -- assignee: - jhylton nosy: +jhylton _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1591035 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Benjamin Peterson [EMAIL PROTECTED] added the comment: Would it be practical to add a _PyErr_InErrorProcessing function to prevent recursion? -- nosy: +benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2776] urllib2.urlopen() gets confused with path with // in it
New submission from Ambarish Malpani [EMAIL PROTECTED]: Try the following code: import urllib import urllib2 url = 'http://features.us.reuters.com//autos/news/95ED98EE-A837-11DC-BCB3-4F218271.html' data = urllib.urlopen(url).read() data2 = urllib2.urlopen(url).read() The attempt to get it with urllib works fine. With urllib2, the request is malformed and I get back a HTTP 404 Request in the 2nd case is: GET //autos/news/95ED98EE-A837-11DC-BCB3-4F218271.html HTTP/1.1\r\n Accept-Encoding: identity\r\n Host: autos\r\n Connection: close\r\n The host line seems to be looking for the last // rather than the first. -- components: Extension Modules messages: 66334 nosy: ambarish severity: normal status: open title: urllib2.urlopen() gets confused with path with // in it type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2776 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2776] urllib2.urlopen() gets confused with path with // in it
Ambarish Malpani [EMAIL PROTECTED] added the comment: Sorry, should have added another line: The reason this is important to fix, is I am getting that URL with a // in a Moved (HTTP 302) message, so I can't just get rid of the // __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2776 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Eric Smith [EMAIL PROTECTED] added the comment: Since we're just trying to prevent this function from recursing (indirectly) into itself, I think all of the logic can go here. What would you suggest the function _PyErr_InErrorProcessing do differently? I think the real issue is: Does the additional logic and execution time involved in adding per-thread state justify being more correct, or can we occasionally lose a warning message? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Tue, May 6, 2008 at 4:50 PM, Eric Smith [EMAIL PROTECTED] wrote: Eric Smith [EMAIL PROTECTED] added the comment: Since we're just trying to prevent this function from recursing (indirectly) into itself, I think all of the logic can go here. What would you suggest the function _PyErr_InErrorProcessing do differently? I was just thinking that this problem would probably come up again. I think the real issue is: Does the additional logic and execution time involved in adding per-thread state justify being more correct, or can we occasionally lose a warning message? Well, the first thing to check for is Py_Py3kWarning. Then do the extra logic and execution speed. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2637] urllib.quote() escapes characters unnecessarily and contrary to docs
Tom Pinckney [EMAIL PROTECTED] added the comment: It also looks like urllib.quote (and quote_plus) do not properly handle unicode strings. urllib.urlencode() properly converts unicode strings to utf-8 encoded ascii strings before then calling urllib.quote() on them. -- nosy: +thomaspinckney3 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2637 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Benjamin Peterson [EMAIL PROTECTED] added the comment: I'm working on removing mac modules. -- nosy: +benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Brett Cannon [EMAIL PROTECTED] added the comment: I am working on audiodev to get the basic structure of removals worked out (testing infrastructure, etc.). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Brett Cannon [EMAIL PROTECTED] added the comment: For the TextMate users, I am going to be checking in a Python-Dev bundle into svn soon which will include a command to insert the warnpy3k() call for module deletions. Might want to wait for that if you want to cut out at least one copy-and-paste step. =) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2776] urllib2.urlopen() gets confused with path with // in it
Martin McNickle [EMAIL PROTECTED] added the comment:
The problem lines are in AbstractHTTPHandler.do_request():
scheme, sel = splittype(request.get_selector())
sel_host, sel_path = splithost(sel)
if not request.has_header('Host'):
request.add_unredirected_header('Host', sel_host or host)
When there is a double '/' sel is something like '//path/to/resource'.
splithost(sel) then gives ('path', '/to/resource'). Therefore the
header 'Host' gets set to 'path'.
I don't understand why sel_host is used in preference for host. host
holds the correct value, even with the double slashes. Could someone
explain why sel_host is used at all?
--
nosy: +BitTorment
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2776
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2776] urllib2.urlopen() gets confused with path with // in it
Changes by Martin McNickle [EMAIL PROTECTED]: -- components: +Library (Lib) -Extension Modules versions: +Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2776 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2507] Exception state lives too long in 3.0
Collin Winter [EMAIL PROTECTED] added the comment: Looks good to me. Antoine, do you have commit privileges? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2507 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
Collin Winter [EMAIL PROTECTED] added the comment: I believe you forgot to add fix_operator.py to this patch. -- components: +Build, Demos and Tools, Distutils, Documentation, Documentation tools (Sphinx), Extension Modules, IDLE, Installation, Interpreter Core, Library (Lib), Macintosh, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML, ctypes __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2370 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
Changes by Collin Winter [EMAIL PROTECTED]: -- components: -Build, Demos and Tools, Distutils, Documentation, Documentation tools (Sphinx), IDLE, Installation, Interpreter Core, Library (Lib), Macintosh, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML, ctypes __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2370 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Eric Smith [EMAIL PROTECTED] added the comment: Well, the first thing to check for is Py_Py3kWarning. Then do the extra logic and execution speed. In 3.0, it's always a PendingDeprecationWarning, so that won't work. The test needs to be: if not recursing and warning_is_not_suppressed: warn() The recursion test is expensive if using thread local storage; the warning suppressed test looks expensive, too. So there's no quick short circuit test that I see. Of course all of this is just hot air until coded and benchmarked. I'll cook up a patch, but it will probably not be ready before the next alpha releases. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2777] subprocess unit tests for kill, term and send_signal flaky
New submission from Christian Heimes [EMAIL PROTECTED]: The unit tests for the kill, term and send_signal methods of the subprocess.Popen object are still flaky and sometimes cause the test suite to hang. I'm going to disable them for the upcoming alpha until I've found a better solution. -- assignee: christian.heimes components: Tests messages: 66347 nosy: christian.heimes priority: critical severity: normal status: open title: subprocess unit tests for kill, term and send_signal flaky type: behavior versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2777 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Brett Cannon [EMAIL PROTECTED] added the comment: If you use TextMate, get the Python-Dev bundle and use the command in there to insert the deprecation boilerplate for removing a module. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Changes by Brett Cannon [EMAIL PROTECTED]: -- keywords: +easy __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2778] set_swap_bodies is unsafe
New submission from Adam Olsen [EMAIL PROTECTED]: set_swap_bodies() is used to cheaply create a frozenset from a set, which is then used for lookups within a set. It does this by creating a temporary empty frozenset, swapping its contents with the original set, doing the lookup using the frozenset, then swapping the contents back and releasing the temporary frozenset. Unfortunately, the lookup can invoke arbitrary code, which may examine the original set and find it empty (until the lookup completes). The lookup may also save a reference to the temporary frozenset, which mutates to being empty after the lookup completes. The purpose seems to be allowing someset in someotherset to automatically convert someset to a frozenset. A brief search didn't reveal a rationale for this, and in fact PEP 218's history section claims the opposite: Auto-conversion between mutable and immutable sets was dropped. Perhaps this is a forgotten vestige of that? set_intersection_update uses set_swap_bodies for a different purpose and it may be safe. It depends on whether subclasses of set may retain a reference to the tmp set somehow. -- files: brokensetswap.py messages: 66349 nosy: Rhamphoryncus severity: normal status: open title: set_swap_bodies is unsafe type: behavior Added file: http://bugs.python.org/file10204/brokensetswap.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2778 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2778] set_swap_bodies is unsafe
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - rhettinger nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2778 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2772] Add PendingDeprecationWarning for % formatting
Neal Norwitz [EMAIL PROTECTED] added the comment: Why not use the normal recursion check mechanism? Specifically, if (Py_EnterRecursiveCall(unicode % )) return NULL; // err = Warn(); Py_LeaveRecursiveCall(); I don't see where the problem with threads comes in. The GIL is held and shouldn't be released during this call. That may not be quite true (it's conceivable the GIL is released when warning). I'm not sure what happens with the I/O system at this point, it's possible that releases the GIL. However, if GIL is released and re-acquired in PyWarn_WarnEx() there are probably bigger issues than this patch that will need to be addressed. Note that since the warnings module is now implemented in C, this should be easier to deal with. Using the macros above in essence uses TLS, but through Python's PyThreadState. -- nosy: +nnorwitz __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
Changes by Jeff Balogh [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9779/issue2370.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2370 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
Jeff Balogh [EMAIL PROTECTED] added the comment: doh! Attaching a new patch that actually contains a fixer. Added file: http://bugs.python.org/file10205/issue2370.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2370 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
Changes by Jeff Balogh [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9787/operator-warnings.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2370 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
Jeff Balogh [EMAIL PROTECTED] added the comment: Updating the deprecation warnings patch to use PyErr_WarnPy3k and apply correctly against current trunk. Added file: http://bugs.python.org/file10206/operator-warnings.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2370 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
