[issue3210] subprocess.Popen does not release process handles if process cannot be started
Changes by Hirokazu Yamamoto [EMAIL PROTECTED]: -- nosy: +ocean-city ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3514] pickle segfault with infinite loop in __getattr__
New submission from Erick Tryzelaar [EMAIL PROTECTED]:
I found a segfault in pickle.load when you overload __getattr__ and
create yourself a infinite loop in the latest svn checkout of python 3:
import pickle
class Foo:
def __getattr__(self, key):
self.foo
with open('foo.db', 'wb') as f:
foo = Foo()
pickle.dump(foo, f)
with open('foo.db', 'rb') as f:
pickle.load(f)
This results in this stack trace on my mac:
Reason: KERN_PROTECTION_FAILURE at address: 0x000c
0xdc6b in PyObject_Call (func=0x0, arg=0x44cd58, kw=0x0) at
Objects/abstract.c:2174
2174if ((call = func-ob_type-tp_call) != NULL) {
(gdb) bt
#0 0xdc6b in PyObject_Call (func=0x0, arg=0x44cd58, kw=0x0) at
Objects/abstract.c:2174
#1 0x004c1b4d in unpickler_call (self=0x4a6240, func=0x0, arg=0x4b66c8)
at /Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:413
#2 0x004cac9a in load_build (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:3844
#3 0x004cbb4f in load (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:4047
#4 0x004cbe71 in Unpickler_load (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:4119
#5 0x000f2fef in call_function (pp_stack=0xbfffea84, oparg=0) at
Python/ceval.c:3387
#6 0x000edfdb in PyEval_EvalFrameEx (f=0x326cd8, throwflag=0) at
Python/ceval.c:2205
#7 0x000f157e in PyEval_EvalCodeEx (co=0x4a9628, globals=0x487f50,
locals=0x0, args=0x32593c, argcount=1, kws=0x325940, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x4b6428, closure=0x0) at
Python/ceval.c:2840
#8 0x000f39e5 in fast_function (func=0x4b4ab8, pp_stack=0xbfffee54,
n=1, na=1, nk=0) at Python/ceval.c:3501
#9 0x000f35cf in call_function (pp_stack=0xbfffee54, oparg=1) at
Python/ceval.c:3424
#10 0x000edfdb in PyEval_EvalFrameEx (f=0x3257f8, throwflag=0) at
Python/ceval.c:2205
#11 0x000f157e in PyEval_EvalCodeEx (co=0x444c28, globals=0x255818,
locals=0x255818, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2840
#12 0x000e564f in PyEval_EvalCode (co=0x444c28, globals=0x255818,
locals=0x255818) at Python/ceval.c:519
#13 0x00122a96 in run_mod (mod=0x872c80, filename=0xb228 foo.py,
globals=0x255818, locals=0x255818, flags=0xb628, arena=0x322020) at
Python/pythonrun.c:1553
#14 0x00122884 in PyRun_FileExFlags (fp=0xa00dcde0, filename=0xb228
foo.py, start=257, globals=0x255818, locals=0x255818, closeit=1,
flags=0xb628) at Python/pythonrun.c:1510
#15 0x00120e39 in PyRun_SimpleFileExFlags (fp=0xa00dcde0,
filename=0xb228 foo.py, closeit=1, flags=0xb628) at
Python/pythonrun.c:1048
#16 0x001202f9 in PyRun_AnyFileExFlags (fp=0xa00dcde0,
filename=0xb228 foo.py, closeit=1, flags=0xb628) at
Python/pythonrun.c:845
#17 0x00134d1c in Py_Main (argc=2, argv=0x227028) at Modules/main.c:592
#18 0x2574 in main (argc=2, argv=0xb748) at python.c:57
It seems that this isn't just for infinite loops. If you replace the
class with this:
class Foo:
def __init__(self):
self.foo = {}
def __getattr__(self, key):
self.foo[5]
It still errors out. So I'm guessing pickle is just not handling
exceptions properly.
--
components: Library (Lib)
messages: 70815
nosy: erickt
severity: normal
status: open
title: pickle segfault with infinite loop in __getattr__
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3514
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3515] refcount gc bug?
New submission from Hirokazu Yamamoto [EMAIL PROTECTED]: I'm not sure this is bug or not, but shouldn't `io' be collected by refcount GC? This happens on python2.5 but doesn't happend on python3.0. import os def foo(): io = open(a.txt, w) raise RuntimeError() try: foo() except: pass os.remove(a.txt) # WindowsError (Error32) # Process cannot access to the file. # Another process is using it. -- messages: 70816 nosy: ocean-city severity: normal status: open title: refcount gc bug? versions: Python 2.5, Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3515] refcount gc bug?
Martin v. Löwis [EMAIL PROTECTED] added the comment: The interpreter holds onto sys.exc_traceback even after the except block. This refers to the frame, which refers to the file object. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288615] Python code.interact() and UTF-8 locale
Changes by Antoine Pitrou [EMAIL PROTECTED]: -- keywords: +patch nosy: +pitrou type: - behavior versions: -Python 2.3, Python 2.4, Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1288615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: Dear GvR, New code review comments by mgiuca have been published. Please go to http://codereview.appspot.com/2827 to read them. Message: Hi Guido, Thanks very much for this very detailed review. I've replied to the comments. I will make the changes as described below and send a new patch to the tracker. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3515] refcount gc bug?
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: Hmm, when exception occurs in some frame, its reference will be retained even after exiting function? Indeed, extra exception fixed problem. import os def foo(): io = open(a.txt, w) raise RuntimeError() try: foo() except: pass try: raise RuntimeError() except: pass os.remove(a.txt) # fine But still I'm little confused why this code prints del. class A: def __del__(self): print del def foo(): a = A() raise RuntimeError() try: foo() except: pass I found this behavior when investigating issue3210. When Lib/subprocess.py (814)'s CreateProcess() raises exception, p2cread will be freed by refcount GC, it never happen before os.remove(). And this error is also fixed by same hack. import subprocess, os file = open(filename, w) try: proc = subprocess.Popen(nosuchprogram, stdout=file) except OSError: pass try: raise RuntimeError() # hack except: pass file.close() os.remove(filename) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3515] refcount gc bug?
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: But still I'm little confused why this code prints del. Oh, sorry, kick me. del should be printed when interpreter exits. :-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3515] refcount gc bug?
Martin v. Löwis [EMAIL PROTECTED] added the comment: Hmm, when exception occurs in some frame, its reference will be retained even after exiting function? Correct. When a traceback is produced, all frames get linked, be able to print later the traceback with source code information. Each frame keeps all its local variables. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3516] string formatting quirk using %.%
New submission from nadav [EMAIL PROTECTED]: %.%s % () '%s' %(a).%(b)s % dict(a=2) '%(b)s' %(a).%(b)s % dict(a=2, b=3) '%(b)s' %(a).%(b)s % dict() Traceback (most recent call last): File pyshell#6, line 1, in -toplevel- %(a).%(b)s % dict() KeyError: 'a' this is counter intuitive and cannot be deduced from the documentation. -- components: Interpreter Core messages: 70822 nosy: blop severity: normal status: open title: string formatting quirk using %.% type: behavior ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3515] refcount gc bug?
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: I understand. Thank you. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: A reply to a point on GvR's review, I'd like to open for discussion. This relates to whether or not quote's safe argument should allow non-ASCII characters. Using errors='ignore' seems like a mistake -- it will hide errors. I also wonder why safe should be limited to ASCII though. The reasoning is this: if we allow non-ASCII characters to be escaped, then we allow quote to generate invalid URIs (URIs are only allowed to have ASCII characters). It's one thing for unquote to accept such URIs, but I think we shouldn't be producing them. Albeit, it only produces an invalid URI if you explicitly request it. So I'm happy to make the change to allow any character to be safe, but I'll let it go to discussion first. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3515] refcount gc bug?
Antoine Pitrou [EMAIL PROTECTED] added the comment: You don't need to raise another exception, calling sys.exc_clear() should be fine. But a cleaner way to write your example is: def foo(): with open(a.txt, w) as io: raise RuntimeError() with will automatically close the file when the block exits. If you are concerned with Python 2.5 compatibility, use try: ... finally: instead. And, you're right, the problem doesn't occur at all in Python 3.0 because the exception is cleaned up after the end of the except: block catching it. -- nosy: +pitrou resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3210] subprocess.Popen does not release process handles if process cannot be started
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: Hello. I had lecture about exception frames on issue3515. When Lib/subprocess.py (814)'s CreateProcess() raises exception, p2cread will be freed by refcount GC, but it never happen before os.remove() because sys.exc_traceback holds reference to frame which has p2cread. import subprocess, os file = open(filename, w) try: proc = subprocess.Popen(nosuchprogram, stdout=file) except OSError: pass try: raise RuntimeError() # hack to clear previous exc_traceback except: pass file.close() os.remove(filename) # runs fine So, I think subprocess module's practice which relys on refcount GC is not good. (p2cread is PC/_subprocess.c 's sp_handle_object, so automatically freed by refcount GC) I don't think attached adhok.patch is enough, but seems to fix this issue at least. -- keywords: +patch Added file: http://bugs.python.org/file11068/adhok.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3210] subprocess.Popen does not release process handles if process cannot be started
Changes by Hirokazu Yamamoto [EMAIL PROTECTED]: ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le jeudi 07 août 2008 à 13:42 +, Matt Giuca a écrit : The reasoning is this: if we allow non-ASCII characters to be escaped, then we allow quote to generate invalid URIs (URIs are only allowed to have ASCII characters). It's one thing for unquote to accept such URIs, but I think we shouldn't be producing them. Albeit, it only produces an invalid URI if you explicitly request it. So I'm happy to make the change to allow any character to be safe, but I'll let it go to discussion first. The important is that the defaults are safe. If users want to override the defaults and produce potentially invalid URIs, there is no reason to discourage them. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3513] test_multiprocessing hangs without this patch on win2k
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: I'll close this entry because this seems to be duplicate of issue3270. -- resolution: - duplicate status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: The important is that the defaults are safe. If users want to override the defaults and produce potentially invalid URIs, there is no reason to discourage them. OK I think that's a fairly valid argument. I'm about to head off so I'll post the patch I have now, which fixes most of the other concerns. That change will cause havoc to quote I think ;) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Martin v. Löwis [EMAIL PROTECTED] added the comment: The patch is fine, please apply (also to the 2.5 and 3.0 branches). Don't forget a Misc/NEWS entry. -- assignee: loewis - schuppenies resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1342811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3270] test_multiprocessing: test_listener_client flakiness
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: Hello. I also experienced test_multiprocessing hang on win2k and I workarounded this by this adhok patch. Index: Lib/multiprocessing/connection.py === --- Lib/multiprocessing/connection.py (revision 65551) +++ Lib/multiprocessing/connection.py (working copy) @@ -217,7 +217,12 @@ self._socket.listen(backlog) address = self._socket.getsockname() if type(address) is tuple: -address = (socket.getfqdn(address[0]),) + address[1:] +def getfqdn(s): # ??? +if s == '127.0.0.1': +return 'localhost' +else: +return socket.getfqdn(s) +address = (getfqdn(address[0]),) + address[1:] self._address = address self._family = family self._last_accepted = None I'm not familiar to socket, so probably this info is useless. ;-) -- nosy: +ocean-city ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3270 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: Following Guido and Antoine's reviews, I've written a new patch which fixes *most* of the issues raised. The ones I didn't fix I have noted below, and commented on the review site (http://codereview.appspot.com/2827/). Note: I intend to address all of these issues after some discussion. Outstanding issues raised by the reviews: Doc/library/urllib.parse.rst: Should unquote accept a bytes/bytearray as well as a str? Lib/email/utils.py: Should encode_rfc2231 with charset=None accept strings with non-ASCII characters, and just encode them to UTF-8? Lib/test/test_http_cookiejar.py: Does RFC 2965 let me get away with changing the test case to expect UTF-8? (I'm pretty sure it doesn't care what encoding is used). Lib/test/test_urllib.py: Should quote raise a TypeError if given a bytes with encoding/errors arguments? (Motivation: TypeError is what you usually raise if you supply too many args to a function). Lib/urllib/parse.py: (As discussed above) Should quote accept safe characters outside the ASCII range (thereby potentially producing invalid URIs)? -- Commit log for patch8: Fix for issue 3300. urllib.parse.unquote: Added encoding and errors optional arguments, allowing the caller to determine the decoding of percent-encoded octets. As per RFC 3986, default is utf-8 (previously implicitly decoded as ISO-8859-1). Also fixed a bug in which mixed-case hex digits (such as %aF) weren't being decoded at all. urllib.parse.quote: Added encoding and errors optional arguments, allowing the caller to determine the encoding of non-ASCII characters before being percent-encoded. Default is utf-8 (previously characters in range(128, 256) were encoded as ISO-8859-1, and characters above that as UTF-8). Also characters/bytes above 128 are no longer allowed to be safe. Also now allows either bytes or strings. Added functions urllib.parse.quote_from_bytes, urllib.parse.unquote_to_bytes. All quote/unquote functions now exported from the module. Doc/library/urllib.parse.rst: Updated docs on quote and unquote to reflect new interface, added quote_from_bytes and unquote_to_bytes. Lib/test/test_urllib.py: Added many new test cases testing encoding and decoding Unicode strings with various encodings, as well as testing the new functions. Lib/test/test_http_cookiejar.py, Lib/test/test_cgi.py, Lib/test/test_wsgiref.py: Updated and added test cases to deal with UTF-8-encoded URIs. Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote with encoding=latin-1, to preserve existing behaviour (which the whole email module is dependent upon). Added file: http://bugs.python.org/file11069/parse.py.patch8 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: I'm also attaching a metapatch - diff from patch 7 to patch 8. This is to give a rough idea of what I changed since the review. (Sorry - This is actually a diff between the two patches, so it's pretty hard to read. It would have been nicer to diff the files themselves but I'm not doing local commits so that's hard. Can one use the Bazaar mirror for development, or is it too out-of-date?) Added file: http://bugs.python.org/file11070/parse.py.metapatch8 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3512] Change fsync to use fullfsync on platforms (like OS X) that have/need it
Guido van Rossum [EMAIL PROTECTED] added the comment: IMO it would be better not to confuse matters my having os.fsync() call fullfsync(); it's better to add a separate os.fullfsync() call on platforms that support it. That way the application can choose. I suppose Apple had a reason for changing the behavior... -- nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3514] pickle segfault with infinite loop in __getattr__
Guido van Rossum [EMAIL PROTECTED] added the comment: Does this occur in 2.6 or 2.5? -- nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3514 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3514] pickle segfault with infinite loop in __getattr__
Erick Tryzelaar [EMAIL PROTECTED] added the comment:
Guido van Rossum [EMAIL PROTECTED] added the comment:
Does this occur in 2.6 or 2.5?
It doesn't in python 2.5. The RuntimeError manages to get printed out.
I don't have 2.6 installed to test against at the moment. Here's the
equivalent code:
import pickle
class Foo:
def __getattr__(self, key):
self.foo
f = open('foo.db', 'w')
foo = Foo()
pickle.dump(foo, f)
f.close()
f = open('foo.db', 'r')
pickle.load(f)
f.close()
This also happens with cPickle.
--
nosy: +idadesub
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3514
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3516] string formatting quirk using %.%
Guido van Rossum [EMAIL PROTECTED] added the comment: It's straightforward if you consider the implementation of the requirement that %% renders a single percent sign: the second % is parsed just like any other formatting code (i, d, f, etc.) and the stuff between the first % and the formatting code is treated completely uniformly. -- nosy: +gvanrossum resolution: - rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3512] Change fsync to use fullfsync on platforms (like OS X) that have/need it
Guido van Rossum [EMAIL PROTECTED] added the comment: Based on discussion in python-dev, I'm rejecting this patch. Open a new one if you want to make F_FULLSYNC available. -- resolution: - rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Guido van Rossum [EMAIL PROTECTED] added the comment: On Thu, Aug 7, 2008 at 8:03 AM, Matt Giuca [EMAIL PROTECTED] wrote: Matt Giuca [EMAIL PROTECTED] added the comment: I'm also attaching a metapatch - diff from patch 7 to patch 8. This is to give a rough idea of what I changed since the review. (Sorry - This is actually a diff between the two patches, so it's pretty hard to read. It would have been nicer to diff the files themselves but I'm not doing local commits so that's hard. Can one use the Bazaar mirror for development, or is it too out-of-date?) A much better way to do this would be to use Rietveld; it can show deltas between patch sets that are actually readable, and it keeps the inline comments. I've uploaded your patch #8 to the issue I created there, and you can see the delta from patch7 starting here: http://codereview.appspot.com/2827/diff2/1:17/27 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3516] string formatting quirk using %.%
nadav [EMAIL PROTECTED] added the comment: The main problem with this is that the following code does not make any sense: %(a)% % dict(a=3) It has no semantic meaning (take the dictionary paramater a, and do nothing with it). It must be a user bug (except in very wierd cases). I agree that when I consider the implementaion, it makes sense, but as a python user, this behavior is really non-intuitive. 2008/8/7 Guido van Rossum [EMAIL PROTECTED] Guido van Rossum [EMAIL PROTECTED] added the comment: It's straightforward if you consider the implementation of the requirement that %% renders a single percent sign: the second % is parsed just like any other formatting code (i, d, f, etc.) and the stuff between the first % and the formatting code is treated completely uniformly. -- nosy: +gvanrossum resolution: - rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3516 ___ Added file: http://bugs.python.org/file11071/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3516 ___div dir=ltrThe main problem with this is that the following code does not make any sense:brquot;%(a)%quot; % dict(a=3)brbrIt has no semantic meaning (take the dictionary paramater a, and do nothing with it).br It must be a user bug (except in very wierd cases).brbrI agree that when I consider the implementaion, it makes sense, but as a python user, this behavior is really non-intuitive.brbrdiv class=gmail_quote2008/8/7 Guido van Rossum span dir=ltrlt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;/spanbr blockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;br Guido van Rossum lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br It#39;s straightforward if you consider the implementation of thebr requirement that %% renders a single percent sign: the second % isbr parsed just like any other formatting code (i, d, f, etc.) and the stuffbr between the first % and the formatting code is treated completely uniformly.br br --br nosy: +gvanrossumbr resolution: nbsp;-gt; rejectedbr status: open -gt; closedbr divdiv/divdiv class=Wj3C7cbr ___br Python tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue3516; target=_blankhttp://bugs.python.org/issue3516/agt;br ___br /div/div/blockquote/divbr/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3517] PATCH - Providing fullfsync on supported platforms
New submission from Ian Charnas [EMAIL PROTECTED]: Python currently provides os.fsync to call the POSIX 'fsync' on platforms that support it. While this function forces the operating system to force a file buffer to the storage device, data may still be waiting in the hardware write buffers on the storage device. Certain platforms (so far, only OS X) provide fullfsync [1] to request that storage devices flush their write buffers to the actual physical media. This functionality is especially useful to VCS and DB developers, and already appears in SQLite [2] and MySQL [3], amongst others. This patch includes code changes to Modules/posixmodule.c that exposes os.fullfsync on supported platforms, including the appropriate documentation added to Doc/library/os.rst -Ian Charnas [1] Discussion of fsync and fullfsync on darwin platform: http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html [2] SQLite uses fullfsync on all platforms that define it: http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c [3] MySQL uses fullfsync only on the darwin platform and only when F_FULLFSYNC is defined as 51, which seems to be short-sighted in that this symbol may change value in future versions of OS X. To see this code, download a mysql 5.x source snapshot and open up mysql-version-number/innobase/os/os0file.c -- components: Library (Lib) files: fullfsync.patch keywords: patch messages: 70842 nosy: icharnas severity: normal status: open title: PATCH - Providing fullfsync on supported platforms type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file11072/fullfsync.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3512] Change fsync to use fullfsync on platforms (like OS X) that have/need it
Ian Charnas [EMAIL PROTECTED] added the comment: Done. See 3517 http://bugs.python.org/issue3517 On Thu, Aug 7, 2008 at 12:53 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] added the comment: Based on discussion in python-dev, I'm rejecting this patch. Open a new one if you want to make F_FULLSYNC available. -- resolution: - rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3512 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3518] multiprocessing: BaseManager.from_address documented but doesn't exist
New submission from Mark Dickinson [EMAIL PROTECTED]: The BaseManager.from_address method is documented at: http://docs.python.org/dev/library/multiprocessing.html#multiprocessing.ma nagers.BaseManager.from_address but it looks as though this method doesn't actually exist. In contrast, the BaseManager.connect method appears to be necessary for making remote connections, but is not documented. -- assignee: jnoller components: Documentation messages: 70844 nosy: jnoller, marketdickinson severity: normal status: open title: multiprocessing: BaseManager.from_address documented but doesn't exist versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3518 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3516] string formatting quirk using %.%
Georg Brandl [EMAIL PROTECTED] added the comment: I'd rather see it this way: It is a programming error if a format string contains a reference to a nonexisting dictionary key, no matter what formatting specifier is used. The implementation is quite consistent here. -- nosy: +georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1717] Get rid of more refercenes to __cmp__
Georg Brandl [EMAIL PROTECTED] added the comment: Additionally, there are still lots of references to __cmp__ in the library which should be ripped out. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3517] PATCH - Providing fullfsync on supported platforms
Guido van Rossum [EMAIL PROTECTED] added the comment: I'm sorry to have lead you this way, but since there is no fullfsync() system call, IMO you should just make the F_FULLFSYNC constant available. That should go into fcntlmodule.c. -- nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346874] httplib simply ignores CONTINUE
Rick Harris [EMAIL PROTECTED] added the comment: I'm implemented the behavior described by Mike above with a patch to 2.6. The patch will raise an ExpectationFailed before sending the body if the server responds with a 417 (Expectation Failed). This patch should only modify behavior for requests that specify Expect: 100-continue in the request's headers. Note: The spec says that the client should send the body if the server does not respond within some reasonable period of time. This is not currently supported. Anyone have any thoughts on how that could be done? -- keywords: +patch nosy: +rharris versions: +Python 2.6 -Python 2.4 Added file: http://bugs.python.org/file11073/issue1346874.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1346874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3517] PATCH - Providing fullfsync on supported platforms
Ian Charnas [EMAIL PROTECTED] added the comment: Sounds fair enough. I was looking forward to the glitz and glamor of the os module, but I'll settle for a good seat in fcntl. Here's a patch implementing just that. -ian Added file: http://bugs.python.org/file11074/fullfsync_fcntl.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288615] Python code.interact() and UTF-8 locale
Antoine Pitrou [EMAIL PROTECTED] added the comment: Fixed in r65578. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1288615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3517] PATCH - Providing fullfsync on supported platforms
Guido van Rossum [EMAIL PROTECTED] added the comment: Thanks, checked into the trunk as r65581. -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288615] Python code.interact() and UTF-8 locale
Karen Tracey [EMAIL PROTECTED] added the comment: Cool, thanks! Do I take it from the Versions setting that the fix will be available in the next 2.6 beta but not get propagated to prior releases? (I'm not very familiar with this issue tracker so am just trying to understand what the various fields mean.) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1288615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288615] Python code.interact() and UTF-8 locale
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le jeudi 07 août 2008 à 18:52 +, Karen Tracey a écrit : Karen Tracey [EMAIL PROTECTED] added the comment: Cool, thanks! Do I take it from the Versions setting that the fix will be available in the next 2.6 beta but not get propagated to prior releases? (I'm not very familiar with this issue tracker so am just trying to understand what the various fields mean.) Indeed, the fix will be present in the next 2.6 beta. As for the 2.5 branch, it is in maintenance mode and we want to minimize the amount the potential breakage that we might cause there. I don't think the present bug is important enough to warrant a backport, but other developers may disagree and fix 2.5 as well :-) (as for 3.0, it is unaffected) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1288615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) - ctypes module
Thomas Heller [EMAIL PROTECTED] added the comment: I can review and try out the fixer if someone provides a patch. OTOH I have never used the dl module. Note that dl exposed a lot of RTLD_ constants that ctypes does not yet, so there should be a patch for ctypes also. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Bill Janssen [EMAIL PROTECTED] added the comment: Just to reply to Antoine's comments on my patch: - it would be nice to have more unit tests, especially for the various bytes/unicode possibilities, and perhaps also roundtripping (Matt's patch has a lot of tests) Yes, I completely agree. - quote_as_bytes() should return a bytes object, not a bytearray Good point. - using the %02X format looks clearer to me than going through the _hextable lookup table... Really? I see it the other way. - when the argument is of the wrong type, quote_as_bytes() should raise a TypeError rather than a ValueError Good point. - why is quote_as_string() hardwired to utf8 while unquote_as_string() provides a charset parameter? wouldn't it be better for them to be consistent with each other? To encourage the use of UTF-8. The caller can alway explicitly encode to some other character set, then pass in the bytes that result from that encoding. Remember that the RFC for percent-encoding really takes bytes in, and produces bytes out. The string-in and string-out versions are to support naive programming (what a nice way of putting it!). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3506] Change buffer/memoryview DeprecationWarning
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le mercredi 06 août 2008 à 20:12 +, Guido van Rossum a écrit : +1. buffer() stinks. memoryview() rules. They don't hvae the same use cases. Is there truly nobody else who understands PEP 3118 well enough? PEP 3118 is not very detailed (for example the exact semantics of slicing are not specified: should it return a copy? I suppose not). Also, most advanced uses of the buffer API seem related to numpy and similar packages, which I've never used. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3506 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3419] multiprocessing module is racy
Mark Dickinson [EMAIL PROTECTED] added the comment: Hmmm. That last message wasn't too coherent; I really shouldn't try to post at 2:30am. Summary: the refcounting logic in the Server class is flawed. In Server.create(), the initial refcount of a newly-created shared object is set to None. This is dangerous: the moment another thread gets a look-in, that refcount can be incremented to 1, then decremented to 0, at which point the shared object gets disposed of (by the code in Server.decref). And all this can happen before the Proxy object for the shared object gets initialized, at which point the KeyError occurs. (Not much better.) Can anyone suggest a way to fix this? I can't see any easy fix. Nevertheless, I consider this a serious flaw that should be fixed before 2.6 and 3.0 are released. I've attached a minimal file that produces the incref error (on about 1 run out of every 5) for me. Added file: http://bugs.python.org/file11075/multibug3.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Bill Janssen [EMAIL PROTECTED] added the comment: My main fear with this patch is that unquote will become seen as unreliable, because naive software trying to parse URLs will encounter uses of percent-encoding where the encoded octets are not in fact UTF-8 bytes. They're just some set of bytes. A secondary concern is that it will invisibly produce invalid data, because it decodes some non-UTF-8-encoded string that happens to only use UTF-8-valid sequences as the wrong string value. Now, I have to confess that I don't know how common these use cases are in actual URL usage. It would be nice if there was some organization that had a large collection of URLs, and could provide a test set we could run a scanner over :-). As a workaround, though, I've sent a message off to Larry Masinter to ask about this case. He's one of the authors of the URI spec. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3419] multiprocessing module is racy
Mark Dickinson [EMAIL PROTECTED] added the comment: Adding Richard Oudkerk to the nosy list in case he can shed any light on this. Should this be considered a release-blocker? -- nosy: +roudkerk ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3419] multiprocessing module is racy
Jesse Noller [EMAIL PROTECTED] added the comment: On Aug 7, 2008, at 5:26 PM, Mark Dickinson [EMAIL PROTECTED] wrote: Mark Dickinson [EMAIL PROTECTED] added the comment: Adding Richard Oudkerk to the nosy list in case he can shed any light on this. Should this be considered a release-blocker? I believe Richard is on summer break - I've dropped him a line on the open issues I need his input on. As for if this should block the release, it should be resolved before final, but should not block the next beta. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: On 2008-08-07 23:17, Bill Janssen wrote: Bill Janssen [EMAIL PROTECTED] added the comment: My main fear with this patch is that unquote will become seen as unreliable, because naive software trying to parse URLs will encounter uses of percent-encoding where the encoded octets are not in fact UTF-8 bytes. They're just some set of bytes. unquote will have to be able to deal with old-style URLs that use the Latin-1 encoding. HTML uses (or used to use) the Latin-1 encoding as default and that's how URLs ended up using it as well: http://www.w3schools.com/TAGS/ref_urlencode.asp I'd suggest to have it first try UTF-8 decoding and then fall back to Latin-1 decoding. A secondary concern is that it will invisibly produce invalid data, because it decodes some non-UTF-8-encoded string that happens to only use UTF-8-valid sequences as the wrong string value. It's rather unlikely that someone will have used a Latin-1 encoded URL which happens to decode as valid UTF-8: The valid UTF-8 combinations don't really make any sense when used as text, e.g. Ã?öÃ1/4 Now, I have to confess that I don't know how common these use cases are in actual URL usage. It would be nice if there was some organization that had a large collection of URLs, and could provide a test set we could run a scanner over :-). As a workaround, though, I've sent a message off to Larry Masinter to ask about this case. He's one of the authors of the URI spec. -- nosy: +lemburg ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Guido van Rossum [EMAIL PROTECTED] added the comment: On Thu, Aug 7, 2008 at 2:17 PM, Bill Janssen [EMAIL PROTECTED] wrote: Bill Janssen [EMAIL PROTECTED] added the comment: My main fear with this patch is that unquote will become seen as unreliable, because naive software trying to parse URLs will encounter uses of percent-encoding where the encoded octets are not in fact UTF-8 bytes. They're just some set of bytes. Apps that want to handle these correctly have no choice but to use unquote_to_bytes(), or setting error='ignore' or error='replace'. Your original proposal was to make unquote() behave like unquote_to_bytes(), which would require changes to virtually every app using unqote(), since almost all apps assume the result is a (text) string. Setting the default encoding to Latin-1 would prevent these errors, but would commit the sin of mojibake (the Japanese word for Perl code :-). I don't like that much either. A middle ground might be to set the default encoding to ASCII -- that's closer to Martin's claim that URLs are supposed to be ASCII only. It will fail as soon as an app receives encoded non-ASCII text. This will require many apps to be changed, but at least it forces the developers to think about which encoding to assume (perhaps there's one handy in the request headers if it's a web app) or about error handling or perhaps using unquote_to_bytes(). However I fear that this middle ground will in practice cause: (a) more in-the-field failures, since devs are notorious for testing with ASCII only; and (b) the creation of a recipe for fixing unquote() calls that fail by setting the encoding to UTF-8 without thinking about the alternatives, thereby effectively recreating the UTF-8 default with much more pain. Therefore I think that the UTF-8 default is probably the most pragmatic choice. In the code review, I have asked Matt to change the default error handling from errors='replace' to errors='strict'. I suppose we could reduce outright crashes in the field by setting this to 'replace' (even though for quote() I think it should remain 'strict'). But this may cause more subtle failures, where apps simply receive garbage data. At least when you're serving pages with error 500 the developers tend to get called in. When the users merely get failing results such bugs may remain lingering much longer. A secondary concern is that it will invisibly produce invalid data, because it decodes some non-UTF-8-encoded string that happens to only use UTF-8-valid sequences as the wrong string value. In my experience this is very unlikely. UTF-8 looks like total junk in Latin-1, so it's unlikely to occur naturally. If you see something that matches a UTF-8 sequence in Latin-1 text, it's most likely that in fact it was incorrectly decoded earlier... Now, I have to confess that I don't know how common these use cases are in actual URL usage. It would be nice if there was some organization that had a large collection of URLs, and could provide a test set we could run a scanner over :-). As a workaround, though, I've sent a message off to Larry Masinter to ask about this case. He's one of the authors of the URI spec. Looking forward to his response. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3460] PyUnicode_Join could perhaps be simpler
Antoine Pitrou [EMAIL PROTECTED] added the comment: I've committed the patch in r65583. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3519] Evaluation order example lacks suffix
New submission from Terry J. Reedy [EMAIL PROTECTED]: Language reference/ Expressions/ Evaluation order ... In the following lines, expressions will be evaluated in the arithmetic order of their suffixes: ... func(expr1, expr2, *expr3, **expr4) The omission of a suffix from the function expression could imply that such are somehow not included in the left-to-right rule. Suggest 'func0', 'f_expr0', 'func_expr0' or just 'expr0' possibly renumbered from 1. expr1(expr2, expr3, *expr4, **expr5) is probably most consistent with other examples. -- assignee: georg.brandl components: Documentation messages: 70864 nosy: georg.brandl, tjreedy severity: normal status: open title: Evaluation order example lacks suffix versions: Python 2.5, Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3520] New Global Module Index glitch on WinXP
New submission from Terry J. Reedy [EMAIL PROTECTED]: New to beta2 (a4,b1 worked fine as I remember). It is possible that I installed xp sp3 in between. In any case, I keep xp updated as per MS downloads. Windows XP: open Start/Python3.0/Python Manuals to get 'Python v3.0b2 documentation' window. Click 'Global Module Index' on contents list. Get Internet Explorer Script Error !An error has occurred in the script on this page. Line 16 Char 7 Error: 'DOCUMENTATION_OPTIONS' is undefined Code: 0 URL: [EMAIL PROTECTED]:C:\Program Files\Python30\Doc\python30b2.chm::/modindex.html Do you want to continue running scripts on this page? When I click yes, seems to work ok as before. Error repeats when I go back to index again. -- assignee: georg.brandl components: Documentation messages: 70865 nosy: georg.brandl, tjreedy severity: normal status: open title: New Global Module Index glitch on WinXP versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3521] file.readline: bad exception recovery
New submission from Terry J. Reedy [EMAIL PROTECTED]:
WinXP, 3.0b2
f=open('somefile', 'r')
f.readline(somefloat)
Traceback (most recent call last):
File pyshell#70, line 1, in module
f.readline(1.0)
File C:\Program Files\Python30\lib\io.py, line 1766, in readline
return line[:endpos]
TypeError: slice indices must be integers or None or have an __index__
method
At this point, any f.read or f.readline calls fail with a similar
TypeError. The error recovery seems incomplete. The same does *not*
happen with f.read(float). Recovery is complete and subsequent
f.read/f.readline calls work.
In 2.5, float size arg worked with a deprecation warning, so issue does
not arise. I presume same is true in 2.6.
--
components: Interpreter Core
messages: 70866
nosy: tjreedy
severity: normal
status: open
title: file.readline: bad exception recovery
type: behavior
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3521
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3521] file.readline: bad exception recovery
Guido van Rossum [EMAIL PROTECTED] added the comment: Good catch! This looks pretty simple to fix; I think a type check is missing (actually several, there are at least two implementations in io.py). In fact, the 2.6 version of io.py already has the necessary checks. (But merging those forward is not 100% trivial since in 3.0 the 'long' type doesn't exist.) -- keywords: +easy nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Bill Janssen [EMAIL PROTECTED] added the comment: Your original proposal was to make unquote() behave like unquote_to_bytes(), which would require changes to virtually every app using unqote(), since almost all apps assume the result is a (text) string. Actually, careful apps realize that the result of unquote in Python 2 is a sequence of bytes, and do something careful with that. So only careless apps would break, and they'd break in such a way that their maintainers would have to look at the situation again, and think about it. Seems like a 'good thing', to me. And since this is Python 3, fully allowed. I really don't understand your position here, I'm afraid. Setting the default encoding to Latin-1 would prevent these errors, but would commit the sin of mojibake (the Japanese word for Perl code :-). I don't like that much either. No, that would be wrong. Returning a string just for the sake of returning a string. Remember, the data percent-encoded is not necessarily a string, and not necessarily in any known encoding. A middle ground might be to set the default encoding to ASCII -- that's closer to Martin's claim that URLs are supposed to be ASCII only. URLs *are* supposed to be ASCII only -- but the percent-encoded byte sequences in various parts of the path aren't. This will require many apps to be changed, but at least it forces the developers to think about which encoding to assume (perhaps there's one handy in the request headers if it's a web app) or about error handling or perhaps using unquote_to_bytes(). Yes, this is closer to my line of reasoning. However I fear that this middle ground will in practice cause: (a) more in-the-field failures, since devs are notorious for testing with ASCII only; and Returning bytes deals with this problem. (b) the creation of a recipe for fixing unquote() calls that fail by setting the encoding to UTF-8 without thinking about the alternatives, thereby effectively recreating the UTF-8 default with much more pain. Could be, but at least they will have had to think about. There's lots of bad code out there, and maybe by making them think about it, some of it will improve. A secondary concern is that it will invisibly produce invalid data, because it decodes some non-UTF-8-encoded string that happens to only use UTF-8-valid sequences as the wrong string value. In my experience this is very unlikely. UTF-8 looks like total junk in Latin-1, so it's unlikely to occur naturally. If you see something that matches a UTF-8 sequence in Latin-1 text, it's most likely that in fact it was incorrectly decoded earlier... Latin-1 isn't the only alternate encoding in the world, and not all percent-encoded byte sequences in URLs are encoded strings. I'd feel better if we were being guided by more than your just experience (vast though it may rightly be said to be!). Say, by looking at all the URLs that Google knows about :-). I'd particularly feel better if some expert in Asian use of the Web spoke up here... Added file: http://bugs.python.org/file11076/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___div dir=ltrgt; Your original proposal was to make unquote() behave likebrgt; unquote_to_bytes(), which would require changes to virtually every appbrgt; using unqote(), since almost all apps assume the result is a (text)br gt; string.brbrActually, careful apps realize that the result of quot;unquotequot; in Python 2 is a sequence of bytes, and do something careful with that.nbsp; So only careless apps would break, and they#39;d break in such a way that their maintainers would have to look at the situation again, and think about it.nbsp; Seems like a #39;good thing#39;, to me.nbsp; And since this is Python 3, fully allowed.nbsp; I really don#39;t understand your position here, I#39;m afraid.br brdiv class=gmail_quotebrblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;Setting the default encoding to Latin-1 would prevent these errors,br but would commit the sin of mojibake (the Japanese word for Perl codebr :-). I don#39;t like that much either./blockquotedivbrNo, that would be wrong.nbsp; Returning a string just for the sake of returning a string.nbsp; Remember, the data percent-encoded is not necessarily a string, and not necessarily in any known encoding.br /divblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;br A middle ground might be to set the default encoding to ASCII --br that#39;s closer to Martin#39;s claim that URLs are supposed to be ASCIIbr only./blockquotedivbrURLs *are* supposed to be ASCII only -- but the percent-encoded byte sequences in various parts of the path aren#39;t.brbr/divblockquote class=gmail_quote style=border-left: 1px solid
[issue3300] urllib.quote and unquote - Unicode issues
Guido van Rossum [EMAIL PROTECTED] added the comment: On Thu, Aug 7, 2008 at 3:58 PM, Bill Janssen [EMAIL PROTECTED] wrote: Bill Janssen [EMAIL PROTECTED] added the comment: Your original proposal was to make unquote() behave like unquote_to_bytes(), which would require changes to virtually every app using unqote(), since almost all apps assume the result is a (text) string. Actually, careful apps realize that the result of unquote in Python 2 is a sequence of bytes, and do something careful with that. Given that in 2.x it's a string, and knowing my users, I expect that careful apps are a tiny minority. So only careless apps would break, and they'd break in such a way that their maintainers would have to look at the situation again, and think about it. Seems like a 'good thing', to me. And since this is Python 3, fully allowed. I really don't understand your position here, I'm afraid. My position is that although 3.0 supports Unicode much better than 2.x (I won't ever use pretentious and meaningless phrases like fully supports), that doesn't mean that you *have* to use it. I expect lots of simple web apps don't need Unicode but do need quote/unquote functionality to get around forbidden characters in query strings like . I don't want to force such apps to become more aware of Unicode than absolutely necessary. A middle ground might be to set the default encoding to ASCII -- that's closer to Martin's claim that URLs are supposed to be ASCII only. URLs *are* supposed to be ASCII only -- but the percent-encoded byte sequences in various parts of the path aren't. This will require many apps to be changed, but at least it forces the developers to think about which encoding to assume (perhaps there's one handy in the request headers if it's a web app) or about error handling or perhaps using unquote_to_bytes(). Yes, this is closer to my line of reasoning. However I fear that this middle ground will in practice cause: (a) more in-the-field failures, since devs are notorious for testing with ASCII only; and Returning bytes deals with this problem. In an unpleasant way. We might as well consider changing all APIs that deal with URLs to insist on bytes. (b) the creation of a recipe for fixing unquote() calls that fail by setting the encoding to UTF-8 without thinking about the alternatives, thereby effectively recreating the UTF-8 default with much more pain. Could be, but at least they will have had to think about. There's lots of bad code out there, and maybe by making them think about it, some of it will improve. I'd rather use a carrot than a stick. IOW I'd rather write aggressive docs than break people's code. A secondary concern is that it will invisibly produce invalid data, because it decodes some non-UTF-8-encoded string that happens to only use UTF-8-valid sequences as the wrong string value. In my experience this is very unlikely. UTF-8 looks like total junk in Latin-1, so it's unlikely to occur naturally. If you see something that matches a UTF-8 sequence in Latin-1 text, it's most likely that in fact it was incorrectly decoded earlier... Latin-1 isn't the only alternate encoding in the world, and not all percent-encoded byte sequences in URLs are encoded strings. I'd feel better if we were being guided by more than your just experience (vast though it may rightly be said to be!). Say, by looking at all the URLs that Google knows about :-). I'd particularly feel better if some expert in Asian use of the Web spoke up here... OK, let's wait and see if one bites. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3429] urllib.urlopen() return type
Senthil [EMAIL PROTECTED] added the comment: I agree with Benjamin on this issue, describing what is a File like Object is so much un-needed in Python and especially at urlopen function. Users have been able to understand and use it properly from a long time. -- nosy: +orsenthil ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3429 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3522] zip() function example in tutorial
New submission from Jim Sizelove [EMAIL PROTECTED]: The zip() function is now a generator in Python 3.0. There is an example of using the zip() function in the Python 3.0 tutorial, http://docs.python.org/dev/3.0/tutorial/datastructures.html. When running the example, I got: mat = [[1, 2, 3], [4, 5, 6], [7, 8, 9]] zip(*mat) zip object at 0x70fc60 I wrapped it in a call to list() to get the example output: list(zip(*mat)) [(1, 4, 7), (2, 5, 8), (3, 6, 9)] The attached patch file contains this change. -- assignee: georg.brandl components: Documentation files: datastructures.diff keywords: patch messages: 70871 nosy: georg.brandl, jsizelove severity: normal status: open title: zip() function example in tutorial versions: Python 3.0 Added file: http://bugs.python.org/file11077/datastructures.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3522 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Bill Janssen [EMAIL PROTECTED] added the comment: On Thu, Aug 7, 2008 at 4:23 PM, Guido van Rossum [EMAIL PROTECTED]wrote: However I fear that this middle ground will in practice cause: (a) more in-the-field failures, since devs are notorious for testing with ASCII only; and Returning bytes deals with this problem. In an unpleasant way. We might as well consider changing all APIs that deal with URLs to insist on bytes. That seems a bit over-the-top. Most URL operations *are* about strings, and most of the APIs should deal with strings; we're talking about the return result of an operation specifically designed to extract binary data from the one place where it's allowed to occur. Vastly smaller than changing all APIs that deal with URLs. By the way, I see that the email package dodges this by encoding the bytes to strings using the codec raw-unicode-escape. In other words, byte sequences in the outward form of a string. I'd be OK with that. That is, make the default codec for unquote be raw-unicode-escape. All the bytes will come through unscathed, and people who are naively expecting ASCII strings will still receive them, so the code won't break. This actually seems to be closest to the current usage, so I'm going to change my patch to do that. Added file: http://bugs.python.org/file11078/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___div dir=ltrOn Thu, Aug 7, 2008 at 4:23 PM, Guido van Rossum span dir=ltrlt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;/span wrote:brdiv class=gmail_quoteblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; brdiv class=Ih2E3d gt;gt; However I fear that this middle ground will in practice cause:br gt;gt;br gt;gt; (a) more in-the-field failures, since devs are notorious for testingbr gt;gt; with ASCII only; andbr gt;br gt; Returning bytes deals with this problem.br br /divIn an unpleasant way. We might as well consider changing all APIs thatbr deal with URLs to insist on bytes.br div class=Ih2E3d/div/blockquotedivbrThat seems a bit over-the-top.nbsp; Most URL operations *are* about strings, and most of the APIs should deal with strings; we#39;re talking about the return result of an operation specifically designed to extract binary data from the one place where it#39;s allowed to occur.nbsp; Vastly smaller than quot;changing all APIs that deal with URLsquot;.br brBy the way, I see that the email package dodges this by encoding the bytes to strings using the codec quot;raw-unicode-escapequot;.nbsp; In other words, byte sequences in the outward form of a string.nbsp; I#39;d be OK with that.nbsp; That is, make the default codec for quot;unquotequot; be quot;raw-unicode-escapequot;.nbsp; All the bytes will come through unscathed, and people who are naively expecting ASCII strings will still receive them, so the code won#39;t break.nbsp; This actually seems to be closest to the current usage, so I#39;m going to change my patch to do that.br /divbr/divbr/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3523] Reverse quotes in Python 3.0 tutorial
New submission from Jim Sizelove [EMAIL PROTECTED]: The Input and Output section of the tutorial says: Reverse quotes (``) are equivalent to repr(), but they are no longer used in modern Python code and are removed in future versions of the language. Is now that future time with Python 3.0? I get syntax errors when I try to run the examples that use reverse quotes. The attached patch removes the explanation and examples of reverse quotes. -- assignee: georg.brandl components: Documentation files: input_output.diff keywords: patch messages: 70873 nosy: georg.brandl, jsizelove severity: normal status: open title: Reverse quotes in Python 3.0 tutorial versions: Python 3.0 Added file: http://bugs.python.org/file11079/input_output.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3466] urllib2 should support HTTPS connections with client keys
Changes by Senthil [EMAIL PROTECTED]: -- nosy: +orsenthil ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3524] IOError when attempting negative seek in file (Python 3.0 tutorial)
New submission from Jim Sizelove [EMAIL PROTECTED]:
The Input and Output section of the Python 3.0 tutorial
(http://docs.python.org/dev/3.0/tutorial/inputoutput.html) shows an
example of seeking in a negative direction from the end of a file. I
get an IOError when attempting to run the example in Python 3.0b2 on Mac
OS X 10.4 (PPC). I don't know whether the tutorial or the code should
be changed.
f = open('workfile', 'r+')
f.write('0123456789abcdef')
16
f.seek(-3, 2)
Traceback (most recent call last):
File stdin, line 1, in module
File
/Users/jimsize/Programming/Python/py3k/3.0b2/lib/python3.0/io.py, line
1609, in seek
raise IOError(can't do nonzero end-relative seeks)
IOError: can't do nonzero end-relative seeks
--
assignee: georg.brandl
components: Documentation
messages: 70874
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: IOError when attempting negative seek in file (Python 3.0 tutorial)
type: behavior
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3524
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue896052] symtable module not documented
Terry J. Reedy [EMAIL PROTECTED] added the comment: I notice that symtable is still in 3.0, still not in the index, and I presume still not documented. The help(symtable) says it defines classes Symbol SymbolTable Class(SymbolTable) Function(symbolTable) so it seems to be used for parsing. Is it for the old ast parser, and therefore obsolete? For the new AST parser and still relevant? For an experiment that ended? Or something else? -- nosy: +tjreedy ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue896052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3525] Changes to exceptions not reflected in tutorial examples.
New submission from Jim Sizelove [EMAIL PROTECTED]:
PEPs 3109 and 3110 describe changes to Exceptions. The attached patch
file makes changes to the tutorial to bring it in line with the changes
to errors and exceptions implemented in Python 3.0.
I'll make a comment about the .args of exceptions instances. The
tutorial states use of .args is discouraged. I found, however, that
the alternative of unpacking the args using __getitem__ raises a
TypeError.
try:
... raise Exception('spam', 'eggs')
... except Exception as inst:
... x, y = inst
...
Traceback (most recent call last):
File stdin, line 2, in module
Exception: ('spam', 'eggs')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File stdin, line 4, in module
TypeError: 'Exception' object is not iterable
Does that mean that now .args is encouraged?
--
assignee: georg.brandl
components: Documentation
files: errors.diff
keywords: patch
messages: 70876
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Changes to exceptions not reflected in tutorial examples.
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11080/errors.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3525
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3525] Changes to exceptions not reflected in tutorial examples.
Jim Sizelove [EMAIL PROTECTED] added the comment: The conversations that led to the removal of __getitem__ from Exceptions can be found in issue2291 and issue2379. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Bill Janssen [EMAIL PROTECTED] added the comment: Now I'm looking at the failing test_http_cookiejar test, which fails because it encodes a non-UTF-8 byte, 0xE5, in a path segment of a URI. The question is, does the http URI scheme allow non-ASCII (say, Latin-1) octets in path segments? IANA says that the http scheme is defined in RFC 2616, and that says: This specification adopts the definitions of URI-reference, absoluteURI, relativeURI, port, host,abs_path, rel_path, and authority from [RFC 2396]. But RFC 2396 says: An individual URI scheme may require a single charset, define a default charset, or provide a way to indicate the charset used. And doesn't say anything about the http scheme. Nor does it indicate any default encoding or character set for URIs. The update, 3986, doesn't say anything new about this, though it does implore URI scheme designers to represent characters in a textual segment with ASCII codes where they exist, and to use UTF-8 when designing *new* URI schemes. Barring any other information, I think that the segments in the path of an http URL must also be assumed to be binary; that is, any octet is allowed, and no character set can be presumed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Changes by Bill Janssen [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11078/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Bill Janssen [EMAIL PROTECTED] added the comment: Looks like the failing test in test_http_cookiejar is just a bad test; it attempts to build an HTTP request object from an invalid URL, yet still seem to expect to be able to extract a cookie from the response headers for that request. I'd expect some exception to be thrown. So this probably indicates a bug in urllib.parse: urllib.parse.urlparse(http://www.acme.com/foo%2f%25/%0anew\345/\346\370\345) should throw an exception somewhere. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Bill Janssen [EMAIL PROTECTED] added the comment: Just to be clear: any octet would seem to be allowed in the path of an http URL, but any non-ASCII octet must be percent-encoded. So the URL itself is still an ASCII string, considered opaquely. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue896052] symtable module not documented
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue896052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3506] Change buffer/memoryview DeprecationWarning
Brett Cannon [EMAIL PROTECTED] added the comment: In r65584 I changed the warning to not mention memoryview(); it just says that buffer() does not exist in 3.0. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3506 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
