From report at bugs.python.org Tue Jan 1 00:07:55 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 31 Dec 2012 23:07:55 +0000 Subject: [issue14958] IDLE 3 and PEP414 - highlighting unicode literals In-Reply-To: <1338338268.62.0.441053102014.issue14958@psf.upfronthosting.co.za> Message-ID: <3YZvLy1cFSzS5H@mail.python.org> Roundup Robot added the comment: New changeset 0dbdb85fd141 by Ned Deily in branch '2.7': Issue #14958: backport to 2.7.x from 3.3 (patch by Roger Serwy) http://hg.python.org/cpython/rev/0dbdb85fd141 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 00:41:26 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Mon, 31 Dec 2012 23:41:26 +0000 Subject: [issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse) In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za> Message-ID: <1356997286.7.0.171532938096.issue9334@psf.upfronthosting.co.za> Changes by Daniel Shahaf : ---------- nosy: +danielsh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 00:57:54 2013 From: report at bugs.python.org (Bryan Bishop) Date: Mon, 31 Dec 2012 23:57:54 +0000 Subject: [issue16830] Add skip_host and skip_accept_encoding to httplib/http.client Message-ID: <1356998273.75.0.911756727263.issue16830@psf.upfronthosting.co.za> New submission from Bryan Bishop: Sometimes I am using httplib/http.client and the server is not exactly conforming to HTTP specs. I need to be able to specify the exact headers that are sent to the server. By default, httplib/http.client injects headers like "Host" and "Accept-Encoding". Issue #831747 added skip_accept_encoding to httplib's putrequest method, but not on the request method. This current patch exposes these two toggles on the request method. This way, headers can be controlled without manually calling the connect/send/endheaders methods. As a result, urllib/urllib3 can call urlopen and pass in these attributes to more directly control the headers sent to the remote server. ---------- components: Library (Lib) files: httplib_better_header_skips.patch keywords: patch messages: 178719 nosy: kanzure priority: normal severity: normal status: open title: Add skip_host and skip_accept_encoding to httplib/http.client type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file28516/httplib_better_header_skips.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 00:58:25 2013 From: report at bugs.python.org (Roger Serwy) Date: Mon, 31 Dec 2012 23:58:25 +0000 Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works) In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za> Message-ID: <1356998305.83.0.182411155198.issue16809@psf.upfronthosting.co.za> Roger Serwy added the comment: In Objects/unicodeobject.c in PyUnicode_FromObject, the call to PyUnicode_CheckExact fails when using 8.6.0 but works with 8.5.13. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 01:11:52 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 01 Jan 2013 00:11:52 +0000 Subject: [issue16819] IDLE b"" method completion incorrect In-Reply-To: <1356854538.64.0.0309588990052.issue16819@psf.upfronthosting.co.za> Message-ID: <1356999112.29.0.638203936835.issue16819@psf.upfronthosting.co.za> Changes by Roger Serwy : ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 01:19:48 2013 From: report at bugs.python.org (Berker Peksag) Date: Tue, 01 Jan 2013 00:19:48 +0000 Subject: [issue16830] Add skip_host and skip_accept_encoding to httplib/http.client In-Reply-To: <1356998273.75.0.911756727263.issue16830@psf.upfronthosting.co.za> Message-ID: <1356999588.69.0.418724921673.issue16830@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 2.7, Python 3.1, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 01:32:50 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 01 Jan 2013 00:32:50 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357000370.87.0.162837799779.issue16076@psf.upfronthosting.co.za> Eli Bendersky added the comment: A couple of high-level questions about the C code (this isn't a detailed review yet): 1. Why did you choose to implement __reduce__ and not __getstate__? 2. A lot of code appears to be shared between element_setstate_from_attributes and the init method implementation, can it be refactored? 3. I've been thinking about the C<->Python pickle compatibility, and it may be too much trouble at this point for no very strong benefit. What could make more sense at some point is implementing a __getstate__/__setstate__ in both the Python and C versions that are compatible (i.e. produce the same things). But this may mean changing the way the Python Element is pickled in 3.3, which may not be acceptable. So we may prefer to forego the compatibility in 3.3 and then for 3.4 make the change. I'm still not sure what is best here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 01:37:02 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 01 Jan 2013 00:37:02 +0000 Subject: [issue16659] Pure Python implementation of random In-Reply-To: <1355178066.71.0.0702719631559.issue16659@psf.upfronthosting.co.za> Message-ID: <1357000622.92.0.611662625987.issue16659@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Okay thanks. I'll look over the patch in detail over the next few days. FYI, I'm the maintainer of this module (and was the one to add the original Mersenne Twister code). ---------- assignee: serhiy.storchaka -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 04:21:16 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 01 Jan 2013 03:21:16 +0000 Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with -E In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za> Message-ID: <1357010476.72.0.863563643046.issue16826@psf.upfronthosting.co.za> Meador Inge added the comment: Is the attached OK? ---------- keywords: +patch nosy: +meador.inge stage: test needed -> patch review Added file: http://bugs.python.org/file28517/issue16826-0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 04:21:37 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Jan 2013 03:21:37 +0000 Subject: [issue16831] Better docs for ABCMeta.__subclasshook__ Message-ID: <1357010497.63.0.917650591234.issue16831@psf.upfronthosting.co.za> New submission from Nick Coghlan: Authors of __subclasshook__ methods need to decide between returning True, False and NotImplemented in various cases. Making that decision requires a clear understanding that the checks in ABCMeta.__subclasscheck__ occur in the following order: - explicit registrations - the __subclasshook__ call - ordinary inheritance So, returning False from __subclasshook__ allows you to override normal rules of inheritance, while returning NotImplemented lets normal inheritance rules apply. Explicit registrations take precedence regardless. ---------- messages: 178724 nosy: ncoghlan priority: normal severity: normal status: open title: Better docs for ABCMeta.__subclasshook__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 04:28:22 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 01 Jan 2013 03:28:22 +0000 Subject: [issue12915] Add inspect.locate and inspect.resolve In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za> Message-ID: <1357010902.31.0.34973404652.issue12915@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 04:38:24 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Jan 2013 03:38:24 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta Message-ID: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> New submission from Nick Coghlan: ABCMeta uses an internal counter to invalidate the negative caches when a register() call changes the virtual inheritance graph. (A global count of register() calls is stored on ABCMeta, which ABCMeta.__instancecheck__ and ABCMeta.__subclasscheck__ then compare to a copy cached on the individual ABC) To properly handle register() method calls on ABCs, generic function implementations also need a way to invalidate their own caches when that graph changes. It seems like the simplest way to handle this would be to expose a read-only "ABCMeta.cache_token" property. Generic function implementations could then work the same way as ABCMeta itself: store explicit implementation registrations and a cache of derived implementations separately, and if a saved copy of the cache token doesn't match the current value of ABCMeta.cache_token, clear the derived cache. ---------- components: Library (Lib) messages: 178725 nosy: ncoghlan priority: normal severity: normal status: open title: Expose cache validity checking support in ABCMeta versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 05:07:43 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Jan 2013 04:07:43 +0000 Subject: [issue16831] Better docs for ABCMeta.__subclasshook__ In-Reply-To: <1357010497.63.0.917650591234.issue16831@psf.upfronthosting.co.za> Message-ID: <1357013263.89.0.284370834207.issue16831@psf.upfronthosting.co.za> Nick Coghlan added the comment: Also, we should probably explain the approach we chose to follow in the stdlib, where we block implicit inheritance of __subclasshook__ behaviour by include an explicit type check at the start of the implementation, so it always returns NotImplemented when the first argument is a subclass rather than the exact expected class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 06:01:16 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Tue, 01 Jan 2013 05:01:16 +0000 Subject: [issue16831] Better docs for ABCMeta.__subclasshook__ In-Reply-To: <1357010497.63.0.917650591234.issue16831@psf.upfronthosting.co.za> Message-ID: <1357016476.05.0.405927724669.issue16831@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 10:02:40 2013 From: report at bugs.python.org (Daniel Urban) Date: Tue, 01 Jan 2013 09:02:40 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1357030960.03.0.684743485536.issue16832@psf.upfronthosting.co.za> Changes by Daniel Urban : ---------- nosy: +daniel.urban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 10:26:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Jan 2013 09:26:51 +0000 Subject: [issue11939] Implement stat.st_dev and os.path.samefile on windows In-Reply-To: <3YZmWm3jrLzSBy@mail.python.org> Message-ID: <201301011126.31649.storchaka@gmail.com> Serhiy Storchaka added the comment: > New changeset 3738d270c54a by Brian Curtin in branch 'default': > st_dev/st_rdev should be unsigned long as dwVolumeSerialNumber, which it is > set to, is a DWORD. This was fixed in #11939 and the overflow was > mentioned in #10657 and seen by me on some machines. > http://hg.python.org/cpython/rev/3738d270c54a But than st_dev used as long in _pystat_fromstructstat(). Perhaps you should check if st_dev is negative and then select PyLong_FromLong/PyLong_FromLongLong or PyLong_FromUnsignedLong/PyLong_FromUnsignedLongLong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 10:36:02 2013 From: report at bugs.python.org (Benno Leslie) Date: Tue, 01 Jan 2013 09:36:02 +0000 Subject: [issue16833] httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages Message-ID: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> New submission from Benno Leslie: he http.client HTTPConnection._send_output method has an optimization for avoiding bad interactions between delayed-ack and the Nagle algorithm: http://hg.python.org/cpython/file/f32f67d26035/Lib/http/client.py#l884 Unfortunately this interacts rather poorly if the case where the message_body is a bytes instance and is rather large. If the message_body is bytes it is appended to the headers, which causes a copy of the data. When message_body is large this duplication of data can cause a significant spike in memory usage. (In my particular case I was uploading a 200MB file to 30 hosts at the same leading to memory spikes over 6GB. [There is a short thread discussing this issue on python-dev; Subject: "http.client Nagle/delayed-ack optimization"; Date: Dec 15, 2012] ---------- components: Library (Lib) files: http_opt.diff keywords: patch messages: 178728 nosy: bennoleslie priority: normal severity: normal status: open title: httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages type: performance versions: Python 3.3 Added file: http://bugs.python.org/file28518/http_opt.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 11:10:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Jan 2013 10:10:02 +0000 Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works) In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za> Message-ID: <1357035002.68.0.950289140231.issue16809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't install Tcl/Tk 8.6 yet, but looks as "pack info" call returns a new type of Tcl data (perhaps DictType) which doesn't detected in FromObj(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 12:41:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 01 Jan 2013 11:41:00 +0000 Subject: [issue16830] Add skip_host and skip_accept_encoding to httplib/http.client In-Reply-To: <1356998273.75.0.911756727263.issue16830@psf.upfronthosting.co.za> Message-ID: <1357040460.32.0.708193225875.issue16830@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure this is a desirable feature in the stdlib, but regardless, your solution isn't very scalable: a new argument will have to be added each time someone wants to avoid sending a given header. Another possibility would be to allow passing None in values of the `headers` dict, in which case the given header wouldn't be send at all. ---------- nosy: +orsenthil, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 12:53:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 01 Jan 2013 11:53:23 +0000 Subject: [issue16833] httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <1357041203.64.0.887019339114.issue16833@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch. Perhaps our MSS value should be an upper bound of common values? Apparently for a localhost connection TCP_MAXSEG gives 16384 here (but I don't know if the http.client optimization is important for localhost connections). Also, it would be nice to add an unit test in Lib/test/test_httplib.py. ---------- nosy: +neologix, pitrou stage: -> patch review versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 12:56:15 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 01 Jan 2013 11:56:15 +0000 Subject: [issue16828] bz2 error on compression of empty string In-Reply-To: <1356973084.81.0.547571826956.issue16828@psf.upfronthosting.co.za> Message-ID: <1357041375.4.0.87879967962.issue16828@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 15:56:29 2013 From: report at bugs.python.org (Yuval Weinbaum) Date: Tue, 01 Jan 2013 14:56:29 +0000 Subject: [issue16834] ioctl mutate_flag behavior in regard to the buffer size limit Message-ID: <1357052189.92.0.352175087043.issue16834@psf.upfronthosting.co.za> New submission from Yuval Weinbaum: In fcntl module, the documentation states the following regarding the mutate_flag in ioctl method: *** If it is false, the buffer?s mutability is ignored and behaviour is as for a read-only buffer, except that the 1024 byte limit mentioned above is avoided ? so long as the buffer you pass is as least as long as what the operating system wants to put there, things should work. *** However, looking at the code (fcntlmodule.c) it seems that the 1024 bytes limitation is avoided when the mutate_flag is set to True (the opposite of what is stated in the doc). ---------- assignee: docs at python components: Documentation messages: 178732 nosy: Yuval.Weinbaum, docs at python priority: normal severity: normal status: open title: ioctl mutate_flag behavior in regard to the buffer size limit versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 16:18:06 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 01 Jan 2013 15:18:06 +0000 Subject: [issue16833] httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357041203.64.0.887019339114.issue16833@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Thanks for the patch. Perhaps our MSS value should be an upper bound of common values? Apparently for a localhost connection TCP_MAXSEG gives 16384 here (but I don't know if the http.client optimization is important for localhost connections). According to http://en.wikipedia.org/wiki/Maximum_transmission_unit, the MTU (from which the MSS is derived) for a wireless NIC is around 8000, and you can have jumbo frames on Ethernet up to 9000, so a value of 2K might be too small (since the goal is to avoid sending a payload less than MSS with its own send() syscall). So I think a value like 16K should be OK (the downside to using a large value is the extra copying, but OTOH it will incur less copying than now). Note that the ideal fix for this would be scatter-gather I/O with sendmsg(): both the header and the payload could be sent in the same segment, without any extra copying. But I'm not sure it's worth it here. A note on the comment: """ 722 # TCP Maximum Segment Size (MSS) is a TCP stack parameter. There 723 # is no simple and efficient platform independent mechanism for 724 # determining the MSS, so instead a reasonable estimate is chosen. """ The MSS is not really a TCP stack parameter (i.e. it's not fixed by the host like socket buffers, etc): it's usually negociated between the hosts (and with path MTU discovery or IPv6 it depends on the path MTU). That's why it's hard to guess ahead of time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 16:33:36 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Jan 2013 15:33:36 +0000 Subject: [issue16787] asyncore.dispatcher_with_send - increase the send buffer size In-Reply-To: <1356529865.78.0.746318746855.issue16787@psf.upfronthosting.co.za> Message-ID: <3YbKDH2jvYzSG2@mail.python.org> Roundup Robot added the comment: New changeset 2eddf7c2efe6 by Charles-Fran?ois Natali in branch 'default': Issue #16787: Increase asyncore and asynchat default output buffers size, to http://hg.python.org/cpython/rev/2eddf7c2efe6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 16:45:37 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 01 Jan 2013 15:45:37 +0000 Subject: [issue16787] asyncore.dispatcher_with_send - increase the send buffer size In-Reply-To: <1356529865.78.0.746318746855.issue16787@psf.upfronthosting.co.za> Message-ID: <1357055137.37.0.63405749423.issue16787@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Closing! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 16:53:59 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 01 Jan 2013 15:53:59 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357055639.81.0.739252265035.issue16076@psf.upfronthosting.co.za> Eli Bendersky added the comment: Other thoughts. I'm not sure why you're surprised the C->Python pickle/unpickle works. You've changed the type name from Element to _elementtree.Element, so I would guess Python always uses the C version to unpickle as well. Can you debug to verify what actually goes on under the hood? Why did you change the class name, by the way, I don't think it's a valid change at least for 3.3 in terms of backwards compatibility. Regarding that compatibility, and even easier idea would be for the C pickle to return the same __dict__ implicitly gathered from the Python version, and then only one version of the unpickle is required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 17:48:18 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 01 Jan 2013 16:48:18 +0000 Subject: [issue16733] Solaris ctypes_test failures In-Reply-To: <1355959487.2.0.457059136813.issue16733@psf.upfronthosting.co.za> Message-ID: <1357058898.85.0.708924514749.issue16733@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 18:39:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 01 Jan 2013 17:39:58 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357061998.15.0.250829906305.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: I just came across the problem described here while reviewing #16694. The idiom I used for the JSON tests[0] (and possibly a couple of other tests) when I rewrote them was to have something like: class FooTest: # all the test methods here class CFooTest(FooTest, unittest.TestCase): module = c_foo class PyFooTest(FooTest, unittest.TestCase): module = py_foo The reason to only have the subclasses inheriting from unittest.TestCase was exactly to avoid having FooTest as a discoverable TestCase. I think PEP 399 should be updated and the tests should be fixed. I don't think it's necessary to provide a base class as suggested in the first message (it's actually not even necessary to set the module to None, because eventually it will be set to either some cmodule or pymodule. In case something goes wrong it's even better if the AttributeError says "self has no attribute 'module'" rather than "NoneType has no attribute 'somemeth'".) @Brett, should I open a separate issue for the PEP 399 changes? [0] see e.g.: Lib/test/json_tests/test_float.py and Lib/test/json_tests/__init__.py (note that here the idiom is a bit more complicated, because in addition to set the self.module, I also had to set additional attributes and work with different test files in the same package. I also added additional tests in __init__ to make sure that import_fresh_module worked after adapting it to work with packages.) ---------- assignee: -> ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 18:54:15 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Jan 2013 17:54:15 +0000 Subject: [issue9586] "warning: comparison between pointer and integer" in multiprocessing build on Tiger In-Reply-To: <1281703428.64.0.285019462814.issue9586@psf.upfronthosting.co.za> Message-ID: <3YbNLZ35qPzS5L@mail.python.org> Roundup Robot added the comment: New changeset a5b49db3383d by Richard Oudkerk in branch '3.2': Issue #9586: Redefine SEM_FAILED on MacOSX to keep compiler happy. http://hg.python.org/cpython/rev/a5b49db3383d New changeset a70db584e897 by Richard Oudkerk in branch '3.3': Issue #9586: Merge http://hg.python.org/cpython/rev/a70db584e897 New changeset 92990dd91b07 by Richard Oudkerk in branch 'default': Issue #9586: Merge. http://hg.python.org/cpython/rev/92990dd91b07 New changeset 395976a1f26f by Richard Oudkerk in branch '2.7': Issue #9586: Redefine SEM_FAILED on MacOSX to keep compiler happy. http://hg.python.org/cpython/rev/395976a1f26f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 19:21:53 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Jan 2013 18:21:53 +0000 Subject: [issue11939] Implement stat.st_dev and os.path.samefile on windows In-Reply-To: <1303923583.07.0.177662562381.issue11939@psf.upfronthosting.co.za> Message-ID: <3YbNyS2k9kzP21@mail.python.org> Roundup Robot added the comment: New changeset 61bada808b34 by Brian Curtin in branch 'default': Set st_dev on Windows as unsigned long to match its DWORD type, related to the change to fix #11939. http://hg.python.org/cpython/rev/61bada808b34 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 19:29:55 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Jan 2013 18:29:55 +0000 Subject: [issue11939] Implement stat.st_dev and os.path.samefile on windows In-Reply-To: <1303923583.07.0.177662562381.issue11939@psf.upfronthosting.co.za> Message-ID: <1357064995.1.0.427032509976.issue11939@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now the code is wrong on non-Windows without PY_LONG_LONG and with signed st_dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 19:30:11 2013 From: report at bugs.python.org (Bryan Bishop) Date: Tue, 01 Jan 2013 18:30:11 +0000 Subject: [issue16830] Add skip_host and skip_accept_encoding to httplib/http.client In-Reply-To: <1356998273.75.0.911756727263.issue16830@psf.upfronthosting.co.za> Message-ID: <1357065011.61.0.0713056005716.issue16830@psf.upfronthosting.co.za> Bryan Bishop added the comment: On Tue, Jan 1, 2013 at 5:41 AM, Antoine Pitrou wrote: > Another possibility would be to allow passing None in values of the `headers` dict, in which case the given header wouldn't be send at all. I agree that your solution is more scaling-friendly than the patch I originally submitted. But from another perspective, consider how alien it is to have to explicitly add keys set to None in the headers to get desired behavior. Maybe there could be a single flag "strict" (or possibly a better name) that would indicate that the dict is in fact what I want to send and that it should not be modified? Or perhaps there should be "base_headers" list (not a dictionary) of header keys of which defaults to not inject? Also, would making {"Accept-Encoding": None} send no "Accept-Encoding" header be backwards incompatible with the current behavior? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 19:32:19 2013 From: report at bugs.python.org (Brian Curtin) Date: Tue, 01 Jan 2013 18:32:19 +0000 Subject: [issue11939] Implement stat.st_dev and os.path.samefile on windows In-Reply-To: <1303923583.07.0.177662562381.issue11939@psf.upfronthosting.co.za> Message-ID: <1357065139.62.0.105726060321.issue11939@psf.upfronthosting.co.za> Brian Curtin added the comment: Backed out the changeset. If you have a solution, feel free to fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 19:40:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 01 Jan 2013 18:40:10 +0000 Subject: [issue16830] Add skip_host and skip_accept_encoding to httplib/http.client In-Reply-To: <1357065011.61.0.0713056005716.issue16830@psf.upfronthosting.co.za> Message-ID: <1357065486.3335.9.camel@localhost.localdomain> Antoine Pitrou added the comment: > On Tue, Jan 1, 2013 at 5:41 AM, Antoine Pitrou wrote: > > Another possibility would be to allow passing None in values of the > `headers` dict, in which case the given header wouldn't be send at > all. > > I agree that your solution is more scaling-friendly than the patch I > originally submitted. But from another perspective, consider how alien > it is to have to explicitly add keys set to None in the headers to get > desired behavior. Well, that is not a common need, is it? That said, we could indeed have a separate argument "omit_headers" listing the headers that we don't want to send. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 19:42:10 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 01 Jan 2013 18:42:10 +0000 Subject: [issue16819] IDLE b"" method completion incorrect In-Reply-To: <1356854538.64.0.0309588990052.issue16819@psf.upfronthosting.co.za> Message-ID: <1357065730.88.0.987355455611.issue16819@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The patch seems good to me. Please commit it. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 19:42:36 2013 From: report at bugs.python.org (Stefan Krah) Date: Tue, 01 Jan 2013 18:42:36 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357065756.54.0.953343768128.issue16076@psf.upfronthosting.co.za> Stefan Krah added the comment: Yes, currently the C version is also used for unpickling. Actually this problem was one of the reasons why _decimal sets its name to "decimal". from test.support import import_fresh_module import pickle, sys C = import_fresh_module('xml.etree.ElementTree', fresh=['_elementtree']) P = import_fresh_module('xml.etree.ElementTree', blocked=['_elementtree']) e = C.Element('foo', bar=42) e.text = "text goes here" e.tail = "opposite of head" C.SubElement(e, 'child').append(C.Element('grandchild')) e.append(C.Element('child')) e.findall('.//grandchild')[0].set('attr', 'other value') sys.modules['xml.etree.ElementTree'] = C s = pickle.dumps(e) s b'\x80\x03c_elementtree\nElement\nq\x00X\x03\x00\x00\x00fooq\x01}q\x02X\x03\x00\x00\x00barq\x03K*s\x86q\x04Rq\x05X \x0e\x00\x00\x00text goes hereq\x06X\x10\x00\x00\x00opposite of headq\x07h\x00X\x05\x00\x00\x00childq\x08\x85q\tRq \nNNh\x00X\n\x00\x00\x00grandchildq\x0b}q\x0cX\x04\x00\x00\x00attrq\rX\x0b\x00\x00\x00other valueq\x0es\x86q\x0fRq \x10NNN\x87q\x11b\x85q\x12\x87q\x13bh\x00h\x08\x85q\x14Rq\x15NNN\x87q\x16b\x86q\x17\x87q\x18b.' sys.modules['xml.etree.ElementTree'] = P x = pickle.loads(s) type(x) ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 20:40:52 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 01 Jan 2013 19:40:52 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357069252.03.0.467900913857.issue16747@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hello Zachary, What'wrong with referencing :class:`file` for iterable? I find it as OK. Also if it needs to be corrected, the reference could be made for :ref:`bltin-file-objects` Re grammatical fixes, you could point out which were made as with the reflow of the text, it is difficult to spot the fix. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 20:48:58 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Jan 2013 19:48:58 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357069738.89.0.681650280911.issue16747@psf.upfronthosting.co.za> R. David Murray added the comment: senthil: the file type doesn't exist any more in python3. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 20:51:46 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Jan 2013 19:51:46 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery Message-ID: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> New submission from Brett Cannon: Don't have the base tests inherit from TestCase else they will be discovered by unittest and run even though they are not fully defined. See http://bugs.python.org/issue16748 as the trigger for this issue. ---------- messages: 178748 nosy: brett.cannon priority: normal severity: normal status: open title: Update PEP 399 to allow for test discovery _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 20:52:07 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Jan 2013 19:52:07 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357069927.1.0.0603372044446.issue16748@psf.upfronthosting.co.za> Brett Cannon added the comment: I created http://bugs.python.org/issue16835 to remind me to update PEP 399. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 20:52:32 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 01 Jan 2013 19:52:32 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357069952.95.0.11750722814.issue16835@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti components: +Documentation nosy: +ezio.melotti stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 21:10:22 2013 From: report at bugs.python.org (Christian Boos) Date: Tue, 01 Jan 2013 20:10:22 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1357071022.73.0.189272014828.issue15564@psf.upfronthosting.co.za> Christian Boos added the comment: I think that reverting to a read_single() when the read_multi() fails could do the trick here. At least this approach seems to work for uploading .mht files. See also http://trac.edgewall.org/ticket/9880. ---------- nosy: +cboos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 21:32:39 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 01 Jan 2013 20:32:39 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357072359.3.0.3192608198.issue16835@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch: 1) the base class doesn't inherit from TestCase anymore -- the subclasses do; 2) added a skipUnless() decorator on the C subclass; 3) used the modern if __name__ == '__main__': unittest.main() idiom; 4) renamed the AcceleratedExampleTest to CExampleTest (I prefer the PyFoo/CFoo parallel, "Accelerated" doesn't necessarily imply that it's testing the C version); 5) added a paragraph to explain the idiom; 6) added Post-History; 7) did a couple of minor cleanup in the code; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 21:36:38 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Jan 2013 20:36:38 +0000 Subject: [issue16819] IDLE b"" method completion incorrect In-Reply-To: <1356854538.64.0.0309588990052.issue16819@psf.upfronthosting.co.za> Message-ID: <3YbRxx62HMzS5L@mail.python.org> Roundup Robot added the comment: New changeset de82da4b04cd by Serhiy Storchaka in branch '2.7': Issue #16819: IDLE method completion now correctly works for unicode literals. http://hg.python.org/cpython/rev/de82da4b04cd New changeset 99a06886b258 by Serhiy Storchaka in branch '3.2': Issue #16819: IDLE method completion now correctly works for bytes literals. http://hg.python.org/cpython/rev/99a06886b258 New changeset b8b5303ac96f by Serhiy Storchaka in branch '3.3': Issue #16819: IDLE method completion now correctly works for bytes literals. http://hg.python.org/cpython/rev/b8b5303ac96f New changeset 00cbbcd8af31 by Serhiy Storchaka in branch 'default': Issue #16819: IDLE method completion now correctly works for bytes literals. http://hg.python.org/cpython/rev/00cbbcd8af31 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 21:38:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Jan 2013 20:38:01 +0000 Subject: [issue16819] IDLE b"" method completion incorrect In-Reply-To: <1356854538.64.0.0309588990052.issue16819@psf.upfronthosting.co.za> Message-ID: <1357072681.93.0.00035973162079.issue16819@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 21:39:06 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 01 Jan 2013 20:39:06 +0000 Subject: [issue16814] use --directory option of make in describing how to build the docs In-Reply-To: <1356880484.32.0.862226241435.issue16814@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: I find, cd Doc easy to remember as well. If make tricks can be used then I hope readers note it rather than be exposed via Documentation. Chris's patch is helpful to me, but still I may not vote a +1 for it to be in Documentation. thanks. On Sun, Dec 30, 2012 at 7:14 AM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > FWIW even if I heard about the one-liner a few times already I can't > really seem to remember it, and prefer to do "cd Doc" anyway. Using "cd > Doc" also makes all the subsequent commands shorter (e.g. opening files, > running other make targets). > The patch proposed by Chris looks OK to me though. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/senthil%40uthcode.com > > ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From senthil at uthcode.com Tue Jan 1 21:39:03 2013 From: senthil at uthcode.com (Senthil Kumaran) Date: Tue, 1 Jan 2013 12:39:03 -0800 Subject: [issue16814] use --directory option of make in describing how to build the docs In-Reply-To: <1356880484.32.0.862226241435.issue16814@psf.upfronthosting.co.za> References: <1356790311.86.0.00498941541992.issue16814@psf.upfronthosting.co.za> <1356880484.32.0.862226241435.issue16814@psf.upfronthosting.co.za> Message-ID: I find, cd Doc easy to remember as well. If make tricks can be used then I hope readers note it rather than be exposed via Documentation. Chris's patch is helpful to me, but still I may not vote a +1 for it to be in Documentation. thanks. On Sun, Dec 30, 2012 at 7:14 AM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > FWIW even if I heard about the one-liner a few times already I can't > really seem to remember it, and prefer to do "cd Doc" anyway. Using "cd > Doc" also makes all the subsequent commands shorter (e.g. opening files, > running other make targets). > The patch proposed by Chris looks OK to me though. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/senthil%40uthcode.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Tue Jan 1 21:55:24 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 01 Jan 2013 20:55:24 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1357069738.89.0.681650280911.issue16747@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: Oh Okay, Thanks! I was checking it against 2.7! On Tue, Jan 1, 2013 at 11:48 AM, R. David Murray wrote: > > R. David Murray added the comment: > > senthil: the file type doesn't exist any more in python3. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 21:56:35 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 01 Jan 2013 20:56:35 +0000 Subject: [issue16820] configparser.ConfigParser.clean and .update bugs In-Reply-To: <1356887573.11.0.450967441519.issue16820@psf.upfronthosting.co.za> Message-ID: <1357073795.39.0.0683387693121.issue16820@psf.upfronthosting.co.za> ?ukasz Langa added the comment: This is a fair point. Stay tuned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 22:06:37 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 01 Jan 2013 21:06:37 +0000 Subject: [issue9586] "warning: comparison between pointer and integer" in multiprocessing build on Tiger In-Reply-To: <1281703428.64.0.285019462814.issue9586@psf.upfronthosting.co.za> Message-ID: <1357074397.87.0.0337806700588.issue9586@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 22:24:05 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Jan 2013 21:24:05 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357075445.02.0.658850783185.issue16208@psf.upfronthosting.co.za> STINNER Victor added the comment: """The switch --disable-ipv6 is supported and works as intended. It is not the intention of the switch to disable AAAA lookups. Instead, it disables support for IPv6 sockets.""" I just think that this definition is not exact. Do you seriously expect IPv6 to work when you explicitly use --disable-ipv6 which *disables* support of IPv6? If you would like to use IPv6, just forget this old configuration option. If you would like to disable IPv6, disable it system-wide. See: http://bugs.python.org/issue7735#msg178634 ---------- nosy: +loewis resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 22:25:32 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Jan 2013 21:25:32 +0000 Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works) In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za> Message-ID: <1357075532.27.0.648254937692.issue16809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The simplest fix probably is just wrap self.tk.call() with str() (I have not tested it yet). However the problem is more serious (tkinter doesn't support fully even 8.5 and subtle bugs are possible) and I'll spend some more time on its research. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 22:30:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Jan 2013 21:30:17 +0000 Subject: [issue16320] Establish order in bytes/string dependencies In-Reply-To: <1351156037.64.0.017004315605.issue16320@psf.upfronthosting.co.za> Message-ID: <1357075817.13.0.102210798663.issue16320@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'll wait for some time, perhaps a Christian wants to say something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 22:37:58 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Jan 2013 21:37:58 +0000 Subject: [issue16820] configparser.ConfigParser.clean and .update bugs In-Reply-To: <1356887573.11.0.450967441519.issue16820@psf.upfronthosting.co.za> Message-ID: <3YbTJg25HjzS3s@mail.python.org> Roundup Robot added the comment: New changeset f580342b63d8 by ?ukasz Langa in branch '3.3': configparser: preserve section order when using `__setitem__` (issue #16820) http://hg.python.org/cpython/rev/f580342b63d8 New changeset a758f561a280 by ?ukasz Langa in branch 'default': Merged section order preservation fix when using `__setitem__` (issue #16820) http://hg.python.org/cpython/rev/a758f561a280 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 22:48:40 2013 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 01 Jan 2013 21:48:40 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357076920.22.0.797638983916.issue16208@psf.upfronthosting.co.za> Ralf Schmitt added the comment: socket getaddrinfo returns garbage: >>> socket.getaddrinfo("python.org", 80) [(2, 1, 6, '', ('82.94.164.162', 80)), (2, 2, 17, '', ('82.94.164.162', 80)), (2, 3, 0, '', ('82.94.164.162', 80)), (10, 1, 6, '', (10, '\x00P\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r')), (10, 2, 17, '', (10, '\x00P\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r')), (10, 3, 0, '', (10, '\x00P\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r'))] yes, I would expect that python didn't give me garbage when calling getaddrinfo. Note that the caller didn't specify AF_INET6 this time! Do you really think that this is not a bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 22:53:19 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Jan 2013 21:53:19 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357077199.44.0.550737890457.issue16208@psf.upfronthosting.co.za> STINNER Victor added the comment: > socket.getaddrinfo("python.org", 80) This is a different issue: it's #7735. > Do you really think that this is not a bug? #7735 is a bug but it was decided that it will not be fixed. You may reopen #7735 if you disagree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 22:57:38 2013 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 01 Jan 2013 21:57:38 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled Message-ID: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> New submission from Ralf Schmitt: The configure script uses a runtime check to determine if IPv6 is working. If IPv6 is disabled system-wide via a kernel option on linux, the resulting python interpreter is compiled as if "--disable-ipv6" had been passed to the configure script. This causes multiple issues: - http://bugs.python.org/issue7735 - http://bugs.python.org/issue16208 Both of the above issues have been closed as wontfix, and I have been told to not use --disable-ipv6 and instead disable IPv6 system wide via a boot option. This is what I did, and now I have the same issue because the configure script has this runtime check... ---------- messages: 178762 nosy: schmir priority: normal severity: normal status: open title: configure script disables support for IPv6 on a system where IPv6 is disabled type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:02:59 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 01 Jan 2013 22:02:59 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled In-Reply-To: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> Message-ID: <1357077779.85.0.963238725892.issue16836@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, I think the runtime check is misguided. If the system provides the required APIs for AF_INET6, then IPv6 support should be enabled regardless of whether the current system config allows to create an IPv6 socket or not. Would you want to provide a patch for this? It's probably simple. ---------- keywords: +easy nosy: +pitrou stage: -> needs patch versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:13:04 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 Jan 2013 22:13:04 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357078384.78.0.420497221673.issue16208@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The data returned is not bogus; this is the correct result. If the system's getaddrinfo returns an unsupported address family, Python returns a bytes object (the system's sockaddr buffer) to the application. This should be documented, though (either in the introduction to the socket module, or specifically for getaddrinfo). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:13:16 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Jan 2013 22:13:16 +0000 Subject: [issue9644] PEP 383: os.statvfs() does not accept surrogateescape arguments In-Reply-To: <1282243237.49.0.435221885834.issue9644@psf.upfronthosting.co.za> Message-ID: <3YbV5S1sXDzS0S@mail.python.org> Roundup Robot added the comment: New changeset 479fca0adbf6 by Victor Stinner in branch '3.2': Issue #9644: Fix the encoding used by os.statvfs(): use the filesystem encoding http://hg.python.org/cpython/rev/479fca0adbf6 New changeset b0cc0b9e2472 by Victor Stinner in branch '3.3': Issue #9644: Add a test on os.statvfs() for the PEP 383 http://hg.python.org/cpython/rev/b0cc0b9e2472 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:18:08 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Jan 2013 22:18:08 +0000 Subject: [issue9644] PEP 383: os.statvfs() does not accept surrogateescape arguments In-Reply-To: <1282243237.49.0.435221885834.issue9644@psf.upfronthosting.co.za> Message-ID: <3YbVC4144WzS0j@mail.python.org> Roundup Robot added the comment: New changeset dbe607fdc271 by Victor Stinner in branch 'default': (Merge 3.3) Issue #9644: Add a test on os.statvfs() for the PEP 383 http://hg.python.org/cpython/rev/dbe607fdc271 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:23:37 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Jan 2013 22:23:37 +0000 Subject: [issue9644] PEP 383: os.statvfs() does not accept surrogateescape arguments In-Reply-To: <1282243237.49.0.435221885834.issue9644@psf.upfronthosting.co.za> Message-ID: <1357079017.55.0.0138554939741.issue9644@psf.upfronthosting.co.za> STINNER Victor added the comment: @baikie: Thanks for the fix, I applied it to Python 3.2 and I added a test. I also added the patch to Python 3.3 and 3.3. You may migrate to Python 3.3, it has a better support for undecodable filenames ;-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:24:39 2013 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 01 Jan 2013 22:24:39 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357079079.91.0.26388928102.issue16208@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Given the fact that the bytes object is rather surprising and probaby useless for the caller I wouldn't call this a "correct result". (sorry, I lost too much time on this issue, I had to put another comment here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:34:30 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 01 Jan 2013 22:34:30 +0000 Subject: [issue11824] freeze.py broken due to ABI flags In-Reply-To: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za> Message-ID: <1357079670.88.0.819639274127.issue11824@psf.upfronthosting.co.za> Meador Inge added the comment: I don't think the current patch is correct. It breaks the usage of `freeze.py -p $path` since LIBDIR and LIBRARY are blindly used. Maybe something like the attached that respects -p and -P can be used instead? As for the testing, I think a reasonable solution to get started with is to add some buildbot runs that automate the hello.py freeze on various hosts. That will give us some basic coverage and then more tests can be added over time if need be. I would be happy to help set that up (with given guidance on how to access the buildbots). Even with the attached patch I still can't fully build (on OS X 10.7.5) because of issue16047: Undefined symbols for architecture x86_64: "_PyInit__imp", referenced from: __PyImport_Inittab in config.o ld: symbol(s) not found for architecture x86_64 I will take a look at that issue next. ---------- assignee: -> meador.inge Added file: http://bugs.python.org/file28519/issue11824-0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:40:00 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 01 Jan 2013 22:40:00 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357080000.24.0.86328468292.issue16076@psf.upfronthosting.co.za> Eli Bendersky added the comment: Thank you for the input Stefan. I was actually glancing at _decimal as an example of implementing pickling and inter-compatibility between the C and Py versions of pickles. You've chosen compatibility by having the same class name and __reduce__ returning the exact same tuple for both implementation. This is a pretty good idea. Unfortunately, in the case of Element it's more difficult, because the existing Py implementation does not have __reduce__, so pickle does its thing by looking at __dict__. Changing the Py version to have a __reduce__ seems risky as it may break compatibility between the different Py versions of Element (say, from 3.2) and this is bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:42:31 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 01 Jan 2013 22:42:31 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> Message-ID: <1357080151.69.0.412855236378.issue16047@psf.upfronthosting.co.za> Meador Inge added the comment: As mentioned, the ABI issues are being handled in issue11824. I believe the linking problems in this issue have to do with the changes that were made in 3.3 to bootstrap importlib into Python. I will look into it more. ---------- assignee: -> meador.inge keywords: +3.3regression stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:48:59 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 Jan 2013 22:48:59 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357080539.94.0.152588003062.issue16208@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's not at all useless: it enables the application to bypass limitations in Python, i.e. process the sockaddr on its own (very much in the same way as you have to do for ioctl/fcntl). Whether it's surprising or not depends on what you expected to happen. Python always tries to expose system interfaces unmodified, so one "should" expect something like this to happen when there is a real chance that the system returns data which Python cannot interpret. What is puzzling is that you (reportedly) get a TypeError when you pass them to the socket creation (or connect); instead, it should tell you that the address family is not supported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:51:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Jan 2013 22:51:23 +0000 Subject: [issue16820] configparser.ConfigParser.clean and .update bugs In-Reply-To: <1356887573.11.0.450967441519.issue16820@psf.upfronthosting.co.za> Message-ID: <3YbVxQ4jrNzS3Z@mail.python.org> Roundup Robot added the comment: New changeset 6f0cee62f0c6 by ?ukasz Langa in branch '3.2': configparser: preserve section order when using `__setitem__` (issue #16820) http://hg.python.org/cpython/rev/6f0cee62f0c6 New changeset 2f5320497017 by ?ukasz Langa in branch '3.3': Null-merged 3.2 section order preservation fix when using `__setitem__` (issue http://hg.python.org/cpython/rev/2f5320497017 New changeset 27b698395d35 by ?ukasz Langa in branch 'default': Null-merged 3.2 section order preservation fix when using `__setitem__` (issue http://hg.python.org/cpython/rev/27b698395d35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:55:01 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 01 Jan 2013 22:55:01 +0000 Subject: [issue16818] Couple of mistakes in PEP 431 In-Reply-To: <1356853990.44.0.712764184905.issue16818@psf.upfronthosting.co.za> Message-ID: <1357080901.48.0.673033771196.issue16818@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:55:41 2013 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 01 Jan 2013 22:55:41 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357080941.82.0.090341984664.issue16208@psf.upfronthosting.co.za> Ralf Schmitt added the comment: The TypeError error happened when using gevent. I've already written in that other issue that this information was wrong and I get a "bad family" error. Sorry, about that. But this also demonstrates my point here. The Type error was raised exactly because the gevent code didn't expect a string at that point! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:56:39 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 01 Jan 2013 22:56:39 +0000 Subject: [issue16820] configparser.ConfigParser.clean and .update bugs In-Reply-To: <1356887573.11.0.450967441519.issue16820@psf.upfronthosting.co.za> Message-ID: <1357080999.03.0.381842025921.issue16820@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Breaking section order when using `__setitem__` was a bug and as such was fixed in 3.2.4 and 3.3.1. In the DEFAULTSECT case above someone could potentially use the broken behaviour as a feature so that change was only made for 3.3.1+. In the section order case there is no such controversy. ---------- resolution: rejected -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 1 23:56:48 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Tue, 01 Jan 2013 22:56:48 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1357055639.81.0.739252265035.issue16076@psf.upfronthosting.co.za> Message-ID: <20130101225642.GB3402@lp-shahaf.local> Daniel Shahaf added the comment: Eli Bendersky wrote on Tue, Jan 01, 2013 at 15:54:00 +0000: > Why did you change the class name, by the way, I don't think it's > a valid change at least for 3.3 in terms of backwards compatibility. > With unmodified tip of 3.4: >>> import pickle, xml.etree.ElementTree as ET >>> pickle.dumps(ET.Element('foo')) Traceback (most recent call last): File "", line 1, in _pickle.PicklingError: Can't pickle : attribute lookup builtins.Element failed I added the "_elementtree" to the tp_name in order to bypass the above error. Module-qualified names were in use elsewhere (including by _elementtree._element_iterator) so it seemed reasonable. I'll defer to you about compatibility implications of this change. > Regarding that compatibility, and even easier idea would be for the > C pickle to return the same __dict__ implicitly gathered from the > Python version, and then only one version of the unpickle is required. That makes sense. But going forward it might be even better to define an explicit __reduce__/__getstate__ for the Python version too, so if the instance dict grows new members, they won't get serialised unintentionally. (This consideration is also why C code in the latest patch makes some effort to notice unknown args in the dict.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:00:36 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Jan 2013 23:00:36 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357081236.73.0.334263157887.issue16747@psf.upfronthosting.co.za> Zachary Ware added the comment: Hi folks, Sorry it's taken me so long to get back to this, it's been a busy month :) Here's the non-reflowed diff. In retrospect, I should have just specifically mentioned the grammatical changes I made in the first place; they were merely to change 'and' between 'dict' and 'file object' to a comma, and add a comma after 'file object'. ---------- Added file: http://bugs.python.org/file28520/iterable_glossary_no-reflow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:03:41 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Jan 2013 23:03:41 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <1357081420.99.0.270439024609.issue16694@psf.upfronthosting.co.za> Zachary Ware added the comment: Sorry, I misunderstood ?ric's suggestions regarding the tests; v6 is useless. v7 forthcoming. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:03:52 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Jan 2013 23:03:52 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <1357081432.38.0.752568233378.issue16694@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file28391/py_operator.v6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:05:23 2013 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 01 Jan 2013 23:05:23 +0000 Subject: [issue13719] bdist_msi upload fails In-Reply-To: <1325855918.9.0.207720990162.issue13719@psf.upfronthosting.co.za> Message-ID: <1357081523.18.0.0625633782637.issue13719@psf.upfronthosting.co.za> Ralf Schmitt added the comment: AFAIK pypi.python.org disallows uploads of .msi files. That means I've lost interest in this issue. Feel free to close it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:07:00 2013 From: report at bugs.python.org (Benno Leslie) Date: Tue, 01 Jan 2013 23:07:00 +0000 Subject: [issue16833] httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <1357081620.57.0.487819921202.issue16833@psf.upfronthosting.co.za> Benno Leslie added the comment: I've updated the patch based on Charles-Fran?ois and Antoine's feedback. Primarily this increase the estimated MSS value to 16KiB. Additionally tests are added and comments improved. Thanks for the feedback. ---------- Added file: http://bugs.python.org/file28521/http_opt_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:07:11 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 01 Jan 2013 23:07:11 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357081631.48.0.584406437123.issue16747@psf.upfronthosting.co.za> Ezio Melotti added the comment: Yes, that would have been better. I actually prefer reflowing text, but pointing out the changes makes reviewing the patch easier. ---------- assignee: docs at python -> ezio.melotti stage: -> commit review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:11:48 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Tue, 01 Jan 2013 23:11:48 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1357000370.87.0.162837799779.issue16076@psf.upfronthosting.co.za> Message-ID: <20130101231143.GC3402@lp-shahaf.local> Daniel Shahaf added the comment: Eli Bendersky wrote on Tue, Jan 01, 2013 at 00:32:51 +0000: > 1. Why did you choose to implement __reduce__ and not __getstate__? Maybe I was simply imitating what some other extension module was doing ;) By using __reduce__ with the type as first return value, the __setstate__ code becomes simpler because it doesn't need to address 'tag' and 'attrib'. This consideration is somewhat moot now that the unpickle-Python-pickled-Element's code path has to think about all instance attributes, including those settable by the constructor. > 2. A lot of code appears to be shared between > element_setstate_from_attributes and the init method implementation, > can it be refactored? It seems there might be room for code reuse --- both functions set tag,text,tail,attrib (but the unpickler sets the children too). I'll look into that in the next iteration (once the class name and pickle output format issues are settled). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:20:26 2013 From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=) Date: Tue, 01 Jan 2013 23:20:26 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1357082426.45.0.877992378426.issue14621@psf.upfronthosting.co.za> Domen Ko?ar added the comment: According to talk at 29c3: http://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html Quote: We also describe a vulnerability of Python's new randomized hash, allowing an attacker to easily recover the 128-bit secret seed. As a reliable fix to hash-flooding, we introduce SipHash, a family of cryptographically strong keyed hash function competitive in performance with the weak hashes, and already adopted in OpenDNS, Perl 5, Ruby, and in the Rust language. ---------- nosy: +iElectric _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:26:03 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 01 Jan 2013 23:26:03 +0000 Subject: [issue16837] Number ABC can be instantiated Message-ID: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: According to the reference manual, "None of the types defined in [numbers] module can be instantiated." However, >>> from numbers import * >>> Number() This can probably be fixed by making Number.__hash__ an abstract method. ---------- messages: 178785 nosy: belopolsky priority: normal severity: normal status: open title: Number ABC can be instantiated type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:29:31 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 01 Jan 2013 23:29:31 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357082971.3.0.0525054932008.issue16747@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Changed lines should still be reflowed to respect the column limit. I was just referring to the unchanged lines before and afterwards that shouldn't be reflowed. Not reflowing makes it easier for people viewing diffs on python-checkins and hg.python.org, using hg annotate, etc. to see what has changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:39:57 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Jan 2013 23:39:57 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <1357083597.94.0.403527460753.issue16694@psf.upfronthosting.co.za> Zachary Ware added the comment: Ok, I believe the attached v7 properly addresses ?ric's concerns about test discovery, and has no other changes unrelated to that compared to v5. Thank you very much to Ezio for directing me towards the json tests for an example to work from. ---------- nosy: +ezio.melotti Added file: http://bugs.python.org/file28522/py_operator.v7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:43:54 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Tue, 01 Jan 2013 23:43:54 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357083834.72.0.45037497765.issue16076@psf.upfronthosting.co.za> Daniel Shahaf added the comment: Also, the class inheritance in the tests should be amended to follow #16835. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:52:29 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 Jan 2013 23:52:29 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357084349.78.0.267866434939.issue16208@psf.upfronthosting.co.za> Martin v. L?wis added the comment: schmir: your information on msi support is probably outdated; pypi.python.org does support MSI files, see for example http://pypi.python.org/pypi/Twisted/12.3.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:53:17 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 Jan 2013 23:53:17 +0000 Subject: [issue13719] bdist_msi upload fails In-Reply-To: <1325855918.9.0.207720990162.issue13719@psf.upfronthosting.co.za> Message-ID: <1357084397.63.0.0711572207024.issue13719@psf.upfronthosting.co.za> Martin v. L?wis added the comment: schmir: your information on msi support is probably outdated; pypi.python.org does support MSI files, see for example http://pypi.python.org/pypi/Twisted/12.3.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:53:43 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 Jan 2013 23:53:43 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357084423.22.0.601749692741.issue16208@psf.upfronthosting.co.za> Martin v. L?wis added the comment: (sorry, wrong issue) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:53:55 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 Jan 2013 23:53:55 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357084435.42.0.164535909124.issue16208@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- Removed message: http://bugs.python.org/msg178789 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 00:54:04 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 Jan 2013 23:54:04 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1357084444.01.0.176733817305.issue16208@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- Removed message: http://bugs.python.org/msg178791 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 01:03:42 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 00:03:42 +0000 Subject: [issue16820] configparser.ConfigParser.clean and .update bugs In-Reply-To: <1356887573.11.0.450967441519.issue16820@psf.upfronthosting.co.za> Message-ID: <3YbXXs3V5FzS8V@mail.python.org> Roundup Robot added the comment: New changeset d5c45089df2d by ?ukasz Langa in branch '3.3': Misc/NEWS updated to tell about #14590 and #16820 http://hg.python.org/cpython/rev/d5c45089df2d New changeset 7938847b2641 by ?ukasz Langa in branch '3.2': Misc/NEWS updated to tell about #16820 http://hg.python.org/cpython/rev/7938847b2641 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 01:03:42 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 00:03:42 +0000 Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space. In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za> Message-ID: <3YbXXt1scmzS5h@mail.python.org> Roundup Robot added the comment: New changeset d5c45089df2d by ?ukasz Langa in branch '3.3': Misc/NEWS updated to tell about #14590 and #16820 http://hg.python.org/cpython/rev/d5c45089df2d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 01:29:05 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 00:29:05 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357086545.84.0.900555227208.issue16835@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 02:32:40 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 01:32:40 +0000 Subject: [issue16818] Couple of mistakes in PEP 431 In-Reply-To: <1356853990.44.0.712764184905.issue16818@psf.upfronthosting.co.za> Message-ID: <1357090360.98.0.451760932079.issue16818@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed in http://hg.python.org/peps/rev/90a9e083933b. I also made a few more fixes in http://hg.python.org/peps/rev/eb668670ad0e. ---------- assignee: -> ezio.melotti nosy: +barry, ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 03:10:53 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 02:10:53 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357092653.6.0.851609500886.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached patch fixes Lib/test/test_heapq.py. I also replaced the test_main() with unittest.main() and got rid of the code previously used to "test" reference leaks. As it is the patch can be applied on 3.3/default. If you think it should be backported to 2.7/3.2 too, the changes on test_main() should be reverted. ---------- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file28523/issue16748.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 04:46:40 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 03:46:40 +0000 Subject: [issue14393] Incorporate Guide to Magic Methods? In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za> Message-ID: <1357098400.32.0.845038199776.issue14393@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 04:56:50 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 02 Jan 2013 03:56:50 +0000 Subject: [issue16833] http.client delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <1357099010.38.0.0901721066428.issue16833@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- title: httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages -> http.client delayed ack / Nagle algorithm optimisation performs badly for large messages _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 05:14:32 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Jan 2013 04:14:32 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <1357100072.31.0.167035139293.issue16694@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file28524/py_operator.v8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 05:20:45 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Jan 2013 04:20:45 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357100445.64.0.350379828243.issue16747@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file28525/issue16747.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 05:20:56 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Jan 2013 04:20:56 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357100456.04.0.970960644583.issue16747@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file28520/iterable_glossary_no-reflow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 05:21:04 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Jan 2013 04:21:04 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357100464.35.0.665718998358.issue16747@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file28392/iterable_glossary.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 05:26:35 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 02 Jan 2013 04:26:35 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1357100464.35.0.665718998358.issue16747@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: I reviewed the patch. Changes LGTM. ---------- _______________________________________ Python tracker _______________________________________ From senthil at uthcode.com Wed Jan 2 05:26:33 2013 From: senthil at uthcode.com (Senthil Kumaran) Date: Tue, 1 Jan 2013 20:26:33 -0800 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1357100464.35.0.665718998358.issue16747@psf.upfronthosting.co.za> References: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> <1357100464.35.0.665718998358.issue16747@psf.upfronthosting.co.za> Message-ID: I reviewed the patch. Changes LGTM. -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Wed Jan 2 06:31:33 2013 From: senthil at uthcode.com (Senthil Kumaran) Date: Tue, 1 Jan 2013 21:31:33 -0800 Subject: [issue13810] refer people to Doc/Makefile when not using 'make' to build main documentation In-Reply-To: <1356799688.24.0.1911555985.issue13810@psf.upfronthosting.co.za> References: <1326844922.3.0.806900590875.issue13810@psf.upfronthosting.co.za> <1356799688.24.0.1911555985.issue13810@psf.upfronthosting.co.za> Message-ID: I think, the the URLs on this page are correct ( or have been corrected since the opening of this issue) - http://hg.python.org/devguide/file/20333d160f4e/documenting.rst If anything needs to be changed, then a patch would be helpful. On Sat, Dec 29, 2012 at 8:48 AM, Tshepang Lekhonkhobe < report at bugs.python.org> wrote: > > Tshepang Lekhonkhobe added the comment: > > > Additionally, the whole way we're fetching those tools will be revisited > soon. > > What are/were your plans ? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/senthil%40uthcode.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Wed Jan 2 06:31:35 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 02 Jan 2013 05:31:35 +0000 Subject: [issue13810] refer people to Doc/Makefile when not using 'make' to build main documentation In-Reply-To: <1356799688.24.0.1911555985.issue13810@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: I think, the the URLs on this page are correct ( or have been corrected since the opening of this issue) - http://hg.python.org/devguide/file/20333d160f4e/documenting.rst If anything needs to be changed, then a patch would be helpful. On Sat, Dec 29, 2012 at 8:48 AM, Tshepang Lekhonkhobe < report at bugs.python.org> wrote: > > Tshepang Lekhonkhobe added the comment: > > > Additionally, the whole way we're fetching those tools will be revisited > soon. > > What are/were your plans ? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/senthil%40uthcode.com > > ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 06:52:45 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Jan 2013 05:52:45 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1357105965.59.0.0975218410934.issue14621@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks for the information! I'm working on a PEP for the issue at hand. ---------- assignee: -> christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 06:54:36 2013 From: report at bugs.python.org (Eiro Neemous) Date: Wed, 02 Jan 2013 05:54:36 +0000 Subject: [issue16838] fail to import "locale" module when there Message-ID: <1357106076.58.0.0839092173031.issue16838@psf.upfronthosting.co.za> Changes by Eiro Neemous : ---------- components: 2to3 (2.x to 3.x conversion tool) nosy: Cravix priority: normal severity: normal status: open title: fail to import "locale" module when there versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 06:55:41 2013 From: report at bugs.python.org (Eiro Neemous) Date: Wed, 02 Jan 2013 05:55:41 +0000 Subject: [issue16838] fail to import "locale" module when there's a dir named "locale" in pwd Message-ID: <1357106141.06.0.608532192635.issue16838@psf.upfronthosting.co.za> New submission from Eiro Neemous: as title said, what's the problem? ---------- title: fail to import "locale" module when there -> fail to import "locale" module when there's a dir named "locale" in pwd type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 06:57:03 2013 From: report at bugs.python.org (Eiro Neemous) Date: Wed, 02 Jan 2013 05:57:03 +0000 Subject: [issue16838] fail to "import locale" when there's a dir named "locale" in current dir In-Reply-To: <1357106141.06.0.608532192635.issue16838@psf.upfronthosting.co.za> Message-ID: <1357106223.89.0.382621253554.issue16838@psf.upfronthosting.co.za> Changes by Eiro Neemous : ---------- title: fail to import "locale" module when there's a dir named "locale" in pwd -> fail to "import locale" when there's a dir named "locale" in current dir _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 08:08:20 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 02 Jan 2013 07:08:20 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1357110500.66.0.135528026544.issue14621@psf.upfronthosting.co.za> Nick Coghlan added the comment: Bob, the hash invariant isn't a mere implementation detail, it is critical to making hash based data structures work properly - if two equal objects (say the integer zero and the float zero) ever end up in different hash bins, then the uniqueness property of dictionary keys and sets breaks down. The three proposed mitigation strategies (using SipHash for string hashing, a tunable collision counting hash map and providing a non-hash based mapping container in the standard library) are all reasonable approaches to the problem and, most importantly, they're *orthogonal* approaches to the problem. There's nothing stopping us doing all three if someone is willing and able to provide the code. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 08:54:06 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Jan 2013 07:54:06 +0000 Subject: [issue16838] fail to "import locale" when there's a dir named "locale" in current dir In-Reply-To: <1357106141.06.0.608532192635.issue16838@psf.upfronthosting.co.za> Message-ID: <1357113246.76.0.275624951113.issue16838@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm not able to reproduce the issue. Please provide a step by step description of what you did. Does the locale directory contain any files? ---------- nosy: +christian.heimes type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 09:03:04 2013 From: report at bugs.python.org (Eiro Neemous) Date: Wed, 02 Jan 2013 08:03:04 +0000 Subject: [issue16838] fail to "from locale import getpreferredencoding" when there's a dir named "locale" in current dir In-Reply-To: <1357106141.06.0.608532192635.issue16838@psf.upfronthosting.co.za> Message-ID: <1357113784.79.0.993022738863.issue16838@psf.upfronthosting.co.za> Eiro Neemous added the comment: @Christian: Sorry that I didnt' attached test file= = It was long ago that I met this problem, so forget some details= = The right description is "cannot do 'from locale import getpreferredencoding'". please extract the attached zip file and test "from locale import getpreferredencoding". ---------- title: fail to "import locale" when there's a dir named "locale" in current dir -> fail to "from locale import getpreferredencoding" when there's a dir named "locale" in current dir Added file: http://bugs.python.org/file28526/locale.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 09:13:06 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Jan 2013 08:13:06 +0000 Subject: [issue16838] fail to "from locale import getpreferredencoding" when there's a dir named "locale" in current dir In-Reply-To: <1357106141.06.0.608532192635.issue16838@psf.upfronthosting.co.za> Message-ID: <1357114386.4.0.492077893698.issue16838@psf.upfronthosting.co.za> Christian Heimes added the comment: Your locale directory contains a __init__.py file. The file causes the directory to become a Python package, that shadows the locale module from Python's standard library. Please remove the __init__.py file and __pycache__ directory to fix your problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 09:20:23 2013 From: report at bugs.python.org (Eiro Neemous) Date: Wed, 02 Jan 2013 08:20:23 +0000 Subject: [issue16838] fail to "from locale import getpreferredencoding" when there's a dir named "locale" in current dir In-Reply-To: <1357106141.06.0.608532192635.issue16838@psf.upfronthosting.co.za> Message-ID: <1357114823.84.0.717281157477.issue16838@psf.upfronthosting.co.za> Eiro Neemous added the comment: @Christian: OK, get it, thank you for your explanation :-) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 09:53:02 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 08:53:02 +0000 Subject: [issue16541] tk_setPalette doesn't accept keyword parameters In-Reply-To: <1353691491.46.0.777146427691.issue16541@psf.upfronthosting.co.za> Message-ID: <3YbmHf0X1xzS6P@mail.python.org> Roundup Robot added the comment: New changeset 956cfe53a99f by Serhiy Storchaka in branch '3.2': Issue #16541: tk_setPalette() now works with keyword arguments. http://hg.python.org/cpython/rev/956cfe53a99f New changeset 1ac028634b60 by Serhiy Storchaka in branch '3.3': Issue #16541: tk_setPalette() now works with keyword arguments. http://hg.python.org/cpython/rev/1ac028634b60 New changeset 589e6175f037 by Serhiy Storchaka in branch 'default': Issue #16541: tk_setPalette() now works with keyword arguments. http://hg.python.org/cpython/rev/589e6175f037 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 10:03:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 09:03:51 +0000 Subject: [issue16541] tk_setPalette doesn't accept keyword parameters In-Reply-To: <1353691491.46.0.777146427691.issue16541@psf.upfronthosting.co.za> Message-ID: <1357117431.57.0.279091539526.issue16541@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 10:08:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 09:08:28 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357117708.3.0.984318048826.issue16829@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But then will be problems with filenames containing ". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 10:37:26 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 02 Jan 2013 09:37:26 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357119446.29.0.673527482099.issue16829@psf.upfronthosting.co.za> Ramchandra Apte added the comment: I think if IDLE directly starts lpr directly (subprocess) rather than using a shell to run it, then this problem won't happen. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 11:02:31 2013 From: report at bugs.python.org (Giovanni Bajo) Date: Wed, 02 Jan 2013 10:02:31 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1357082426.45.0.877992378426.issue14621@psf.upfronthosting.co.za> Message-ID: <0505B8CD-224D-4955-88C1-E298784562D6@gmail.com> Giovanni Bajo added the comment: Il giorno 02/gen/2013, alle ore 00:20, Domen Ko?ar ha scritto: > > Domen Ko?ar added the comment: > > According to talk at 29c3: http://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html > > Quote: We also describe a vulnerability of Python's new randomized hash, allowing an attacker to easily recover the 128-bit secret seed. As a reliable fix to hash-flooding, we introduce SipHash, a family of cryptographically strong keyed hash function competitive in performance with the weak hashes, and already adopted in OpenDNS, Perl 5, Ruby, and in the Rust language. That is exactly the vulnerability that was previously mentioned in the context of this bug. SipHash is currently the only solution for a collision-resistant fast-enough hash. -- Giovanni Bajo ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 11:15:43 2013 From: report at bugs.python.org (Giovanni Bajo) Date: Wed, 02 Jan 2013 10:15:43 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1357105965.59.0.0975218410934.issue14621@psf.upfronthosting.co.za> Message-ID: Giovanni Bajo added the comment: Il giorno 02/gen/2013, alle ore 06:52, Christian Heimes ha scritto: > > Christian Heimes added the comment: > > Thanks for the information! I'm working on a PEP for the issue at hand. Since you're collecting ideas on this, I would like to stress that, in the Python 3 transition, it was deemed acceptable to switch all objects to use unicode strings for attribute names, making the hash computation of such attributes (in the context of the instance dictionary) at least twice as slow than it used to be (the 'at least' refers to the fact that longer strings might have even worse effects because of a higher number of cache misses). SipHash isn't twice as slow as the current hash function, not even for short strings. So there is a precedent in slowing down the hash computation time in a very important use case, and it doesn't look like hell froze over. -- Giovanni Bajo ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 13:32:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 12:32:39 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1357129959.77.0.0912950272875.issue13968@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated for current tip. ---------- Added file: http://bugs.python.org/file28527/glob_recursive_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 13:32:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 12:32:59 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1357129979.18.0.185554845377.issue13968@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 13:33:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 12:33:27 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1357130007.51.0.430470111102.issue13968@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28213/glob_recursive.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 13:36:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 12:36:46 +0000 Subject: [issue16761] Fix int(base=X) In-Reply-To: <1356344179.57.0.256003858099.issue16761@psf.upfronthosting.co.za> Message-ID: <1357130206.89.0.664818999304.issue16761@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 14:23:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 13:23:51 +0000 Subject: [issue16630] IDLE: Calltip fails if __getattr__ raises exception In-Reply-To: <1354844775.58.0.855877358898.issue16630@psf.upfronthosting.co.za> Message-ID: <1357133031.52.0.0633183262496.issue16630@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 14:50:36 2013 From: report at bugs.python.org (Masaya Suzuki) Date: Wed, 02 Jan 2013 13:50:36 +0000 Subject: [issue16839] segmentation fault when unicode(classic_class_instance) Message-ID: <1357134636.13.0.449777533909.issue16839@psf.upfronthosting.co.za> New submission from Masaya Suzuki: Python 2.7.3 crushes when the following code is run without any library, which means run python with -S option: class Test: pass unicode(Test()) In the course of the interpreter tries to find the "__unicode__" attribute in a class, it uses a cached python string of "__unicode__". The reason of this crush is that the cached value is used before initialized. It is initialized only when trying to find the one of a new-style class, so the interpreter will crush if one uses only classic classes. The attached patch will fix this issue by initializing a cached value before it is used. Thanks. ---------- components: Interpreter Core files: object_unicode.patch keywords: patch messages: 178811 nosy: draftcode priority: normal severity: normal status: open title: segmentation fault when unicode(classic_class_instance) type: crash versions: Python 2.7 Added file: http://bugs.python.org/file28528/object_unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 15:16:42 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Jan 2013 14:16:42 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357136202.03.0.19518898006.issue16748@psf.upfronthosting.co.za> Brett Cannon added the comment: Why remove the refleak tests? I'm sure Raymond put those in for a reason as I know he tries to reuse various objects a lot and this helped make sure he didn't mess anything up. I don't think the tests need to be backported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 15:19:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 14:19:23 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <1357136363.01.0.512967447374.issue16694@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: v8 LGTM (except some trailing whitespaces). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 15:32:32 2013 From: report at bugs.python.org (Daniel Urban) Date: Wed, 02 Jan 2013 14:32:32 +0000 Subject: [issue16839] segmentation fault when unicode(classic_class_instance) In-Reply-To: <1357134636.13.0.449777533909.issue16839@psf.upfronthosting.co.za> Message-ID: <1357137152.64.0.0689432622864.issue16839@psf.upfronthosting.co.za> Changes by Daniel Urban : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 15:49:30 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 02 Jan 2013 14:49:30 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: Message-ID: Benjamin Peterson added the comment: 2013/1/2 Giovanni Bajo : > > Giovanni Bajo added the comment: > > Il giorno 02/gen/2013, alle ore 06:52, Christian Heimes ha scritto: > >> >> Christian Heimes added the comment: >> >> Thanks for the information! I'm working on a PEP for the issue at hand. > > Since you're collecting ideas on this, I would like to stress that, in the Python 3 transition, it was deemed acceptable to switch all objects to use unicode strings for attribute names, making the hash computation of such attributes (in the context of the instance dictionary) at least twice as slow than it used to be (the 'at least' refers to the fact that longer strings might have even worse effects because of a higher number of cache misses). SipHash isn't twice as slow as the current hash function, not even for short strings. > > So there is a precedent in slowing down the hash computation time in a very important use case, and it doesn't look like hell froze over. It's probably not to bad for attribute names because a) they're short b) they're interned c) the hash is cached. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 16:09:13 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 15:09:13 +0000 Subject: [issue16840] Tkinter doesn't support large integers Message-ID: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: A long time Tcl got support first 64-bit integers, and then arbitrary size integers. Python also supports arbitrary size integers. However Tkinter supports only C?long integers. For example, on 32-bit platform: >>> import tkinter >>> t = tkinter.Tk() >>> t.tk.call('expr', 2**30) 1073741824 >>> t.tk.call('expr', 2**31) >>> t.tk.call('expr', 2**63) Those and are not usable from Python. Potentially this can cause errors in some rare circumstances. I'm working on a patch, but was faced with a problem. Tcl provides functions for conversions between Bignum Tcl object and mp_int, but it does not provide all functions for conversions between mp_int and bytes sequence. Which is better, add libtommath library to CPython dependencies, or implement the missing functionality manually? Or may be use haxadecimal representation for conversions? ---------- assignee: serhiy.storchaka components: Tkinter messages: 178815 nosy: gpolo, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Tkinter doesn't support large integers type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 16:32:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 15:32:57 +0000 Subject: [issue16841] Set st_dev on Windows as unsigned long Message-ID: <1357140777.81.0.151859871717.issue16841@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: st_dev field of stat() result was set as signed long or long long, but now it is unsigned long on Windows (see issue11939). The proposed patch uses appropriate conversion for it. ---------- components: Extension Modules, Windows files: st_dev_unsigned.patch keywords: patch messages: 178816 nosy: brian.curtin, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Set st_dev on Windows as unsigned long type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file28529/st_dev_unsigned.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 16:35:16 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 02 Jan 2013 15:35:16 +0000 Subject: [issue16839] segmentation fault when unicode(classic_class_instance) In-Reply-To: <1357134636.13.0.449777533909.issue16839@psf.upfronthosting.co.za> Message-ID: <1357140916.6.0.101995703325.issue16839@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thank you for the bug report. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 16:37:52 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 15:37:52 +0000 Subject: [issue16839] segmentation fault when unicode(classic_class_instance) In-Reply-To: <1357134636.13.0.449777533909.issue16839@psf.upfronthosting.co.za> Message-ID: <3YbxGl5qPvzM87@mail.python.org> Roundup Robot added the comment: New changeset 0012d4f0ca59 by Benjamin Peterson in branch '2.7': ensure the attribute name string is initalized before using it (closes #16839) http://hg.python.org/cpython/rev/0012d4f0ca59 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:06:45 2013 From: report at bugs.python.org (Meador Inge) Date: Wed, 02 Jan 2013 16:06:45 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> Message-ID: <1357142805.9.0.59504210268.issue16047@psf.upfronthosting.co.za> Meador Inge added the comment: After applying the fix for issue11824 to tip there ended up being three more issues: 1. makeconfig.py should have been updated in d777f854a66e when changing imp to _imp. Without this change a reference to 'PyInit__imp' was being generated, but that function does not actually exist. 2. After fixing (1) I hit an issue where '_frozen_importlib' can not be found while bringing up the interpreter. 3. After fixing (2) I hit the following error when running the simple frozen hello app: $ ./hello Traceback (most recent call last): ... File "/Users/meadori/Code/src/cpython/Lib/site.py", line 578, in main setcopyright() File "/Users/meadori/Code/src/cpython/Lib/site.py", line 438, in setcopyright here = os.path.dirname(os.__file__) AttributeError: 'module' object has no attribute '__file__' This happens during 'initsite' and is because of a change made to remove the __file__ attribute from frozen modules in 702009f3c0b1. The attached patch fixes (1) by filtering '_imp' instead of 'imp' in makeconfig.py, (2) by making sure '_frozen_importlib' is in the frozen module table created by freeze.py, and (3) by removing the code to delete __file__ from frozen modules. I am a little unsure about (3) since I am not sure why the __file__ attribute is being removed to begin with. eric.smith? ---------- keywords: +patch nosy: +brett.cannon, eric.smith Added file: http://bugs.python.org/file28530/issue16047-0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:11:17 2013 From: report at bugs.python.org (Brian Curtin) Date: Wed, 02 Jan 2013 16:11:17 +0000 Subject: [issue16841] Set st_dev on Windows as unsigned long In-Reply-To: <1357140777.81.0.151859871717.issue16841@psf.upfronthosting.co.za> Message-ID: <1357143077.55.0.539658851342.issue16841@psf.upfronthosting.co.za> Brian Curtin added the comment: Looks good. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:22:15 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 02 Jan 2013 16:22:15 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1357142805.9.0.59504210268.issue16047@psf.upfronthosting.co.za> Message-ID: <20130102112210.6930ca1f@resist.wooz.org> Barry A. Warsaw added the comment: On Jan 02, 2013, at 04:06 PM, Meador Inge wrote: >I am a little unsure about (3) since I am not sure why the __file__ attribute >is being removed to begin with. eric.smith? This is related to PEP 420, which relaxes the requirement that all modules have a __file__ attribute. Now they only need it if it makes sense. At the time, we didn't think it made sense for frozen modules to have an __file__. FrozenImporter.module_repr() provides a reasonable repr in the absence of __file__. I'm not sure what to do. I still think it doesn't make a lot of sense for frozen modules to have an __file__, but perhaps practicality beats purity here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:23:55 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 16:23:55 +0000 Subject: [issue16841] Set st_dev on Windows as unsigned long In-Reply-To: <1357140777.81.0.151859871717.issue16841@psf.upfronthosting.co.za> Message-ID: <3YbyHt3QwBzS1q@mail.python.org> Roundup Robot added the comment: New changeset 07d07111cec9 by Serhiy Storchaka in branch 'default': Issue #16841: Set st_dev on Windows as unsigned long to match its DWORD type. http://hg.python.org/cpython/rev/07d07111cec9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:29:35 2013 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 02 Jan 2013 16:29:35 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> Message-ID: <1357144175.31.0.615325626341.issue16047@psf.upfronthosting.co.za> Eric V. Smith added the comment: What Barry said. :) I haven't had time to check yet: but why does site.py need the __file__ attribute? Maybe that's the actual problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:34:40 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 02 Jan 2013 16:34:40 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1357144175.31.0.615325626341.issue16047@psf.upfronthosting.co.za> Message-ID: <20130102113437.2f98df5f@resist.wooz.org> Barry A. Warsaw added the comment: On Jan 02, 2013, at 04:29 PM, Eric V. Smith wrote: >I haven't had time to check yet: but why does site.py need the __file__ >attribute? Maybe that's the actual problem. It uses it to find the license text when you type license() at the interactive prompt. I think setcopyright() should just ignore that if os.__file__ isn't defined. Why would you be printing the license at a prompt in a frozen Python? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:43:55 2013 From: report at bugs.python.org (Matthias Klose) Date: Wed, 02 Jan 2013 16:43:55 +0000 Subject: [issue16828] bz2 error on compression of empty string In-Reply-To: <1356973084.81.0.547571826956.issue16828@psf.upfronthosting.co.za> Message-ID: <1357145035.29.0.25977068637.issue16828@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:53:54 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Jan 2013 16:53:54 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> Message-ID: <1357145634.77.0.779472140311.issue16047@psf.upfronthosting.co.za> Brett Cannon added the comment: I agree that it makes no sense to define __file__ for frozen modules. Originally they did because that was the only way to tell if a module was a builtin module or not, but with the imp module's API on top of sys.builtin_module_names, there is no need to maintain this invariant. As for site.py requiring the module to have a __file__ on os, I think that is somewhat bogus as well and should be optional so issue (3) for Meador should be to patch site.py to not flat-out require os.__file__ exist. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 17:56:55 2013 From: report at bugs.python.org (Matthias Klose) Date: Wed, 02 Jan 2013 16:56:55 +0000 Subject: [issue16828] bz2 error on compression of empty string In-Reply-To: <1356973084.81.0.547571826956.issue16828@psf.upfronthosting.co.za> Message-ID: <1357145815.71.0.484730334071.issue16828@psf.upfronthosting.co.za> Matthias Klose added the comment: looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 18:02:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 17:02:37 +0000 Subject: [issue16841] Set st_dev on Windows as unsigned long In-Reply-To: <1357140777.81.0.151859871717.issue16841@psf.upfronthosting.co.za> Message-ID: <1357146157.62.0.710106355595.issue16841@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 18:30:06 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 17:30:06 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1357147806.95.0.180600934091.issue15239@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 18:37:37 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 02 Jan 2013 17:37:37 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1357148257.9.0.596833952129.issue16837@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Attached patch fixes the issue and passes regression tests, so most likely the ability to instantiate Number is not an intentional feature. "pass" should probably be replaced with a meaningful docstring, but I would like to hear from others on whether the solution is conceptually correct before making it commit-ready. ---------- keywords: +patch nosy: +eric.araujo, ncoghlan, rhettinger stage: -> patch review Added file: http://bugs.python.org/file28531/issue16837.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 18:56:49 2013 From: report at bugs.python.org (Catalin Iacob) Date: Wed, 02 Jan 2013 17:56:49 +0000 Subject: [issue8745] zipimport is a bit slow In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za> Message-ID: <1357149409.57.0.607857349002.issue8745@psf.upfronthosting.co.za> Catalin Iacob added the comment: Yes Serhiy, I was planning to, lack of time followed by (just finished) vacation lead to a stall. Thanks for following up on this. I should soon, probably this weekend, have an updated version addressing your comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:16:14 2013 From: report at bugs.python.org (Tom Tromey) Date: Wed, 02 Jan 2013 18:16:14 +0000 Subject: [issue15516] exception-handling bug in PyString_Format In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za> Message-ID: <1357150574.02.0.219896681713.issue15516@psf.upfronthosting.co.za> Tom Tromey added the comment: It does fail without the patch: test_format XXX undetected error test test_format failed -- Traceback (most recent call last): File "/home/tromey/Space/Python/cpython/Lib/test/test_format.py", line 251, in test_format def test_exc(formatstr, args, exception, excmsg): File "/home/tromey/Space/Python/cpython/Lib/test/test_format.py", line 240, in __int__ raise TestFailed TestFailed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:18:06 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Jan 2013 18:18:06 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <1357150686.31.0.847658526679.issue16694@psf.upfronthosting.co.za> Zachary Ware added the comment: Note to self: learn to run patchcheck.py before posting. Whitespace issues fixed in v9. ---------- Added file: http://bugs.python.org/file28532/py_operator.v9.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:18:59 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 18:18:59 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357150739.33.0.352583158486.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Why remove the refleak tests? Because regrtest already provides the feature, so I don't see a reason to duplicate it here. FWIW the same code is copy/pasted elsewhere too, e.g. in Lib/test/test_operator.py:438. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:23:42 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 18:23:42 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1357151022.27.0.0955784785764.issue16701@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:23:45 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 18:23:45 +0000 Subject: [issue15516] exception-handling bug in PyString_Format In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za> Message-ID: <3Yc0y84pSJzS1m@mail.python.org> Roundup Robot added the comment: New changeset 80cfd4caa726 by Benjamin Peterson in branch '2.7': call PyErr_Clear() when ignoring error from PyNumber_Int (closes #15516) http://hg.python.org/cpython/rev/80cfd4caa726 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:25:35 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 02 Jan 2013 18:25:35 +0000 Subject: [issue15516] exception-handling bug in PyString_Format In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za> Message-ID: <1357151135.74.0.202983291006.issue15516@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the patch. For future reference, we use spaces instead of tabs. ---------- resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:26:04 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 02 Jan 2013 18:26:04 +0000 Subject: [issue15516] exception-handling bug in PyString_Format In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za> Message-ID: <1357151164.95.0.0165401554387.issue15516@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:28:05 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Jan 2013 18:28:05 +0000 Subject: [issue16737] Different behaviours in script run directly and via runpy.run_module In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za> Message-ID: <1357151285.29.0.392077121083.issue16737@psf.upfronthosting.co.za> Brett Cannon added the comment: Just to have this written down somewhere, site.py already goes through and changes __file__ to absolute for modules already imported before it is run, so there is some precedent to not caring about relative file paths. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:30:00 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Jan 2013 18:30:00 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357151400.08.0.176143794558.issue16748@psf.upfronthosting.co.za> Brett Cannon added the comment: The patch LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:51:52 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Jan 2013 18:51:52 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1357152712.45.0.811391231368.issue14621@psf.upfronthosting.co.za> Christian Heimes added the comment: Giovanni, why do you think that hashing of unicode strings is slower than byte strings? First of all ASCII only unicode strings are packed and use just one byte per char. CPython's FNV implementation processes one element in each cycle, that is one byte for bytes and ASCII unicode, two bytes for UCS-2 and four bytes for UCS-4. Bytes and UCS-4 strings require the same amount of CPU instructions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 19:56:26 2013 From: report at bugs.python.org (Giovanni Bajo) Date: Wed, 02 Jan 2013 18:56:26 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1357152712.45.0.811391231368.issue14621@psf.upfronthosting.co.za> Message-ID: Giovanni Bajo added the comment: Il giorno 02/gen/2013, alle ore 19:51, Christian Heimes ha scritto: > > Christian Heimes added the comment: > > Giovanni, why do you think that hashing of unicode strings is slower than byte strings? > > First of all ASCII only unicode strings are packed and use just one byte per char. CPython's FNV implementation processes one element in each cycle, that is one byte for bytes and ASCII unicode, two bytes for UCS-2 and four bytes for UCS-4. Bytes and UCS-4 strings require the same amount of CPU instructions. Ah sorry, I stand corrected (though packing wasn't there in 3.0, was it? I was specifically referred to the 2.x -> 3.0 transition). -- Giovanni Bajo My Blog: http://giovanni.bajo.it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 20:12:22 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 19:12:22 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <1357153942.34.0.285669512781.issue16694@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If no one objects I will commit this next week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 20:23:11 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 19:23:11 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <3Yc2Gl0PwBzS2B@mail.python.org> Roundup Robot added the comment: New changeset 008bac4e181c by Ezio Melotti in branch '3.3': #16748: test_heapq now works with unittest test discovery. http://hg.python.org/cpython/rev/008bac4e181c New changeset de6bac0a40cc by Ezio Melotti in branch 'default': #16748: merge with 3.3. http://hg.python.org/cpython/rev/de6bac0a40cc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 20:26:01 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 19:26:01 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357154761.8.0.756148942763.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the review! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 20:27:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 19:27:40 +0000 Subject: [issue16748] Ensure test discovery doesn't break for modules testing C and Python implementations In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357154860.97.0.842641335107.issue16748@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As I mentioned above, not only test_heapq uses this idiom, but a lot of other tests. Try to fix hard cases first: test_genericpath and test_functools. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 20:42:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 19:42:48 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1357155768.72.0.681222240401.issue14621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See microbenchmark results in issue16427. Really hashing of ASCII/UCS1 strings more than 2x slower than bytes hashing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 20:59:01 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 19:59:01 +0000 Subject: [issue16801] Preserve original representation for integers / floats in docstrings In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za> Message-ID: <1357156741.01.0.827574330824.issue16801@psf.upfronthosting.co.za> Ezio Melotti added the comment: Either repeating the default value in the text with the desired form (and leave it "wrong" in the signature) or what Georg suggested in msg178519 sound good to me. I don't think anything more than that is necessary to solve this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 21:04:17 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 20:04:17 +0000 Subject: [issue16827] Remove the relatively advanced content from section 2 in tutorial In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za> Message-ID: <1357157057.98.0.945872725965.issue16827@psf.upfronthosting.co.za> Ezio Melotti added the comment: Those section could be moved to an appendix or somewhere near http://docs.python.org/3/tutorial/interactive.html. Note that this page and the one about float issues could be appendices too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 21:06:47 2013 From: report at bugs.python.org (Philip Jenvey) Date: Wed, 02 Jan 2013 20:06:47 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357157207.35.0.659404121986.issue16835@psf.upfronthosting.co.za> Philip Jenvey added the comment: Hey Ezio, you forgot to attach the patch ---------- nosy: +pjenvey _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 21:08:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 20:08:25 +0000 Subject: [issue16842] Allow to override a function signature for pydoc with a docstring Message-ID: <1357157305.88.0.0239428638229.issue16842@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Just a quote of Georg Brandl's msg178519: > A simple, minimal-invasive solution would be to allow a signature for documentation purposes as the first line of the docstrings. > > pydoc could recognize this (if docstring.startswith(func.__name__ + '(') or something like that), and display the given signature instead of the introspected one. I see only one obstacle. Some functions (like dict.update()) needs several signatures. How detect and format them? ---------- components: Interpreter Core messages: 178846 nosy: georg.brandl, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Allow to override a function signature for pydoc with a docstring type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 21:08:29 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 20:08:29 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357157309.89.0.833143420846.issue16835@psf.upfronthosting.co.za> Ezio Melotti added the comment: That would explain why no one was reviewing it :) ---------- keywords: +patch Added file: http://bugs.python.org/file28533/issue16835.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 21:30:10 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 20:30:10 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <3Yc3m12BTHzS49@mail.python.org> Roundup Robot added the comment: New changeset 2afc0997e440 by Ezio Melotti in branch '3.2': #16747: fix link to file objects in the glossary. http://hg.python.org/cpython/rev/2afc0997e440 New changeset 6e4fc5e2acf8 by Ezio Melotti in branch '3.3': #16747: merge with 3.2. http://hg.python.org/cpython/rev/6e4fc5e2acf8 New changeset e19ed347523e by Ezio Melotti in branch 'default': #16747: merge with 3.3. http://hg.python.org/cpython/rev/e19ed347523e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 21:31:01 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 20:31:01 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <1357158661.06.0.395151196164.issue16747@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report and the patch! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 21:44:45 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 02 Jan 2013 20:44:45 +0000 Subject: [issue16839] segmentation fault when unicode(classic_class_instance) In-Reply-To: <1357134636.13.0.449777533909.issue16839@psf.upfronthosting.co.za> Message-ID: <1357159485.78.0.886866178854.issue16839@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 21:48:41 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 20:48:41 +0000 Subject: [issue13810] refer people to Doc/Makefile when not using 'make' to build main documentation In-Reply-To: <1326844922.3.0.806900590875.issue13810@psf.upfronthosting.co.za> Message-ID: <3Yc49N5mc1zS26@mail.python.org> Roundup Robot added the comment: New changeset 47df28c52840 by Ezio Melotti in branch 'default': #13810: fix Sphinx URL. http://hg.python.org/devguide/rev/47df28c52840 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 22:14:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 Jan 2013 21:14:30 +0000 Subject: [issue16843] sporadic test_sched failure Message-ID: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Just got this: [255/372/1] test_sched Warning -- threading._dangling was modified by test_sched test test_sched failed -- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/test/test_sched.py", line 83, in test_cancel_concurrent scheduler.cancel(event1) File "/home/antoine/cpython/default/Lib/sched.py", line 96, in cancel self._queue.remove(event) ValueError: list.remove(x): x not in list ---------- components: Library (Lib), Tests messages: 178851 nosy: pitrou, serhiy.storchaka priority: normal severity: normal status: open title: sporadic test_sched failure type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 22:14:45 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 21:14:45 +0000 Subject: [issue16833] http.client delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <3Yc4lS5npjzSK8@mail.python.org> Roundup Robot added the comment: New changeset 002bf9857278 by Antoine Pitrou in branch 'default': Issue #16833: In http.client.HTTPConnection, do not concatenate the request headers and body when the payload exceeds 16 KB, since it can consume more memory for no benefit. http://hg.python.org/cpython/rev/002bf9857278 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 22:15:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 Jan 2013 21:15:32 +0000 Subject: [issue16833] http.client delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <1357161332.63.0.39072903785.issue16833@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch looks good to me, I've committed it. Thank you! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 22:16:03 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 Jan 2013 21:16:03 +0000 Subject: [issue16833] http.client delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <1357161363.77.0.92937517126.issue16833@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, could you sign a contributor agreement? http://www.python.org/psf/contrib/ Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 22:58:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 21:58:10 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> Message-ID: <1357163890.24.0.2300003455.issue16843@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a test only issue. There are two ways to fix this test. On first simple way we can just increase the timing and hope for a luck. On second more complicated way we should use custom deterministic time and sleep functions. Here is a first way patch to shut up the test failing. ---------- assignee: -> serhiy.storchaka components: -Library (Lib) keywords: +patch Added file: http://bugs.python.org/file28534/test_sched_concurrent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 22:59:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Jan 2013 21:59:39 +0000 Subject: [issue16842] Allow to override a function signature for pydoc with a docstring In-Reply-To: <1357157305.88.0.0239428638229.issue16842@psf.upfronthosting.co.za> Message-ID: <1357163979.96.0.292205230808.issue16842@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 23:13:10 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 02 Jan 2013 22:13:10 +0000 Subject: [issue16801] Preserve original representation for integers / floats in docstrings In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za> Message-ID: <1357164790.28.0.0917255231388.issue16801@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A subclass with a custom representation, as I suggested above, is even simpler and involves no change to inspect or docstring conventions. I otherwise agree with closing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 23:14:31 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Jan 2013 22:14:31 +0000 Subject: [issue16828] bz2 error on compression of empty string In-Reply-To: <1356973084.81.0.547571826956.issue16828@psf.upfronthosting.co.za> Message-ID: <3Yc64Q6d2VzRxX@mail.python.org> Roundup Robot added the comment: New changeset 06a08144af1b by Nadeem Vawda in branch '2.7': Issue #16828: Fix error incorrectly raised by bz2.compress(''). http://hg.python.org/cpython/rev/06a08144af1b New changeset c4a4863b85b2 by Nadeem Vawda in branch '3.2': Issue #16828: Fix error incorrectly raised by bz2.compress(''). http://hg.python.org/cpython/rev/c4a4863b85b2 New changeset 011981143087 by Nadeem Vawda in branch '3.3': Issue #16828: Fix error incorrectly raised by bz2.compress(''). http://hg.python.org/cpython/rev/011981143087 New changeset 93654d0d9b1e by Nadeem Vawda in branch '3.3': Correction: issue #16828 also affects BZ2Compressor.compress(). http://hg.python.org/cpython/rev/93654d0d9b1e New changeset 44cfd43b09f5 by Nadeem Vawda in branch 'default': Issue #16828: Fix error incorrectly raised by bz2.compress(b'') and bz2.BZ2Compressor.compress(b''). http://hg.python.org/cpython/rev/44cfd43b09f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 23:19:42 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 02 Jan 2013 22:19:42 +0000 Subject: [issue16828] bz2 error on compression of empty string In-Reply-To: <1356973084.81.0.547571826956.issue16828@psf.upfronthosting.co.za> Message-ID: <1357165182.29.0.0840136305844.issue16828@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Fixed. Thanks for the bug report and the patches! ---------- assignee: -> nadeem.vawda keywords: +3.3regression -patch resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 2 23:37:22 2013 From: report at bugs.python.org (Alejandro Marco Ramos) Date: Wed, 02 Jan 2013 22:37:22 +0000 Subject: [issue16844] funcName in logging module for python 2.6 Message-ID: <1357166242.35.0.208386343695.issue16844@psf.upfronthosting.co.za> New submission from Alejandro Marco Ramos: hi, when use the param 'funcName' in the logging module (version 0.4.9.6 for python 2.6) the module crash. Researching in the code (__init__.py) i see that the code for get the function name is in method '_log' in the class 'Logger'. The function 'findCaller()' returns in the last value the name of the function (in the variable name 'func'), but this variable is not present in the caller function for create a 'record' object (in this case 'makeRecord'). I added code to fix this but i like that review this bug. ---------- components: Extension Modules messages: 178859 nosy: amarco priority: normal severity: normal status: open title: funcName in logging module for python 2.6 type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 00:01:32 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Jan 2013 23:01:32 +0000 Subject: [issue16844] funcName in logging module for python 2.6 In-Reply-To: <1357166242.35.0.208386343695.issue16844@psf.upfronthosting.co.za> Message-ID: <1357167692.53.0.505188246552.issue16844@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can you provide some code to reproduce the issue and/or the traceback you got? Note that 2.6 only receives security fixes, so it won't be fixed there -- but it can be fixed in 2.7/3.2/3.3/3.x if they are affected. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 00:05:46 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Jan 2013 23:05:46 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357167946.21.0.163149913155.issue16748@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a patch that should clear up test_genericpath.py (and other path tests). ---------- resolution: fixed -> title: Ensure test discovery doesn't break for modules testing C and Python implementations -> Make CPython test package discoverable Added file: http://bugs.python.org/file28535/issue16748_genericpath.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 00:08:02 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Jan 2013 23:08:02 +0000 Subject: [issue16844] funcName in logging module for python 2.6 In-Reply-To: <1357166242.35.0.208386343695.issue16844@psf.upfronthosting.co.za> Message-ID: <1357168082.94.0.434967446797.issue16844@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder if this is related to issue 16778. ---------- nosy: +r.david.murray, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 00:20:39 2013 From: report at bugs.python.org (Alejandro Marco Ramos) Date: Wed, 02 Jan 2013 23:20:39 +0000 Subject: [issue16844] funcName in logging module for python 2.6 In-Reply-To: <1357166242.35.0.208386343695.issue16844@psf.upfronthosting.co.za> Message-ID: <1357168839.62.0.542873958511.issue16844@psf.upfronthosting.co.za> Alejandro Marco Ramos added the comment: is not related to 16778 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 01:24:06 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 00:24:06 +0000 Subject: [issue16455] Decode command line arguments from ASCII on FreeBSD and Solaris if the locale is C In-Reply-To: <1352672055.11.0.23985291602.issue16455@psf.upfronthosting.co.za> Message-ID: <3Yc8xv44PWzS2f@mail.python.org> Roundup Robot added the comment: New changeset c256764e2b3f by Victor Stinner in branch '3.2': Issue #16455: On FreeBSD and Solaris, if the locale is C, the http://hg.python.org/cpython/rev/c256764e2b3f New changeset 5bb289e4fb35 by Victor Stinner in branch '3.3': (Merge 3.2) Issue #16455: On FreeBSD and Solaris, if the locale is C, the http://hg.python.org/cpython/rev/5bb289e4fb35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 01:35:41 2013 From: report at bugs.python.org (Leo Arias) Date: Thu, 03 Jan 2013 00:35:41 +0000 Subject: [issue16739] texttestresult should decorate the stream with _WritelnDecorator In-Reply-To: <1356020181.84.0.076442170736.issue16739@psf.upfronthosting.co.za> Message-ID: <1357173341.72.0.728865414143.issue16739@psf.upfronthosting.co.za> Leo Arias added the comment: What if we check if the stream has the writeln method? ---------- Added file: http://bugs.python.org/file28536/fix-16739-texttestresult_writeln-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 01:41:24 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 00:41:24 +0000 Subject: [issue16455] Decode command line arguments from ASCII on FreeBSD and Solaris if the locale is C In-Reply-To: <1352672055.11.0.23985291602.issue16455@psf.upfronthosting.co.za> Message-ID: <1357173684.77.0.756053046568.issue16455@psf.upfronthosting.co.za> STINNER Victor added the comment: I backported the fix to Python 3.2 and 3.3 because I consider it important enough. ---------- versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 01:42:06 2013 From: report at bugs.python.org (Sebastian Berg) Date: Thu, 03 Jan 2013 00:42:06 +0000 Subject: [issue16845] warnings.simplefilter should validate input Message-ID: <1357173726.64.0.0586309357998.issue16845@psf.upfronthosting.co.za> New submission from Sebastian Berg: `warnings.simplefilter` does not validate that the category passed in is actually a class. This means that an invalid category leads to a `TypeError` whenever a warning would otherwise occur due to `issubclass` check failing. It is a very small thing, but for usability it would be clearer if this was checked right away. ---------- messages: 178867 nosy: seberg priority: normal severity: normal status: open title: warnings.simplefilter should validate input type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 01:59:43 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 00:59:43 +0000 Subject: [issue16444] Use support.TESTFN_UNDECODABLE on UNIX In-Reply-To: <1352415134.41.0.932872803675.issue16444@psf.upfronthosting.co.za> Message-ID: <3Yc9ks49hzzS0r@mail.python.org> Roundup Robot added the comment: New changeset 41658a4fb3cc by Victor Stinner in branch '3.2': Issue #16218, #16414, #16444: Backport FS_NONASCII, TESTFN_UNDECODABLE, http://hg.python.org/cpython/rev/41658a4fb3cc New changeset 4d40c1ce8566 by Victor Stinner in branch '3.3': (Merge 3.2) Issue #16218, #16414, #16444: Backport FS_NONASCII, http://hg.python.org/cpython/rev/4d40c1ce8566 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 01:59:43 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 00:59:43 +0000 Subject: [issue16218] Python launcher does not support unicode characters In-Reply-To: <1350138278.8.0.551817049969.issue16218@psf.upfronthosting.co.za> Message-ID: <3Yc9kt2jCHzR3k@mail.python.org> Roundup Robot added the comment: New changeset 41658a4fb3cc by Victor Stinner in branch '3.2': Issue #16218, #16414, #16444: Backport FS_NONASCII, TESTFN_UNDECODABLE, http://hg.python.org/cpython/rev/41658a4fb3cc New changeset 4d40c1ce8566 by Victor Stinner in branch '3.3': (Merge 3.2) Issue #16218, #16414, #16444: Backport FS_NONASCII, http://hg.python.org/cpython/rev/4d40c1ce8566 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 01:59:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 00:59:48 +0000 Subject: [issue16414] Add support.NONASCII to test non-ASCII characters In-Reply-To: <1352117534.37.0.611340206867.issue16414@psf.upfronthosting.co.za> Message-ID: <3Yc9kr5g6tzS0b@mail.python.org> Roundup Robot added the comment: New changeset 41658a4fb3cc by Victor Stinner in branch '3.2': Issue #16218, #16414, #16444: Backport FS_NONASCII, TESTFN_UNDECODABLE, http://hg.python.org/cpython/rev/41658a4fb3cc New changeset 4d40c1ce8566 by Victor Stinner in branch '3.3': (Merge 3.2) Issue #16218, #16414, #16444: Backport FS_NONASCII, http://hg.python.org/cpython/rev/4d40c1ce8566 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:07:03 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:07:03 +0000 Subject: [issue16455] Decode command line arguments from ASCII on FreeBSD and Solaris if the locale is C In-Reply-To: <1352672055.11.0.23985291602.issue16455@psf.upfronthosting.co.za> Message-ID: <1357175223.25.0.986523118386.issue16455@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:07:33 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:07:33 +0000 Subject: [issue16414] Add support.NONASCII to test non-ASCII characters In-Reply-To: <1352117534.37.0.611340206867.issue16414@psf.upfronthosting.co.za> Message-ID: <1357175253.59.0.0880297139865.issue16414@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:07:37 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:07:37 +0000 Subject: [issue16444] Use support.TESTFN_UNDECODABLE on UNIX In-Reply-To: <1352415134.41.0.932872803675.issue16444@psf.upfronthosting.co.za> Message-ID: <1357175257.03.0.427735098178.issue16444@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:08:38 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:08:38 +0000 Subject: [issue16218] Python launcher does not support unicode characters In-Reply-To: <1350138278.8.0.551817049969.issue16218@psf.upfronthosting.co.za> Message-ID: <1357175318.19.0.873508801124.issue16218@psf.upfronthosting.co.za> STINNER Victor added the comment: > I assign the issue to you than. Is it ok? Sure. I backported all changesets related to this issue to Python 3.2 and 3.3. So I can finally close this issue. ---------- assignee: haypo -> resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:14:16 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:14:16 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1357175656.67.0.62299286232.issue15596@psf.upfronthosting.co.za> STINNER Victor added the comment: serhiy: I'm not really motivated to finish the work on this issue (especially "... it would probably be good idea to benchmarks non-ASCII strings as well."). Would you like to work on this? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:15:21 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:15:21 +0000 Subject: [issue14094] nt.realpath() should use GetFinalPathNameByHandle() when available In-Reply-To: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za> Message-ID: <1357175721.95.0.0516070903472.issue14094@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:15:59 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Jan 2013 01:15:59 +0000 Subject: [issue14393] Incorporate Guide to Magic Methods? In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za> Message-ID: <1357175759.33.0.54633083977.issue14393@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Much of that article is taken directly from the official docs and adds very little in the way of explanation. I think we need our own write-up with better explanations and examples. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:16:38 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:16:38 +0000 Subject: [issue13552] Compilation issues of the curses module on OpenIndiana In-Reply-To: <1323305598.14.0.0193622635558.issue13552@psf.upfronthosting.co.za> Message-ID: <1357175796.78.0.0712136288646.issue13552@psf.upfronthosting.co.za> STINNER Victor added the comment: What is the status of this issue? Is curses still broken on Python 3.4? ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:20:43 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:20:43 +0000 Subject: [issue12495] Rewrite InterProcessSignalTests In-Reply-To: <1309818801.22.0.236460194103.issue12495@psf.upfronthosting.co.za> Message-ID: <1357176043.78.0.642913409233.issue12495@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't want to work on signals anymore, and nobody looks to be interested, so I'm closing this issue. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:24:56 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:24:56 +0000 Subject: [issue7651] Python3: guess text file charset using the BOM In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za> Message-ID: <1357176296.71.0.385921282855.issue7651@psf.upfronthosting.co.za> STINNER Victor added the comment: The idea was somehow rejected on the python-dev mailing list. I'm not really motivated to work on this issue since I never see any file starting with a BOM on Linux, and I'm only working on Linux. So I just close this issue. If someone is motivated to work on this topic, I suppose that it would be better to reopen the discussion on the python-dev mailing list first. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:26:51 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:26:51 +0000 Subject: [issue9561] distutils: set encoding to utf-8 for input and output files In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za> Message-ID: <1357176411.41.0.909279977984.issue9561@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:28:42 2013 From: report at bugs.python.org (Meador Inge) Date: Thu, 03 Jan 2013 01:28:42 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> Message-ID: <1357176522.7.0.893227149183.issue16047@psf.upfronthosting.co.za> Meador Inge added the comment: Thanks for the feedback everyone -- that helped. Here is a new patch which addresses issue (3) by not requiring os.__file__ to exist. The patch from issue11824 fixes freeze for 3.2 completely. The patch from issue11824 plus this patch fixes freeze for 3.3 and 3.4. I tested both `make install` and Python source tree versions (i.e. freeze.py -p). A frozen "Hello, world" app works fine in all cases. I also verified that 'license' works from a frozen app. You will see something like the following instead of the full licensing text on stdout: See http://www.python.org/3.4/license.html ---------- assignee: meador.inge -> stage: needs patch -> patch review versions: -Python 3.2 Added file: http://bugs.python.org/file28537/issue16047-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:29:46 2013 From: report at bugs.python.org (Meador Inge) Date: Thu, 03 Jan 2013 01:29:46 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> Message-ID: <1357176586.42.0.476590595762.issue16047@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- assignee: -> meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:33:56 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:33:56 +0000 Subject: [issue10951] gcc 4.6 warnings In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za> Message-ID: <1357176836.0.0.827771195261.issue10951@psf.upfronthosting.co.za> STINNER Victor added the comment: fix_2warnings.diff: I don't like statement like (void)err; to kill a compiler warning. I prefer GCC __attribute__((unused)) using a macro instead. About the change on unicode_fromascii, the code changed a lot since the patch was written. The patch is outdated and not really interesting. Please open a new issue with a new patch if there are remaining warnings. I'm closing the issue because I agree with Martin von Loewis, it's better to open new issues for each warning (warning class?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:34:02 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:34:02 +0000 Subject: [issue10951] gcc 4.6 warnings In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za> Message-ID: <1357176842.69.0.86867971762.issue10951@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:35:13 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:35:13 +0000 Subject: [issue11242] urllib.request.url_open() doesn't support SSLContext In-Reply-To: <1298029318.21.0.486512384779.issue11242@psf.upfronthosting.co.za> Message-ID: <1357176913.34.0.325130220462.issue11242@psf.upfronthosting.co.za> STINNER Victor added the comment: A solution does already exist, and I'm not motivated to work on an helper, so I'm closing this issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:35:51 2013 From: report at bugs.python.org (Meador Inge) Date: Thu, 03 Jan 2013 01:35:51 +0000 Subject: [issue16842] Allow to override a function signature for pydoc with a docstring In-Reply-To: <1357157305.88.0.0239428638229.issue16842@psf.upfronthosting.co.za> Message-ID: <1357176951.53.0.413329936881.issue16842@psf.upfronthosting.co.za> Meador Inge added the comment: Serhiy, did you mean to mark this as "patch review"? I don't see a patch. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:36:19 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:36:19 +0000 Subject: [issue11365] Integrate Buildroot patches (cross-compilation) In-Reply-To: <1299015633.09.0.58407944374.issue11365@psf.upfronthosting.co.za> Message-ID: <1357176979.65.0.149560181128.issue11365@psf.upfronthosting.co.za> STINNER Victor added the comment: @doko: You integrated patches related to cross-compilation. Can this issue be closed, or does the Buildroot project still contain useful patches? ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:37:47 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:37:47 +0000 Subject: [issue11619] On Windows, don't encode filenames in the import machinery In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za> Message-ID: <1357177067.79.0.538186329535.issue11619@psf.upfronthosting.co.za> STINNER Victor added the comment: The patch is really huge for such a very rare use case, so I prefer to close the issue as wont fix. Common cases with non-ASCII names are already handled correctly in Python 3.3. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:42:06 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:42:06 +0000 Subject: [issue8952] Doc/c-api/arg.rst: fix documentation of number formats In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za> Message-ID: <1357177326.65.0.213645491026.issue8952@psf.upfronthosting.co.za> STINNER Victor added the comment: Three years later, nobody looks to be interested to work on this part of the documentation, so I'm closing the issue. => read the code, luke! (not the doc...) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:44:26 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:44:26 +0000 Subject: [issue11726] linecache becomes specific to Python scripts in Python 3 In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za> Message-ID: <1357177466.96.0.55168979952.issue11726@psf.upfronthosting.co.za> STINNER Victor added the comment: Well, my initial message doesn't convince me anymore today (especially after reading Terry's message), so I prefer to close the issue as rejected. I don't think that it's really a problem :-) ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:44:36 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 03 Jan 2013 01:44:36 +0000 Subject: [issue11995] test_pydoc loads all Python modules In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za> Message-ID: <1357177476.94.0.487188301253.issue11995@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : Removed file: http://bugs.python.org/file22133/python-2.7-issue_11995.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:44:41 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 03 Jan 2013 01:44:41 +0000 Subject: [issue11995] test_pydoc loads all Python modules In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za> Message-ID: <1357177481.84.0.134235879554.issue11995@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : Removed file: http://bugs.python.org/file22134/python-3.2-issue_11995.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:44:44 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 03 Jan 2013 01:44:44 +0000 Subject: [issue11995] test_pydoc loads all Python modules In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za> Message-ID: <1357177484.64.0.999121683715.issue11995@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : Removed file: http://bugs.python.org/file22135/python-3.3-issue_11995.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:46:01 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:46:01 +0000 Subject: [issue11769] test_notify() of test_threading hang on "x86 XP-4 3.x": In-Reply-To: <1301964330.57.0.512119675756.issue11769@psf.upfronthosting.co.za> Message-ID: <1357177561.14.0.967772512255.issue11769@psf.upfronthosting.co.za> STINNER Victor added the comment: Sporadic failure, I don't know if it was reproduced recently, and the issue has no activity since more than 6 months => I'm closing the issue. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:46:48 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:46:48 +0000 Subject: [issue11925] test_ttk_guionly.test_traversal() failed on "x86 Windows7 3.x" In-Reply-To: <1303776010.8.0.380054844246.issue11925@psf.upfronthosting.co.za> Message-ID: <1357177608.46.0.574525421673.issue11925@psf.upfronthosting.co.za> STINNER Victor added the comment: Sporadic failure, I don't know if it was reproduced recently, and the issue has no activity since more than 6 months => I'm closing the issue. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:47:02 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:47:02 +0000 Subject: [issue12336] tkinter.test.test_ttk.test_widgets.test_select() failure on FreeBSD 6.4 3.x In-Reply-To: <1308088699.26.0.99920721974.issue12336@psf.upfronthosting.co.za> Message-ID: <1357177622.13.0.158505667523.issue12336@psf.upfronthosting.co.za> STINNER Victor added the comment: Sporadic failure, I don't know if it was reproduced recently, and the issue has no activity since more than 6 months => I'm closing the issue. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:47:13 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:47:13 +0000 Subject: [issue12453] test_import.test_failing_import_sticks() sporadic failures In-Reply-To: <1309446981.3.0.601023155331.issue12453@psf.upfronthosting.co.za> Message-ID: <1357177633.26.0.880808494192.issue12453@psf.upfronthosting.co.za> STINNER Victor added the comment: Sporadic failure, I don't know if it was reproduced recently, and the issue has no activity since more than 6 months => I'm closing the issue. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:47:23 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:47:23 +0000 Subject: [issue12466] test_subprocess.test_close_fds() sporadic failures on Mac OS X Tiger In-Reply-To: <1309524982.22.0.267480095279.issue12466@psf.upfronthosting.co.za> Message-ID: <1357177643.05.0.750663208538.issue12466@psf.upfronthosting.co.za> STINNER Victor added the comment: Sporadic failure, I don't know if it was reproduced recently, and the issue has no activity since more than 6 months => I'm closing the issue. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:51:14 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:51:14 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <1357177874.0.1.3230298616e-05.issue10527@psf.upfronthosting.co.za> STINNER Victor added the comment: > New changeset c5c27b84d7af by Giampaolo Rodola' in branch '2.7': > Fix issue 10527: make multiprocessing use poll() instead of select() if available. > http://hg.python.org/cpython/rev/c5c27b84d7af This changeset broke many buildbots, at least: http://buildbot.python.org/all/builders/x86%20XP-5%202.7/builds/439/steps/test/logs/stdio File "D:\Buildslave\2.7.moore-windows\build\lib\multiprocessing\connection.py", line 203, in if hasattr(select, 'poll'): NameError: name 'select' is not defined (I reopen the issue) ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:53:25 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:53:25 +0000 Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": AEST timezone called "EST" In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za> Message-ID: <1357178005.32.0.363930025176.issue11886@psf.upfronthosting.co.za> STINNER Victor added the comment: What is the status of this issue? Was the failure reproduced recently? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:54:16 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:54:16 +0000 Subject: [issue13059] Sporadic test_multiprocessing failure: IOError("bad message length") in recv_bytes() In-Reply-To: <1317300485.05.0.349182962077.issue13059@psf.upfronthosting.co.za> Message-ID: <1357178056.95.0.949737460869.issue13059@psf.upfronthosting.co.za> STINNER Victor added the comment: Sporadic failure, I don't know if it was reproduced recently, and the issue has no activity since more than 6 months => I'm closing the issue. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:55:37 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 01:55:37 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <3YcBzV2GRCzS3v@mail.python.org> Roundup Robot added the comment: New changeset 7cf4ea64f603 by Giampaolo Rodola' in branch '2.7': issue 10527: fix missing import http://hg.python.org/cpython/rev/7cf4ea64f603 New changeset d565d862545c by Giampaolo Rodola' in branch '3.2': issue 10527: fix missing import http://hg.python.org/cpython/rev/d565d862545c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:57:10 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 03 Jan 2013 01:57:10 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <1357178230.61.0.766626727154.issue10527@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: My bad, sorry. It should be fixed now. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 02:59:21 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 01:59:21 +0000 Subject: [issue12309] os.environ was modified by test_packaging In-Reply-To: <1307696523.79.0.913575304812.issue12309@psf.upfronthosting.co.za> Message-ID: <1357178361.59.0.471642712676.issue12309@psf.upfronthosting.co.za> STINNER Victor added the comment: The packaging modules has been removed from Python, so I close the issue. ---------- dependencies: -regrtest checks (os.environ, sys.path, etc.) are hard to use resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:02:38 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:02:38 +0000 Subject: [issue13100] sre_compile._optimize_unicode() needs a cleanup In-Reply-To: <1317748318.81.0.992039803801.issue13100@psf.upfronthosting.co.za> Message-ID: <1357178558.46.0.032727472187.issue13100@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't know what to do with this issue. The code looks to work anyway, so I guess that it's safer to not touch it :-) ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:04:30 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 03 Jan 2013 02:04:30 +0000 Subject: [issue16833] http.client delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <1357178670.24.0.379929561393.issue16833@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:04:49 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:04:49 +0000 Subject: [issue13157] Build Python outside the source directory In-Reply-To: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za> Message-ID: <1357178689.37.0.831195948192.issue13157@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't have this issue anymore (but I also don't build Python outside the source directory anymore), I already applied my patch, so I consider that the issue can be closed. If someone has a similar problem, it's maybe better to open a new issue. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:06:47 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:06:47 +0000 Subject: [issue14057] Speedup sysconfig startup In-Reply-To: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za> Message-ID: <1357178807.19.0.187740711966.issue14057@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not really convinced by my patch. It looks like a quick hack. Nick's PEP 432 looks more promising (in speed), simple and safer. So I prefer to close this issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:08:22 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:08:22 +0000 Subject: [issue12858] crypt.mksalt: use ssl.RAND_pseudo_bytes() if available In-Reply-To: <1314715278.55.0.540710035592.issue12858@psf.upfronthosting.co.za> Message-ID: <1357178902.84.0.946795099283.issue12858@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not sure that a salt must be cryptographic. Mersenne Twister should be enough to generate a salt. Anyway, ssl.RAND_pseudo_bytes() cannot be used currently and I don't have a patch, so I prefer to close this issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:12:33 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:12:33 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357179153.84.0.428386842397.issue12939@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not really motivated to work on a Windows-specific issue. The issue has no patch, even no proof-of-concept implemented in Python. Can I close the issue, or is someone interested to work on this topic? Python 3.3 adds a opener argument to open(). It may be enough to workaround this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:20:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 02:20:27 +0000 Subject: [issue16281] TODO in tailmatch(): it does not support backward in all cases In-Reply-To: <1350607883.61.0.918476063498.issue16281@psf.upfronthosting.co.za> Message-ID: <3YcCXB2yHGzQqm@mail.python.org> Roundup Robot added the comment: New changeset 49eb2488145d by Victor Stinner in branch 'default': Close #16281: handle tailmatch() failure and remove useless comment http://hg.python.org/cpython/rev/49eb2488145d ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:21:46 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:21:46 +0000 Subject: [issue16281] TODO in tailmatch(): it does not support backward in all cases In-Reply-To: <1350607883.61.0.918476063498.issue16281@psf.upfronthosting.co.za> Message-ID: <1357179706.55.0.215432428612.issue16281@psf.upfronthosting.co.za> STINNER Victor added the comment: "Here I see a one obvious opportunity for optimization: ..." @Serhiy: Can you please open a new issue for this? I consider the issue as fixed: I just removed the TODO (for the reason explained in the changeset). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:24:50 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:24:50 +0000 Subject: [issue16286] Optimize a==b and a!=b for bytes and str In-Reply-To: <1350650166.87.0.27478619259.issue16286@psf.upfronthosting.co.za> Message-ID: <1357179890.01.0.423651832537.issue16286@psf.upfronthosting.co.za> STINNER Victor added the comment: > P.S. I rather like the optimization and don't want to discourage it. I'm just curious about what the current optimizations are missing. I'm too lazy to produce more statistics or run other benchmarks. I just saw an interesting optimization oportunity. I don't understand why it was not done before. If you consider that compare_hash.patch might slow down Python, so ok, I will just close the issue as rejected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:42:54 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 02:42:54 +0000 Subject: [issue16367] io.FileIO.readall() is not 64-bit safe on Windows In-Reply-To: <1351640587.41.0.234658150745.issue16367@psf.upfronthosting.co.za> Message-ID: <3YcD252nKJzS1B@mail.python.org> Roundup Robot added the comment: New changeset 9aba9ad6c15b by Victor Stinner in branch '3.2': Issue #16367: Fix FileIO.readall() on Windows for files larger than 2 GB http://hg.python.org/cpython/rev/9aba9ad6c15b New changeset 5f96e4619ceb by Victor Stinner in branch '3.3': (Merge 3.2) Issue #16367: Fix FileIO.readall() on Windows for files larger than 2 GB. http://hg.python.org/cpython/rev/5f96e4619ceb New changeset d81d4b3059e4 by Victor Stinner in branch 'default': (Merge 3.3) Issue #16367: Fix FileIO.readall() on Windows for files larger than 2 GB. http://hg.python.org/cpython/rev/d81d4b3059e4 New changeset f26c91bf61bf by Victor Stinner in branch '2.7': Issue #16367: Fix FileIO.readall() on Windows for files larger than 2 GB http://hg.python.org/cpython/rev/f26c91bf61bf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:43:49 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:43:49 +0000 Subject: [issue16367] io.FileIO.readall() is not 64-bit safe on Windows In-Reply-To: <1351640587.41.0.234658150745.issue16367@psf.upfronthosting.co.za> Message-ID: <1357181029.84.0.720365905601.issue16367@psf.upfronthosting.co.za> STINNER Victor added the comment: > Perhaps we could add a bigmem test for that (in test_fileio)? Well, I'm too lazy to write such test. Instead of leaving the issue open for weeks, I prefer to commit my patch with no new test (sorry!). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:45:31 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:45:31 +0000 Subject: [issue15599] test_threaded_import fails sporadically on Windows and FreeBSD In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1357181131.85.0.108851361028.issue15599@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:48:28 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:48:28 +0000 Subject: [issue14372] Fix all invalid usage of borrowed references In-Reply-To: <1332247424.34.0.747604429133.issue14372@psf.upfronthosting.co.za> Message-ID: <1357181308.59.0.723693249168.issue14372@psf.upfronthosting.co.za> STINNER Victor added the comment: Nobody looks motivated to work on such complex and long issue, so I close the issue. It's maybe simpler to open an issue per invalid usage of borrowed reference (as it was done for #14211 and #14231). ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:50:28 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:50:28 +0000 Subject: [issue13453] Tests and network timeouts In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za> Message-ID: <1357181428.86.0.556235642205.issue13453@psf.upfronthosting.co.za> STINNER Victor added the comment: Various fixes were done thanks to this issue. I close it. Open a new issue if you see again similar issues. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:52:18 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:52:18 +0000 Subject: [issue13256] Document and test new socket options In-Reply-To: <1319456775.82.0.463656498781.issue13256@psf.upfronthosting.co.za> Message-ID: <1357181538.37.0.296826278273.issue13256@psf.upfronthosting.co.za> STINNER Victor added the comment: I created this issue for myself (as a reminder), but sorry I'm not really motivated to work on the documentation, nor test. Document socket options is not trivial because the exact definition depends on the platform. I close the issue. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:55:57 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:55:57 +0000 Subject: [issue13209] Refactor code using unicode_encode_call_errorhandler() in unicodeobject.c In-Reply-To: <1318938611.14.0.651217726677.issue13209@psf.upfronthosting.co.za> Message-ID: <1357181757.69.0.782193499644.issue13209@psf.upfronthosting.co.za> STINNER Victor added the comment: I tried to factorize the code, but it is too complex. Each encoder handles errors differently. The most tricky is charmap: it reencodes the result of the error handler for non-ASCII characters. I'm not happy with the current situtation, but I don't see how to factorize easily the code, so I prefer to leave it unchanged. I close the issue. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 03:57:56 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 02:57:56 +0000 Subject: [issue12112] The new packaging module should not use the locale encoding In-Reply-To: <1305806068.46.0.0788802994526.issue12112@psf.upfronthosting.co.za> Message-ID: <1357181876.77.0.957022496796.issue12112@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 04:16:27 2013 From: report at bugs.python.org (Meador Inge) Date: Thu, 03 Jan 2013 03:16:27 +0000 Subject: [issue16742] PyOS_Readline drops GIL and calls PyOS_StdioReadline, which isn't thread safe In-Reply-To: <1356086390.48.0.327620937355.issue16742@psf.upfronthosting.co.za> Message-ID: <1357182987.86.0.387285923098.issue16742@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 04:23:07 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Jan 2013 03:23:07 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357183387.2.0.18867659229.issue16835@psf.upfronthosting.co.za> Zachary Ware added the comment: A few minor grammatical and style nits in the prose added at the end of the diff: > +The test module defines a base class with the tests methods that access the > +``heapq`` module through a ``self.heapq`` class attribute, and two subclasses > +that set this attribute to either the Python and C versions of the module. I think that should be "Python or C version" (and -> or; versions -> version). > +Note that only the two subclasses inherit from ``unittest.TestCase`` -- this > +prevents the ``ExampleTest`` class to be detected as a ``TestCase`` subclass "to be" should be "from being", I believe. > +by ``unittest`` test discovery. > +A ``skipUnless`` decorator can be added to the class that tests the C code This should either have another newline inbetween or be reflowed. Either one paragraph or two makes sense to me, but I can't tell which way you actually meant it to go which makes for confusing reading of the ReST source. As far as the example code changes, those look good to me :) ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 05:40:30 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 04:40:30 +0000 Subject: [issue13100] sre_compile._optimize_unicode() needs a cleanup In-Reply-To: <1317748318.81.0.992039803801.issue13100@psf.upfronthosting.co.za> Message-ID: <1357188030.65.0.961367799681.issue13100@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +mrabarnett stage: -> committed/rejected type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 05:47:50 2013 From: report at bugs.python.org (Meador Inge) Date: Thu, 03 Jan 2013 04:47:50 +0000 Subject: [issue16730] _fill_cache in _bootstrap.py crashes without directory execute permissions In-Reply-To: <1355928901.47.0.243119596238.issue16730@psf.upfronthosting.co.za> Message-ID: <1357188470.14.0.21731543685.issue16730@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 05:49:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 04:49:58 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357188598.24.0.175833376173.issue16835@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for the review, new patch attached. > This should either have another newline inbetween or be reflowed. > Either one paragraph or two makes sense to me, but I can't tell which > way you actually meant I meant one and half :) I guess in HTML that would have been a
inside the

, but I don't think it really matters if it's rendered as a single paragraph. ---------- assignee: ezio.melotti -> Added file: http://bugs.python.org/file28538/issue16835-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 05:50:39 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 04:50:39 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357188639.79.0.393443324201.issue16835@psf.upfronthosting.co.za> Changes by Ezio Melotti : Removed file: http://bugs.python.org/file28538/issue16835-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 05:50:48 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 04:50:48 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357188648.52.0.986149220756.issue16835@psf.upfronthosting.co.za> Changes by Ezio Melotti : Added file: http://bugs.python.org/file28539/issue16835-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 05:56:01 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 04:56:01 +0000 Subject: [issue8821] Range check on unicode repr In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za> Message-ID: <1357188961.56.0.432818684971.issue8821@psf.upfronthosting.co.za> Ezio Melotti added the comment: Should this be closed then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 06:52:11 2013 From: report at bugs.python.org (FizzledOut) Date: Thu, 03 Jan 2013 05:52:11 +0000 Subject: [issue16846] relative import solution Message-ID: <1357192331.61.0.693606949117.issue16846@psf.upfronthosting.co.za> New submission from FizzledOut: Instead of giving the error message " Attempted relative import in non-package", simply process the line! from . import Example whether or not the file is __main__, it should be able to go up one directory, if possible, and try to import Example.py. It makes no sense that this cannot be done. ---------- components: Windows messages: 178913 nosy: Fixpythonbugs priority: normal severity: normal status: open title: relative import solution type: resource usage versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 07:44:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 06:44:27 +0000 Subject: [issue16009] Json error messages could provide more information about the error In-Reply-To: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> Message-ID: <3YcKNp56rMzS3d@mail.python.org> Roundup Robot added the comment: New changeset 17b4bf9e9f43 by Ezio Melotti in branch 'default': #16009: JSON error messages now provide more information. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/17b4bf9e9f43 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 07:45:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 06:45:15 +0000 Subject: [issue16009] Json error messages could provide more information about the error In-Reply-To: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> Message-ID: <1357195515.78.0.97283364411.issue16009@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: ezio.melotti -> resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 07:56:50 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 03 Jan 2013 06:56:50 +0000 Subject: [issue16847] sha module broken Message-ID: <1357196210.69.0.740863456669.issue16847@psf.upfronthosting.co.za> New submission from Ronald Oussoren: On OSX 10.8 with the following configure line and a fresh checkout (as of 10 minutes ago): '../configure' '--enable-framework' '--enable-universalsdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk' '--with-universal-archs=intel' '--with-framework-name=Python' 'MACOSX_DEPLOYMENT_TARGET=10.8' 'CC=clang' 'CXX=clang++' The build fails because _PyUnicode_CheckConsistency cannot be found when trying to load (amongst others) _sha1. According to the unicodeobject.h that function is only available in debug builds, while it gets used unconditionally in sha1module.c I haven't run a bisect yet to find why the build fails now, the call to _PyUnicode_CheckConsistency was added in April and the build failure is (much) more recent. ---------- keywords: 3.3regression messages: 178916 nosy: ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: sha module broken type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 07:57:41 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 Jan 2013 06:57:41 +0000 Subject: [issue16833] http.client delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <1357196261.18.0.2201104957.issue16833@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Jesus, why are you reopening this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 08:05:29 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 07:05:29 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357196729.51.0.784233521419.issue13094@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm having some problem at deciding what the title of the FAQ should be, and what the actual problem is. ISTM that OP's problem is the same as: >>> x = 1 >>> def foo(): return x ... >>> x = 2 >>> foo() 2 except that he has 3 lambdas in a loop that get attached to an instance rather than a simple function -- but the problem is that in both cases the function references a global variable whose value is retrieved at calling time rather that being set at definition time. IOW the solution should be clear, but the code is complex enough that it's not easy to recognize the analogy with the simpler case. I'm not even sure this has anything to do with closures, unless you consider the global scope a closure. Maybe the "What are the rules for local and global variables in Python?" FAQ could be expanded with a few examples to cover this case too. ---------- assignee: ezio.melotti -> nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 08:17:25 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 Jan 2013 07:17:25 +0000 Subject: [issue16847] sha module broken In-Reply-To: <1357196210.69.0.740863456669.issue16847@psf.upfronthosting.co.za> Message-ID: <1357197445.17.0.0496992623511.issue16847@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 08:43:15 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 03 Jan 2013 07:43:15 +0000 Subject: [issue16847] sha module broken In-Reply-To: <1357196210.69.0.740863456669.issue16847@psf.upfronthosting.co.za> Message-ID: <1357198995.39.0.951265170849.issue16847@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, a build of current top-of-branch 3.3 using the same configure command and in a subdirectory (../configure) seemed to work fine on 10.8.2 with Xcode 4.5.2. And I've not seen the issue with other recent builds of default. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 08:48:58 2013 From: report at bugs.python.org (Alejandro Marco Ramos) Date: Thu, 03 Jan 2013 07:48:58 +0000 Subject: [issue16844] funcName in logging module for python 2.6 In-Reply-To: <1357166242.35.0.208386343695.issue16844@psf.upfronthosting.co.za> Message-ID: <1357199338.94.0.193447497589.issue16844@psf.upfronthosting.co.za> Alejandro Marco Ramos added the comment: In response to msg178860. When use the module logging and in the definition of the format string appear '%(funcName)s' the module crash. (Extract): File "/Library/Python/2.6/site-packages/logging-0.4.9.6-py2.6.egg/logging/__init__.py", line 724, in emit msg = self.format(record) File "/Library/Python/2.6/site-packages/logging-0.4.9.6-py2.6.egg/logging/__init__.py", line 610, in format return fmt.format(record) File "/Library/Python/2.6/site-packages/logging-0.4.9.6-py2.6.egg/logging/__init__.py", line 403, in format s = self._fmt % record.__dict__ KeyError: 'funcName' The object 'record' not contain attribute 'funcName' and line 403 (s = self._fmt % record.__dict__) crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 08:50:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 Jan 2013 07:50:32 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357199432.92.0.313104068558.issue12939@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 08:54:32 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2013 07:54:32 +0000 Subject: [issue16847] sha module broken In-Reply-To: <1357196210.69.0.740863456669.issue16847@psf.upfronthosting.co.za> Message-ID: <1357199672.67.0.492601870964.issue16847@psf.upfronthosting.co.za> Christian Heimes added the comment: The problem can only occur when you compile a non-pydebug build with the -DDEBUG flag instead the -DNDEBUG flag. With -DNDEBUG the assert() call doesn't do anything and the function call is removed by the preprocessor. I'll fix it later. ---------- assignee: -> christian.heimes nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 09:00:46 2013 From: report at bugs.python.org (Georg Brandl) Date: Thu, 03 Jan 2013 08:00:46 +0000 Subject: [issue8952] Doc/c-api/arg.rst: fix documentation of number formats In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za> Message-ID: <1357200046.35.0.97938509785.issue8952@psf.upfronthosting.co.za> Georg Brandl added the comment: It's still a valid bug. ---------- nosy: +georg.brandl resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 09:13:37 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 03 Jan 2013 08:13:37 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357200817.81.0.724662416997.issue12939@psf.upfronthosting.co.za> ???? ????????? added the comment: Yes, re-writing windows IO to direct API, without intemediate layer is still needed. Please don't close bug. Maybe someone will implement this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 09:19:56 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 08:19:56 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357201196.73.0.903433279118.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: The attached patch adds a couple of section about the single and multiple clones approaches. The patch is still incomplete, because the rest of the page should be adapted to the new content (in particular the old sections should be removed, and the whole structure revisited), but I wanted some early feedback about the ones I added. The idea is that contributors can use the single clone approach, and since they don't need to commit/merge, they don't need more instructions then the ones provided already in the setup.rst page. Committers are better off with multiple clones, and the best way to do it is IMHO with the share extension, so that's what I described. Ideally this section should be followed by a FAQ-like list that explains how to deal with conflicts, head merges, null merges, long-term features and similar. Some of these things are already there; some extra things are also there, and they should probably be moved or removed. ---------- Added file: http://bugs.python.org/file28540/issue14468.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 09:23:03 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Jan 2013 08:23:03 +0000 Subject: [issue16847] sha module broken In-Reply-To: <1357196210.69.0.740863456669.issue16847@psf.upfronthosting.co.za> Message-ID: <3YcMZZ2ngRzS1K@mail.python.org> Roundup Robot added the comment: New changeset 944e86223d1f by Christian Heimes in branch '3.3': Issue #16847: Fixed improper use of _PyUnicode_CheckConsistency() in http://hg.python.org/cpython/rev/944e86223d1f New changeset 4b42d7f288c5 by Christian Heimes in branch 'default': Issue #16847: Fixed improper use of _PyUnicode_CheckConsistency() in http://hg.python.org/cpython/rev/4b42d7f288c5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 09:23:43 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2013 08:23:43 +0000 Subject: [issue16847] sha module broken In-Reply-To: <1357196210.69.0.740863456669.issue16847@psf.upfronthosting.co.za> Message-ID: <1357201423.4.0.358988952503.issue16847@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 09:43:06 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 03 Jan 2013 08:43:06 +0000 Subject: [issue16847] sha module broken In-Reply-To: <1357196210.69.0.740863456669.issue16847@psf.upfronthosting.co.za> Message-ID: <1357202586.83.0.750611841118.issue16847@psf.upfronthosting.co.za> Ronald Oussoren added the comment: That's quick, thank :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 09:46:52 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 03 Jan 2013 08:46:52 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357202812.64.0.986671519246.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Content-wise the patch looks pretty good. I agree with the recommendations. A couple suggestions though: I would break up the 20 lines of command-line commands. Right now that chunk is a bit too long to grasp meaningfully. My suggestion would be to break it up into two sections with text in between: one for applying a patch to 2.x or 3.x, and the other for merging (forward-porting) from 3.x to 3.y, with a textual explanation of what the subsequent chunk of commands will do. I would also state (or link to) something about forward-porting from 3.x to 3.y and that 2.7 should be kept separate (both of which I think the current patch assumes knowledge of). I would also say (or link to) something about pushing all branches simultaneously. Lastly, might it be worth explicitly dividing the Mercurial stuff into separate sections for (1) everyone, and (2) committers? Putting the committer-specific stuff (e.g. instructions on merging and pushing changes) in a separate section will simplify things for the general contributor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 09:57:19 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 08:57:19 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357203439.78.0.904056572053.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I would break up the 20 lines of command-line commands. I would have to find a compromise for this, because on one hand it's convenient to have all the commands in a single place (so it's easy to get an overview), but on the other hand that block includes several logically different operation (importing, grafting, merging) that would deserve their own "FAQ". > I would also state (or link to) something about forward-porting from > 3.x to 3.y and that 2.7 should be kept separate (both of which I > think the current patch assumes knowledge of). This is currently explained, but should be reorganized and integrated with my patch. > I would also say (or link to) something about pushing all branches > simultaneously. This happens automatically, so I don't think it deserves more than a short mention somewhere. > Lastly, might it be worth explicitly dividing the Mercurial stuff > into separate sections for (1) everyone, and (2) committers? ISTM that all the things that contributors need to know are already explained somewhere else in the devguide. This includes cloning, switching branches, and applying and generating patches. What I'm described here is mostly aimed to developers, since contributors don't have to commit/merging/grafting and dealing with all the related things. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 10:54:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 09:54:20 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357206860.45.0.950167643153.issue12939@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Windows nosy: +ezio.melotti stage: -> needs patch type: -> enhancement versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 11:03:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 10:03:31 +0000 Subject: [issue8821] Range check on unicode repr In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za> Message-ID: <1357207411.72.0.855216585182.issue8821@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can accept the patch. You can reject the patch. It doesn't matter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 11:08:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 10:08:59 +0000 Subject: [issue16842] Allow to override a function signature for pydoc with a docstring In-Reply-To: <1357157305.88.0.0239428638229.issue16842@psf.upfronthosting.co.za> Message-ID: <1357207739.73.0.592792871004.issue16842@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I mixed up the issues. For this issue I have not a patch yet. I wait for some suggestions and decisions first. See also related issue16638. ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 11:13:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 10:13:20 +0000 Subject: [issue16801] Preserve original representation for integers / floats in docstrings In-Reply-To: <1357164790.28.0.0917255231388.issue16801@psf.upfronthosting.co.za> Message-ID: <201301031213.04354.storchaka@gmail.com> Serhiy Storchaka added the comment: > A subclass with a custom representation, as I suggested above, is even > simpler and involves no change to inspect or docstring conventions. Agree, but this is a particular and cumbersome solution. I open new issue16842 for docstring conventions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 11:45:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 10:45:37 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357209937.16.0.0300916677589.issue16748@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also test_functools, test_xml_etree, test_bisect, test_bz2, test_warnings, test_decimal, test_datetime, json_tests, test_io, test_concurrent_futures, and many, many other undiscoverable tests. ---------- stage: committed/rejected -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 12:04:12 2013 From: report at bugs.python.org (Samuel John) Date: Thu, 03 Jan 2013 11:04:12 +0000 Subject: [issue1584] Mac OS X: building with X11 Tkinter In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za> Message-ID: <1357211052.26.0.196142521991.issue1584@psf.upfronthosting.co.za> Samuel John added the comment: Hello from Homebrew (Mac)! Indeed we also patch setup.py (but right now only for python2.7) and uncommented the "detect_tkinter_darwin" related lines to support linking against a Tkinter build with homebrew (optionally with X11 support). (Our patch: https://github.com/mxcl/homebrew/pull/16626/files#L0R270) I agree that an option to tell setup.py to use another Tk would be much appreciated. ---------- nosy: +samueljohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 12:04:52 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 11:04:52 +0000 Subject: [issue15596] pickle: Faster serialization of Unicode strings In-Reply-To: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za> Message-ID: <1357211092.69.0.287666099695.issue15596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, I take care of this. I have the own patch for raw_unicode_escape() optimization, but microbenchmarks don't show any speed up. Maybe your approach will be better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 12:16:56 2013 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 Jan 2013 11:16:56 +0000 Subject: [issue16844] funcName in logging module for python 2.6 In-Reply-To: <1357166242.35.0.208386343695.issue16844@psf.upfronthosting.co.za> Message-ID: <1357211816.84.0.200622988618.issue16844@psf.upfronthosting.co.za> Vinay Sajip added the comment: You are apparently not using the logging in stdlib, but the older, standalone logging package intended to be used in versions of Python older than 2.3 - note the presence of "site-packages/logging-0.4.9.6-py2.6.egg" in the traceback. If you are using Python 2.6, you don't need the standalone logging-0.4.9.6, as the logging in the stdlib is more up to date (as you've discovered). ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 12:32:54 2013 From: report at bugs.python.org (Samuel John) Date: Thu, 03 Jan 2013 11:32:54 +0000 Subject: [issue16848] Mac OS X: python-config --ldflags and location of Python.framework Message-ID: <1357212774.75.0.369526303193.issue16848@psf.upfronthosting.co.za> New submission from Samuel John: Some tools use `python-config --ldflags` to get the flags in order to link against the Python lib on OS X (for example gst-python from pygtk (2.x). For framework builds, `python-config --ldflags` returns (among few other): -u _PyMac_Error Python.framework/Versions/2.7/Python which is an incomplete path. This issue is almost a duplicate of http://bugs.python.org/issue3588 and the fix discussed there would work. However I report this for Python 2.7. We at Homebrew propose a very similar fix but I'd prefer the one in issue3588: LINKFORSHARED = -u _PyMac_Error -framework Python LDFLAGS += -F$(PYTHONFRAMEWORKPREFIX) ---------- components: Build messages: 178936 nosy: hynek, ned.deily, ronaldoussoren, samueljohn priority: normal severity: normal status: open title: Mac OS X: python-config --ldflags and location of Python.framework type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 12:49:17 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 03 Jan 2013 11:49:17 +0000 Subject: [issue16848] Mac OS X: python-config --ldflags and location of Python.framework In-Reply-To: <1357212774.75.0.369526303193.issue16848@psf.upfronthosting.co.za> Message-ID: <1357213757.78.0.784872429608.issue16848@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Using '-framework Python' is suboptimal because this doesn't control which framework is used for linking (in particular, if you have both Python 2.7 and 3.3 installed '-framework Python' will link against the one installed last). For Python 3.3 I get: $ /Library/Frameworks/Python.framework/Versions/3.2/bin/python3-config --ldflags -L/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m -ldl -framework CoreFoundation -lpython3.2m Simular output would also work for python 2.7 (but I don't have a patch right now) ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 13:30:39 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Jan 2013 12:30:39 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357216239.54.0.00481985352528.issue13094@psf.upfronthosting.co.za> R. David Murray added the comment: The FAQ (as in, this question gets asked again and again) is something like "why do the lambdas I define in a loop all return the same result when the input value was different when each one was defined?" The same applies to regular functions, but people almost never do that in a loop, so in that case they are more likely to think of the scoping issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 13:36:42 2013 From: report at bugs.python.org (Franck Michea) Date: Thu, 03 Jan 2013 12:36:42 +0000 Subject: [issue16849] Element.{get, iter} doesn't handle keyword arguments when using _elementtree C accelerator. Message-ID: <1357216602.29.0.17641407766.issue16849@psf.upfronthosting.co.za> New submission from Franck Michea: Documentation: - http://docs.python.org/3.3/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.get - http://docs.python.org/3.3/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.iter These two functions are documented with keyword arguments. Python implementation works correctly, but as of 3.3, _etreeelement module in C is hot-patching this module to enhance speed. C implementation only expects normal arguments for get and iter. This is what this patch fixes. First patch so: - I am not sure about the "key" string in kwlist array, I followed code above and it doesn't work without it, so I guess it's to for the normal arg. - I am not sure about how to test iter with this. tag argument is never used. - Included a test that shows the problem. Have a nice day, ---------- components: Library (Lib), XML files: etree.patch keywords: patch messages: 178939 nosy: kushou priority: normal severity: normal status: open title: Element.{get,iter} doesn't handle keyword arguments when using _elementtree C accelerator. type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file28541/etree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 13:39:07 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Jan 2013 12:39:07 +0000 Subject: [issue16846] relative import solution In-Reply-To: <1357192331.61.0.693606949117.issue16846@psf.upfronthosting.co.za> Message-ID: <1357216747.34.0.0505489907478.issue16846@psf.upfronthosting.co.za> R. David Murray added the comment: Could you give more information about what you see as the bug, here? I'm not understanding the problem because there doesn't appear to be enough context. What is your directory structure? Where is the import happening? ---------- components: +Interpreter Core -Windows nosy: +r.david.murray type: resource usage -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 13:43:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 12:43:01 +0000 Subject: [issue16281] TODO in tailmatch(): it does not support backward in all cases In-Reply-To: <1350607883.61.0.918476063498.issue16281@psf.upfronthosting.co.za> Message-ID: <1357216981.16.0.658562681605.issue16281@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Shouldn't this be applied to 3.3? As for optimization, I made some benchmarks and didn't saw any significant difference. Usually this function used to check short ASCII heads and tails and any optimization will not be seen even under a microscope. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 13:45:05 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 03 Jan 2013 12:45:05 +0000 Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za> Message-ID: <1357217105.2.0.410619200775.issue12105@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Note that on Windows there is an O_NOINHERIT flag which almost corresponds to O_CLOEXEC on Linux. I don't think there is a need to use the win32 api. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 14:11:57 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 03 Jan 2013 13:11:57 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357218717.62.0.608128704551.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: A while ago I did write a PipeIO class which subclasses io.RawIOBase and works for overlapped pipe handles. (It was intended for multiprocessing and doing asynchronous IO with subprocess.) As it is it would not work with normal files because when you do overlapped IO on files you must manually track the file position. > Yes, re-writing windows IO to direct API, without intemediate layer is still > needed. What are the expected benefits? > It would help feature #12105 to implement "O_CLOEXEC" flag using the > lpSecurityAttributes argument. Isn't O_NOINHERIT the Windows equivalent of O_CLOEXEC? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 14:38:55 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 13:38:55 +0000 Subject: [issue16281] TODO in tailmatch(): it does not support backward in all cases In-Reply-To: <1357216981.16.0.658562681605.issue16281@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Shouldn't this be applied to 3.3? It's just a cleanup, it doesn't fix any real bug. I prefer to not pollute old versions with cleanup. > As for optimization, I made some benchmarks and didn't saw any significant difference. Usually this function used to check short ASCII heads and tails and any optimization will not be seen even under a microscope. Ok, agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 15:01:05 2013 From: report at bugs.python.org (Georg Brandl) Date: Thu, 03 Jan 2013 14:01:05 +0000 Subject: [issue16846] relative import solution In-Reply-To: <1357192331.61.0.693606949117.issue16846@psf.upfronthosting.co.za> Message-ID: <1357221665.8.0.790523934634.issue16846@psf.upfronthosting.co.za> Georg Brandl added the comment: David, the "issue" is that Python only allows relative imports within packages. The OP wants to have a.py and b.py in the same directory and then be able to said "from . import b" in the a module. This is a design decision and will not change without a PEP. ---------- nosy: +georg.brandl, ncoghlan resolution: -> rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 15:44:02 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 03 Jan 2013 14:44:02 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <20130101225642.GB3402@lp-shahaf.local> Message-ID: Eli Bendersky added the comment: On Tue, Jan 1, 2013 at 2:56 PM, Daniel Shahaf wrote: > > Daniel Shahaf added the comment: > > Eli Bendersky wrote on Tue, Jan 01, 2013 at 15:54:00 +0000: > > Why did you change the class name, by the way, I don't think it's > > a valid change at least for 3.3 in terms of backwards compatibility. > > > > With unmodified tip of 3.4: > > >>> import pickle, xml.etree.ElementTree as ET > >>> pickle.dumps(ET.Element('foo')) > Traceback (most recent call last): > File "", line 1, in > _pickle.PicklingError: Can't pickle : attribute > lookup builtins.Element failed > > I added the "_elementtree" to the tp_name in order to bypass the above > error. Module-qualified names were in use elsewhere (including by > _elementtree._element_iterator) so it seemed reasonable. I'll defer to > you about compatibility implications of this change. I asked on pydev, but this is a key point to resolve. Can pickling/unpickling be made to work correctly without such (or similar) change at all? How will the unpickler know which module to load when it sees a pickled object of Element type? If this change is required (even if we choose to name it "xml.etree.ElementTree.Element" for Py compatibility to fix the pickling regression, we may find ourselves in a need to change it between 3.3 and 3.3.1 and I'm not sure if that's valid. I hope my question on pydev will be resolved conclusively. Danial, could you investigate if such a change is absolutely required to make pickling/unickling of Element work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 15:55:38 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 14:55:38 +0000 Subject: [issue8952] Doc/c-api/arg.rst: fix documentation of number formats In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za> Message-ID: <1357224938.29.0.232667747984.issue8952@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:08:29 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Jan 2013 15:08:29 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357225709.79.0.801562280256.issue16748@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's version 2 of the genericpath patch. Should I try to fix everything in one patch, or one patch per test module (or group of test modules like test_(generic|mac|nt|posix)path.py)? And if separate, should each one get its own issue, or just keep them all here? ---------- Added file: http://bugs.python.org/file28542/issue16748_genericpath.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:19:33 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Jan 2013 15:19:33 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357226373.83.0.775140068045.issue16835@psf.upfronthosting.co.za> Zachary Ware added the comment: > Thanks for the review, new patch attached. You're quite welcome. Is there anything I've missed in the process of reviewing itself? This is the first time I've reviewed a patch here... I did miss another nit in the prose, though; "the tests methods" in the first line isn't quite right, but I can't decide if it should be "the test's methods" (singular possessive), "the tests' methods" (plural possessive), or "test methods" (non-specific, non-possessive). Any of the three that better gets your point across makes me happy :) >> This should either have another newline inbetween or be reflowed. >> Either one paragraph or two makes sense to me, but I can't tell which >> way you actually meant > > I meant one and half :) > I guess in HTML that would have been a
inside the

, but I don't > think it really matters if it's rendered as a single paragraph. I see. As is works for me if it works for you, though I might lean towards rounding it up to 2 paragraphs :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:23:26 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 15:23:26 +0000 Subject: [issue16850] Atomic open + close-and-exec Message-ID: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> New submission from STINNER Victor: Recent version on different operating systems support opening a file with close-on-exec flag set immediatly (atomic). This feature fixes a race condition when the process calls execv() between open() and fcntl() (to set the FD_CLOEXEC flag to the newly opened file). It would be nice to expose this feature in Python. The problem is the find a portable and safe way to expose the feature: neologix is against a best-effort function. For example, Linux kernel older than 2.6.22 simply ignores O_CLOEXEC flag (while the libc may expose it). The feature looks to be supported by at least: * Linux kernel >= 2.6.23 * FreeBSD 8+ * Windows: _open(filename, _O_NOINHERIT). Is it supported by Windows XP and older versions? http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx See also: * Issue #12760 (closed): This issue added an "x" mode to open() to create a file in exclusive mode * Issue #12103: "Document how to use open with os.O_CLOEXEC" * Issue #12105: It was proposed to add an "e" mode to open() for O_CLOEXEC ---------- components: Interpreter Core messages: 178949 nosy: alexey-smirnov, amaury.forgeotdarc, haypo, neologix, sbt priority: normal severity: normal status: open title: Atomic open + close-and-exec versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:23:49 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Jan 2013 15:23:49 +0000 Subject: [issue15067] Clean up the sqlite3 docs In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za> Message-ID: <1357226629.72.0.229408065777.issue15067@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file27829/sqlite3_cleanup_2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:23:55 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Jan 2013 15:23:55 +0000 Subject: [issue15067] Clean up the sqlite3 docs In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za> Message-ID: <1357226635.42.0.927015265851.issue15067@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file27830/sqlite3_cleanup_3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:24:48 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 15:24:48 +0000 Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za> Message-ID: <1357226688.33.0.136155566618.issue12105@psf.upfronthosting.co.za> STINNER Victor added the comment: > Note that on Windows there is an O_NOINHERIT flag which > almost corresponds to O_CLOEXEC on Linux. > I don't think there is a need to use the win32 api. Ah yes. Because this issue is closed, I created the issue #16850 which is more specific to open + close-and-exec. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:27:01 2013 From: report at bugs.python.org (Samuel John) Date: Thu, 03 Jan 2013 15:27:01 +0000 Subject: [issue16848] Mac OS X: python-config --ldflags and location of Python.framework In-Reply-To: <1357212774.75.0.369526303193.issue16848@psf.upfronthosting.co.za> Message-ID: <1357226821.08.0.0879052065684.issue16848@psf.upfronthosting.co.za> Samuel John added the comment: Agreed. My patch, I did for Homebrew is to use the full path like so: PYTHONFRAMEWORKDIR= full/path/to/Frameworks/Python.framework instead of just `Python.framework`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:30:04 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 15:30:04 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357227004.81.0.80107872477.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: > The problem is the find a portable and safe way to expose the feature A solution is to add a "e" mode to open() which would raise a NotImplementedError if the platform is not known to support this feature. For example, if the OS is linux, we would check if the kernel version is at least 2.6.23, otherwise an exception would be raised. The check (on the OS/version) would be done at the first call the function (if the "e" mode if used). We already have such behaviour on other functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:32:58 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2013 15:32:58 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357227178.19.0.40575204584.issue16850@psf.upfronthosting.co.za> Christian Heimes added the comment: You could do both: use the O_CLOEXEC flag and do a fcntl() call on POSIX. In my opinion it's enough to document that the x flag may be affected by a race condition issue on some operation systems. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:33:43 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 15:33:43 +0000 Subject: [issue12103] Document how to use open with os.O_CLOEXEC In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za> Message-ID: <1357227223.63.0.929012376696.issue12103@psf.upfronthosting.co.za> STINNER Victor added the comment: > x Open the file exclusively (like the O_EXCL flag of open(2)). > If the file already exists, fopen() fails, and sets errno to EEXIST. > This flag is ignored for fdopen(). Python 3.3 adds support for this mode: see issue #12760. > e (since glibc 2.7) > Open the file with the O_CLOEXEC flag. See open(2) for more information. I created the issue #16850 for this mode. -- Other modes seem to be very specific to some platforms. I don't think that it would be possible to expose them in a portable way using the open() function directly. Can we close this issue? I prefer to work on #16850 for the close-on-exec mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:44:22 2013 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 03 Jan 2013 15:44:22 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled In-Reply-To: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> Message-ID: <1357227862.93.0.397846125823.issue16836@psf.upfronthosting.co.za> Ralf Schmitt added the comment: > Would you want to provide a patch for this? No, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:46:19 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Jan 2013 15:46:19 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357227979.16.0.367977371421.issue16748@psf.upfronthosting.co.za> R. David Murray added the comment: I would suggest one patch and issue per test module. If multiple test modules are related enough, they could go in one patch/issue; that's a judgement call. We can make this issue dependent on those individual issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:47:47 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 15:47:47 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357228067.84.0.990971599555.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: > You could do both: use the O_CLOEXEC flag and do a fcntl() call on POSIX This is the best-effort option. It was already discussed and rejected in the issue #12760. We had a similar discussion for the PEP 418 on monotonic clock. The final decision is not only provide time.monotonic() if the OS supports monotonic clock. Using an exception, a developer can develop its own best-effort function: try: fileobj = open(filename, "e") except NotImplementedError: fileobj = open(filename, "r") # may also fail here if the fcntl module is missing import fcntl flags = fcntl.fcntl(self.socket, fcntl.F_GETFD) fcntl.fcntl(fileobj, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC) We may expose the best-effort function somewhere else, but not in open() which must be atomic in my opinion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 16:58:53 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Jan 2013 15:58:53 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357228733.69.0.776335155834.issue16748@psf.upfronthosting.co.za> Zachary Ware added the comment: Sounds good to me. Shall I move the genericpath fix to a new issue, or leave that one here and begin starting new issues with the next one tackled? Any volunteers for being nosied on new issues to make the dependency link back to this one for me? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:25:29 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2013 16:25:29 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357230329.27.0.988994999232.issue16850@psf.upfronthosting.co.za> Christian Heimes added the comment: Do you mean #12105? I didn't know about the ticket before. How about two options, like 'e' for guaranteed atomic CLOEXEC and 'E' for CLOEXEC with or without atomic ops? It's not much additional work and lowers the burden on the user. It's going to be hard to get a list of platforms and versions where O_CLOEXEC is supported. We should go for a white list approach and only enable it on platforms that are either documented to support it or have been tested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:28:01 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 16:28:01 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357230481.78.0.623152360394.issue13094@psf.upfronthosting.co.za> Ezio Melotti added the comment: > "why do the lambdas I define in a loop all return the same result when > the input value was different when each one was defined?" I thought about that, but that sounds a bit too long/specific. It also has the problem that the issue is not strictly related to lambdas or loops (even if this combination might be more common), and doesn't say where the "result" come from. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:31:48 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2013 16:31:48 +0000 Subject: [issue12103] Document how to use open with os.O_CLOEXEC In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za> Message-ID: <1357230708.01.0.603064297717.issue12103@psf.upfronthosting.co.za> Christian Heimes added the comment: Sounds good to me. ---------- nosy: +christian.heimes resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:33:18 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 03 Jan 2013 16:33:18 +0000 Subject: [issue14810] tarfile does not support timestamp older 1970-01-01 In-Reply-To: <1337039308.77.0.231194182342.issue14810@psf.upfronthosting.co.za> Message-ID: <1357230798.11.0.594971428034.issue14810@psf.upfronthosting.co.za> ???? ????????? added the comment: Yes, bug exists in python 2.7. The same problem - negative timestamp in mtime field. It prepresented in binary value as '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xc7\xfc' in my case. ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:35:19 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 03 Jan 2013 16:35:19 +0000 Subject: [issue16730] _fill_cache in _bootstrap.py crashes without directory execute permissions In-Reply-To: <1355928901.47.0.243119596238.issue16730@psf.upfronthosting.co.za> Message-ID: <1357230919.83.0.848898587111.issue16730@psf.upfronthosting.co.za> Christian Heimes added the comment: NotADirectoryError is missing from the list of exception. The error can occur when the directory is removed and replaced by an ordinary file. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:41:29 2013 From: report at bugs.python.org (Wojciech Danilo) Date: Thu, 03 Jan 2013 16:41:29 +0000 Subject: [issue16851] ismethod and isfunction methods error Message-ID: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> New submission from Wojciech Danilo: Hi! I think this behaviour is bug. Lets concider the following code: import inspect class X(object): def a(self):pass def b(self):pass def c(self):pass print(inspect.getmembers(X, predicate=inspect.ismethod)) print(inspect.getmembers(X, predicate=inspect.isfunction)) In python 2.7, the results are: [('a', ), ('b', ), ('c', )] [] and in Python 3.2: [] [('a', ), ('b', ), ('c', )] I think, the results from python 2.7 are correct. ---------- components: Library (Lib) messages: 178964 nosy: wdanilo priority: normal severity: normal status: open title: ismethod and isfunction methods error type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:46:36 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Jan 2013 16:46:36 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357231596.03.0.269433542349.issue16748@psf.upfronthosting.co.za> Brett Cannon added the comment: You can go ahead and start a new issue so it isn't forgotten about as this becomes a meta issue. And you can always add me to the nosy, just can't guarantee how fast I will do the reviews. =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:56:23 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 16:56:23 +0000 Subject: [issue16851] ismethod and isfunction methods error In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1357232183.0.0.614786408485.issue16851@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think that's expected and by design. In Python 3 there are no unbound methods, but simply functions: >>> class X: ... def add(a, b): return a+b ... >>> add = X.add >>> add >>> add(3, 4) 7 >>> def add(a, b): return a+b ... >>> add >>> add(3, 4) 7 As you can see there's no real difference between the two "add". It's different though with bound methods (obtained from an instance rather than a class): >>> add = X().add >>> add > The documentation is also clear that ismethod() "Return true if the object is a bound method written in Python.". Maybe an additional note can be added to state that "unbound methods" are not included, and that are instead recognized by isfunction(). ---------- assignee: -> docs at python components: +Documentation -Library (Lib) keywords: +easy nosy: +docs at python, ezio.melotti stage: -> needs patch type: behavior -> enhancement versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:58:41 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Jan 2013 16:58:41 +0000 Subject: [issue16852] Fix test discovery for test_genericpath.py Message-ID: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za> New submission from Zachary Ware: See Issue 16748 for previous discussion. This patch should fix test_genericpath.py, with changes to test_macpath.py, test_ntpath.py, and test_posixpath.py required by the fix to test_genericpath.py. This is version 2 of the patch after a review by Serhiy Storchaka in issue 16748. ---------- components: Tests messages: 178967 nosy: brett.cannon, serhiy.storchaka, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_genericpath.py type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:59:14 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Jan 2013 16:59:14 +0000 Subject: [issue16852] Fix test discovery for test_genericpath.py In-Reply-To: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za> Message-ID: <1357232354.25.0.92637563321.issue16852@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- keywords: +patch Added file: http://bugs.python.org/file28543/issue16852.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 17:59:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 16:59:43 +0000 Subject: [issue16852] Fix test discovery for test_genericpath.py In-Reply-To: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za> Message-ID: <1357232383.92.0.305291669028.issue16852@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 18:12:44 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Jan 2013 17:12:44 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357233164.34.0.745382056096.issue16748@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Fix test discovery for test_genericpath.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 18:14:30 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Jan 2013 17:14:30 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357233270.97.0.00171718300199.issue16748@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 18:23:05 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Jan 2013 17:23:05 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357233785.96.0.284797276109.issue13094@psf.upfronthosting.co.za> R. David Murray added the comment: The point is, it is a FAQ. We are talking about updating the FAQ document. It doesn't matter if the text is "too specific", if it is in fact a FAQ. And it is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 18:36:03 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 03 Jan 2013 17:36:03 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357234563.71.0.839388564319.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Attached is a module for Python 3.3+ which subclasses io.RawIOBase. The constructor signature is WinFileIO(handle, mode="r", closehandle=True) where mode is "r", "w", "r+" or "w+". Handles can be created using _winapi.CreateFile(). Issues: - No support for append mode. - Truncate is not atomic. (Is atomicity supposed to be guaranteed?) - Not properly tested. ---------- Added file: http://bugs.python.org/file28544/winfileio.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 18:36:21 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 03 Jan 2013 17:36:21 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357234581.94.0.110746478961.issue12939@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Added file: http://bugs.python.org/file28545/test_winfileio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 18:38:07 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 17:38:07 +0000 Subject: [issue16853] add a Selector to the select module Message-ID: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: Recently, the multiprocessing and telnetlib modules have been patched to use poll() instead of select() when available (mainly for the FD_SETSIZE limitation): http://bugs.python.org/issue10527 http://bugs.python.org/issue14635 This leads to code duplication (just have a look at the commits to convince yourself), and also it highlights the fact that the select module is too low-level: right now, there's no easy way to do portable and efficient I/O multiplexing. What's more, /dev/poll and epoll() support have been added recently, which can make one puzzled by the myriad of available options. Therefore, to reduce code duplication, and make writing portable and efficient code easier, I suggest the addition of a new select.Selector() class, which offers a - hopefully - simple and consistent API. It has the following advantages: - portable - consistent (select() accepts and returns file objects, whereas pol() only returns FD, the timeouts don't have the same units - seconds/milliseconds, etc). You'll find a tentative implementation attached, with tests (but no docs). I'm also attaching two patches, one for multiprocessing.connection and the other for telnetlib, to show the before/after. I'd like to have your feedback, especially on those points: - right now, Selector.select() returns a set of (fd, event mask). What do you think, would a bare list be OK? - the current version doesn't retry on EINTR, and I'd like to catch it by default: what do you think - since I use an abstract base class, I don't know how to have docstrings show up in the help ---------- components: Library (Lib) files: selector.diff keywords: patch messages: 178970 nosy: giampaolo.rodola, neologix, pitrou priority: normal severity: normal status: open title: add a Selector to the select module type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28546/selector.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 18:38:18 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 17:38:18 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357234698.8.0.565245001493.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28547/selector_multiprocessing.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 18:38:33 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 17:38:33 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357234713.77.0.418979884158.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28548/selector_telnetlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 19:13:23 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 03 Jan 2013 18:13:23 +0000 Subject: [issue14810] tarfile does not support timestamp older 1970-01-01 In-Reply-To: <1337039308.77.0.231194182342.issue14810@psf.upfronthosting.co.za> Message-ID: <1357236803.42.0.0231716459819.issue14810@psf.upfronthosting.co.za> ???? ????????? added the comment: And yes, bug does not appear in python3.2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 19:41:52 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 18:41:52 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled In-Reply-To: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> Message-ID: <1357238512.38.0.864113453181.issue16836@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's a patch, tested with ipv6.disable=1. ---------- keywords: +patch nosy: +neologix Added file: http://bugs.python.org/file28549/ipv6config.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 19:44:45 2013 From: report at bugs.python.org (Felipe Cruz) Date: Thu, 03 Jan 2013 18:44:45 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357238685.1.0.26917568529.issue16853@psf.upfronthosting.co.za> Felipe Cruz added the comment: I think you have a point. Did you know about the tulip project? http://code.google.com/p/tulip/source/browse/tulip/unix_events.py#76 It has a PollsterBase class and a SelectPollster(PollsterBase) so the idea is to have a Poller(and you call poll()) but select can be used underneath. Since tulip will be merged to stdlib, maybe you can work on tulip itself. Current tulip Pollers don't return (fd, event) but I have a fork that does for Poll, EPoll, KQueue and WindowsPollster: https://bitbucket.org/felipecruz/tulip/ The selector class doesn't have this change (return fd, mask tuple) right now. ---------- nosy: +felipecruz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 19:47:38 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 03 Jan 2013 18:47:38 +0000 Subject: [issue16849] Element.{get, iter} doesn't handle keyword arguments when using _elementtree C accelerator. In-Reply-To: <1357216602.29.0.17641407766.issue16849@psf.upfronthosting.co.za> Message-ID: <1357238858.42.0.485737067234.issue16849@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:18:27 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 Jan 2013 19:18:27 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357240707.74.0.341830938815.issue16853@psf.upfronthosting.co.za> Antoine Pitrou added the comment: tulip is much bigger than simply a select / poll wrapper. It would probably make more sense for tulip to reuse the abstraction which is proposed here. ---------- nosy: +gvanrossum stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:22:00 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 19:22:00 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357240920.49.0.225786500471.issue13094@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file28550/issue13094.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:30:53 2013 From: report at bugs.python.org (Ross Lagerwall) Date: Thu, 03 Jan 2013 19:30:53 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357241453.67.0.798706290566.issue16850@psf.upfronthosting.co.za> Changes by Ross Lagerwall : ---------- nosy: +rosslagerwall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:32:29 2013 From: report at bugs.python.org (Ross Lagerwall) Date: Thu, 03 Jan 2013 19:32:29 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357241549.24.0.307368994215.issue16853@psf.upfronthosting.co.za> Changes by Ross Lagerwall : ---------- nosy: +rosslagerwall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:46:20 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 03 Jan 2013 19:46:20 +0000 Subject: [issue16833] http.client delayed ack / Nagle algorithm optimisation performs badly for large messages In-Reply-To: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za> Message-ID: <1357242380.29.0.869392734146.issue16833@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Sorry, firefox is playing with me. As usual :). Just writing about i in python-dev. Thanks for the heads up. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:47:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 19:47:09 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py Message-ID: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -u spam Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/home/serhiy/py/cpython/Lib/runpy.py", line 73, in _run_code exec(code, run_globals) File "/home/serhiy/py/cpython/Lib/test/regrtest.py", line 1599, in main() File "/home/serhiy/py/cpython/Lib/test/regrtest.py", line 473, in main usage('Invalid -u/--use option: ' + a) NameError: global name 'usage' is not defined This is 3.4 only issue. ---------- components: Tests messages: 178977 nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: usage() is not defined in Lib/test/regrtest.py type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:48:51 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 19:48:51 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <1357242531.09.0.468642795649.issue16854@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +chris.jerdonek stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:52:59 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 03 Jan 2013 19:52:59 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <1357242779.69.0.077927618706.issue16854@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I observed this issue earlier in issue 16799. See that issue for a fix. Can one of you review that patch? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:53:04 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 19:53:04 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357238685.1.0.26917568529.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I think you have a point. Did you know about the tulip project? > > http://code.google.com/p/tulip/source/browse/tulip/unix_events.py#76 > > It has a PollsterBase class and a SelectPollster(PollsterBase) so the idea is to have a Poller(and you call poll()) but select can be used underneath. Since tulip will be merged to stdlib, maybe you can work on tulip itself. I've had a look, and indeed it has its own Pollster wrapper. Since it can be useful outside of Tulip, it would probably make sense to make it part of the expose API. > Current tulip Pollers don't return (fd, event) but I have a fork that does for Poll, EPoll, KQueue and WindowsPollster Indeed, I think it would be useful. I'm not sure what's best, accept events masks or have distinct methods to register read and write events. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:54:08 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 03 Jan 2013 19:54:08 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <1357242848.36.0.737298755234.issue16854@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- dependencies: +switch regrtest from getopt options to argparse Namespace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:54:31 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 03 Jan 2013 19:54:31 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <1357242871.94.0.427424785105.issue16854@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- assignee: -> chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:57:16 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 19:57:16 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: Oh, I noticed that EpollPollster never closes the underlying epoll FD: that's why Pollster objects should have a close() method (and probably support a context manager). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 20:57:23 2013 From: report at bugs.python.org (Felipe Cruz) Date: Thu, 03 Jan 2013 19:57:23 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357243043.04.0.811554814616.issue16853@psf.upfronthosting.co.za> Felipe Cruz added the comment: Hi Antonie, What you said also makes sense to me. There is one problem(?) that _map_events() is called for every event(for Poll and EPoll) and this can make things slower (I didn't tested it). Also, does it needs to be thread-safe? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:02:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 Jan 2013 20:02:08 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357243328.2.0.471447011384.issue16850@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > How about two options, like 'e' for guaranteed atomic CLOEXEC and 'E' > for CLOEXEC with or without atomic ops? Why would you want that? Best effort is sufficient. Also, I'm not sure why "e". ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:03:35 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 03 Jan 2013 20:03:35 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357243415.51.0.806143516887.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: One thing that occurred to me is that it is often or usually not sufficient to go from 2.7 to 3.2 and on forward because applying a patch made against the default branch loses information if first applied to an earlier branch. The given workflow assumes no loss of information and so should probably note this constraint. I usually craft my patch against the default branch. If applying to 2.7 or 3.2, etc. loses information (which has been more often the case for me), then instead of merging I null-merge and reapply the original patch. Should the recommended workflow cover this possibility? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:10:52 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 20:10:52 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357243852.76.0.562737571888.issue16850@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: I don't comfortable exposing this. The main reason is that this flag is really non-portable. Having open() fail at runtime because the platform doesn't support it looks really wrong to me. And silently ignore it is even worse. The 'x' flag was added because it is useful, on available on all platforms (I mean, even Windows has it). Here's, it's by definition Unix-specific, and even then, many Unices don't support it. So I'm -1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:13:07 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 20:13:07 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357243987.9.0.416524666388.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: It can probably be added to the list of "FAQs", or mentioned together with null merges. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:19:41 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 20:19:41 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1357244381.6.0.614703344786.issue2771@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:20:22 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 20:20:22 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1357244422.65.0.281138600207.issue2771@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: -python-dev type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:30:39 2013 From: report at bugs.python.org (David Pritchard) Date: Thu, 03 Jan 2013 20:30:39 +0000 Subject: [issue16730] _fill_cache in _bootstrap.py crashes without directory execute permissions In-Reply-To: <1355928901.47.0.243119596238.issue16730@psf.upfronthosting.co.za> Message-ID: <1357245039.48.0.560320864049.issue16730@psf.upfronthosting.co.za> David Pritchard added the comment: Here's an example where Python 3.3.0 crashes, but where the patched code works. I have only been able to trigger the bug when PYTHONPATH is set (even if to an empty value). (1) create a directory (2) chmod a-rw+x on that directory (3) export PYTHONPATH="" (4) python3 from within that directory: should crash on loading Note, without step (3) the error does not occur. Alternatively, do (1), (2), (3') set PYTHONPATH to that -rw'ed directory (4') python3 from outside of that directory: should crash on loading ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:32:01 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 03 Jan 2013 20:32:01 +0000 Subject: [issue16849] Element.{get, iter} doesn't handle keyword arguments when using _elementtree C accelerator. In-Reply-To: <1357216602.29.0.17641407766.issue16849@psf.upfronthosting.co.za> Message-ID: <1357245121.57.0.389340107668.issue16849@psf.upfronthosting.co.za> Eli Bendersky added the comment: Thank you for the patch, Franck. I will review it when I have the time. ---------- assignee: -> eli.bendersky stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 21:49:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 20:49:39 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1357246179.25.0.794567324554.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which adds support of "wideInt" and "bignum" Tcl types. ---------- assignee: serhiy.storchaka -> keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file28551/tkinter_bignum.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:16:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 21:16:02 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> Message-ID: <1357247762.04.0.620169149472.issue16843@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a second way patch. It adds a deterministic non-realtime timer. ---------- assignee: serhiy.storchaka -> stage: -> patch review Added file: http://bugs.python.org/file28552/test_sched_deterministic_timer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:18:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 21:18:36 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357247916.45.0.968329274481.issue13094@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:24:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 21:24:24 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> Message-ID: <1357248264.53.0.194419804077.issue16843@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:24:53 2013 From: report at bugs.python.org (Bradley Froehle) Date: Thu, 03 Jan 2013 21:24:53 +0000 Subject: [issue5309] packaging doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1357248293.57.0.544287175295.issue5309@psf.upfronthosting.co.za> Changes by Bradley Froehle : ---------- nosy: +bfroehle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:33:42 2013 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Jan 2013 21:33:42 +0000 Subject: [issue16674] Faster getrandbits() for small integers In-Reply-To: <1355432076.17.0.54183868892.issue16674@psf.upfronthosting.co.za> Message-ID: <1357248822.2.0.451287949071.issue16674@psf.upfronthosting.co.za> Mark Dickinson added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:44:04 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 21:44:04 +0000 Subject: [issue16009] Json error messages could provide more information about the error In-Reply-To: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> Message-ID: <1357249444.71.0.724973991108.issue16009@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:49:05 2013 From: report at bugs.python.org (Walter Mundt) Date: Thu, 03 Jan 2013 21:49:05 +0000 Subject: [issue16855] traceback module leaves off module name in last line of formatted tracebacks Message-ID: <1357249745.89.0.552193091281.issue16855@psf.upfronthosting.co.za> New submission from Walter Mundt: The documentation for the traceback module states that it "exactly mimics the behavior of the Python interpreter when it prints a stack trace." However, this does not seem to be the case. In Python 2.7.3, executing the following: import socket import sys import traceback def raises_socket_timeout(): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(0.001) s.connect(('8.8.8.8', 9999)) try: raises_socket_timeout() except Exception: print "print_exc():" traceback.print_exc() print "-------------" print "uncaught:" raise Results in this output: print_exc(): Traceback (most recent call last): File "test.py", line 11, in raises_socket_timeout() File "test.py", line 8, in raises_socket_timeout s.connect(('8.8.8.8', 9999)) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) timeout: timed out ------------- uncaught: Traceback (most recent call last): File "test.py", line 11, in raises_socket_timeout() File "test.py", line 8, in raises_socket_timeout s.connect(('8.8.8.8', 9999)) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) socket.timeout: timed out Note that the last line of the former message is "timeout: timed out" while the latter is "socket.timeout: timed out" (much more informative). I've run into this specific difference in trying to debug production systems that use the traceback module to log exceptions. It also affects traceback.format_exc(), traceback.format_exception_only(), logging.exception(), and logging.info(..., exc_info=True) and friends. ---------- messages: 178991 nosy: waltermundt priority: normal severity: normal status: open title: traceback module leaves off module name in last line of formatted tracebacks type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:53:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Jan 2013 21:53:17 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1357249997.23.0.202456679357.issue16840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 22:53:20 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Jan 2013 21:53:20 +0000 Subject: [issue16009] Json error messages could provide more information about the error In-Reply-To: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> Message-ID: <1357250000.93.0.946428998512.issue16009@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 23:26:45 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 22:26:45 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357252005.03.0.271761412909.issue16853@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's a new version closer to Tulip's one. ---------- Added file: http://bugs.python.org/file28553/selector-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 23:26:58 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Jan 2013 22:26:58 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357252018.3.0.970633101487.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28546/selector.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 3 23:27:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 Jan 2013 22:27:08 +0000 Subject: [issue5309] setup.py doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1357252028.9.0.888482910934.issue5309@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The original request is really about setup.py, not packaging. I don't care about packaging, and it's not in the stdlib. ---------- assignee: tarek -> components: +Build -Distutils2 title: packaging doesn't parallelize extension module compilation -> setup.py doesn't parallelize extension module compilation versions: +Python 3.4 -3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 00:08:38 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 23:08:38 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357254518.05.0.385002510063.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: > The feature looks to be supported by at least: > * FreeBSD 8+ Hum, it looks like it was only added to FreeBSD 8.3: http://www.freebsd.org/cgi/man.cgi?query=open&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html (O_CLOEXEC doesn't appear in FreeBSD 8.2 manual page) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 00:11:05 2013 From: report at bugs.python.org (Martin Mokrejs) Date: Thu, 03 Jan 2013 23:11:05 +0000 Subject: [issue15416] 3 * [] gives a list of 3 cross-referenced lists, a[1]='blah' writes in to ALL three! In-Reply-To: <1342907675.08.0.583810202929.issue15416@psf.upfronthosting.co.za> Message-ID: <1357254665.86.0.306352453843.issue15416@psf.upfronthosting.co.za> Martin Mokrejs added the comment: For the sake of internet archives, the following could be included in the FAQ you referred to: http://www.scipy.org/Cookbook/BuildingArrays >>> import numpy as np >>> a=np.array(5*[False],bool) >>> a array([False, False, False, False, False], dtype=bool) >>> a[4]=1 >>> a array([False, False, False, False, True], dtype=bool) >>> But thanks for the link, it helped me at that time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 00:23:26 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Jan 2013 23:23:26 +0000 Subject: [issue15416] 3 * [] gives a list of 3 cross-referenced lists, a[1]='blah' writes in to ALL three! In-Reply-To: <1342907675.08.0.583810202929.issue15416@psf.upfronthosting.co.za> Message-ID: <1357255406.25.0.523156887052.issue15416@psf.upfronthosting.co.za> R. David Murray added the comment: But that's about numpy, which is not part of core Python, and so doesn't belong in a Python FAQ. But perhaps your posting it here will help someone doing an internet search... ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 00:30:51 2013 From: report at bugs.python.org (David M. Cooke) Date: Thu, 03 Jan 2013 23:30:51 +0000 Subject: [issue16856] Segfault from calling repr() on a dict with a key whose repr raise an exception Message-ID: <1357255851.7.0.241432552715.issue16856@psf.upfronthosting.co.za> New submission from David M. Cooke: The following segfaults: class A(int): def __repr__(self): raise Exception() a = A() d = {a : 1} repr(d) This is with Python 3.3.0, running on Mac OS 10.7.5, from MacPorts: Python 3.3.0 (default, Sep 29 2012, 08:16:08) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin ---------- components: Interpreter Core messages: 178997 nosy: david.m.cooke priority: normal severity: normal status: open title: Segfault from calling repr() on a dict with a key whose repr raise an exception type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 00:40:26 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Jan 2013 23:40:26 +0000 Subject: [issue16856] Segfault from calling repr() on a dict with a key whose repr raise an exception In-Reply-To: <1357255851.7.0.241432552715.issue16856@psf.upfronthosting.co.za> Message-ID: <1357256426.69.0.420471083845.issue16856@psf.upfronthosting.co.za> R. David Murray added the comment: Confirmed on Gentoo linux. On default, too. This is a regression from 3.2. ---------- nosy: +r.david.murray versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 00:42:54 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Jan 2013 23:42:54 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357256574.93.0.873081663094.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: > Also, I'm not sure why "e". The choice of the "e" letter comes from the GNU version of fopen(). Extract of fopen manual page on Linux: e (since glibc 2.7) Open the file with the O_CLOEXEC flag. See open(2) for more information. Oh, by the way: "e" mode is a best-effort approach. It uses fcntl() if O_CLOEXEC is not supported by the running kernel. fopen() doesn't check the kernel version, but pass O_CLOEXEC and check (once) if FD_CLOEXEC is set: http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c;h=61b61b30d88d0fca9e6b20a2fe62a2406cc027cf;hb=HEAD#l319 It's interesting to know that the glibc chose the best-effort approach. > The 'x' flag was added because it is useful, on available on all > platforms (I mean, even Windows has it). Here's, it's by definition > Unix-specific, ... Windows provides O_NOINHERIT (_O_NOINHERIT) flag which has a similar purpose. > ... and even then, many Unices don't support it. Yes, but I bet that more and more OSes will support it :-) For example, it looks like O_CLOEXEC is part of the POSIX standard 2008: http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html ("O_CLOEXEC: If set, the FD_CLOEXEC flag for the new file descriptor shall be set.") The O_CLOEXEC flag of Linux comes from QNX and BeOS which support it since many years (I don't know when, at least since 2004). So O_CLOEXEC is not really specific to Linux. -- For more information of the Linux support, this article of Ulrich Drepper contains many useful information: http://udrepper.livejournal.com/20407.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 01:49:23 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 04 Jan 2013 00:49:23 +0000 Subject: [issue10529] Write argparse i18n howto In-Reply-To: <1290688089.28.0.749623528369.issue10529@psf.upfronthosting.co.za> Message-ID: <1357260563.32.0.986827380969.issue10529@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 01:56:59 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 04 Jan 2013 00:56:59 +0000 Subject: [issue16857] replace email address on howto with my home page Message-ID: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe: I would rather not get the 'thanks' I have been getting since this was published. Rather let that be my website. ---------- assignee: docs at python components: Documentation files: no-mail.diff keywords: patch messages: 179000 nosy: docs at python, tshepang priority: normal severity: normal status: open title: replace email address on howto with my home page versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28554/no-mail.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 01:57:40 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 04 Jan 2013 00:57:40 +0000 Subject: [issue16857] replace my email address on argparse howto with my website In-Reply-To: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za> Message-ID: <1357261060.67.0.518156440071.issue16857@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- title: replace email address on howto with my home page -> replace my email address on argparse howto with my website _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 02:37:06 2013 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2013 01:37:06 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357263426.15.0.309113655688.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think this is a great idea. But let's wait until Tulip is a bit further along; the design of its Pollster might still change as PEP 3156 gets more review and feedback. According to PEP 429 the first beta of 3.4 won't go out until November this year. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 03:09:37 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Fri, 04 Jan 2013 02:09:37 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: Message-ID: <20130104020930.GS3005@lp-shahaf.local> Daniel Shahaf added the comment: Eli Bendersky wrote on Thu, Jan 03, 2013 at 14:44:02 +0000: > On Tue, Jan 1, 2013 at 2:56 PM, Daniel Shahaf wrote: > > I added the "_elementtree" to the tp_name in order to bypass the above > > error. Module-qualified names were in use elsewhere (including by > > _elementtree._element_iterator) so it seemed reasonable. I'll defer to > > you about compatibility implications of this change. > > I asked on pydev, but this is a key point to resolve. Can > pickling/unpickling be made to work correctly without such (or similar) > change at all? How will the unpickler know which module to load when it > sees a pickled object of Element type? Is there a requirement that it loads a particular module? Would etree users notice the difference if pickle.load() returns an instance of the "other" Element implementation than the one they pickled? > Danial, could you investigate if such a change is absolutely required to > make pickling/unickling of Element work? Yes, I'll look into that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 05:35:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Jan 2013 04:35:25 +0000 Subject: [issue16857] replace my email address on argparse howto with my website In-Reply-To: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za> Message-ID: <3YctTR6NK6zS8b@mail.python.org> Roundup Robot added the comment: New changeset c7ae3772b4d4 by Benjamin Peterson in branch '3.2': drop email (closes #16857) http://hg.python.org/cpython/rev/c7ae3772b4d4 New changeset c8e885ecbc89 by Benjamin Peterson in branch '2.7': drop email (closes #16857) http://hg.python.org/cpython/rev/c8e885ecbc89 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 05:36:17 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 04 Jan 2013 04:36:17 +0000 Subject: [issue16857] replace my email address on argparse howto with my website In-Reply-To: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za> Message-ID: <1357274177.47.0.952574665696.issue16857@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I hope that works for you. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 08:53:48 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 04 Jan 2013 07:53:48 +0000 Subject: [issue16858] tarfile silently hides errors Message-ID: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> New submission from ???? ?????????: TarFile.next() silently drop error of one of - EOFHeaderError - InvalidHeaderError occur. So, extracting corrupted .tar file will not raise error. ---------- components: Library (Lib) messages: 179005 nosy: mmarkk priority: normal severity: normal status: open title: tarfile silently hides errors type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 08:55:22 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 04 Jan 2013 07:55:22 +0000 Subject: [issue16859] tarfile.TarInfo.fromtarfile does not check read() return value Message-ID: <1357286122.2.0.304851627332.issue16859@psf.upfronthosting.co.za> New submission from ???? ?????????: tarfile.TarInfo.fromtarfile does not check read() return value. read() may return less than requested size, so, buf = tarfile.fileobj.read(BLOCKSIZE) ... obj.offset = tarfile.fileobj.tell() - BLOCKSIZE may do something nasty. ---------- messages: 179006 nosy: mmarkk priority: normal severity: normal status: open title: tarfile.TarInfo.fromtarfile does not check read() return value _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 09:00:13 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 04 Jan 2013 08:00:13 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1357286413.63.0.873735324123.issue16858@psf.upfronthosting.co.za> ???? ????????? added the comment: Ups. hiding EOFHeaderError is not an error. But handilng of other errors is not perfect. Please review TarFile.next() for cases where .tar file is corrupted. For example, TruncatedHeaderError is re-raised only if problem at the start of the file. Really, it can appear in the (original) middle of the file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 09:07:01 2013 From: report at bugs.python.org (Ned Deily) Date: Fri, 04 Jan 2013 08:07:01 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1357286821.22.0.592358216751.issue16858@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lars.gustaebel versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 09:07:58 2013 From: report at bugs.python.org (Ned Deily) Date: Fri, 04 Jan 2013 08:07:58 +0000 Subject: [issue16859] tarfile.TarInfo.fromtarfile does not check read() return value In-Reply-To: <1357286122.2.0.304851627332.issue16859@psf.upfronthosting.co.za> Message-ID: <1357286878.95.0.663564361289.issue16859@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 10:41:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 09:41:31 +0000 Subject: [issue16856] Segfault from calling repr() on a dict with a key whose repr raise an exception In-Reply-To: <1357255851.7.0.241432552715.issue16856@psf.upfronthosting.co.za> Message-ID: <1357292491.8.0.744018584909.issue16856@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. ---------- assignee: -> serhiy.storchaka components: +Unicode keywords: +3.3regression, patch nosy: +ezio.melotti, serhiy.storchaka stage: -> patch review Added file: http://bugs.python.org/file28555/unicode_append.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 10:45:37 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2013 09:45:37 +0000 Subject: [issue16856] Segfault from calling repr() on a dict with a key whose repr raise an exception In-Reply-To: <1357255851.7.0.241432552715.issue16856@psf.upfronthosting.co.za> Message-ID: <1357292737.82.0.891149686314.issue16856@psf.upfronthosting.co.za> Christian Heimes added the comment: IMO the check is better performed a couple of lines later: if (right == NULL || left == NULL || !PyUnicode_Check(left)) { ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 11:01:17 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2013 10:01:17 +0000 Subject: [issue5309] setup.py doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1357293677.63.0.614197438043.issue5309@psf.upfronthosting.co.za> Christian Heimes added the comment: +1 I think it's sufficient to parallelize the compilation step (.c -> .o) and ignore the linker step. Linking is usually so fast that it doesn't matter. Idea: * separate compile step from link step * run all compile calls for all extensions in parallel until all objects of all extensions are generated * do linking and error reporting in serial mode ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 11:09:41 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 04 Jan 2013 10:09:41 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <20130104020930.GS3005@lp-shahaf.local> Message-ID: <20130104100943.GA4199@sleipnir.bytereef.org> Stefan Krah added the comment: Daniel Shahaf wrote: > Is there a requirement that it loads a particular module? Would etree > users notice the difference if pickle.load() returns an instance of the > "other" Element implementation than the one they pickled? Yes: If you send an "_elementtree.Element" pickle to another machine that doesn't have a working C version, it can't be unpickled. As far as I know the only way around that is to pickle as "xml.etree.ElementTree.Element". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 11:20:54 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Jan 2013 10:20:54 +0000 Subject: [issue16674] Faster getrandbits() for small integers In-Reply-To: <1355432076.17.0.54183868892.issue16674@psf.upfronthosting.co.za> Message-ID: <3Yd2855KrfzSLX@mail.python.org> Roundup Robot added the comment: New changeset b0926ddcab5e by Serhiy Storchaka in branch 'default': Issue #16674: random.getrandbits() is now 20-40% faster for small integers. http://hg.python.org/cpython/rev/b0926ddcab5e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 11:21:58 2013 From: report at bugs.python.org (=?utf-8?q?Nico_M=C3=B6ller?=) Date: Fri, 04 Jan 2013 10:21:58 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za> Message-ID: <1357294918.4.0.881182568913.issue9720@psf.upfronthosting.co.za> Nico M?ller added the comment: I most definitely need a patch for 2.7.3 Would be awesome if you could provide a patch for that version. ---------- nosy: +Nico.M?ller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 11:21:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 10:21:59 +0000 Subject: [issue16674] Faster getrandbits() for small integers In-Reply-To: <1355432076.17.0.54183868892.issue16674@psf.upfronthosting.co.za> Message-ID: <1357294919.61.0.983496301012.issue16674@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 11:40:50 2013 From: report at bugs.python.org (Kushal Das) Date: Fri, 04 Jan 2013 10:40:50 +0000 Subject: [issue16799] switch regrtest from getopt options to argparse Namespace In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za> Message-ID: <1357296050.43.0.404920890143.issue16799@psf.upfronthosting.co.za> Kushal Das added the comment: The patches look good. Applied successfully and tests ran ok. ---------- nosy: +kushaldas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 11:42:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Jan 2013 10:42:04 +0000 Subject: [issue16856] Segfault from calling repr() on a dict with a key whose repr raise an exception In-Reply-To: <1357255851.7.0.241432552715.issue16856@psf.upfronthosting.co.za> Message-ID: <3Yd2cW1wv0zS7d@mail.python.org> Roundup Robot added the comment: New changeset 3cee61137598 by Serhiy Storchaka in branch '3.3': Issue #16856: Fix a segmentation fault from calling repr() on a dict with http://hg.python.org/cpython/rev/3cee61137598 New changeset fee4bc043d73 by Serhiy Storchaka in branch 'default': Issue #16856: Fix a segmentation fault from calling repr() on a dict with http://hg.python.org/cpython/rev/fee4bc043d73 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 11:48:32 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 10:48:32 +0000 Subject: [issue16856] Segfault from calling repr() on a dict with a key whose repr raise an exception In-Reply-To: <1357255851.7.0.241432552715.issue16856@psf.upfronthosting.co.za> Message-ID: <1357296512.69.0.598396317607.issue16856@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > IMO the check is better performed a couple of lines later: Done. Thank you for report, David. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 13:46:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Jan 2013 12:46:35 +0000 Subject: [issue16747] Remove 'file' type reference from 'iterable' glossary entry In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za> Message-ID: <3Yd5NC0R5JzS9q@mail.python.org> Roundup Robot added the comment: New changeset dea89ee34402 by Chris Jerdonek in branch '2.7': Issue #16747: Reflow iterable glossary entry to match 3.x change e19ed347523e. http://hg.python.org/cpython/rev/dea89ee34402 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 14:18:11 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 13:18:11 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357305491.57.0.597912977053.issue16853@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's a new version adressing Guido's comments (except for kqueue, for which I'll add support later when I can test it). I'm also attaching a benchmark to compare the implementations: as noted by Guido, the complexity of select/poll/epoll are the theoretical ones: in real life, the syscall's cost is probably dwarfed by objects creation, etc. Here's a run, for two ready FDs among 1018: """ $ ./python ~/selector_bench.py -r 2 -m 1018 -t socket Trying with 2 ready FDs out of 1018, type socket 0.056010190999586484 0.2639519829990604 1.1859817369986558 """ So this can be interesting when a large number of FDs are monitored. For sake of cmpleteness, for a sparse allocation (i.e. just a couple FDS allocated near FD_SETSIZE), there's not much gain: """ $ ./python ~/selector_bench.py -r 2 -m 1018 -t socket -s Trying with 2 FDs starting at 1018, type socket 0.06651040699944133 0.06033727799876942 0.0948788189998595 """ Two points I'm not sure about: - should EINTR be handled (i.e. retry, with an updated timeout). I'm tempted to say yes, because EINTR is just a pain the user should never be exposed with. - what should be done with POLLNVAL and POLLERR? Raise an exception (that's what Java does, but since you can get quite quite easily it would be a pain to use), return a generic SELECT_ERR event? FWIW, twisted returns POLLERR|POLLNVAL as a CONNECTION_LOST event. ---------- Added file: http://bugs.python.org/file28556/selector-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 14:18:47 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 13:18:47 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357305527.93.0.173044673538.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28557/selector_bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 14:18:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 13:18:57 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357305537.52.0.678852742867.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28553/selector-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 14:27:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 13:27:38 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1357294918.4.0.881182568913.issue9720@psf.upfronthosting.co.za> Message-ID: <201301041527.09347.storchaka@gmail.com> Serhiy Storchaka added the comment: Here are second variant patches for 2.7 and 3.2. ---------- Added file: http://bugs.python.org/file28558/zipfile_zip64_try_2-2.7.patch Added file: http://bugs.python.org/file28559/zipfile_zip64_try_2-3.2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r c8e885ecbc89 Lib/zipfile.py --- a/Lib/zipfile.py Thu Jan 03 20:34:19 2013 -0800 +++ b/Lib/zipfile.py Fri Jan 04 15:24:35 2013 +0200 @@ -316,7 +316,7 @@ # compress_size Size of the compressed file # file_size Size of the uncompressed file - def FileHeader(self): + def FileHeader(self, zip64=None): """Return the per-file header as a string.""" dt = self.date_time dosdate = (dt[0] - 1980) << 9 | dt[1] << 5 | dt[2] @@ -331,12 +331,17 @@ extra = self.extra - if file_size > ZIP64_LIMIT or compress_size > ZIP64_LIMIT: - # File is larger than what fits into a 4 byte integer, - # fall back to the ZIP64 extension + if zip64 is None: + zip64 = file_size > ZIP64_LIMIT or compress_size > ZIP64_LIMIT + if zip64: fmt = ' ZIP64_LIMIT or compress_size > ZIP64_LIMIT: + if not zip64: + raise LargeZipFile("Filesize would require ZIP64 extensions") + # File is larger than what fits into a 4 byte integer, + # fall back to the ZIP64 extension file_size = 0xffffffff compress_size = 0xffffffff self.extract_version = max(45, self.extract_version) @@ -1113,20 +1118,23 @@ zinfo.CRC = 0 self.filelist.append(zinfo) self.NameToInfo[zinfo.filename] = zinfo - self.fp.write(zinfo.FileHeader()) + self.fp.write(zinfo.FileHeader(False)) return with open(filename, "rb") as fp: # Must overwrite CRC and sizes with correct data later zinfo.CRC = CRC = 0 zinfo.compress_size = compress_size = 0 - zinfo.file_size = file_size = 0 - self.fp.write(zinfo.FileHeader()) + # Compressed size can be larger than uncompressed size + zip64 = self._allowZip64 and \ + zinfo.file_size * 1.05 > ZIP64_LIMIT + self.fp.write(zinfo.FileHeader(zip64)) if zinfo.compress_type == ZIP_DEFLATED: cmpr = zlib.compressobj(zlib.Z_DEFAULT_COMPRESSION, zlib.DEFLATED, -15) else: cmpr = None + file_size = 0 while 1: buf = fp.read(1024 * 8) if not buf: @@ -1146,11 +1154,16 @@ zinfo.compress_size = file_size zinfo.CRC = CRC zinfo.file_size = file_size - # Seek backwards and write CRC and file sizes + if not zip64 and self._allowZip64: + if file_size > ZIP64_LIMIT: + raise RuntimeError('File size has increased during compressing') + if compress_size > ZIP64_LIMIT: + raise RuntimeError('Compressed size larger than uncompressed size') + # Seek backwards and write file header (which will now include + # correct CRC and file sizes) position = self.fp.tell() # Preserve current position in file - self.fp.seek(zinfo.header_offset + 14, 0) - self.fp.write(struct.pack(" ZIP64_LIMIT or \ + zinfo.compress_size > ZIP64_LIMIT + if zip64 and not self._allowZip64: + raise LargeZipFile("Filesize would require ZIP64 extensions") + self.fp.write(zinfo.FileHeader(zip64)) self.fp.write(bytes) - self.fp.flush() if zinfo.flag_bits & 0x08: # Write CRC and file sizes after the file data - self.fp.write(struct.pack(" ZIP64_LIMIT or compress_size > ZIP64_LIMIT: - # File is larger than what fits into a 4 byte integer, - # fall back to the ZIP64 extension + if zip64 is None: + zip64 = file_size > ZIP64_LIMIT or compress_size > ZIP64_LIMIT + if zip64: fmt = ' ZIP64_LIMIT or compress_size > ZIP64_LIMIT: + if not zip64: + raise LargeZipFile("Filesize would require ZIP64 extensions") + # File is larger than what fits into a 4 byte integer, + # fall back to the ZIP64 extension file_size = 0xffffffff compress_size = 0xffffffff self.extract_version = max(45, self.extract_version) @@ -1135,20 +1140,23 @@ zinfo.CRC = 0 self.filelist.append(zinfo) self.NameToInfo[zinfo.filename] = zinfo - self.fp.write(zinfo.FileHeader()) + self.fp.write(zinfo.FileHeader(False)) return with open(filename, "rb") as fp: # Must overwrite CRC and sizes with correct data later zinfo.CRC = CRC = 0 zinfo.compress_size = compress_size = 0 - zinfo.file_size = file_size = 0 - self.fp.write(zinfo.FileHeader()) + # Compressed size can be larger than uncompressed size + zip64 = self._allowZip64 and \ + zinfo.file_size * 1.05 > ZIP64_LIMIT + self.fp.write(zinfo.FileHeader(zip64)) if zinfo.compress_type == ZIP_DEFLATED: cmpr = zlib.compressobj(zlib.Z_DEFAULT_COMPRESSION, zlib.DEFLATED, -15) else: cmpr = None + file_size = 0 while 1: buf = fp.read(1024 * 8) if not buf: @@ -1168,11 +1176,16 @@ zinfo.compress_size = file_size zinfo.CRC = CRC zinfo.file_size = file_size - # Seek backwards and write CRC and file sizes + if not zip64 and self._allowZip64: + if file_size > ZIP64_LIMIT: + raise RuntimeError('File size has increased during compressing') + if compress_size > ZIP64_LIMIT: + raise RuntimeError('Compressed size larger than uncompressed size') + # Seek backwards and write file header (which will now include + # correct CRC and file sizes) position = self.fp.tell() # Preserve current position in file - self.fp.seek(zinfo.header_offset + 14, 0) - self.fp.write(struct.pack(" ZIP64_LIMIT or \ + zinfo.compress_size > ZIP64_LIMIT + if zip64 and not self._allowZip64: + raise LargeZipFile("Filesize would require ZIP64 extensions") + self.fp.write(zinfo.FileHeader(zip64)) self.fp.write(data) - self.fp.flush() if zinfo.flag_bits & 0x08: # Write CRC and file sizes after the file data - self.fp.write(struct.pack(" Message-ID: Charles-Fran?ois Natali added the comment: > Windows provides O_NOINHERIT (_O_NOINHERIT) flag which has a similar purpose. > >> ... and even then, many Unices don't support it. > > Yes, but I bet that more and more OSes will support it :-) For example, it looks like O_CLOEXEC is part of the POSIX standard 2008: Hum, OK, but many operating systems don't support it to this day. So if we expose it and the underlying operating system doesn't support it, do you want to fallback to fcntl (which wouldb't be atomic anymore, but let's pretend the GIL protection is enough). Also, I'm not sure exactly if this flag is useful enough to be exposed: there are many flags that can be passed when opening a file: O_DIRECT, O_SYNC, O_NONBLOCK, O_DSYNC... Amusingly, Java exposes some of them (but not O_CLOEXEC): http://docs.oracle.com/javase/7/docs/api/java/nio/file/StandardOpenOption.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 14:28:04 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 04 Jan 2013 13:28:04 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357306084.86.0.90820842362.issue16853@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 14:46:22 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Jan 2013 13:46:22 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357307182.97.0.451140043086.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: > So if we expose it and the underlying operating system doesn't support it, do you want to fallback to fcntl (which wouldb't be atomic anymore, but let's pretend the GIL protection is enough). At the beginning, I was convinced that the atomicity was important than the portability. But after having read that even fopen() uses a fallback, it is maybe much more convinient to have a fallback. For example, it would be annoying that a program works on Linux 2.6.23, but not on Linux 2.6.22 whereas the atomicity is not a must-have. Said differently: the manual fallback described in msg178957 now seems annoying to me :-) So let's say that a fallback is preferable to improve the portability, but that open(name, "e") would still fail with NotImplementedError if O_CLOEXEC, O_NOINHERIT and fcntl(FD_CLOEXEC) are all missing on a platform. I guess that all platform provide at least one flag/function. You already implemented a similar fallback for subprocess: use pipe2(O_CLOEXEC) if available, or fallback to pipe()+fcntl(FD_CLOEXEC). > I'm not sure exactly if this flag is useful enough to be exposed I would like to benefit of the atomicity feature of O_CLOEXEC, without having to implement myself all the tricky things to check if the platform supports it or not. O_CLOEXEC solves for example a race condition in tempfile._mkstemp_inner(): fd = _os.open(file, flags, 0o600) _set_cloexec(fd) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:17:25 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 14:17:25 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357307182.97.0.451140043086.issue16850@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > O_CLOEXEC solves for example a race condition in tempfile._mkstemp_inner(): > > fd = _os.open(file, flags, 0o600) > _set_cloexec(fd) Hum... """ diff --git a/Lib/tempfile.py b/Lib/tempfile.py --- a/Lib/tempfile.py +++ b/Lib/tempfile.py @@ -57,6 +57,8 @@ _allocate_lock = _thread.allocate_lock _text_openflags = _os.O_RDWR | _os.O_CREAT | _os.O_EXCL +if hasattr(_os, 'O_CLOEXEC'): + _text_openflags |= _os.O_CLOEXEC if hasattr(_os, 'O_NOINHERIT'): _text_openflags |= _os.O_NOINHERIT if hasattr(_os, 'O_NOFOLLOW'): """ We should probably add this to 3.3 and default (IIRC O_CLOEXEC was added to the os module in 3.3). Also, I think O_NOFOLLOW is useless: if the file is created (O_EXCL|O_CREAT), then by definition it's not a symlink (juste check glibc's mkstemp() implementation, and it only passes O_CREAT|O_EXCL). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:22:29 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Jan 2013 14:22:29 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module Message-ID: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za> New submission from STINNER Victor: os.O_CLOEXEC has been added to Python 3.3. This flag solves a race condition if the process is forked between open() and a call to fcntl() to set the FD_CLOEXEC flag. The following patch written by neologix should fix this issue: """ diff --git a/Lib/tempfile.py b/Lib/tempfile.py --- a/Lib/tempfile.py +++ b/Lib/tempfile.py @@ -57,6 +57,8 @@ _allocate_lock = _thread.allocate_lock _text_openflags = _os.O_RDWR | _os.O_CREAT | _os.O_EXCL +if hasattr(_os, 'O_CLOEXEC'): + _text_openflags |= _os.O_CLOEXEC if hasattr(_os, 'O_NOINHERIT'): _text_openflags |= _os.O_NOINHERIT if hasattr(_os, 'O_NOFOLLOW'): """ The patch can be applied to Python 3.3 and 3.4. ---------- components: Library (Lib) messages: 179023 nosy: haypo, neologix priority: normal severity: normal status: open title: Use O_CLOEXEC in the tempfile module versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:23:27 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Jan 2013 14:23:27 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357309407.62.0.643427263944.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: > We should probably add this to 3.3 and default (IIRC O_CLOEXEC was added to the os module in 3.3). I created the issue #16860. I just realized that tempfile doesn't use open() but os.open(), so this issue help to fix #16860. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:23:59 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Jan 2013 14:23:59 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module In-Reply-To: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za> Message-ID: <1357309439.0.0.19164473245.issue16860@psf.upfronthosting.co.za> STINNER Victor added the comment: See also #16850 which proposes to expose O_CLOEXEC feature in the open() builtin function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:29:22 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 14:29:22 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module In-Reply-To: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za> Message-ID: <1357309762.81.0.503675209884.issue16860@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's the patch. It also removes O_NOFOLLOW, which is basically useless (if the file is created with O_CREAT|O_EXCL, then by definition it's not a symlink). ---------- keywords: +needs review, patch type: -> behavior Added file: http://bugs.python.org/file28560/tempfile_cloexec.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:30:25 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Jan 2013 14:30:25 +0000 Subject: [issue16850] Atomic open + close-and-exec In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357309825.96.0.866627782609.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a work-in-progress patch to test my idea: add "e" flag to open(). Limitations/TODO: * The unit test doesn't work on Windows (it requires fcntl) * "e" mode and the opener argument are exclusive: if O_CLOEXEC and O_NOINHERINT are missing, I don't see how the opener can be aware of the "e" flag. Or should we call fcntl(F_SETFD, flags|FD_CLOEXEC) after the opener? It would be strange: the opener is supposed to be the only one to decide how the file is opened, isn't it? * NotImplementedError is raised if O_CLOEXEC, O_NOINHERIT and fcntl() are missing I only tested my patch on Linux (3.6). ---------- keywords: +patch Added file: http://bugs.python.org/file28561/open_mode_e.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:31:09 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 04 Jan 2013 14:31:09 +0000 Subject: [issue16857] replace my email address on argparse howto with my website In-Reply-To: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za> Message-ID: <1357309869.42.0.658104665794.issue16857@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:35:46 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Jan 2013 14:35:46 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module In-Reply-To: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za> Message-ID: <1357310146.03.0.758048650169.issue16860@psf.upfronthosting.co.za> STINNER Victor added the comment: > Here's the patch. _set_cloexec() is still called whereas it is useless if the OS supports O_CLOEXEC... But the call must be kept because Linux < 2.6.23 just ignores O_CLOEXEC: we would have to check _fcntl.fcntl(fd, _fcntl.F_GETFD, 0) & _fcntl.FD_CLOEXEC to check if the kernel does really support O_CLOEXEC, which is overkill. The possibly useless syscall doesn't hurt. > (if the file is created with O_CREAT|O_EXCL, then by definition it's not a symlink). Ah yes, because of O_EXCL. The patch looks good to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:36:22 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 14:36:22 +0000 Subject: [issue15359] Sockets support for CAN_BCM In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za> Message-ID: <1357310182.26.0.171435898216.issue15359@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Brian, could you add tests to Lib/test/test_socket.py (look for CANTest, you should be able to complete them). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:43:01 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 04 Jan 2013 14:43:01 +0000 Subject: [issue11477] Incorrect operand precedence when implementing sequences in C In-Reply-To: <1299965091.63.0.267715976543.issue11477@psf.upfronthosting.co.za> Message-ID: <1357310581.85.0.569901829947.issue11477@psf.upfronthosting.co.za> Nick Coghlan added the comment: Updated issue title to better describe the symptoms of the issue (and hopefully make it so I don't spend 5 minutes remembering the issue title every time I want to look at it...) ---------- title: Bug in code dispatching based on internal slots -> Incorrect operand precedence when implementing sequences in C _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 15:59:18 2013 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 04 Jan 2013 14:59:18 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <20130104100943.GA4199@sleipnir.bytereef.org> Message-ID: Eli Bendersky added the comment: On Jan 4, 2013 2:09 AM, "Stefan Krah" wrote: > > > Stefan Krah added the comment: > > Daniel Shahaf wrote: > > Is there a requirement that it loads a particular module? Would etree > > users notice the difference if pickle.load() returns an instance of the > > "other" Element implementation than the one they pickled? > > Yes: If you send an "_elementtree.Element" pickle to another machine that > doesn't have a working C version, it can't be unpickled. As far as I know > the only way around that is to pickle as "xml.etree.ElementTree.Element". > > ---------- > Yes this is a good point. Another thing to consider is that if both report the same name then it will be possible to unpickle on a machine running 3.2 > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 16:13:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 15:13:14 +0000 Subject: [issue14807] Move tarfile.filemode() into stat module In-Reply-To: <1337000678.3.0.189462567372.issue14807@psf.upfronthosting.co.za> Message-ID: <1357312394.48.0.962560511717.issue14807@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 16:37:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 15:37:26 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357313846.79.0.203955057763.issue9685@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core type: resource usage -> performance versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 16:41:27 2013 From: report at bugs.python.org (Todd Rovito) Date: Fri, 04 Jan 2013 15:41:27 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357314087.97.0.221996791992.issue5066@psf.upfronthosting.co.za> Todd Rovito added the comment: A "ping" on this bug since it has not had any forward movement. Can somebody please review and or commit? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 16:46:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 15:46:04 +0000 Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za> Message-ID: <1357314364.2.0.740373616741.issue12018@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Tests -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 16:53:21 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 04 Jan 2013 15:53:21 +0000 Subject: [issue16861] Portion of code example not highlighted in collections doc Message-ID: <1357314801.72.0.589947390341.issue16861@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- nosy: ramchandra.apte priority: normal severity: normal status: open title: Portion of code example not highlighted in collections doc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 16:54:25 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 04 Jan 2013 15:54:25 +0000 Subject: [issue16861] Portion of code example not highlighted in collections doc Message-ID: <1357314865.26.0.887283345978.issue16861@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/2/library/collections.html#namedtuple-factory-function-for-tuples-with-named-fields , a portion of the code example is not highlighted. --- Happy, new, melodious, joyful, etc, boring new year. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:00:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 16:00:48 +0000 Subject: [issue9267] Update pickle opcode documentation in pickletools for 3.x In-Reply-To: <1279217581.88.0.294098163632.issue9267@psf.upfronthosting.co.za> Message-ID: <1357315248.62.0.809951175478.issue9267@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue16550. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:04:54 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 04 Jan 2013 16:04:54 +0000 Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za> Message-ID: <1357315494.15.0.0554574508526.issue12018@psf.upfronthosting.co.za> Ronald Oussoren added the comment: There are tests for samefile and sameopenfile in test_genericpath.GenericTest which is included by test_ntpath (NtCommonTest subclasses test_genericpath.CommonTest which again subclasses GenericTest). I cannot easily test on Windows (the only windows systems I've easy access to are production boxes using py2.7), but if my analysis is correct this issue can be closed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:09:01 2013 From: report at bugs.python.org (Brian Curtin) Date: Fri, 04 Jan 2013 16:09:01 +0000 Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za> Message-ID: <1357315741.32.0.159311841987.issue12018@psf.upfronthosting.co.za> Brian Curtin added the comment: That's true of the default branch due to some changes I recently made in the implementation of the functions, but we should probably put tests into 3.2/3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:13:47 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 04 Jan 2013 16:13:47 +0000 Subject: [issue16862] FAQ has outdated information about Stackless Message-ID: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za> New submission from Ramchandra Apte: The FAQ says "It?s [Stackless] still experimental but looks very promising." AFAIK, Stackless is mature. ---------- assignee: docs at python components: Documentation messages: 179038 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: FAQ has outdated information about Stackless _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:14:10 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 04 Jan 2013 16:14:10 +0000 Subject: [issue16862] FAQ has outdated information about Stackless In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za> Message-ID: <1357316050.05.0.790907004449.issue16862@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Sorry, link here, http://docs.python.org/3/faq/design.html#can-t-you-emulate-threads-in-the-interpreter-instead-of-relying-on-an-os-specific-thread-implementation . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:30:09 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 04 Jan 2013 16:30:09 +0000 Subject: [issue14807] Move tarfile.filemode() into stat module In-Reply-To: <1337000678.3.0.189462567372.issue14807@psf.upfronthosting.co.za> Message-ID: <1357317009.28.0.814489607619.issue14807@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Previous issue should have been fixed by now. Closing. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:37:44 2013 From: report at bugs.python.org (Charlie Dimino) Date: Fri, 04 Jan 2013 16:37:44 +0000 Subject: [issue16863] Argparse tutorial outdated Message-ID: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za> New submission from Charlie Dimino: http://docs.python.org/2/howto/argparse.html Error message in the first example is outdated, may indicate further out of date information on page. Example: The tutorial says: prog.py: error: the following arguments are required: echo When the actual error received is: prog.py: error: too few arguments ---------- assignee: docs at python components: Documentation messages: 179041 nosy: Charlie.Dimino, docs at python priority: normal severity: normal status: open title: Argparse tutorial outdated versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:48:11 2013 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2013 16:48:11 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357318091.17.0.42859883865.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: Would it make sense to explore this in the Tulip project first? It could be a new module, tulip/selector.py. (Heck, I'll even give you commit privileges in Tulip.) Also, I've heard (but don't know from personal experience) that Jython supports select but it takes only lists of socket objects, not file descriptors (which don't exist in Java). Finally, what about Windows? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:56:50 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Jan 2013 16:56:50 +0000 Subject: [issue16863] Argparse tutorial outdated In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za> Message-ID: <1357318610.49.0.773390383503.issue16863@psf.upfronthosting.co.za> R. David Murray added the comment: Actually it looks like it is future-dated. The documented error message is the one you get from 3.3. I guess someone backported a doc change for a feature change. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 17:59:21 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Jan 2013 16:59:21 +0000 Subject: [issue16863] Argparse tutorial outdated In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za> Message-ID: <1357318761.1.0.604089354006.issue16863@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, the whole tutorial is newish. So this is a bug just in the 2.7 version of the tutorial (it doesn't match the 2.7 code), and yes, there may be other issues as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:01:49 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Jan 2013 17:01:49 +0000 Subject: [issue16863] Argparse tutorial outdated In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za> Message-ID: <1357318909.45.0.129727668514.issue16863@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 14034. Ezio apparently left the error messages unchanged on purpose...I'm not sure why. ---------- assignee: docs at python -> nosy: +ezio.melotti, tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:06:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Jan 2013 17:06:20 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357319180.63.0.654930900963.issue16853@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've posted a review on Rietveld. Not sure the notification e-mail was sent since I got a weird response from the server. > should EINTR be handled (i.e. retry, with an updated timeout). I'm tempted to say > yes, because EINTR is just a pain the user should never be exposed with. You could add an optional argument to the select() method? > what should be done with POLLNVAL and POLLERR? Raise an exception (that's what Java > does, but since you can get quite quite easily it would be a pain to use), return a > generic SELECT_ERR event? I would say return SELECT_ERR. > So this can be interesting when a large number of FDs are monitored. The difference is impressive indeed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:12:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 17:12:12 +0000 Subject: [issue10557] Malformed error message from float() In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za> Message-ID: <1357319532.36.0.530610933867.issue10557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can this issue be closed? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:21:29 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 04 Jan 2013 17:21:29 +0000 Subject: [issue16862] FAQ has outdated information about Stackless In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za> Message-ID: <1357320089.43.0.920233601348.issue16862@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:23:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 17:23:28 +0000 Subject: [issue9554] test_argparse.py: use new unittest features In-Reply-To: <1281408827.47.0.183260667114.issue9554@psf.upfronthosting.co.za> Message-ID: <1357320208.6.0.509194087153.issue9554@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue16510. ---------- nosy: +serhiy.storchaka versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:24:20 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 17:24:20 +0000 Subject: [issue16863] Argparse tutorial outdated In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za> Message-ID: <1357320260.25.0.928312856504.issue16863@psf.upfronthosting.co.za> Ezio Melotti added the comment: When I backported the patch I probably didn't want to try all the examples to see what the py2 error was. In addition the py3 error is more clear even if it doesn't match what you actually get. I think this can be closed as won't fix, unless someone wants to propose a patch. ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:24:20 2013 From: report at bugs.python.org (Jim Minter) Date: Fri, 04 Jan 2013 17:24:20 +0000 Subject: [issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement Message-ID: <1357320260.32.0.764505068506.issue16864@psf.upfronthosting.co.za> New submission from Jim Minter: sqlite3 doesn't populate the lastrowid member of the Cursor object when a SQL REPLACE statement is executed. The following snippet doesn't work as I would expect: cursor = db.execute("REPLACE INTO table(column) VALUES ('datum')") print cursor.lastrowid # prints None The following snippet, with SQL which is in effect identical to SQLite, does work as expected: cursor = db.execute("INSERT OR REPLACE INTO table(column) VALUES ('datum')") print cursor.lastrowid # prints some rowid Looking at Modules/_sqlite/cursor.c, in _pysqlite_query_execute(), the following snippet is found: if (!multiple && statement_type == STATEMENT_INSERT) { Py_BEGIN_ALLOW_THREADS lastrowid = sqlite3_last_insert_rowid(self->connection->db); Py_END_ALLOW_THREADS self->lastrowid = PyLong_FromLong((long)lastrowid); } else { Py_INCREF(Py_None); self->lastrowid = Py_None; } I suggest this should read something like: if (!multiple && (statement_type == STATEMENT_INSERT || statement_type == STATEMENT_REPLACE)) { instead of: if (!multiple && statement_type == STATEMENT_INSERT) { Thanks, Jim ---------- components: Library (Lib) messages: 179049 nosy: jim_minter priority: normal severity: normal status: open title: sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement type: enhancement versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:25:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 17:25:58 +0000 Subject: [issue16861] Portion of code example not highlighted in collections doc In-Reply-To: <1357314865.26.0.887283345978.issue16861@psf.upfronthosting.co.za> Message-ID: <1357320358.65.0.0791734840509.issue16861@psf.upfronthosting.co.za> Ezio Melotti added the comment: The part that is not highlighted is not part of the code, but the output of the function. ---------- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:31:18 2013 From: report at bugs.python.org (Charlie Dimino) Date: Fri, 04 Jan 2013 17:31:18 +0000 Subject: [issue16863] Argparse tutorial outdated In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za> Message-ID: <1357320678.37.0.909671618554.issue16863@psf.upfronthosting.co.za> Charlie Dimino added the comment: If it's okay, don't close this just yet. I'm new to this system but I'll submit a patch with any fixes to the tutorial I find. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:33:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Jan 2013 17:33:34 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module In-Reply-To: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za> Message-ID: <3YdClL1gblzRyS@mail.python.org> Roundup Robot added the comment: New changeset 64883c614c88 by Charles-Fran?ois Natali in branch 'default': Issue #16860: In tempfile, use O_CLOEXEC when available to set the http://hg.python.org/cpython/rev/64883c614c88 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:36:30 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 17:36:30 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module In-Reply-To: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za> Message-ID: <1357320990.31.0.14246853519.issue16860@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: I've committed it only to default, since it's not really a bug, but rather an improvement (if we did consider this a "security" bug then it should also be backported to 2.7, 3.1, etc). I'll wait a little before removing O_NOFOLLOW: I'm 99% sure it's useless, but just in case someone finds a really subtle reason to keep it... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:37:03 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 17:37:03 +0000 Subject: [issue12613] itertools fixer fails In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za> Message-ID: <1357321023.38.0.948300323637.issue12613@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:41:37 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 17:41:37 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled In-Reply-To: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> Message-ID: <1357321297.69.0.638805861097.issue16836@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:50:08 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 17:50:08 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357321808.41.0.211707615825.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: Feel free to add me to the nosy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:50:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 17:50:24 +0000 Subject: [issue7378] unexpected truncation of traceback In-Reply-To: <1258970662.35.0.76558630095.issue7378@psf.upfronthosting.co.za> Message-ID: <1357321824.91.0.713537731798.issue7378@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 3.1 gets only security fixes. In 2.7 and 3.2+ the bug has already fixed. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:51:28 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 17:51:28 +0000 Subject: [issue16803] Make test_importlib run tests under both _frozen_importlib and importlib._bootstrap In-Reply-To: <1356718069.62.0.143946538677.issue16803@psf.upfronthosting.co.za> Message-ID: <1357321888.12.0.208668642943.issue16803@psf.upfronthosting.co.za> Ezio Melotti added the comment: Is the usual PEP 399 idiom enough, or is something more advanced required? ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 18:55:48 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Jan 2013 17:55:48 +0000 Subject: [issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement In-Reply-To: <1357320260.32.0.764505068506.issue16864@psf.upfronthosting.co.za> Message-ID: <1357322148.2.0.722759508132.issue16864@psf.upfronthosting.co.za> R. David Murray added the comment: Considering that sqlite's 'replace' is a synonym for 'insert or replace', I think the logic error is actually in the detect_statement_type function. Since actions are conditionally taken on the REPLACE statement type in the code, including at least one that adjusts the lastrowid, I don't think the fix for lastrowid is as simple as just always setting it. But I'm not that familiar with sqlite internals, so perhaps someone with more knowledge will weigh in. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:03:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 18:03:23 +0000 Subject: [issue8136] urllib.unquote decodes percent-escapes with Latin-1 In-Reply-To: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za> Message-ID: <1357322603.47.0.0638399707543.issue8136@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:07:45 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Jan 2013 18:07:45 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357322865.27.0.614112346889.issue5066@psf.upfronthosting.co.za> Zachary Ware added the comment: Hi Todd, I can't commit, but I have a review in the works for you. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:09:27 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Jan 2013 18:09:27 +0000 Subject: [issue16803] Make test_importlib run tests under both _frozen_importlib and importlib._bootstrap In-Reply-To: <1356718069.62.0.143946538677.issue16803@psf.upfronthosting.co.za> Message-ID: <1357322967.45.0.0481190460799.issue16803@psf.upfronthosting.co.za> Brett Cannon added the comment: With some tricky use of import_fresh_module() because importlib.__init__ does some masking trickery, it should ... I think. =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:12:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 18:12:47 +0000 Subject: [issue1694663] Overloading int.__pow__ does not work Message-ID: <1357323167.51.0.511924973952.issue1694663@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This behavior doesn't reproduced more on 2.7 and 3.2+. >>> class MyInt(int): ... __pow__ = int.__add__ ... >>> i = MyInt(42) >>> i**3 45 ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:13:14 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 18:13:14 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357323194.5.0.729958286429.issue16835@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached a new patch. ---------- Added file: http://bugs.python.org/file28562/issue16835-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:18:13 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Jan 2013 18:18:13 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357323493.98.0.5093932175.issue16835@psf.upfronthosting.co.za> Zachary Ware added the comment: Looks good to me :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:26:14 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 18:26:14 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357323974.72.0.90329822392.issue13094@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached a new patch. ---------- Added file: http://bugs.python.org/file28563/issue13094-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:29:16 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 04 Jan 2013 18:29:16 +0000 Subject: [issue16799] start using argparse.Namespace in regrtest In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za> Message-ID: <1357324156.38.0.483706468635.issue16799@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks. Andrew, could you also take a quick look at this? ---------- title: switch regrtest from getopt options to argparse Namespace -> start using argparse.Namespace in regrtest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:42:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 18:42:11 +0000 Subject: [issue1617161] Instance methods compare equal when their self's are equal Message-ID: <1357324931.76.0.623330064162.issue1617161@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:44:06 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 04 Jan 2013 18:44:06 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357325046.75.0.137198237604.issue16853@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Is this currently being written from scratch? It shouldn't be IMO. Instead I recommend using the existent Tornado or pyftpdlib IO loop as an example: https://github.com/facebook/tornado/tree/master/tornado/platform https://github.com/facebook/tornado/blob/master/tornado/ioloop.py#L544 http://code.google.com/p/pyftpdlib/source/browse/trunk/pyftpdlib/ioloop.py?spec=svn1144&r=1135#266 ...and modify the central polling method so that it returns a list of (fd, events) instead of calling handler methods. Everything (except Windows support) is already in place and they have been tested extensively. Exploring this into Tulip would be important IMO, as it would help figuring out whether the API is good enough to support what this component aims to achieve: being a generic poller upon which to build async IO loops. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:49:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 18:49:00 +0000 Subject: [issue1611154] os.path.exists("file/") failure on Solaris 9 Message-ID: <1357325340.46.0.435811554961.issue1611154@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch need be revised for 3.3+. ---------- nosy: +jcea, serhiy.storchaka versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 19:52:13 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 04 Jan 2013 18:52:13 +0000 Subject: [issue16863] Python 2 error in Argparse tutorial In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za> Message-ID: <1357325533.84.0.895177575741.issue16863@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- title: Argparse tutorial outdated -> Python 2 error in Argparse tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:00:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 19:00:31 +0000 Subject: [issue6157] Tkinter.Text: changes for bbox, debug, and edit methods. In-Reply-To: <1243800373.79.0.587066766962.issue6157@psf.upfronthosting.co.za> Message-ID: <1357326031.63.0.816870146675.issue6157@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +serhiy.storchaka stage: patch review -> commit review versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:08:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 19:08:36 +0000 Subject: [issue4350] Remove dead code from Tkinter.py In-Reply-To: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za> Message-ID: <1357326516.68.0.587251389255.issue4350@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. However I?am not sure should this issue be classified as "behavior" or "enhancement". Removed code is not usable in Tk versions which supported in Python 2.7 and 3.2+ and can be removed safely. ---------- nosy: +georg.brandl, serhiy.storchaka versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:11:39 2013 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Jan 2013 19:11:39 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357326699.46.0.752560562246.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: Giampaolo, there are many details in the Tornado and pyftpdlib I/O loops that may or may not be intentional. I wrote the Tulip pollster from scratch but am looking to merge in relevant knowledge and features from Tornado, Twisted and pyftpdlib. AFAIK the code here is mostly adapted from Tulip. Please suggest specific features from Tornado or pyftpdlib that are currently missing. However I don't think we should just copy over the existing 3rd party code (if only because we're trying to write pure Python 3.3 code here, without historical baggage). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:19:05 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Jan 2013 19:19:05 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357327145.1.0.989453205002.issue13094@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:36:31 2013 From: report at bugs.python.org (Todd Rovito) Date: Fri, 04 Jan 2013 19:36:31 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1357322865.27.0.614112346889.issue5066@psf.upfronthosting.co.za> Message-ID: Todd Rovito added the comment: Thanks much appreciated! Sent from my iPhone On Jan 4, 2013, at 1:07 PM, Zachary Ware wrote: > > Zachary Ware added the comment: > > Hi Todd, I can't commit, but I have a review in the works for you. > > ---------- > nosy: +zach.ware > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:38:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Jan 2013 19:38:17 +0000 Subject: [issue16852] Fix test discovery for test_genericpath.py In-Reply-To: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za> Message-ID: <1357328297.15.0.289055803902.issue16852@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks as v1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:45:11 2013 From: report at bugs.python.org (Ed Campbell) Date: Fri, 04 Jan 2013 19:45:11 +0000 Subject: [issue16848] Mac OS X: python-config --ldflags and location of Python.framework In-Reply-To: <1357212774.75.0.369526303193.issue16848@psf.upfronthosting.co.za> Message-ID: <1357328711.14.0.367228092127.issue16848@psf.upfronthosting.co.za> Changes by Ed Campbell : ---------- nosy: +esc24 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:53:07 2013 From: report at bugs.python.org (Ross Lagerwall) Date: Fri, 04 Jan 2013 19:53:07 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357329187.81.0.925627037297.issue16853@psf.upfronthosting.co.za> Ross Lagerwall added the comment: Interesting benchmark. There is no gain for epoll with a large number of ready fds (as expected) but at least it is no worse than poll. Poll offers a large improvement on select, in this case. $ ./python selector_bench.py -r 2 -m 1000 -t pipe Trying with 2 ready FDs out of 1000, type pipe 0.004317363000154728 0.08897221900042496 0.1558117479999055 $ ./python selector_bench.py -r 100 -m 1000 -t pipe Trying with 100 ready FDs out of 1000, type pipe 0.11067074099992169 0.18777027299984184 0.30157805000089866 $ ./python selector_bench.py -r 1000 -m 1000 -t pipe Trying with 1000 ready FDs out of 1000, type pipe 1.08963231099915 1.111169247998987 8.283167362000313 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 20:57:42 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 19:57:42 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357325046.75.0.137198237604.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Indeed, tornado and pyftpdlib implementations are much more complex, have somewhat different APIs (i.e. only support FDs), have special cases for older python versions, lack some newer features (e.g. context manager). The current code is much close to Tulip's. > Exploring this into Tulip would be important IMO, as it would help figuring out whether the API is good enough to support what this component aims to achieve: being a generic poller upon which to build async IO loops. That's indeed a good idea, there's no need to rush this in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 21:20:31 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Jan 2013 20:20:31 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357330831.92.0.079725678432.issue16835@psf.upfronthosting.co.za> Brett Cannon added the comment: LGTM as well. Feel free to commit it, Ezio, or assign to me and I will commit it later (probably this weekend). ---------- assignee: -> eric.araujo nosy: +eric.araujo stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 21:27:00 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 20:27:00 +0000 Subject: [issue16835] Update PEP 399 to allow for test discovery In-Reply-To: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za> Message-ID: <1357331220.55.0.5330048355.issue16835@psf.upfronthosting.co.za> Ezio Melotti added the comment: Done in http://hg.python.org/peps/rev/3740f42d3b94, thanks for the reviews! ---------- assignee: eric.araujo -> ezio.melotti resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 21:34:18 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 20:34:18 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357331658.3.0.942128998922.issue16853@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Ross, the select() result for a large number of ready FDs was completely skewed because of a bug spotted by Antoine (complexity was much worse than it ought to be). Here are the results with the fix: """ $ ./python ~/selector_bench.py -r 10 -m 1000 -t socket Trying with 10 ready FDs out of 1000, type socket 0.05156186099338811 0.23772043800272513 0.5181516080047004 $ ./python ~/selector_bench.py -r 100 -m 1000 -t socket Trying with 100 ready FDs out of 1000, type socket 0.47576940699946135 0.6458770600002026 0.828609222000523 $ ./python ~/selector_bench.py -r 1000 -m 1000 -t socket Trying with 1000 ready FDs out of 1000, type socket 4.970445963997918 5.7709292660001665 4.030775418999838 """ With a large number of FDs, many of which are ready, select can be faster. Here's the output of "strace -c -e select,poll,epoll_wait": """ % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 83.86 0.000421 0 1024 epoll_wait 16.14 0.000081 0 1024 poll 0.00 0.000000 0 1024 select ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000502 3072 total """ The systime is greater in epoll, but the systime is negligible, as show by 'time': """ real 0m14.856s user 0m14.289s sys 0m0.340s """ The time is really spent in the interpreter. I'll dig some more (even though I doubt having 1000/1000 ready FDs is a common use case). Note that it doesn't change anything when a small number of FDs are ready: """ $ ./python ~/selector_bench.py -r 10 -m 1000 -t socket Trying with 10 ready FDs out of 1000, type socket 0.05238822099636309 0.25595822899776977 0.5156362060006359 """ ---------- Added file: http://bugs.python.org/file28564/selector-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 21:34:29 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 04 Jan 2013 20:34:29 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357331669.45.0.178841692141.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28556/selector-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:08:51 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Jan 2013 21:08:51 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357333731.69.0.319120025656.issue8109@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an updated patch with cyclic GC support, and other small things. ---------- components: +Library (Lib) -Extension Modules Added file: http://bugs.python.org/file28565/sni.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:21:24 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Jan 2013 21:21:24 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357334484.28.0.647174921114.issue8109@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file28565/sni.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:21:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Jan 2013 21:21:32 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357334492.51.0.172824318807.issue8109@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file28566/sni.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:28:18 2013 From: report at bugs.python.org (Jeffrey Bush) Date: Fri, 04 Jan 2013 21:28:18 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception Message-ID: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> New submission from Jeffrey Bush: The environment is Windows 8 Pro 64-bit running Python 64-bit in the WinPython distribution. Python is v2.7.3 built on Apr 10 2012. I first found this with create_string_buffer however I found out that it happens with an even simpler example. The following code throws an AttributeException: class must define a _length_ attribute, which must be a positive integer. import ctypes c_char * int(2*1024*1024*1024) # 2GB, also fails with long() instead of int() However the following works import ctypes c_char * int(2*1024*1024*1024-1) # 1 byte less than 2GB This is the same with the other c_ types (not limited to size of memory since c_int * int(2*1024*1024*1024-1) works and would be nearly 4 times the size of the failed c_char one). ---------- components: ctypes messages: 179080 nosy: coderforlife priority: normal severity: normal status: open title: ctypes arrays >=2GB in length causes exception type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:30:43 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Jan 2013 21:30:43 +0000 Subject: [issue16852] Fix test discovery for test_genericpath.py In-Reply-To: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za> Message-ID: <1357335043.55.0.876209003877.issue16852@psf.upfronthosting.co.za> Zachary Ware added the comment: My apologies, I seem to have managed to rename the wrong file... Here's the real v2 as v3, with the TestGenericTest comment pointing to this issue instead of 16748. ---------- Added file: http://bugs.python.org/file28567/issue16852.v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:33:24 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Jan 2013 21:33:24 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1357335204.29.0.92225140848.issue14187@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:35:01 2013 From: report at bugs.python.org (Ross Lagerwall) Date: Fri, 04 Jan 2013 21:35:01 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357335301.02.0.111003859396.issue16853@psf.upfronthosting.co.za> Ross Lagerwall added the comment: > Ross, the select() result for a large number of ready FDs was > completely skewed because of a bug spotted by Antoine (complexity > was much worse than it ought to be). Ah, that makes a little more sense now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:44:48 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 04 Jan 2013 21:44:48 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception In-Reply-To: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> Message-ID: <1357335887.92.0.163280576756.issue16865@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Would you like to investigate a patch? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:47:38 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 21:47:38 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception In-Reply-To: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> Message-ID: <1357336058.54.0.929040172709.issue16865@psf.upfronthosting.co.za> Ezio Melotti added the comment: Note that adding support for >2GB arrays is a new feature and therefore can't go in 2.7 (but it would be OK for 3.4+). The error message could be improved though. ---------- nosy: +amaury.forgeotdarc, belopolsky, ezio.melotti, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:51:29 2013 From: report at bugs.python.org (Jeffrey Bush) Date: Fri, 04 Jan 2013 21:51:29 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception In-Reply-To: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> Message-ID: <1357336289.34.0.377165889514.issue16865@psf.upfronthosting.co.za> Jeffrey Bush added the comment: I have no idea where I would start and don't have much time... I am not so sure it is a new features. It seems that the ctypes system is internally using unsigned integers for length but should be using size_t (or at least ssize_t). Seems like a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 22:52:12 2013 From: report at bugs.python.org (Jeffrey Bush) Date: Fri, 04 Jan 2013 21:52:12 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception In-Reply-To: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> Message-ID: <1357336332.38.0.504294288507.issue16865@psf.upfronthosting.co.za> Jeffrey Bush added the comment: I mean using signed integers currently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 23:02:49 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 22:02:49 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception In-Reply-To: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> Message-ID: <1357336969.6.0.354762736637.issue16865@psf.upfronthosting.co.za> Ezio Melotti added the comment: If it works elsewhere and/or it's documented to work, then it might indeed considered a bug. Maybe someone more familiar with ctype can comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 23:19:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Jan 2013 22:19:32 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> Message-ID: <1357337972.38.0.374507492158.issue16843@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for the deterministic version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 23:24:39 2013 From: report at bugs.python.org (Jeffrey Bush) Date: Fri, 04 Jan 2013 22:24:39 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception In-Reply-To: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> Message-ID: <1357338279.55.0.0365938977126.issue16865@psf.upfronthosting.co.za> Jeffrey Bush added the comment: Okay, so I tested in Linux (CentOS 6.3) which has Python 2.6.6 64-bit. It works. So the Windows 2.7.3 64-bit version is bugged. I was able to perform the c_char * long(32*1024*1024*1024) [the highest value I tried] and it worked fine. The Linux machine I tested this on was limited in RAM so ran into memory issues, but I was able to allocate a 2GB buffer with create_string_buffer(). So all in all, it is a bug. Works with Linux Python v2.6.6 64-bit but not Windows Python v2.7.3. The ctypes documentation does not mention an upper limit so I would assume that it should be based on the maximum memory allocation of the underlying system (e.g. Windows 32-bit can't allocate more than 2GB, but Windows 64-bit should be very very large). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 23:34:26 2013 From: report at bugs.python.org (Meador Inge) Date: Fri, 04 Jan 2013 22:34:26 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception In-Reply-To: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> Message-ID: <1357338866.41.0.957245308559.issue16865@psf.upfronthosting.co.za> Meador Inge added the comment: This case works fine on 64-bit Linux (Ubuntu) and OS X 10.7.5. I suspect this is due to the fact that 64-bit Windows uses the LLP64 data model and we are using longs somewhere. I am investigating further now. ---------- stage: -> needs patch versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 23:51:56 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Jan 2013 22:51:56 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <3YdLpg5xNyzSCM@mail.python.org> Roundup Robot added the comment: New changeset fdc894d44d82 by Ezio Melotti in branch '2.7': #13094: add Programming FAQ entry about the behavior of closures. http://hg.python.org/cpython/rev/fdc894d44d82 New changeset 02933454b7ce by Ezio Melotti in branch '3.2': #13094: add Programming FAQ entry about the behavior of closures. http://hg.python.org/cpython/rev/02933454b7ce New changeset 827ddaaa45e4 by Ezio Melotti in branch '3.3': #13094: merge with 3.2. http://hg.python.org/cpython/rev/827ddaaa45e4 New changeset 1bf7ae6c5324 by Ezio Melotti in branch 'default': #13094: merge with 3.3. http://hg.python.org/cpython/rev/1bf7ae6c5324 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 4 23:52:45 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Jan 2013 22:52:45 +0000 Subject: [issue13094] Need Programming FAQ entry for the behavior of closures In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> Message-ID: <1357339965.42.0.594612080146.issue13094@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the review! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 00:01:09 2013 From: report at bugs.python.org (vyrus) Date: Fri, 04 Jan 2013 23:01:09 +0000 Subject: [issue16283] ctypes.util.find_library does not find all DLLs anymore In-Reply-To: <1350636778.52.0.107234052838.issue16283@psf.upfronthosting.co.za> Message-ID: <1357340469.67.0.164658569967.issue16283@psf.upfronthosting.co.za> Changes by vyrus : ---------- nosy: +loewis, vyrus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 00:01:51 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Jan 2013 23:01:51 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357340511.29.0.97148822576.issue8109@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch after Daniel's comments. ---------- Added file: http://bugs.python.org/file28568/sni2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 00:40:25 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 04 Jan 2013 23:40:25 +0000 Subject: [issue9242] unicodeobject.c: use of uninitialized values In-Reply-To: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za> Message-ID: <1357342825.54.0.407244103583.issue9242@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 00:41:18 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 04 Jan 2013 23:41:18 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1357342878.55.0.563108662606.issue10156@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 00:41:35 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 04 Jan 2013 23:41:35 +0000 Subject: [issue16143] Building with configure option "--without-doc-strings" crashes first time through PyUnicode_DecodeUTF8Stateful In-Reply-To: <1349455516.0.0.465126799391.issue16143@psf.upfronthosting.co.za> Message-ID: <1357342895.18.0.380736907642.issue16143@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 00:54:11 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 04 Jan 2013 23:54:11 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357343651.02.0.965583528722.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It would be good if a) the patch was against hg default b) it had tests ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 01:13:47 2013 From: report at bugs.python.org (Peter) Date: Sat, 05 Jan 2013 00:13:47 +0000 Subject: [issue6715] xz compressor support In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za> Message-ID: <1357344827.36.0.9170360143.issue6715@psf.upfronthosting.co.za> Peter added the comment: Apologies again for the noise, but I've just made the first public release of the lzma backport at http://pypi.python.org/pypi/backports.lzma/ with the repository as mentioned before at https://github.com/peterjc/backports.lzma I have tested this on Python 2.6, 2.7 and 3.0 through 3.3 under Linux and Mac OS. I've not tried building this on Windows yet, but it should be possible and I will be reviewing Amaury's notes on this thread. My thanks to Nadeem and Per for looking over this with helpful feedback, and agreeing to the use of the 3-clause BSD license for the backport. If anyone has any further questions about the backport, please get in touch via GitHub or email me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 02:24:07 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 01:24:07 +0000 Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline string expressions In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za> Message-ID: <1357349047.36.0.356870953452.issue16806@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If this is really an 'enhancement', it will only go in 3.4. If it is a bug/behavior issue, then it should be marked as such and 2.7,3.2,3.3 selected. I have not read the doc and messages well enough to know, so I leave that to you and Benjamin. The patch includes a test. It needs a patch to Misc/ACKS to add Carsten Klein between Reid Kleckner and Bastian Kleineidam ---------- nosy: +terry.reedy stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 02:27:46 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 05 Jan 2013 01:27:46 +0000 Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline string expressions In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za> Message-ID: <1357349266.87.0.68581685481.issue16806@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I left comments on Rietveld a few days ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 02:33:08 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 05 Jan 2013 01:33:08 +0000 Subject: [issue812369] module shutdown procedure based on GC Message-ID: <1357349588.52.0.458780361296.issue812369@psf.upfronthosting.co.za> Nick Coghlan added the comment: In addition to the problem Neil noted with references in extension modules keeping module objects themselves alive, Antoine recently noted that the other major challenge is the reference cycles between module global dictionaries and their contents. As soon as a module global has both a __del__ method and a reference back to the module globals, the entire cycle becomes uncollectable. I suspect one of the reasons PyPy can cope without the explicit reference breaking step is that their GC is better able to cope with __del__ methods than ours. I wonder if a useful interim step might be to make the current explicit reference breaking hack a bit smarter by looking at the reference counts. (Note: some aspects of this idea could be made simpler if modules supported weak references) 1. Call importlib.invalidate_caches() 2. Delete the first module from sys.modules that has a reference count of exactly one 3. Repeat 2 until sys.modules is empty or every remaining module has a reference count greater than 1 (meaning another module has a reference to it one way or another) 4. Pick the module in sys.modules with the lowest number of references to it, delete it from sys.modules and delete the reference from the module object to its dictionary 5. Repeat 4 until sys.modules is empty Throughout the process, keep an eye on gc.garbage - if we see a module dict show up there, hit it with the "set all globals to None" hammer. (The new callback functionality in 3.3 makes that easier - for example, you could put a sentinel object in the globals of the module being cleared and watching for a dict containing that sentinel object showing up in 'uncollectable' during the stop phase) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 02:33:50 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 01:33:50 +0000 Subject: [issue16808] inspect.stack() should return list of named tuples In-Reply-To: <1356750149.18.0.966123919893.issue16808@psf.upfronthosting.co.za> Message-ID: <1357349630.55.0.809334962443.issue16808@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Should a test be added to or changed in test_inspect? Line 163 has a test_stack method that calls inspect.stack. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 03:18:44 2013 From: report at bugs.python.org (Meador Inge) Date: Sat, 05 Jan 2013 02:18:44 +0000 Subject: [issue16808] inspect.stack() should return list of named tuples In-Reply-To: <1356750149.18.0.966123919893.issue16808@psf.upfronthosting.co.za> Message-ID: <1357352324.21.0.691840457754.issue16808@psf.upfronthosting.co.za> Meador Inge added the comment: I suppose asserting the type wouldn't hurt, but I don't consider it that important: --- a/Lib/test/test_inspect.py +++ b/Lib/test/test_inspect.py @@ -164,12 +164,16 @@ class TestInterpreterStack(IsTestBase): self.assertTrue(len(mod.st) >= 5) self.assertEqual(revise(*mod.st[0][1:]), (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) + self.assertIsInstance(mod.st[0], inspect.FrameInfo) self.assertEqual(revise(*mod.st[1][1:]), (modfile, 9, 'spam', [' eggs(b + d, c + f)\n'], 0)) + self.assertIsInstance(mod.st[1], inspect.FrameInfo) self.assertEqual(revise(*mod.st[2][1:]), (modfile, 43, 'argue', [' spam(a, b, c)\n'], 0)) + self.assertIsInstance(mod.st[2], inspect.FrameInfo) self.assertEqual(revise(*mod.st[3][1:]), (modfile, 39, 'abuse', [' self.argue(a, b, c)\n'], 0)) + self.assertIsInstance(mod.st[3], inspect.FrameInfo) TestGetClosureVars builds the named tuples directly and compares them. For example: expected = inspect.ClosureVars(nonlocal_vars, global_vars, builtin_vars, unbound_names) self.assertEqual(inspect.getclosurevars(f(_arg)), expected) Doing this for FrameInfo is awkward because we don't have a frame object to construct the named tuple with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 03:40:20 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 02:40:20 +0000 Subject: [issue16823] Python crashes on running tkinter code with threads In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za> Message-ID: <1357353620.53.0.734078556438.issue16823@psf.upfronthosting.co.za> Terry J. Reedy added the comment: What you are doing appears to be unsupported (invalid). From http://www.astro.washington.edu/users/rowen/TkinterSummary.html "all Tkinter access must be from the main thread (or more precisely, from the thread that calls the mainloop). Violating this is likely to cause nasty and mysterious symptoms such as freezes and core dumps." There have been at multiple posts on python-list and stack overflow from other users that have run into this limitation. I cannot find it in our tkinter docs, but I think perhaps it should be (even though not-thread-safe is the default for any python structure). ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, gpolo, serwy, terry.reedy resolution: -> invalid status: open -> closed type: crash -> behavior versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 03:54:09 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 02:54:09 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357354449.72.0.679368418193.issue16829@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since there is no 'print filename' command on the menu, I am guessing that this is about 'File/Print Window' where the window is an edit window for a file with spaces in the name. In any case, on Win7 3.3 this worked fine for 'tem with space.py' except that .py is left off. However, the latter has nothing to do with spaces as 'tem.py' also appears as just 'tem' (centered at top of page). Is stripping the extension intended and done by idle or something Windows does? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 04:47:30 2013 From: report at bugs.python.org (Benno Leslie) Date: Sat, 05 Jan 2013 03:47:30 +0000 Subject: [issue16866] libainstall doesn't create all directories Message-ID: <1357357650.4.0.164255645189.issue16866@psf.upfronthosting.co.za> New submission from Benno Leslie: make libainstall fails when $(BINDIR) does not exist. ---------- components: Build files: ainstall.diff keywords: patch messages: 179103 nosy: bennoleslie priority: normal severity: normal status: open title: libainstall doesn't create all directories type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file28569/ainstall.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 04:47:45 2013 From: report at bugs.python.org (Benno Leslie) Date: Sat, 05 Jan 2013 03:47:45 +0000 Subject: [issue16866] libainstall doesn't create $(BINDIR) directory In-Reply-To: <1357357650.4.0.164255645189.issue16866@psf.upfronthosting.co.za> Message-ID: <1357357665.86.0.431885705142.issue16866@psf.upfronthosting.co.za> Changes by Benno Leslie : ---------- title: libainstall doesn't create all directories -> libainstall doesn't create $(BINDIR) directory _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 04:59:55 2013 From: report at bugs.python.org (Benno Leslie) Date: Sat, 05 Jan 2013 03:59:55 +0000 Subject: [issue16867] setup.py fails if there are no extensions Message-ID: <1357358395.58.0.464299518205.issue16867@psf.upfronthosting.co.za> New submission from Benno Leslie: When building if there are zero extensions setup.py fails (max of a zero length list is undefined.) Although not a very common case, there are potential speciality cases where there will be zero extensions. ---------- components: Build files: zero_length_extensions.diff keywords: patch messages: 179104 nosy: bennoleslie priority: normal severity: normal status: open title: setup.py fails if there are no extensions versions: Python 3.4 Added file: http://bugs.python.org/file28570/zero_length_extensions.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 05:06:23 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 04:06:23 +0000 Subject: [issue16855] traceback module leaves off module name in last line of formatted tracebacks In-Reply-To: <1357249745.89.0.552193091281.issue16855@psf.upfronthosting.co.za> Message-ID: <1357358783.08.0.864468686435.issue16855@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On Win7, 2.7.3 gives me the same output. (Running in IDLE, I don't get the 'socket.' prefix even on the second traceback.) With 3.3, I get socket.timeout both times (console or IDLE). So the problem seems to be 2.x only. print_exc calls print_exception, which calls print_tb and format_exception_only, which is responsible for the last line. The 2.7 code if (isinstance(etype, BaseException) or isinstance(etype, types.InstanceType) or etype is None or type(etype) is str): return [_format_final_exc_line(etype, value)] is simplified in 3.x to if etype is None: return [_format_final_exc_line(etype, value)] After stype = etype.__name__ 3.3 (and 3.x, I presume) adds smod = etype.__module__ if smod not in ("__main__", "builtins"): stype = smod + '.' + stype That is where the 'socket' prefix is added in 3.3, so perhaps that should be added to 2.7. Note: indenting code makes it harder to cut, paste, and run ;-( Using 'print (x)', which works fine in 2.7, instead of 'print x' would also greatly help testing in 3.x, which is needed for any bug report.) ---------- nosy: +georg.brandl, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 05:10:05 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Sat, 05 Jan 2013 04:10:05 +0000 Subject: [issue16808] inspect.stack() should return list of named tuples In-Reply-To: <1357349630.55.0.809334962443.issue16808@psf.upfronthosting.co.za> Message-ID: <20130105040955.GA3989@lp-shahaf.local> Daniel Shahaf added the comment: Terry J. Reedy wrote on Sat, Jan 05, 2013 at 01:33:50 +0000: > Should a test be added to or changed in test_inspect? Line 163 has > a test_stack method that calls inspect.stack. Makes sense; added a test that tests named attribute access. Thanks for the pointer. ---------- Added file: http://bugs.python.org/file28571/inspect-v4.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 4b42d7f288c5 Doc/library/inspect.rst --- a/Doc/library/inspect.rst Thu Jan 03 09:22:41 2013 +0100 +++ b/Doc/library/inspect.rst Sat Jan 05 04:06:25 2013 +0000 @@ -800,11 +800,17 @@ Classes and functions The interpreter stack --------------------- -When the following functions return "frame records," each record is a tuple of -six items: the frame object, the filename, the line number of the current line, +When the following functions return "frame records," each record is a +:term:`named tuple` +``FrameInfo(frame, filename, lineno, function, code_context, index)``. +The tuple contains the frame object, the filename, the line number of the +current line, the function name, a list of lines of context from the source code, and the index of the current line within that list. +.. versionchanged:: 3.3 + Return a named tuple instead of a tuple. + .. note:: Keeping references to frame objects, as found in the first element of the frame diff -r 4b42d7f288c5 Lib/inspect.py --- a/Lib/inspect.py Thu Jan 03 09:22:41 2013 +0100 +++ b/Lib/inspect.py Sat Jan 05 04:06:25 2013 +0000 @@ -1139,6 +1139,8 @@ def getlineno(frame): # FrameType.f_lineno is now a descriptor that grovels co_lnotab return frame.f_lineno +FrameInfo = namedtuple('FrameInfo', ('frame',) + Traceback._fields) + def getouterframes(frame, context=1): """Get a list of records for a frame and all higher (calling) frames. @@ -1146,7 +1148,8 @@ def getouterframes(frame, context=1): name, a list of lines of context, and index within the context.""" framelist = [] while frame: - framelist.append((frame,) + getframeinfo(frame, context)) + frameinfo = (frame,) + getframeinfo(frame, context) + framelist.append(FrameInfo(*frameinfo)) frame = frame.f_back return framelist @@ -1157,7 +1160,8 @@ def getinnerframes(tb, context=1): name, a list of lines of context, and index within the context.""" framelist = [] while tb: - framelist.append((tb.tb_frame,) + getframeinfo(tb, context)) + frameinfo = (tb.tb_frame,) + getframeinfo(tb, context) + framelist.append(FrameInfo(*frameinfo)) tb = tb.tb_next return framelist diff -r 4b42d7f288c5 Lib/test/test_inspect.py --- a/Lib/test/test_inspect.py Thu Jan 03 09:22:41 2013 +0100 +++ b/Lib/test/test_inspect.py Sat Jan 05 04:06:25 2013 +0000 @@ -170,6 +170,8 @@ class TestInterpreterStack(IsTestBase): (modfile, 43, 'argue', [' spam(a, b, c)\n'], 0)) self.assertEqual(revise(*mod.st[3][1:]), (modfile, 39, 'abuse', [' self.argue(a, b, c)\n'], 0)) + self.assertEqual(mod.st[0].frame, mod.fr) + self.assertEqual(mod.st[0].lineno, 16) def test_trace(self): self.assertEqual(len(git.tr), 3) From report at bugs.python.org Sat Jan 5 05:13:09 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Sat, 05 Jan 2013 04:13:09 +0000 Subject: [issue16808] inspect.stack() should return list of named tuples In-Reply-To: <1356750149.18.0.966123919893.issue16808@psf.upfronthosting.co.za> Message-ID: <1357359189.12.0.969441406941.issue16808@psf.upfronthosting.co.za> Changes by Daniel Shahaf : Removed file: http://bugs.python.org/file28571/inspect-v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 05:13:49 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Sat, 05 Jan 2013 04:13:49 +0000 Subject: [issue16808] inspect.stack() should return list of named tuples In-Reply-To: <1356750149.18.0.966123919893.issue16808@psf.upfronthosting.co.za> Message-ID: <1357359229.73.0.654694903595.issue16808@psf.upfronthosting.co.za> Changes by Daniel Shahaf : Added file: http://bugs.python.org/file28572/inspect-v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 05:14:26 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 04:14:26 +0000 Subject: [issue16862] FAQ has outdated information about Stackless In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za> Message-ID: <1357359266.59.0.976914318226.issue16862@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think answer 2 should just say "An alternative is Stackless Python." and let interested people click the link. The entire second sentence should go, and I am not sure how much of the rest of the first is still correct, as Stackless has changed from when it was written. ---------- keywords: +patch nosy: +terry.reedy stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 05:17:21 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 04:17:21 +0000 Subject: [issue16863] Python 2 error in Argparse tutorial In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za> Message-ID: <1357359441.38.0.155245636254.issue16863@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A quick patch would be 'This tutorial was written for argparse in Python 3. A few details are different in 2.x.' But feel free to do better. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 05:21:06 2013 From: report at bugs.python.org (Todd Rovito) Date: Sat, 05 Jan 2013 04:21:06 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner Message-ID: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> New submission from Todd Rovito: The Python Developer Guide in section 3.3 about the life cycle of a patch/review process makes no mention that a bug should be "pinged" first before posting to the python-dev at python.org email list requesting a review. For more information see this thread on the Python-Dev email list: http://mail.python.org/pipermail/python-dev/2013-January/123453.html ---------- assignee: docs at python components: Documentation messages: 179109 nosy: Todd.Rovito, docs at python priority: normal severity: normal status: open title: Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 05:21:55 2013 From: report at bugs.python.org (Todd Rovito) Date: Sat, 05 Jan 2013 04:21:55 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357359715.45.0.984364301535.issue16868@psf.upfronthosting.co.za> Changes by Todd Rovito : ---------- components: +Devguide -Documentation nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 05:46:30 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 04:46:30 +0000 Subject: [issue16823] Python crashes on running tkinter code with threads In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za> Message-ID: <1357361190.57.0.736913362022.issue16823@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: invalid -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 06:29:44 2013 From: report at bugs.python.org (Todd Rovito) Date: Sat, 05 Jan 2013 05:29:44 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357363784.35.0.87729711199.issue16868@psf.upfronthosting.co.za> Todd Rovito added the comment: Here is a suggested patch with help from R. David Murray: "To begin with, please be patient! There are many more people submitting patches than there are people capable of reviewing your patch. Getting your patch reviewed requires a reviewer to have the spare time and motivation to look at your patch (we cannot force anyone to review patches). If your patch has not received any notice from reviewers (i.e., no comment made) after a substantial amount of time first ?ping? the issue on the issue tracker to remind the nosy list that the patch needs a review. It is possible that the nosy committers have just forgotten about the issue. After the issue has been ?pinged? and if you don?t get a response after a few days then you may email python-dev at python.org asking for someone to review your patch." ---------- keywords: +patch Added file: http://bugs.python.org/file28573/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-dev.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 06:56:47 2013 From: report at bugs.python.org (Benno Leslie) Date: Sat, 05 Jan 2013 05:56:47 +0000 Subject: [issue16869] makesetup should support .S source files Message-ID: <1357365407.25.0.925950325615.issue16869@psf.upfronthosting.co.za> New submission from Benno Leslie: It is useful to be able to build .S files as built-in modules (in particular if you want ctypes as a built-in you need .S files) The patch enables .S files to be specified in Setup.dist files. ---------- components: Build files: makesetup-asm.diff keywords: patch messages: 179111 nosy: bennoleslie priority: normal severity: normal status: open title: makesetup should support .S source files versions: Python 3.4 Added file: http://bugs.python.org/file28574/makesetup-asm.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 07:05:21 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 05 Jan 2013 06:05:21 +0000 Subject: [issue16867] setup.py fails if there are no extensions In-Reply-To: <1357358395.58.0.464299518205.issue16867@psf.upfronthosting.co.za> Message-ID: <1357365921.58.0.230838909423.issue16867@psf.upfronthosting.co.za> Ned Deily added the comment: This has already been reported in Issue16537. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Python?s setup.py raises a ValueError when self.extensions is empty _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 07:54:20 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Jan 2013 06:54:20 +0000 Subject: [issue16862] FAQ has outdated information about Stackless In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za> Message-ID: <3YdYWH1DBvzS7X@mail.python.org> Roundup Robot added the comment: New changeset d2867c430333 by Ezio Melotti in branch '3.2': #16862: remove outdated statements about Stackless. http://hg.python.org/cpython/rev/d2867c430333 New changeset b66049748535 by Ezio Melotti in branch '3.3': #16862: merge with 3.2. http://hg.python.org/cpython/rev/b66049748535 New changeset 547dc3aa3e9a by Ezio Melotti in branch 'default': #16862: merge with 3.3. http://hg.python.org/cpython/rev/547dc3aa3e9a New changeset 0f24c65fb7e5 by Ezio Melotti in branch '2.7': #16862: remove outdated statements about Stackless. http://hg.python.org/cpython/rev/0f24c65fb7e5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 07:56:04 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 05 Jan 2013 06:56:04 +0000 Subject: [issue16862] FAQ has outdated information about Stackless In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za> Message-ID: <1357368964.96.0.0519544891532.issue16862@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 09:16:07 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 05 Jan 2013 08:16:07 +0000 Subject: [issue16863] Python 2 error in Argparse tutorial In-Reply-To: <1357359441.38.0.155245636254.issue16863@psf.upfronthosting.co.za> Message-ID: Tshepang Lekhonkhobe added the comment: > A quick patch would be 'This tutorial was written for argparse in Python 3. A few details are different in 2.x.' But feel free to do better. That really sounds great, especially since it avoids resorting to things as ugly as "...and this is Python 2 output". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 10:21:55 2013 From: report at bugs.python.org (Poul-Henning Kamp) Date: Sat, 05 Jan 2013 09:21:55 +0000 Subject: [issue16870] re fails to match ^ when start index is specified ? Message-ID: <1357377715.09.0.558139465053.issue16870@psf.upfronthosting.co.za> New submission from Poul-Henning Kamp: I'm surprised that this does not find any matches: import re r = re.compile("^abc") s = "0123abcxyz" for i in range(0,len(s)): print(i, r.search(s, i)) I would have expected the i==4 case to match ? (This is on: Python 2.7.3 (default, Dec 14 2012, 02:46:02) [GCC 4.2.1 Compatible FreeBSD Clang 3.2 (branches/release_32 168974)] on freebsd10 ) ---------- components: Regular Expressions messages: 179116 nosy: bsdphk, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re fails to match ^ when start index is specified ? versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 11:01:41 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 05 Jan 2013 10:01:41 +0000 Subject: [issue16870] re fails to match ^ when start index is specified ? In-Reply-To: <1357377715.09.0.558139465053.issue16870@psf.upfronthosting.co.za> Message-ID: <1357380101.28.0.247497164871.issue16870@psf.upfronthosting.co.za> Ned Deily added the comment: Note the warning about '^' in the documentation for the re search method: "The optional second parameter pos gives an index in the string where the search is to start; it defaults to 0. This is not completely equivalent to slicing the string; the '^' pattern character matches at the real beginning of the string and at positions just after a newline, but not necessarily at the index where the search is to start." http://docs.python.org/2/library/re.html#re.RegexObject.search ---------- nosy: +ned.deily resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 11:22:02 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 05 Jan 2013 10:22:02 +0000 Subject: [issue16870] re fails to match ^ when start index is specified ? In-Reply-To: <1357377715.09.0.558139465053.issue16870@psf.upfronthosting.co.za> Message-ID: <1357381322.45.0.518067086588.issue16870@psf.upfronthosting.co.za> Ned Deily added the comment: To expand a bit, rather than multiple calls to search, you can use the start and end methods of the match object to determine where the string (without the '^' anchor) matches. For example: r = re.compile("abc") s = "0123abcxyz" match = r.search(s) if match: print(match.start(), match.end()) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 13:35:24 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 05 Jan 2013 12:35:24 +0000 Subject: [issue1694663] Overloading int.__pow__ does not work Message-ID: <1357389324.72.0.219434145472.issue1694663@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yep, this was fixed as part of the issue 14658 fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 13:40:12 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 05 Jan 2013 12:40:12 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357389612.59.0.680461308507.issue16853@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's a new version, with the following changes: - there's no SELECT_ERR anymore: error conditions (POLLNVAL|POLLERR and also POLLHUP) are reported as SELECT_IN|SELECT_OUT, depending on the input event mask: I don't think that a separate error flag is needed, because the error will be reported when the FD will be read/written (and in the context where the error can be handled appropriately, which wouldn't be the case if an exception was thrown by the Selector). That's what Java and libevent do, for example. libevent reports IN|OUT inconditionally in case of POLLER|POLLHUP, but I think that the output events should be a subset ot input events. - the exceptions set isn't passed to select() anymore: exception events (like OOB) are already reported in the read or write sets (checked with libevent and in the Linux kernel source) - most importantly, there was something missing/annoying in the API: now, it only accepts only file descriptors, and also an optional opaque object: the object - called "attached data" - can be used for example to pass a callback (that can be invoked by a higher-level reactor), or for example context-specific data: it could be a kind of a thread state to make it easy to do a context-switch, or simply a high-level object like a file, a socket or a telnet instance. This is actually what Java does, but they take it further into encapsulating the FD, interested events, attached data and ready events into a SelectionKey, which is passed and returned to/from the Selector: http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SelectionKey.html - I've added some tests ---------- Added file: http://bugs.python.org/file28575/selector-data.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 13:46:39 2013 From: report at bugs.python.org (Trent Nelson) Date: Sat, 05 Jan 2013 12:46:39 +0000 Subject: [issue16762] test_subprocess failure on OpenBSD/NetBSD buildbots In-Reply-To: <1356344635.01.0.0408386674119.issue16762@psf.upfronthosting.co.za> Message-ID: <1357389999.98.0.961843579535.issue16762@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 13:58:45 2013 From: report at bugs.python.org (Poul-Henning Kamp) Date: Sat, 05 Jan 2013 12:58:45 +0000 Subject: [issue16870] re fails to match ^ when start index is specified ? In-Reply-To: <1357377715.09.0.558139465053.issue16870@psf.upfronthosting.co.za> Message-ID: <1357390725.0.0.359925639478.issue16870@psf.upfronthosting.co.za> Poul-Henning Kamp added the comment: I have tried hard, but have utterly failed to figure out why you have chosen the semantics for ^ you mention, tried to come up with a plausible use case, and I have utterly failed. I find it distinctly counter intuitive. I think the Principle of Least Astonishment compliant definition of ^ and $ would be that they match the start and end of the string offered for matching, ie: taking start+end into account. The real use-case behind this is searching through a mmap'ed database file, for a particular regexp in a particular field of the records, with the minimum amount of copying. The semantics you mention, makes ^ and $ useless in this, and as far as I can tell, any other scenario involving start+end arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 15:16:40 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 05 Jan 2013 14:16:40 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357395400.71.0.343635632824.issue16853@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: @Guido: agreed. > there's no SELECT_ERR anymore [...] the error will be reported when the FD will be read/written I don't think this is a good idea, particularly during this early stage. This assumption might be valid for select() but not for poll() and epoll() where (POLLERR | POLLHUP | POLLNVAL) is an alias for "connection lost", and that's an event which both Twisted and Tornado take into account and treat differently than a pure "read" event. The same assumption should also apply for kqueue(). > the exceptions set isn't passed to select() anymore: exception events (like OOB) are already reported in the read or write sets That's true only if SO_OOBINLINE has been pre-emptively set against the socket. It might be ok to ignore select()'s exceptional events anyway though. This is probably another thing you might want to decide later. > there was something missing/annoying in the API [...] now, it only accepts only file descriptors, and also an optional opaque 'data' object I like this change as it avoids maintaining a separate fd->handler map. Will add line-by-line comments by using the review tool. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 15:34:46 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 05 Jan 2013 14:34:46 +0000 Subject: [issue16849] Element.{get, iter} doesn't handle keyword arguments when using _elementtree C accelerator. In-Reply-To: <1357216602.29.0.17641407766.issue16849@psf.upfronthosting.co.za> Message-ID: <1357396486.49.0.228388699646.issue16849@psf.upfronthosting.co.za> Eli Bendersky added the comment: The patch was committed with some minor modifications to 3.3 (c1fc6b6d1cfc) and default branch (e1bee8b09828). New tests were added to the test classes (please don't add new tests to the doctests, they are deprecated). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 16:01:11 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 05 Jan 2013 15:01:11 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <1357398071.61.0.148090695908.issue15075@psf.upfronthosting.co.za> Eli Bendersky added the comment: I investigated a bit, and type checks were added to protect from such mixing. Please open a new patch with a speficic reproducer if you run into similar problems (interepreter crash). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 16:05:56 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 05 Jan 2013 15:05:56 +0000 Subject: [issue16849] Element.{get, iter} doesn't handle keyword arguments when using _elementtree C accelerator. In-Reply-To: <1357216602.29.0.17641407766.issue16849@psf.upfronthosting.co.za> Message-ID: <1357398356.37.0.0100589241543.issue16849@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 16:07:34 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 05 Jan 2013 15:07:34 +0000 Subject: [issue16817] test___all__ affects other tests by doing too much importing In-Reply-To: <1356828969.86.0.130125185831.issue16817@psf.upfronthosting.co.za> Message-ID: <1357398454.56.0.465259278425.issue16817@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- dependencies: +sys.path in tests contains system directories _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 16:09:35 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 05 Jan 2013 15:09:35 +0000 Subject: [issue1674555] sys.path in tests contains system directories Message-ID: <1357398575.72.0.45010555063.issue1674555@psf.upfronthosting.co.za> Eli Bendersky added the comment: Issue #16817 discusses a similar problem arising with test___all__. The patches have to be updated to provide a generic way to delegate certain tests to separate subprocesses. Arfrever, it's not necessary to update all the patches at once. Start with the one for 3.2 and after we figure out it's acceptable, it should be easy to convert to the other branches. ---------- versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 16:22:39 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 05 Jan 2013 15:22:39 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357399359.02.0.841329515114.issue16853@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Inline comments: http://bugs.python.org/review/16853/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 16:30:10 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 05 Jan 2013 15:30:10 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357395400.71.0.343635632824.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: >> there's no SELECT_ERR anymore [...] the error will be reported when the FD will be read/written > > I don't think this is a good idea, particularly during this early stage. > This assumption might be valid for select() but not for poll() and epoll() where (POLLERR | POLLHUP | POLLNVAL) is an alias for "connection lost", and that's an event which both Twisted and Tornado take into account and treat differently than a pure "read" event. POLLERR and POLLNVAL semantics can be really different from "connection lost", so this mapping sounds wrong. The actual error (which may be ECONNRESET, but also EBADF, ENOBUFS...) will be raised upon the next call to read()/write(), or can be retrieved through getsockopt(SO_ERROR). Also, that's exactly what the Linux kernel does for select(): http://lxr.free-electrons.com/source/fs/select.c#L381 POLLHUP is mapped to the read-set, POLLERR both to the read and write set. This means that "connection lost" could never be returned on platforms where the select() syscall is used, which could lead to subtle portability problems. But I'm definitely open on this (I've based the behavior on libevent and Java, FWIW). >> the exceptions set isn't passed to select() anymore: exception events (like OOB) are already reported in the read or write sets > > That's true only if SO_OOBINLINE has been pre-emptively set against the socket. > It might be ok to ignore select()'s exceptional events anyway though. Thanks, I didn't know: since the POSIX man pages was rather evasive on this, I checked the Linux kernel source code, but apparently it's non-standard. If we do ignore OOB in select(), then we probably also want to suppress POLLPRI|EPOLLPRI, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 17:08:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Jan 2013 16:08:57 +0000 Subject: [issue16871] Cleanup a few minor things Message-ID: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a set of patches which clean a few minor things: add spaces after if/while/return/etc, remove spaces after class/function name, remove redundant parens after if/while/return/etc. One set contains only space changes, another set contains parens changes. ---------- components: Library (Lib), Tests messages: 179128 nosy: ezio.melotti, serhiy.storchaka priority: normal severity: normal status: open title: Cleanup a few minor things versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 17:14:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Jan 2013 16:14:31 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> Message-ID: <1357402471.47.0.744149968226.issue16871@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file28576/minor_things_parens-2.7.diff Added file: http://bugs.python.org/file28577/minor_things_parens-3.2.diff Added file: http://bugs.python.org/file28578/minor_things_parens-3.3.diff Added file: http://bugs.python.org/file28579/minor_things_parens-3.4.diff Added file: http://bugs.python.org/file28580/minor_things_spaces-3.2.diff Added file: http://bugs.python.org/file28581/minor_things_spaces-2.7.diff Added file: http://bugs.python.org/file28582/minor_things_spaces-3.3.diff Added file: http://bugs.python.org/file28583/minor_things_spaces-3.4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 17:28:53 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 05 Jan 2013 16:28:53 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357403333.36.0.103239288802.issue16853@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > The actual error (which may be ECONNRESET, but also EBADF, ENOBUFS...) will be raised > upon the next call to read()/write(), or can be retrieved through getsockopt(SO_ERROR). Mmmm... I would be tempted to think the same but the fact that both Tornado and Twisted distinguish between READ and ERROR events is suspicious. > then we probably also want to suppress POLLPRI|EPOLLPRI, no? Yes. ---------- _______________________________________ Python tracker _______________________________________ From senthil at uthcode.com Sat Jan 5 18:05:05 2013 From: senthil at uthcode.com (Senthil Kumaran) Date: Sat, 5 Jan 2013 09:05:05 -0800 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402471.47.0.744149968226.issue16871@psf.upfronthosting.co.za> References: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> <1357402471.47.0.744149968226.issue16871@psf.upfronthosting.co.za> Message-ID: Looks good in most of the places, but at some places the parenthesis are of course helpful for cohesiveness, and this can be quite subjective. With these patches, are you in general removing all instances of parenthesis when it is not required or also considering for places where parens may help while reading the code? +1 for the space changes patches. On Sat, Jan 5, 2013 at 8:14 AM, Serhiy Storchaka wrote: > > Changes by Serhiy Storchaka : > > > ---------- > keywords: +patch > Added file: http://bugs.python.org/file28576/minor_things_parens-2.7.diff > Added file: http://bugs.python.org/file28577/minor_things_parens-3.2.diff > Added file: http://bugs.python.org/file28578/minor_things_parens-3.3.diff > Added file: http://bugs.python.org/file28579/minor_things_parens-3.4.diff > Added file: http://bugs.python.org/file28580/minor_things_spaces-3.2.diff > Added file: http://bugs.python.org/file28581/minor_things_spaces-2.7.diff > Added file: http://bugs.python.org/file28582/minor_things_spaces-3.3.diff > Added file: http://bugs.python.org/file28583/minor_things_spaces-3.4.diff > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/senthil%40uthcode.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Sat Jan 5 18:05:08 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 05 Jan 2013 17:05:08 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402471.47.0.744149968226.issue16871@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: Looks good in most of the places, but at some places the parenthesis are of course helpful for cohesiveness, and this can be quite subjective. With these patches, are you in general removing all instances of parenthesis when it is not required or also considering for places where parens may help while reading the code? +1 for the space changes patches. On Sat, Jan 5, 2013 at 8:14 AM, Serhiy Storchaka wrote: > > Changes by Serhiy Storchaka : > > > ---------- > keywords: +patch > Added file: http://bugs.python.org/file28576/minor_things_parens-2.7.diff > Added file: http://bugs.python.org/file28577/minor_things_parens-3.2.diff > Added file: http://bugs.python.org/file28578/minor_things_parens-3.3.diff > Added file: http://bugs.python.org/file28579/minor_things_parens-3.4.diff > Added file: http://bugs.python.org/file28580/minor_things_spaces-3.2.diff > Added file: http://bugs.python.org/file28581/minor_things_spaces-2.7.diff > Added file: http://bugs.python.org/file28582/minor_things_spaces-3.3.diff > Added file: http://bugs.python.org/file28583/minor_things_spaces-3.4.diff > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/senthil%40uthcode.com > > ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 18:12:42 2013 From: report at bugs.python.org (Walter Mundt) Date: Sat, 05 Jan 2013 17:12:42 +0000 Subject: [issue16855] traceback module leaves off module name in last line of formatted tracebacks In-Reply-To: <1357249745.89.0.552193091281.issue16855@psf.upfronthosting.co.za> Message-ID: <1357405962.63.0.908662710066.issue16855@psf.upfronthosting.co.za> Walter Mundt added the comment: Thanks for looking into the version applicability. I'd bet that under the covers IDLE is relying on the traceback module too. Anyone have a Windows CPython 2.7.3 and care to check the output of the test code in a cmd window? I originally ran it unindented out of a file if that helps. I will remember your comments on code indenting and use of cross-version print idioms in test code for future reference. Others wanting to paste it into a file or interpreter can add an "if True:" prefix as a workaround for this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 19:02:24 2013 From: report at bugs.python.org (Matthew Barnett) Date: Sat, 05 Jan 2013 18:02:24 +0000 Subject: [issue16870] re fails to match ^ when start index is specified ? In-Reply-To: <1357377715.09.0.558139465053.issue16870@psf.upfronthosting.co.za> Message-ID: <1357408944.66.0.896866350044.issue16870@psf.upfronthosting.co.za> Matthew Barnett added the comment: The semantics of '^' are common to many different regex implementations, including those of Perl and C#. The 'pos' argument merely gives the starting position the search (C# also lets you provide a starting position, and behaves in exactly the same way). Perhaps you should be using 'match' instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 19:12:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Jan 2013 18:12:42 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> Message-ID: <1357409562.3.0.365416671488.issue16871@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For me none of these parens help while reading the code (but this is quite subjective). I not object if only a part of these changes will be applied. Review the patches and point what changes should be applied and what changes should not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 19:24:30 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 05 Jan 2013 18:24:30 +0000 Subject: [issue16869] makesetup should support .S source files In-Reply-To: <1357365407.25.0.925950325615.issue16869@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: Should not this be? *.S) obj=`basename $src .S`.o; cc='$(CC)';; # The filetype extension .S instead .cpp. And, I have less know-how on these, but for my understanding how would non-preprocessed asm files (.s) will be handled? And doc reference to how this change is help as well (unless some other core dev knowing BUILD takes up). On Fri, Jan 4, 2013 at 9:56 PM, Benno Leslie wrote: > > New submission from Benno Leslie: > > It is useful to be able to build .S files as built-in modules (in > particular if you want ctypes as a built-in you need .S files) > > The patch enables .S files to be specified in Setup.dist files. > > ---------- > components: Build > files: makesetup-asm.diff > keywords: patch > messages: 179111 > nosy: bennoleslie > priority: normal > severity: normal > status: open > title: makesetup should support .S source files > versions: Python 3.4 > Added file: http://bugs.python.org/file28574/makesetup-asm.diff > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > New-bugs-announce mailing list > New-bugs-announce at python.org > http://mail.python.org/mailman/listinfo/new-bugs-announce > ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 20:20:23 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Jan 2013 19:20:23 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357413623.62.0.533965253733.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think that this needs extensive tests that verify the behavior of many end cases, including under duress (e.g. when there are too many connections for the kernel to handle). That would seem the only way to make sure that the code is reliable across platforms. It is likely that you could borrow some ideas for test scenarios from Twisted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 20:36:31 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 05 Jan 2013 19:36:31 +0000 Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za> Message-ID: <1357414591.08.0.960576786199.issue13103@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Same problem in 3.4. $ ./python Python 3.4.0a0 (default:e1bee8b09828, Jan 5 2013, 20:29:00) [GCC 4.3.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import asyncore >>> a = asyncore.dispatcher() >>> del a.socket >>> a.foo Traceback (most recent call last): File "", line 1, in File "./Lib/asyncore.py", line 410, in __getattr__ retattr = getattr(self.socket, attr) ... File "./Lib/asyncore.py", line 410, in __getattr__ retattr = getattr(self.socket, attr) RuntimeError: maximum recursion depth exceeded while calling a Python object >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 20:56:48 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 05 Jan 2013 19:56:48 +0000 Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za> Message-ID: <1357415808.72.0.937930136019.issue13103@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: asyncore's __getattr__ horror was scheduled for removal a long ago (3.1 as per issue8483). We can safely remove it for 3.4 and fix the RuntimeError exception above for all the earlier Python versions which are affected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 20:56:58 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 05 Jan 2013 19:56:58 +0000 Subject: [issue13103] copy of an asyncore dispatcher causes infinite recursion In-Reply-To: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za> Message-ID: <1357415818.07.0.0598200055399.issue13103@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- assignee: -> giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 20:58:43 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 05 Jan 2013 19:58:43 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> Message-ID: <1357415923.77.0.719792668517.issue16871@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: How about innecessary code churn? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 21:05:10 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 05 Jan 2013 20:05:10 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> Message-ID: <1357416310.91.0.481618189045.issue16871@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I elaborate: issue15580. An example of many. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 21:09:45 2013 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Sat, 05 Jan 2013 20:09:45 +0000 Subject: [issue16872] Metaclass conflict proposition Message-ID: <1357416585.82.0.262219789669.issue16872@psf.upfronthosting.co.za> New submission from Jo?o Bernardo: This is actually a proposition for a behavior change caused by a bugfix. I have a project dealing with a metaclass factory and the next thing in the TODO list was to add multiple inheritance support. For my surprise, I tried and there was no metaclass conflict on Python 2.7... I've been developing on Py3.2 and now on Py3.3 an it couldn't obviously choose one of the metaclass to use. I found this(http://hg.python.org/cpython/rev/c2a89b509be4) commit saying the metaclass calculation was fixed on some special cases (I think it is because of the __new__ method on the metaclass). Py3.1 and inferior are not affected. ---- The thing is: My metaclasses are smart enough to produce the right behavior so the "bug" doesn't bother me as long as this bugfix never gets backported. For Python 3.2+, the solution requires some more code/knowledge for the user: If I have this class diagram for "Obj", "A" and "B": Obj[type=M] M / \ -> / \ A[type=MA] B[type=MB] MA MB then, I want to create C: class C(A, B, metaclass=something): pass Where "something" cannot be neither "MA", "MB" or "M" because of metaclass conflict. but if something = lambda *args: M(*args) I can call finally call my "smart" metaclass to solve the problem. ---- Now the proposition: It is possible for the metaclass to have some special attribute (e.g. __call_me_maybe__ = True) so Python knows it can deal with these special cases and avoid the user to explicitly use the `metaclass` parameter? So class C(A, B): pass Would call "MA" because of the special attribute inherited from "M" and it would know how to deal with the B class. If it can't do it with some X class, just return NotImplemented or other thing so the `TypeError: metaclass conflict...` will finally be shown. ---------- components: Interpreter Core messages: 179140 nosy: JBernardo priority: normal severity: normal status: open title: Metaclass conflict proposition type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 21:22:49 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Jan 2013 20:22:49 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <3YdvS82YJwzQjG@mail.python.org> Roundup Robot added the comment: New changeset 927afb7bca2a by Antoine Pitrou in branch 'default': Issue #8109: The ssl module now has support for server-side SNI, thanks to a :meth:`SSLContext.set_servername_callback` method. http://hg.python.org/cpython/rev/927afb7bca2a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 21:23:27 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 05 Jan 2013 20:23:27 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357413623.62.0.533965253733.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I think that this needs extensive tests that verify the behavior of many end cases, including under duress (e.g. when there are too many connections for the kernel to handle). That would seem the only way to make sure that the code is reliable across platforms. It is likely that you could borrow some ideas for test scenarios from Twisted. Will do. I'm adding a new version taking into account some of Giampaolo's remarks. Also, the API now also allows passing a file descriptor or any object with a `fileno()` method, since it will likely be useful. To sum up, the API is: def register(self, fileobj, events, data=None): """Register a file object. Parameters: fileobj -- file object events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) data -- attached data """ def unregister(self, fileobj): """Unregister a file object. Parameters: fileobj -- file object """ def modify(self, fileobj, events, data=None): """Change a registered file object monitored events or attached data. Parameters: fileobj -- file object events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) data -- attached data """ def select(self, timeout=None): """Perform the actual selection, until some monitored file objects are ready or a timeout expires. Parameters: timeout -- if timeout > 0, this specifies the maximum wait time, in seconds if timeout == 0, the select() call won't block, and will report the currently ready file objects if timeout is None, select() will block until a monitored file object becomes ready Returns: list of (fileobj, events, attached data) for ready file objects `events` is a bitwise mask of SELECT_IN|SELECT_OUT Selector.select() output looks a lot like poll()/epoll() except for two details: the output is the file object, and not the file descriptor (poll()/epoll() are unfortunately inconsistent in this regard), and there's a third field, the attached data (will be None if not provided in register()/modify()). I think that this optional field is really useful to pass e.g. a callback or some context information. ---------- Added file: http://bugs.python.org/file28584/selector-5.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff --git a/Lib/select.py b/Lib/select.py new file mode 100644 --- /dev/null +++ b/Lib/select.py @@ -0,0 +1,286 @@ +"""Select module. + +This module supports asynchronous I/O on multiple file descriptors. +""" + + +from _select import * + + +# generic events, that must be mapped to implementation-specific ones +# read event +SELECT_IN = (1 << 0) +# write event +SELECT_OUT = (1 << 1) + + +def _fileobj_to_fd(fileobj): + """Return a file descriptor from a file object. + + Parameters: + fileobj -- file descriptor, or any object with a `fileno()` method + + Returns: + corresponding file descriptor + """ + if isinstance(fileobj, int): + fd = fileobj + else: + try: + fd = int(fileobj.fileno()) + except (ValueError, TypeError): + raise ValueError("Invalid file object: {!r}".format(fileobj)) + return fd + + +class _Key: + """Object used internally to associate a file object to its backing file + descriptor and attached data.""" + + def __init__(self, fileobj, data=None): + self.fileobj = fileobj + self.data = data + self.fd = _fileobj_to_fd(fileobj) + + +class _BaseSelector: + """Base selector class. + + A selector supports registering file objects to be monitored for specific + I/O events. + + A file object is a file descriptor or any object with a `fileno()` method. + An arbitrary object can be attached to the file object, which can be used + for example to store context information, a callback, etc. + + A selector can use various implementations (select(), poll(), epoll()...) + depending on the platform. The default `Selector` class uses the most + performant implementation on the current platform. + """ + + def __init__(self): + # this maps file descriptors to keys + self._fd_to_key = {} + # this maps file objects to keys - for fast (un)registering + self._fileobj_to_key = {} + + def register(self, fileobj, events, data=None): + """Register a file object. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + if (not events) or (events & ~(SELECT_IN|SELECT_OUT)): + raise ValueError("Invalid events: {}".format(events)) + + if fileobj in self._fileobj_to_key: + raise ValueError("{!r} is already registered".format(fileobj)) + + key = _Key(fileobj, data) + self._fd_to_key[key.fd] = key + self._fileobj_to_key[fileobj] = key + return key + + def unregister(self, fileobj): + """Unregister a file object. + + Parameters: + fileobj -- file object + """ + try: + key = self._fileobj_to_key[fileobj] + del self._fd_to_key[key.fd] + del self._fileobj_to_key[fileobj] + except KeyError: + raise ValueError("{!r} is not registered".format(fileobj)) + return key + + def modify(self, fileobj, events, data=None): + """Change a registered file object monitored events or attached data. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + self.unregister(fileobj) + self.register(fileobj, events, data) + + def select(self, timeout=None): + """Perform the actual selection, until some monitored file objects are + ready or a timeout expires. + + Parameters: + timeout -- if timeout > 0, this specifies the maximum wait time, in + seconds + if timeout == 0, the select() call won't block, and will + report the currently ready file objects + if timeout is None, select() will block until a monitored + file object becomes ready + + Returns: + list of (fileobj, events, attached data) for ready file objects + `events` is a bitwise mask of SELECT_IN|SELECT_OUT + """ + raise NotImplementedError() + + def close(self): + """Close the selector. + + This must be called to make sure that any underlying resource is freed. + """ + self._fd_to_key.clear() + self._fileobj_to_key.clear() + + def __enter__(self): + return self + + def __exit__(self, *args): + self.close() + + def _key_from_fd(self, fd): + """Return the key associated to a given file descriptor. + + Parameters: + fd -- file descriptor + + Returns: + corresponding key + """ + try: + return self._fd_to_key[fd] + except KeyError: + raise RuntimeError("No key found for fd {}".format(fd)) + + +class SelectSelector(_BaseSelector): + """Select-based selector.""" + + def __init__(self): + super().__init__() + self._readers = set() + self._writers = set() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + if events & SELECT_IN: + self._readers.add(key.fd) + if events & SELECT_OUT: + self._writers.add(key.fd) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._readers.discard(key.fd) + self._writers.discard(key.fd) + + def select(self, timeout=None): + r, w, _ = select(self._readers, self._writers, [], timeout) + r = set(r) + w = set(w) + ready = [] + for fd in r | w: + events = 0 + if fd in r: + events |= SELECT_IN + if fd in w: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + +class PollSelector(_BaseSelector): + """Poll-based selector.""" + + def __init__(self): + super().__init__() + self._poll = poll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + poll_events = 0 + if events & SELECT_IN: + poll_events |= POLLIN + if events & SELECT_OUT: + poll_events |= POLLOUT + self._poll.register(key.fd, poll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._poll.unregister(key.fd) + + def select(self, timeout=None): + timeout = None if timeout is None else int(1000 * timeout) + ready = [] + for fd, event in self._poll.poll(timeout): + events = 0 + if event & (POLLERR|POLLNVAL): + # in case of error, signal read and write ready + events |= SELECT_IN|SELECT_OUT + else: + if event & (POLLIN|POLLHUP): + # in case of hangup, signal read ready + events |= SELECT_IN + if event & POLLOUT: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + +class EpollSelector(_BaseSelector): + """Epoll-based selector.""" + + def __init__(self): + super().__init__() + self._epoll = epoll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + epoll_events = 0 + if events & SELECT_IN: + epoll_events |= EPOLLIN + if events & SELECT_OUT: + epoll_events |= EPOLLOUT + self._epoll.register(key.fd, epoll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._epoll.unregister(key.fd) + + def select(self, timeout=None): + timeout = -1 if timeout is None else timeout + ready = [] + for fd, event in self._epoll.poll(timeout): + events = 0 + if event & EPOLLERR: + # in case of error, signal read and write ready + events |= SELECT_IN|SELECT_OUT + else: + if event & (EPOLLIN|EPOLLHUP): + # in case of hangup, signal read ready + events |= SELECT_IN + if event & EPOLLOUT: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + def close(self): + super().close() + self._epoll.close() + + +# Choose the best implementation: roughly, epoll|kqueue > poll > select. +# select() also can't accept a FD > FD_SETSIZE (usually around 1024) +if 'epoll' in globals(): + Selector = EpollSelector +elif 'poll' in globals(): + Selector = PollSelector +else: + Selector = SelectSelector diff --git a/Lib/test/test_select.py b/Lib/test/test_select.py --- a/Lib/test/test_select.py +++ b/Lib/test/test_select.py @@ -1,10 +1,20 @@ import errno import os +import random import select import sys import unittest from test import support + +def find_ready_matching(ready, flag): + match = [] + for fd, mode, data in ready: + if mode & flag: + match.append(fd) + return match + + @unittest.skipIf((sys.platform[:3]=='win'), "can't easily test on this system") class SelectTestCase(unittest.TestCase): @@ -75,9 +85,172 @@ a[:] = [F()] * 10 self.assertEqual(select.select([], a, []), ([], a[:5], [])) + +class BasicSelectorTestCase(unittest.TestCase): + + def test_constants(self): + select.SELECT_IN + select.SELECT_OUT + + +class BaseSelectorTestCase(unittest.TestCase): + + def test_error_conditions(self): + s = self.SELECTOR() + self.assertRaises(TypeError, s.register) + self.assertRaises(TypeError, s.register, 0) + self.assertRaises(ValueError, s.register, 0, 18) + self.assertRaises(TypeError, s.unregister, 0, 1) + self.assertRaises(TypeError, s.modify, 0) + self.assertRaises(TypeError, s.select, 0, 1) + + def test_basic(self): + with self.SELECTOR() as s: + rd, wr = os.pipe() + wro = os.fdopen(os.dup(wr), "wb") + self.addCleanup(os.close, rd) + self.addCleanup(os.close, wr) + self.addCleanup(wro.close) + + # test without attached data + s.register(wr, select.SELECT_OUT) + self.assertEqual(set(((wr, select.SELECT_OUT, None),)), set(s.select())) + + # test with attached data + s.unregister(wr) + s.register(wr, select.SELECT_OUT, sys.stdin) + self.assertEqual(set(((wr, select.SELECT_OUT, sys.stdin),)), set(s.select())) + + # test with file object + s.register(wro, select.SELECT_OUT) + self.assertEqual(set(((wro, select.SELECT_OUT, None), + (wr, select.SELECT_OUT, sys.stdin))), set(s.select())) + s.unregister(wro) + + # modify + s.modify(wr, select.SELECT_OUT, sys.stdout) + self.assertEqual(set(((wr, select.SELECT_OUT, sys.stdout),)), set(s.select())) + + # test timeout + s.unregister(wr) + s.register(rd, select.SELECT_IN) + self.assertFalse(s.select(0.1)) + s.register(wr, select.SELECT_OUT) + self.assertEqual(set(((wr, select.SELECT_OUT, None),)), + set(s.select(0.1))) + + s.unregister(rd) + s.unregister(wr) + # unregistering twice should raise an error + self.assertRaises(ValueError, s.unregister, wr) + + def test_selector(self): + s = self.SELECTOR() + self.addCleanup(s.close) + + NUM_PIPES = 12 + MSG = b" This is a test." + MSG_LEN = len(MSG) + readers = [] + writers = [] + r2w = {} + w2r = {} + + for i in range(NUM_PIPES): + rd, wr = os.pipe() + s.register(rd, select.SELECT_IN) + s.register(wr, select.SELECT_OUT) + readers.append(rd) + writers.append(wr) + r2w[rd] = wr + w2r[wr] = rd + + bufs = [] + + while writers: + ready = s.select() + ready_writers = find_ready_matching(ready, select.SELECT_OUT) + if not ready_writers: + self.fail("no pipes ready for writing") + wr = random.choice(ready_writers) + os.write(wr, MSG) + + ready = s.select() + ready_readers = find_ready_matching(ready, select.SELECT_IN) + if not ready_readers: + self.fail("no pipes ready for reading") + self.assertEqual([w2r[wr]], ready_readers) + rd = ready_readers[0] + buf = os.read(rd, MSG_LEN) + self.assertEqual(len(buf), MSG_LEN) + bufs.append(buf) + os.close(r2w[rd]) ; os.close(rd) + s.unregister(r2w[rd]) + s.unregister(rd) + writers.remove(r2w[rd]) + + self.assertEqual(bufs, [MSG] * NUM_PIPES) + + def test_timeout(self): + s = self.SELECTOR() + self.addCleanup(s.close) + + cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done' + p = os.popen(cmd, 'r') + s.register(p.fileno(), select.SELECT_IN, p) + + for tout in (0, 1, 2, 4, 8, 16) + (None,)*10: + if support.verbose: + print('timeout =', tout) + + ready = s.select(tout) + if not ready: + continue + if set(ready) == set(((p.fileno(), select.SELECT_IN, p),)): + line = p.readline() + if support.verbose: + print(repr(line)) + if not line: + if support.verbose: + print('EOF') + break + continue + self.fail('Unexpected return values from select(): %r' % ready) + p.close() + + + at unittest.skipIf((sys.platform[:3]=='win'), + "can't easily test on this system") +class SelectorTestCase(BaseSelectorTestCase): + + SELECTOR = select.Selector + + +class SelectSelectorTestCase(BaseSelectorTestCase): + + SELECTOR = select.SelectSelector + + + at unittest.skipUnless(hasattr(select, 'poll'), "Test needs select.poll()") +class PollSelectorTestCase(BaseSelectorTestCase): + + SELECTOR = select.PollSelector + + + at unittest.skipUnless(hasattr(select, 'epoll'), "Test needs select.epoll()") +class EpollSelectorTestCase(BaseSelectorTestCase): + + SELECTOR = select.EpollSelector + + def test_main(): - support.run_unittest(SelectTestCase) + tests = [SelectTestCase] + tests.extend([BasicSelectorTestCase, SelectorTestCase, + SelectSelectorTestCase, PollSelectorTestCase, + EpollSelectorTestCase]) + support.run_unittest(*tests) support.reap_children() + if __name__ == "__main__": test_main() diff --git a/Modules/selectmodule.c b/Modules/selectmodule.c --- a/Modules/selectmodule.c +++ b/Modules/selectmodule.c @@ -2129,7 +2129,7 @@ static struct PyModuleDef selectmodule = { PyModuleDef_HEAD_INIT, - "select", + "_select", module_doc, -1, select_methods, @@ -2143,7 +2143,7 @@ PyMODINIT_FUNC -PyInit_select(void) +PyInit__select(void) { PyObject *m; m = PyModule_Create(&selectmodule); diff --git a/setup.py b/setup.py --- a/setup.py +++ b/setup.py @@ -623,7 +623,7 @@ missing.append('spwd') # select(2); not on ancient System V - exts.append( Extension('select', ['selectmodule.c']) ) + exts.append( Extension('_select', ['selectmodule.c']) ) # Fred Drake's interface to the Python parser exts.append( Extension('parser', ['parsermodule.c']) ) From report at bugs.python.org Sat Jan 5 21:24:42 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 Jan 2013 20:24:42 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357417482.91.0.996321386957.issue8109@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed the latest patch. Thank you very much! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 22:05:59 2013 From: report at bugs.python.org (Meador Inge) Date: Sat, 05 Jan 2013 21:05:59 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357419959.63.0.781348542312.issue16853@psf.upfronthosting.co.za> Meador Inge added the comment: The EpollSelector and PollSelector implementations are basically identical. You might want to refactor these to share more code. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 22:27:27 2013 From: report at bugs.python.org (danblack) Date: Sat, 05 Jan 2013 21:27:27 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357421247.8.0.803732400081.issue8109@psf.upfronthosting.co.za> danblack added the comment: > I've committed the latest patch. Thank you very much! much appreciate your help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 22:38:18 2013 From: report at bugs.python.org (Meador Inge) Date: Sat, 05 Jan 2013 21:38:18 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357421898.75.0.0671037445056.issue16868@psf.upfronthosting.co.za> Meador Inge added the comment: This seems like a reasonable addition to me. Although, I don't like the "substantial amount of time" part (yes I know it was already there). That should probably be replaced with something more concrete, e.g. one week. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 22:47:47 2013 From: report at bugs.python.org (Meador Inge) Date: Sat, 05 Jan 2013 21:47:47 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357422467.13.0.626420342104.issue9685@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 22:48:22 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 05 Jan 2013 21:48:22 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357422502.44.0.156005001741.issue16868@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I would also take out the sentence about forgetting about the issue, because that's just one of several possible reasons and I don't think usually the main reason. ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 22:50:15 2013 From: report at bugs.python.org (Franck Michea) Date: Sat, 05 Jan 2013 21:50:15 +0000 Subject: [issue16143] Building with configure option "--without-doc-strings" crashes first time through PyUnicode_DecodeUTF8Stateful In-Reply-To: <1349455516.0.0.465126799391.issue16143@psf.upfronthosting.co.za> Message-ID: <1357422615.77.0.60500085043.issue16143@psf.upfronthosting.co.za> Changes by Franck Michea : ---------- nosy: +kushou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 5 22:53:13 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 05 Jan 2013 21:53:13 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> Message-ID: <1357422793.14.0.899612016375.issue16871@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is another recent comment from Georg on this topic: "And please don't commit cosmetic/"cleanup" changes to bugfix branches in the future." (from http://bugs.python.org/issue16793#msg178372 ) ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 00:12:36 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jan 2013 23:12:36 +0000 Subject: [issue16855] traceback module leaves off module name in last line of formatted tracebacks In-Reply-To: <1357249745.89.0.552193091281.issue16855@psf.upfronthosting.co.za> Message-ID: <1357427556.55.0.526216357471.issue16855@psf.upfronthosting.co.za> Terry J. Reedy added the comment: console = cmd window. I did run it there and that is where I duplicated your 2.7.3 result. I don't understand the different result with 2.7.3 IDLE, since it runs in a separate pythonw process that *should* give the same result as the python cmd window. But given that all in well in 3.3, I don't care to try to investigate. Who knows, maybe the fix you want would change both 2.7 IDLE results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 00:24:10 2013 From: report at bugs.python.org (Sven Brauch) Date: Sat, 05 Jan 2013 23:24:10 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357428250.44.0.482253979479.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: While writing tests, I noticed that the additional fields (lineno, col_offset for vararg, kwarg, and other arguments) currently are mandatory. Is that a problem? It doesn't seem trivial to change that, since apparently only attributes (not fields) can be optional, but those are not allowed by the syntax of python.asdl at this point. In case the fields need to be mandatory, what would be the correct approach to achieve that? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 00:30:22 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 05 Jan 2013 23:30:22 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357428622.15.0.299947129306.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: A question mark after the type name in the AST makes it optional. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 00:42:38 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 05 Jan 2013 23:42:38 +0000 Subject: [issue16872] Metaclass conflict proposition In-Reply-To: <1357416585.82.0.262219789669.issue16872@psf.upfronthosting.co.za> Message-ID: <1357429358.56.0.50022957359.issue16872@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This is material for the python-ideas list. ---------- nosy: +benjamin.peterson resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 00:55:16 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 05 Jan 2013 23:55:16 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357430116.56.0.895253546978.issue16868@psf.upfronthosting.co.za> Ezio Melotti added the comment: I agree with Chris. +substantial amount of time first "ping" the issue on the `issue tracker`_ I would add a comma after 'time'. > I don't like the "substantial amount of time" part (yes I know it > was already there). That should probably be replaced with something > more concrete, e.g. one week. That really depends on the situation. I think the point of that sentence is to make clear that some time might pass before someone can look at the issue, and I'm not sure it's necessary to quantify this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 00:58:06 2013 From: report at bugs.python.org (Sven Brauch) Date: Sat, 05 Jan 2013 23:58:06 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357430286.27.0.231308831381.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Thanks. I had seen and tried this before, but the "ast" module in python, which is used in the tests, still requires the additional arguments. Probably this is only valid for the C API? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 01:05:42 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 06 Jan 2013 00:05:42 +0000 Subject: [issue16866] libainstall doesn't create $(BINDIR) directory In-Reply-To: <1357357650.4.0.164255645189.issue16866@psf.upfronthosting.co.za> Message-ID: <1357430742.57.0.045362402894.issue16866@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the fix. The patches fixes it. Since this is a bug fix, it should be backported all the way till 2.7. ---------- assignee: -> orsenthil nosy: +orsenthil stage: -> commit review versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 01:28:54 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 00:28:54 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357419959.63.0.781348542312.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: I've noticed a bug present in Tulip, pyftpdlib and tornado (and this implementation, too): none of them passes the maxevents argument to epoll.poll(), and by default the poll() wrapper in the socket module uses FD_SETSIZE-1, so you'll never get more than FD_SETSIZE-1 events. Note that the default value used by epoll() is probably too low (we could maybe use an heuristic to use RLIMIT_NOFILE hard limit, with capping because it can be quite large on FreeBSD or the Hurd ;-), or at least the documentation doesn't warn users enough about this. The signature reads: """ .. method:: epoll.poll(timeout=-1, maxevents=-1) Wait for events. timeout in seconds (float) """ Which confuses users into thinking that the number of returned events is unlimited by default. > The EpollSelector and PollSelector implementations are basically identical. You might want to refactor these to share more code. Yes, but I find the current code much easier to read: epoll() and poll() have different constants, different units for timeout, epoll() must accept a maxevents argument, have a close() method, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 01:33:24 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 00:33:24 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation Message-ID: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: In issue #16853, it was noted that many several projects don't set epoll.poll() maxevents argument, which effectively limits the number of events retuend to FD_SETSIZE-1 (set in selectmodule.c). Also, the methode documentation can confuse users into thinking that by default, the number of events is unlimited: """ .. method:: epoll.poll(timeout=-1, maxevents=-1) Wait for events. timeout in seconds (float) """ It would probably make sense to use a larger default value for epoll max events (the only downside is increased memory consumption for the events array), maybe based on RLIMIT_NOFILE hard limit. And the documentation should probably be improved. ---------- components: Library (Lib) messages: 179157 nosy: neologix priority: normal severity: normal stage: needs patch status: open title: increase epoll.poll() maxevents default value, and improve documentation type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 01:36:25 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2013 00:36:25 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357432585.56.0.811947814974.issue8109@psf.upfronthosting.co.za> Christian Heimes added the comment: Coverity reports an issue in the callback function: /Modules/_ssl.c: 2403 ( uninit_use) 2400 /* remove race condition in this the call back while if removing the 2401 * callback is in progress */ 2402 PyGILState_Release(gstate); >>> CID 966640: Uninitialized scalar variable (UNINIT) >>> Using uninitialized value "ret". 2403 return ret; 2404 } 2405 2406 ssl = SSL_get_app_data(s); 2407 assert(PySSLSocket_Check(ssl)); I don't know which error code should be returned in this case. ---------- nosy: +christian.heimes resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 01:41:54 2013 From: report at bugs.python.org (Meador Inge) Date: Sun, 06 Jan 2013 00:41:54 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357430116.56.0.895253546978.issue16868@psf.upfronthosting.co.za> Message-ID: Meador Inge added the comment: On Sat, Jan 5, 2013 at 5:55 PM, Ezio Melotti wrote: > That really depends on the situation. I think the point of that sentence is to make clear that some time might > pass before someone can look at the issue, and I'm not sure it's necessary to quantify this. It currently says: """ If your patch has not received any notice from reviewers (i.e., no comment made) after a substantial amount of time then you may email python-dev at python.org asking for someone to take a look at your patch. """ That doesn't seem very useful to me because a newcomer is going to wonder how much time is "substantial". If you quantify it, then they don't really have to think about it as much which makes contributing easier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 01:45:42 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 06 Jan 2013 00:45:42 +0000 Subject: [issue16866] libainstall doesn't create $(BINDIR) directory In-Reply-To: <1357357650.4.0.164255645189.issue16866@psf.upfronthosting.co.za> Message-ID: <1357433142.44.0.591687969145.issue16866@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Digging a little deeper, make libainstall needs $(BINDIR) because of this $(INSTALL_SCRIPT) python-config $(DESTDIR)$(BINDIR)/python$(VERSION)-config *And* that python$(VERSION)-config file refers to the python exe which is available only after bininstall or it's dependees are called. In affect, if make libainstall is for using lib/* contents this fix is okay, but leaves a resultant invalid bin/python-config So, I am not sure the utility of make libainstall is without executing make bininstall - in which case, this is not a bug and probably a documentation change would be required. I am adding Martin and Georg who have dabbled with BUILD previously for their views. ---------- nosy: +georg.brandl, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 01:59:10 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Jan 2013 00:59:10 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357433950.15.0.97433595896.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: I am trying to use this module in Tulip instead of its pollster implementation, and am running into a problem. Tulip defines separate add_reader()/add_writer() methods, which call to the pollster's register_reader()/register_writer(), respectively. The translation of this to the selector's API is somewhat complex; I would have to keep track of whether I already have a reader or writer registered, and then decide whether to call register() or modify(). If you don't want to change the API back to separate register_*() methods for readers and writers, perhaps you can add a method that tells me, for a given fileobj, whether it is registered, and with which poll flags (SELECT_IN/OUT/both) and the user data? Also, I need a method that gives me the number of registered FDs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 02:14:24 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 06 Jan 2013 01:14:24 +0000 Subject: [issue16874] setup.py upload option repeated in docs Message-ID: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The following page: http://docs.python.org/dev/distutils/uploading.html says, "Other upload options include --repository= or --repository= where url..." I haven't looked into what the correct wording is meant to be. ---------- assignee: eric.araujo components: Distutils, Documentation keywords: easy messages: 179162 nosy: chris.jerdonek, eric.araujo, tarek priority: normal severity: normal stage: needs patch status: open title: setup.py upload option repeated in docs type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 02:43:39 2013 From: report at bugs.python.org (Danilo Bargen) Date: Sun, 06 Jan 2013 01:43:39 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1357436619.98.0.591949998814.issue7434@psf.upfronthosting.co.za> Changes by Danilo Bargen : ---------- nosy: +gwrtheyrn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 02:44:31 2013 From: report at bugs.python.org (Benno Leslie) Date: Sun, 06 Jan 2013 01:44:31 +0000 Subject: [issue16866] libainstall doesn't create $(BINDIR) directory In-Reply-To: <1357357650.4.0.164255645189.issue16866@psf.upfronthosting.co.za> Message-ID: <1357436671.27.0.668965418711.issue16866@psf.upfronthosting.co.za> Benno Leslie added the comment: I was using this in the case where I just want to link against libpython.a and for me it is a limited case where I don't really need the functionality of python-config; so for me this is certainly the best approach. But I concede this use case is probably a very little general interest. If the goal is to have a working python-config, then I guess libainstall should depend on bininstall. I'm not too fussed which approach is taken, I just think that (make && make libainstall) should work. I'm happy to fashion a patch for whichever approach is thought to be best. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 03:49:22 2013 From: report at bugs.python.org (Glenn) Date: Sun, 06 Jan 2013 02:49:22 +0000 Subject: [issue16875] in 3.3.0 windows 64 idle editor Message-ID: <1357440562.93.0.0668661513739.issue16875@psf.upfronthosting.co.za> New submission from Glenn: when in the Idle editor this line command does not work: >>> print "Hello World!" does not work it says it is a syntax error but >>> x="Hello World!" >>> x produces this 'Hello World!' ---------- components: IDLE messages: 179164 nosy: pargo priority: normal severity: normal status: open title: in 3.3.0 windows 64 idle editor type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 03:50:54 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 Jan 2013 02:50:54 +0000 Subject: [issue16875] in 3.3.0 windows 64 idle editor In-Reply-To: <1357440562.93.0.0668661513739.issue16875@psf.upfronthosting.co.za> Message-ID: <1357440654.52.0.193054746368.issue16875@psf.upfronthosting.co.za> Ezio Melotti added the comment: That's because in Python 3 print is a function, so you need to do print("Hello World!") instead. See the Python 3 tutorial: http://docs.python.org/3/tutorial/ ---------- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 03:56:16 2013 From: report at bugs.python.org (Ned Deily) Date: Sun, 06 Jan 2013 02:56:16 +0000 Subject: [issue16875] in 3.3.0 windows 64 idle editor In-Reply-To: <1357440562.93.0.0668661513739.issue16875@psf.upfronthosting.co.za> Message-ID: <1357440976.0.0.683490869642.issue16875@psf.upfronthosting.co.za> Ned Deily added the comment: Also see http://docs.python.org/3/whatsnew/3.0.html#print-is-a-function ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 04:30:02 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 03:30:02 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() Message-ID: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: Currently, epoll.poll() allocates an epoll_event buffer every time/ this is bad, because it changes an O(number of ready FDs) syscall into a O(maxevents/FD_SETSIZE) complexity. The patch attached allocates a epoll events buffer per epoll instance, and it only gets reallocated when necessary (note that the reallocation heuristic will probably be improved in #16873 (and having a per instance maxevents count will likely be useful). Here's a benchmark without patch: $ ./python -m timeit -s 'import select; ep = select.epoll(); ep.register(1, select.EPOLLOUT)' 'ep.poll()' 100000 loops, best of 3: 4.25 usec per loop With patch: $ ./python -m timeit -s 'import select; ep = select.epoll(); ep.register(1, select.EPOLLOUT)' 'ep.poll()' 100000 loops, best of 3: 3.38 usec per loop ---------- components: Extension Modules files: epoll_realloc.diff keywords: needs review, patch messages: 179167 nosy: neologix priority: normal severity: normal stage: patch review status: open title: epoll: reuse epoll_event buffer instead of allocating a new one at each poll() type: performance versions: Python 3.4 Added file: http://bugs.python.org/file28585/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 04:44:40 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 03:44:40 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357443879.99.0.303212477568.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28585/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 04:44:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 03:44:57 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357443897.36.0.273882131204.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28586/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 04:45:30 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2013 03:45:30 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357443930.86.0.64172744491.issue16876@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 04:46:46 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 06 Jan 2013 03:46:46 +0000 Subject: [issue16866] libainstall doesn't create $(BINDIR) directory In-Reply-To: <1357357650.4.0.164255645189.issue16866@psf.upfronthosting.co.za> Message-ID: <1357444006.73.0.808348563878.issue16866@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks Benno. I think that making libainstall depend on bininstall is a right solution too. A nod from devs who have committed changes in that area may help. Also, I believe that this is a bug fix and should be ported back upto 2.7. If there are any concerns it could be raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 05:09:20 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 06 Jan 2013 04:09:20 +0000 Subject: [issue16499] CLI option for isolated mode In-Reply-To: <1353248771.63.0.703024605939.issue16499@psf.upfronthosting.co.za> Message-ID: <1357445360.1.0.243576542732.issue16499@psf.upfronthosting.co.za> Nick Coghlan added the comment: The "system Python" idea in PEP 432 is aimed at providing an alternate interpreter binary which changes the default behaviour to be appropriate for system utilities, while allowing such features to be enabled selectively. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 05:25:15 2013 From: report at bugs.python.org (Ian Shields) Date: Sun, 06 Jan 2013 04:25:15 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath Message-ID: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> New submission from Ian Shields: Filespecs that start with ~ are not properly handled by os.path.realpath or os.path.abspath (and maybe other functions). Following console output from Fedora 17 using Puthon 3.2 illustrates the issue. Similar issue in 2.7 [ian at attic4 developerworks]$ cd .. [ian at attic4 ~]$ mkdir testpath [ian at attic4 ~]$ cd testpath [ian at attic4 testpath]$ pwd /home/ian/testpath [ian at attic4 testpath]$ python3 Python 3.2.3 (default, Jun 8 2012, 05:36:09) [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.abspath("~") '/home/ian/testpath/~' >>> os.path.realpath("~/xxx/zzz") '/home/ian/testpath/~/xxx/zzz' >>> os.path.abspath("~/..") '/home/ian/testpath' Function should probably use expanduser to determine if path is already absolute. Documentation at http://docs.python.org/3/library/os.path.html is also misleading as this is not how these functions work if given an absolute path to start with. ---------- components: None messages: 179170 nosy: ibshields priority: normal severity: normal status: open title: Odd behavior of ~ in os.path.abspath and os.path.realpath type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 05:54:37 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Jan 2013 04:54:37 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357448077.84.0.658143252582.issue16877@psf.upfronthosting.co.za> R. David Murray added the comment: This is intentional. You have to call expanduser yourself if you want ~ to be expanded. Otherwise it is treated as any other path component would be. I don't understand your final comment, can you clarify? ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 06:27:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 Jan 2013 05:27:15 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1357450035.55.0.428896984736.issue15204@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 06:29:26 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 Jan 2013 05:29:26 +0000 Subject: [issue11346] Generator object should be mentioned in gc module document In-Reply-To: <1298818993.14.0.492098392223.issue11346@psf.upfronthosting.co.za> Message-ID: <1357450166.42.0.224454253339.issue11346@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +pitrou stage: -> needs patch type: -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 06:31:07 2013 From: report at bugs.python.org (Benno Leslie) Date: Sun, 06 Jan 2013 05:31:07 +0000 Subject: [issue16869] makesetup should support .S source files In-Reply-To: <1357365407.25.0.925950325615.issue16869@psf.upfronthosting.co.za> Message-ID: <1357450267.56.0.892989171599.issue16869@psf.upfronthosting.co.za> Benno Leslie added the comment: Thanks for the comments Senthil. I'll improve the patch fixing the bug, adding support for .s and updating the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 07:18:37 2013 From: report at bugs.python.org (danblack) Date: Sun, 06 Jan 2013 06:18:37 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357453117.58.0.0385019559879.issue8109@psf.upfronthosting.co.za> danblack added the comment: > I don't know which error code should be returned in this case. Thanks Christian. My fault - asked Antoine to remove the default value for it and didn't see this like. make line 2403: return SSL_TLSEXT_ERR_OK; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 10:41:39 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 06 Jan 2013 09:41:39 +0000 Subject: [issue16878] argparse: positional args with nargs='*' defaults to [] Message-ID: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za> New submission from Chris Jerdonek: In argparse, positional arguments with nargs='*' default to [] rather None, even if default=None is passed explicitly. The documentation says otherwise: "The default keyword argument of add_argument(), whose value defaults to None, specifies what value should be used if the command-line argument is not present. ... For positional arguments with nargs equal to ? or *, the default value is used when no command-line argument was present:" (from http://docs.python.org/dev/library/argparse.html#default ) import argparse def parse(args, **kwargs): parser = argparse.ArgumentParser() parser.add_argument('foo', **kwargs) ns = parser.parse_args(args) print(repr(ns.foo)) parse([], nargs='?') # None parse([], nargs='*') # [] <-- parse([], nargs='*', default=None) # [] <-- parse([], nargs='*', default=False) # False parse([], nargs='*', default=0) # 0 Three options include (there may be more): (1) document the behavior (2) make a default of None yield None (3) do (2), but change the default to [] instead of None when nargs='*' ---------- components: Library (Lib) messages: 179174 nosy: bethard, chris.jerdonek priority: normal severity: normal status: open title: argparse: positional args with nargs='*' defaults to [] type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 10:48:30 2013 From: report at bugs.python.org (Geert Jansen) Date: Sun, 06 Jan 2013 09:48:30 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1357465710.33.0.0889804493753.issue12641@psf.upfronthosting.co.za> Geert Jansen added the comment: *bump* I just installed MinGW 2.6.2 32-bit on Windows XP. It doesn't accept -mnocygwin and there is no binary "i686-pc-mingw32-gcc" either. It would be great if you could agree on an approach and get this fixed. This impacts a lot of users that want to build extensions on Windows. In the mean time users can find a hack to work around the issue here: https://gist.github.com/4466320 ---------- nosy: +geertj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 11:07:25 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 06 Jan 2013 10:07:25 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1357466845.08.0.902861454929.issue12641@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Geert: Someone will have to provide a patch, else the issue will go nowhere. I will insist that the patch continues to support "older" gcc installations (from 2012), at least if implemented as a bug fix to older Python releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 11:26:50 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 10:26:50 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357468010.11.0.871635657725.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28586/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 11:27:06 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 10:27:06 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357468026.35.0.631599871354.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28587/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 11:30:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 10:30:58 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> Message-ID: <1357468258.5.0.211786998416.issue16843@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The previous patch is broken, here is a fixed, more complicated, patch. May be this class would be useful in other tests. ---------- Added file: http://bugs.python.org/file28588/test_sched_deterministic_timer_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 11:37:18 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 10:37:18 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357468638.5.0.167955301793.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28587/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 11:51:02 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 10:51:02 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357469462.24.0.381237854144.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28589/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 13:12:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2013 12:12:16 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> Message-ID: <1357474336.79.0.841540448608.issue16843@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The previous patch is broken, here is a fixed, more complicated, > patch. May be this class would be useful in other tests. I don't understand what you're gaining with this complicated class: your class guarantees that the sleepers will be woken up, but it doesn't guarantee that any user code will actually run. Perhaps the whole thing would be simpler if your tests used a Queue instead of a list? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 13:44:37 2013 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Sun, 06 Jan 2013 12:44:37 +0000 Subject: [issue16879] distutils.command.config uses fragile constant temporary file name Message-ID: <1357476277.46.0.0647034504115.issue16879@psf.upfronthosting.co.za> New submission from Micha? G?rny: The distutils.command.config module reads: def _gen_temp_sourcefile(self, body, headers, lang): filename = "_configtest" + LANG_EXT[lang] which means that every time one of the functions is used, a temporary file with the same name will be created. This is really fragile and fails terribly whenever more than one process tries to use the relevant functions in the same working directory. I believe this code should use the tempfile module to generate unique temporary files names instead. ---------- assignee: eric.araujo components: Distutils messages: 179179 nosy: eric.araujo, mgorny, tarek priority: normal severity: normal status: open title: distutils.command.config uses fragile constant temporary file name versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 14:12:45 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Jan 2013 13:12:45 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357477965.09.0.620811506721.issue16873@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Is this actually a problem? If events are arranged in a queue and epoll_wait() just removes the oldest events (up to maxevents) from that queue then there would be no problem with using a small value for maxevents. I don't *know* if that is the case, but I would consider epoll to be broken if it does not do something similar. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 14:59:18 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Jan 2013 13:59:18 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357480758.84.0.686871679817.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Attached is a patch which adds a winio module which is a replacement for io, but uses windows handles instead of fds. It reimplements FileIO and open(), and provides openhandle() and closehandle() as replacements for os.open() and os.close(). test_io has been modified to exercise winio (in addition to _io and _pyio) and all the tests pass. Note that some of the implementation (openhandle(), open(), FileIO.__init__()) is still done in Python rather than C. ---------- keywords: +patch Added file: http://bugs.python.org/file28590/winfileio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 15:30:49 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2013 14:30:49 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1357482649.22.0.0116841011.issue8109@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed in 52b4d9bfc9ea (Roundup e-mail gateway seems broken). ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 15:37:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 14:37:57 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357483077.82.0.401129563894.issue16873@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: The implementation can't simply drain a queue, because it can be level-triggered (which is the case by default), so you want to keep events around. The kernel actually uses a red-black tree, but I didn't really check how it's done (there's probably very good reasosns for that). Anyway, it can turn out to be a problem, for two reasons: - performance: by specifying a maxevents value too low, several calls to epoll_wait() must be made, instead of being able to process all events at once - the main problem that came to my mind is really starvation: let's say you have 2*FD_SETSIZE client sockets registered in your poll object. The first call to epoll_wait() returns sockets from 0 to FD_SETSIZE-1: you process them, so they're not ready anymore. The next call returns the clients from FD_SETSIZE to 2*FD_SETSIZE, same thing. But by the time you call epoll_wait() for the third time, if the first FD_SETSIZE clients are ready again, they will be returned, etc. So the 2*FD_SETSIZE th client may very well never be reported ready: that's starvation. I actually wrote a script to reproduce this issue: """ $ ./python /home/cf/test_epoll.py Working with 4080 FDs, -1 maxevents Number of missing FDs:4080 Number of ready FDs: 1023 Number of missing FDs:3057 Number of ready FDs: 0 Number of missing FDs:3057 Number of ready FDs: 1023 Number of missing FDs:2034 Number of ready FDs: 0 Number of missing FDs:2034 Number of ready FDs: 1023 Number of missing FDs:2034 Number of ready FDs: 0 Number of missing FDs:2034 Number of ready FDs: 1023 Number of missing FDs:2034 Number of ready FDs: 0 [...] """ If you specify a large enough maxevents: """ $ ./python /home/cf/test_epoll.py 64000 Working with 4080 FDs, 64000 maxevents Number of missing FDs:4080 Number of ready FDs: 4080 """ Note that it's really a corner issue, but I stumpled upon this problem while writing a test in issue #16853, and several projects (Tulip, Tornado, pyftpdlib) fall into this trap. I see several options: 1) just keep it that way (i.e. with maxevents set to FD_SETSIZE), and add a note in the documentation. I think it's always better to handle problems in the library than let the users get bitten. 2) increase `maxevents` default value. The problem is that I don't like magic values, and a too large value could incur increased memory consumption (and with the current implementation reduced performance because the epoll events buffer is allocated at each poll(), see issue #16876. 3) use a simple heuristic: start with a reasonable value for `maxevents` (FD_SETSIZE seems like a good candidate), and if epoll_wait() ever returns `maxevents` events, double the value (that's what libevent does, with a capping to 32000). ---------- Added file: http://bugs.python.org/file28591/test_epoll.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 15:43:19 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Jan 2013 14:43:19 +0000 Subject: [issue16878] argparse: positional args with nargs='*' defaults to [] In-Reply-To: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za> Message-ID: <1357483399.25.0.604350559892.issue16878@psf.upfronthosting.co.za> R. David Murray added the comment: I'd prefer to fix it, since having the action='append' and nargs='*' behaviors be different looks like a bug. However, fixing it to match 'append' (default really is None) would be likely to break working code, so we certainly couldn't backport that, and I'd be really reluctant to fix it that way in 3.4, either. (3) is thus preferable to (2), even though it leaves us with an inconsistency. It would still be a judgment call on whether or not to backport it. It seems like it would be reasonably safe, but such changes always worry me :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 15:53:57 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2013 14:53:57 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357484037.8.0.177111704303.issue16873@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > 3) use a simple heuristic: start with a reasonable value for > `maxevents` (FD_SETSIZE seems like a good candidate), and if > epoll_wait() ever returns `maxevents` events, double the value (that's > what libevent does, with a capping to 32000). What if some events are edge-triggered? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:20:26 2013 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 06 Jan 2013 15:20:26 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported Message-ID: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> New submission from Jeffrey Armstrong: On a platform where dynamic loading is unsupported, the function "imp_load_dynamic" is not compiled (Python/import.c:1775), and the Python function "load_dynamic" (Python/import.c:1845) will not be included in the _imp module. However, Lib/imp.py attempts to import "load_dynamic" from _imp (Lib/imp.py:9), causing an ImportError if dynamic loading is unsupported. The interpreter is unable to start under these circumstances. The error was encountered on m68k-atari-mint using GCC as the compiler. This platform is a desktop environment, but has no support for true shared objects and libraries. ---------- components: Library (Lib) messages: 179186 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Importing "imp" will fail if dynamic loading not supported type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:29:52 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2013 15:29:52 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357486192.31.0.0839730850659.issue16880@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brett.cannon, ncoghlan stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:32:47 2013 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 06 Jan 2013 15:32:47 +0000 Subject: [issue16881] Py_ARRAY_LENGTH macro incorrect with GCC < 3.1 Message-ID: <1357486367.34.0.653712599224.issue16881@psf.upfronthosting.co.za> New submission from Jeffrey Armstrong: The Py_ARRAY_LENGTH macro (Include/pymacro.h:36) checks to see if using GCC by simply looking for __GCC__ being defined. If so, it uses the GCC extension function "__builtin_types_compatible_p." However, this function was not introduced until GCC 3.1. This simple check for a GCC compiler causes the Python build to fail on GCC < 3.1 (2.95 for example). The check should actually be: #if (defined(__GNUC__) && !defined(__STRICT_ANSI__) && \ ((__GNUC__ == 3) && (__GNU_MINOR__) >= 1) || (__GNUC__ >= 4))) Similar checks are made in other locations in the core library, just not here. This bug was discovered while attempting a build on m68k-atari-mint, which relies on GCC 2.95.3. Other systems may also be using this compiler still. ---------- components: Build messages: 179187 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Py_ARRAY_LENGTH macro incorrect with GCC < 3.1 type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:43:18 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2013 15:43:18 +0000 Subject: [issue16881] Py_ARRAY_LENGTH macro incorrect with GCC < 3.1 In-Reply-To: <1357486367.34.0.653712599224.issue16881@psf.upfronthosting.co.za> Message-ID: <1357486998.6.0.761997707248.issue16881@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in http://hg.python.org/cpython/rev/13c83199c211 ---------- assignee: -> christian.heimes nosy: +christian.heimes resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:45:36 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Jan 2013 15:45:36 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357487136.23.0.795047316444.issue16873@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I actually wrote a script to reproduce this issue: The program does *not* demonstrate starvation because you are servicing the resource represented by the "starved" duplicate fds before calling poll() again. You are creating thousands of duplicate handles for the same resource and then complaining that they do not behave independently! I tried modifing your program by running poll() in a loop, exiting when no more unseen fds are reported as ready. This makes the program exit immediately. So ready_writers = set(fd for fd, evt in ep.poll(-1, MAXEVENTS) if fd != r) seen_writers |= ready_writers becomes while True: ready_writers = set(fd for fd, evt in ep.poll(-1, MAXEVENTS) if fd != r) if ready_writers.issubset(seen_writers): break seen_writers |= ready_writers I still cannot see a problem with epoll(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:48:26 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2013 15:48:26 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1357487306.59.0.948792607871.issue15204@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Would the deprecation need to be moved up to 3.4 though now? Yes, I think so. ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:48:32 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2013 15:48:32 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357487312.31.0.96694767979.issue16880@psf.upfronthosting.co.za> Christian Heimes added the comment: The attached patch should fix the issue. Can you give it a try, please? ---------- assignee: -> christian.heimes nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:49:07 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 06 Jan 2013 15:49:07 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357487347.18.0.431031586707.issue16880@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- keywords: +patch Added file: http://bugs.python.org/file28592/imp_dynamic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:50:38 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Jan 2013 15:50:38 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357487438.75.0.595796161014.issue16880@psf.upfronthosting.co.za> Brett Cannon added the comment: LGTM ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:50:59 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Jan 2013 15:50:59 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357487459.52.0.438707316558.issue16880@psf.upfronthosting.co.za> Brett Cannon added the comment: I should say LGTM in terms of looking at the patch, not actually trying it out. =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:51:14 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2013 15:51:14 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1357340511.29.0.97148822576.issue8109@psf.upfronthosting.co.za> Message-ID: <1357487341.3297.9.camel@localhost.localdomain> Antoine Pitrou added the comment: (testing Roundup mail gateway, please ignore) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 16:52:55 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Jan 2013 15:52:55 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357487575.16.0.62713549392.issue16880@psf.upfronthosting.co.za> Brett Cannon added the comment: I did just realize, though, there is no test for temporarily setting load_dynamic() to None in imp.py to make sure the expected exception is raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 17:42:33 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Jan 2013 16:42:33 +0000 Subject: =?utf-8?q?=5Bissue16537=5D_Python=E2=80=99s_setup=2Epy_raises_a_ValueErro?= =?utf-8?q?r_when_self=2Eextensions_is_empty?= In-Reply-To: <1353633257.31.0.391670680901.issue16537@psf.upfronthosting.co.za> Message-ID: <1357490553.19.0.827185121765.issue16537@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 17:42:40 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Jan 2013 16:42:40 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357490560.28.0.112832018454.issue16868@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 17:58:35 2013 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 06 Jan 2013 16:58:35 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357491515.82.0.348503105983.issue16880@psf.upfronthosting.co.za> Jeffrey Armstrong added the comment: The patch works with respect to allowing the interpreter to start, and importing modules from the interpreter seems to be working fine. I can't speak to Brett's concerns about possible side effects of setting load_dynamic to None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 18:40:02 2013 From: report at bugs.python.org (Ian Shields) Date: Sun, 06 Jan 2013 17:40:02 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357494002.37.0.122527489222.issue16877@psf.upfronthosting.co.za> Ian Shields added the comment: Regarding last comment. I had missed the comment in documentation fo os.path.join "Join one or more path components intelligently. If any component is an absolute path, all previous components (on Windows, including the previous drive letter, if there was one) are thrown away, and joining continues". So the issue is really the behavior of os.path.join where the intelligence in the joining does not recognize that "~" is usually expanded to an absolute path. Consider the following Bash commands: [ian at attic4 testpath]$ pwd /home/ian/testpath [ian at attic4 testpath]$ echo $(cd ~/testpath/..;pwd) /home/ian [ian at attic4 testpath]$ cd /home/ian/~ bash: cd: /home/ian/~: No such file or directory Now consider some Python >>> os.getcwd() '/home/ian/testpath' >>> os.path.join(os.getcwd(), "/home/ian") '/home/ian' >>> os.path.expanduser("~") '/home/ian' >>> os.path.join(os.getcwd(), "~") '/home/ian/testpath/~' >>> os.path.expanduser(os.path.abspath("~")) '/home/ian/testpath/~' >>> os.path.abspath(os.path.expanduser("~")) '/home/ian' I find the Python behavior rather odd. I cna live with it now I know about it, but if it is really intentional it would help to document this rather odd behavior somewhat better. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 18:49:45 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2013 17:49:45 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357494585.01.0.460946986254.issue16877@psf.upfronthosting.co.za> Georg Brandl added the comment: Can you point exactly where the "odd behavior" is? Note that "~" is a normal component for UNIX file/path names, and in such it has no special meaning (as opposed to "/"). This is why it gets no special handling by any Python path functions, except for expanduser(). That it is handled specially by the shell is no reason for Python to do the same. ---------- nosy: +georg.brandl status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 18:53:44 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2013 17:53:44 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357494824.31.0.33519990328.issue9685@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 19:10:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 18:10:44 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357474336.79.0.841540448608.issue16843@psf.upfronthosting.co.za> Message-ID: <201301062010.12041.storchaka@gmail.com> Serhiy Storchaka added the comment: > I don't understand what you're gaining with this complicated class: your > class guarantees that the sleepers will be woken up, but it doesn't > guarantee that any user code will actually run. It guarantees that advance() returns only when all sleepers are sleeping or died, and all user code before specified time mark have executed. User code running does not take time, only sleeps take time. Actually this class is a forward-running time-machine with pause. But it looks overkill here. > Perhaps the whole thing would be simpler if your tests used a Queue > instead of a list? Hmm, I had not occurred to this idea. Indeed, the patch is a little complicated (honestly speaking, it is a lot complicated). Here is a more simplified patch that uses a queue for synchronization in one direction and simple custom timer for synchronization in another direction. Thank you for suggestion. ---------- Added file: http://bugs.python.org/file28593/test_sched_queue.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r c1fc6b6d1cfc Lib/test/test_sched.py --- a/Lib/test/test_sched.py Sat Jan 05 06:26:39 2013 -0800 +++ b/Lib/test/test_sched.py Sun Jan 06 19:48:45 2013 +0200 @@ -1,5 +1,6 @@ #!/usr/bin/env python +import queue import sched import time import unittest @@ -9,6 +10,35 @@ except ImportError: threading = None +TIMEOUT = 10 + + +class Timer: + def __init__(self): + self._cond = threading.Condition() + self._time = 0 + self._stop = 0 + + def time(self): + with self._cond: + return self._time + + def sleep(self, t): + assert t >= 0 + with self._cond: + t += self._time + while self._stop < t: + self._time = self._stop + self._cond.wait() + self._time = t + + def advance(self, t): + assert t >= 0 + with self._cond: + self._stop += t + self._cond.notify_all() + + class TestCase(unittest.TestCase): def test_enter(self): @@ -31,17 +61,33 @@ @unittest.skipUnless(threading, 'Threading required for this test.') def test_enter_concurrent(self): - l = [] - fun = lambda x: l.append(x) - scheduler = sched.scheduler(time.time, time.sleep) - scheduler.enter(0.03, 1, fun, (0.03,)) + q = queue.Queue() + fun = q.put + timer = Timer() + scheduler = sched.scheduler(timer.time, timer.sleep) + scheduler.enter(1, 1, fun, (1,)) + scheduler.enter(3, 1, fun, (3,)) t = threading.Thread(target=scheduler.run) t.start() - for x in [0.05, 0.04, 0.02, 0.01]: - z = scheduler.enter(x, 1, fun, (x,)) - scheduler.run() - t.join() - self.assertEqual(l, [0.01, 0.02, 0.03, 0.04, 0.05]) + timer.advance(1) + self.assertEqual(q.get(timeout=TIMEOUT), 1) + self.assertTrue(q.empty()) + for x in [4, 5, 2]: + z = scheduler.enter(x - 1, 1, fun, (x,)) + timer.advance(2) + self.assertEqual(q.get(timeout=TIMEOUT), 2) + self.assertEqual(q.get(timeout=TIMEOUT), 3) + self.assertTrue(q.empty()) + timer.advance(1) + self.assertEqual(q.get(timeout=TIMEOUT), 4) + self.assertTrue(q.empty()) + timer.advance(1) + self.assertEqual(q.get(timeout=TIMEOUT), 5) + self.assertTrue(q.empty()) + timer.advance(1000) + t.join(timeout=TIMEOUT) + self.assertFalse(t.is_alive()) + self.assertTrue(q.empty()) def test_priority(self): l = [] @@ -69,21 +115,35 @@ @unittest.skipUnless(threading, 'Threading required for this test.') def test_cancel_concurrent(self): - l = [] - fun = lambda x: l.append(x) - scheduler = sched.scheduler(time.time, time.sleep) - now = time.time() - event1 = scheduler.enterabs(now + 0.01, 1, fun, (0.01,)) - event2 = scheduler.enterabs(now + 0.02, 1, fun, (0.02,)) - event3 = scheduler.enterabs(now + 0.03, 1, fun, (0.03,)) - event4 = scheduler.enterabs(now + 0.04, 1, fun, (0.04,)) - event5 = scheduler.enterabs(now + 0.05, 1, fun, (0.05,)) + q = queue.Queue() + fun = q.put + timer = Timer() + scheduler = sched.scheduler(timer.time, timer.sleep) + now = timer.time() + event1 = scheduler.enterabs(now + 1, 1, fun, (1,)) + event2 = scheduler.enterabs(now + 2, 1, fun, (2,)) + event4 = scheduler.enterabs(now + 4, 1, fun, (4,)) + event5 = scheduler.enterabs(now + 5, 1, fun, (5,)) + event3 = scheduler.enterabs(now + 3, 1, fun, (3,)) t = threading.Thread(target=scheduler.run) t.start() - scheduler.cancel(event1) + timer.advance(1) + self.assertEqual(q.get(timeout=TIMEOUT), 1) + self.assertTrue(q.empty()) + scheduler.cancel(event2) scheduler.cancel(event5) - t.join() - self.assertEqual(l, [0.02, 0.03, 0.04]) + timer.advance(1) + self.assertTrue(q.empty()) + timer.advance(1) + self.assertEqual(q.get(timeout=TIMEOUT), 3) + self.assertTrue(q.empty()) + timer.advance(1) + self.assertEqual(q.get(timeout=TIMEOUT), 4) + self.assertTrue(q.empty()) + timer.advance(1000) + t.join(timeout=TIMEOUT) + self.assertFalse(t.is_alive()) + self.assertTrue(q.empty()) def test_empty(self): l = [] From report at bugs.python.org Sun Jan 6 19:12:46 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Jan 2013 18:12:46 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <201301062010.12041.storchaka@gmail.com> Message-ID: <1357495833.3297.11.camel@localhost.localdomain> Antoine Pitrou added the comment: > Actually this class is a > forward-running time-machine with pause. Perhaps you should give it to Guido as a present? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 19:14:48 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 18:14:48 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357487136.23.0.795047316444.issue16873@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > The program does *not* demonstrate starvation because you are servicing the resource represented by the "starved" duplicate fds before calling poll() again. No. What the program does is the following: while all the write FDs have not been returned by epoll.wait() at least once: 1) make all writer FDs ready by draining the pipe 2) fetch the list of event reported by epoll(), and add them to the list of seen FDs 3) make all the writers FDs not ready by filling the PIPE 4) fetch the list of event reported by epoll(), and add them to the list of seen FDs With the default 'maxevents' parameters, it never completes. This shows that the FDs returned at step 2 are actually a strict subset of all the ready FDs, and this forever: some FDs which are actually ready (they are all ready at step 2) are *never* reported. This is starvation. By increasing epoll.wait() maxevents, it completes immediately. > You are creating thousands of duplicate handles for the same resource and then complaining that they do not behave independently! The fact that that the FDs are duped shouldn't change anything to the events reported: it works while the number of FDs is less than FD_SETSIZE (epoll_wait() maxevents argument). See also epoll() documentation: """ Q0 What is the key used to distinguish the file descriptors registered in an epoll set? A0 The key is the combination of the file descriptor number and the open file description (also known as an "open file handle", the kernel's internal representation of an open file). Q1 What happens if you register the same file descriptor on an epoll instance twice? A1 You will probably get EEXIST. However, it is possible to add a duplicate (dup(2), dup2(2), fcntl(2) F_DUPFD) descriptor to the same epoll instance. This can be a useful technique for filtering events, if the duplicate file descriptors are registered with different events masks. """ I just used dup() to make it easier to test, but you'll probably get the same thing it your FDs were sockets connected to different endpoints. > I tried modifing your program by running poll() in a loop, exiting when no more unseen fds are reported as ready. This makes the program exit immediately. > > So > > ready_writers = set(fd for fd, evt in > ep.poll(-1, MAXEVENTS) if fd != r) > seen_writers |= ready_writers > > becomes > > while True: > ready_writers = set(fd for fd, evt in > ep.poll(-1, MAXEVENTS) if fd != r) > if ready_writers.issubset(seen_writers): > break > seen_writers |= ready_writers Of course it does, since the returned FDs are a subset of all the ready file descriptors. The point is precisely that, when there are more FDs ready than maxevents, some FDs will never be reported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 19:32:22 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 18:32:22 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357497142.82.0.159519710161.issue9685@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, Raymond. It was a bad day for Roundup. ---------- assignee: -> rhettinger nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 19:36:06 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 18:36:06 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357495833.3297.11.camel@localhost.localdomain> Message-ID: <201301062035.54678.storchaka@gmail.com> Serhiy Storchaka added the comment: > Perhaps you should give it to Guido as a present? First I have to find some application for it. Wait for me at the 3013 year. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 19:40:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 18:40:04 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1357497604.53.0.842118037781.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I reclassify this as enhancement until the real bug is not found. ---------- type: behavior -> enhancement versions: -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 19:50:01 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Jan 2013 18:50:01 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357498201.89.0.531609954521.issue16877@psf.upfronthosting.co.za> R. David Murray added the comment: In addition, as far as I know, ba/sh has no equivalent to os.path.join (see, eg: http://unix.stackexchange.com/questions/23208/building-paths-robustly). So even if we *did* want to "act like the shell" there's no analog to point to. The shell only expands ~ when it is the first component of a path in a globbing context, and Python does not do globbing automatically anywhere. So calling expanduser on a path before doing the join allows you to recognize '~'s if you want to support them in your input. But, as I said, the shell has no real analog for join, so talking about the behavior of join in analogy to the behavior of the shell is pretty meaningless. The key thing to realize here is that Python does not do globbing automatically (there is a separate glob module for that). I don't think even a doc update is warranted, since it would be a bit weird to document things we *don't* do :) However, if you have a specific proposal for what such a note would look like and where it would be placed, we would consider it, as we are always looking to make the docs better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:14:30 2013 From: report at bugs.python.org (Ian Shields) Date: Sun, 06 Jan 2013 19:14:30 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357499670.19.0.601673897887.issue16877@psf.upfronthosting.co.za> Ian Shields added the comment: Oddity may be in the eye of the beholder. I've been programming and scripting for about 40 years, including several *IX shells and many other systems. I'm relatively new to Python. Mostly the results of doing things in Python are what I expect. Not doing expansion of a leading tilde when I ask for an absolute path is not what I expect. So to me it's odd. Or different. Or just not what I expect. Substitute "unexpected" for "odd" if you like. Sure, tilde expansion wasn't part of the Bourne shell, but it's been in POSIX shells for about the same amount of time that Python has been around, so it's odd to me that Python differs in this way. It's not hard to work around now that I know about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:20:15 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Jan 2013 19:20:15 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357500015.18.0.808528305373.issue16873@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > The fact that that the FDs are duped shouldn't change anything to the > events reported: it works while the number of FDs is less than > FD_SETSIZE (epoll_wait() maxevents argument). That assumes that epoll_wait() is supposed to return *all* ready fds. But that is not possible because maxevents is finite. If you want all events then obviously you may need to call epoll_wait() multiple times. > I just used dup() to make it easier to test, but you'll probably get > the same thing it your FDs were sockets connected to different > endpoints. This is the part I disagree with -- I think it makes all the difference. Please try making such a modification. >> while True: >> ready_writers = set(fd for fd, evt in >> ep.poll(-1, MAXEVENTS) if fd != r) >> if ready_writers.issubset(seen_writers): >> break >> seen_writers |= ready_writers > >Of course it does, since the returned FDs are a subset of all the >ready file descriptors. > >The point is precisely that, when there are more FDs ready than >maxevents, some FDs will never be reported. The program can only terminate when the outer while all_writers - seen_writers: ... loop terminates. So seen_writers == all_writers, and every fd has been reported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:37:11 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Jan 2013 19:37:11 +0000 Subject: [issue16320] Establish order in bytes/string dependencies In-Reply-To: <1351156037.64.0.017004315605.issue16320@psf.upfronthosting.co.za> Message-ID: <3YfVP23hYDzP77@mail.python.org> Roundup Robot added the comment: New changeset 8a6068ec220e by Serhiy Storchaka in branch 'default': Issue #16320: Remove redundant Makefile dependencies for strings and bytes. http://hg.python.org/cpython/rev/8a6068ec220e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:41:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 19:41:21 +0000 Subject: [issue16320] Establish order in bytes/string dependencies In-Reply-To: <1351156037.64.0.017004315605.issue16320@psf.upfronthosting.co.za> Message-ID: <1357501281.62.0.181294007945.issue16320@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed. Thank you for review, Meador. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:42:05 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 19:42:05 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357500015.18.0.808528305373.issue16873@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > That assumes that epoll_wait() is supposed to return *all* ready fds. But that is not possible because maxevents is finite. If you want all events then obviously you may need to call epoll_wait() multiple times. Yes, but the problem is that between two epoll_wait() calls, the readiness of the FDs can have changed: and if that happens, you'll get the same list over and over. > The program can only terminate when the outer > > while all_writers - seen_writers: > ... > > loop terminates. So seen_writers == all_writers, and every fd has been reported. Yes, but there are no event generated between calls to epoll_wait() in your inner loop. In a typical usage of select()/poll() epoll() will look like: while True: evts = poll() for evt in evts: do_something(fd) and between two calls to poll(), you can get new events (new connections, space in the socket buffer, etc). The pipe filling/draining is used to generate new events. Your modification doesn't take that into account. > This is the part I disagree with -- I think it makes all the difference. Please try making such a modification. Will do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:46:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 19:46:47 +0000 Subject: [issue16499] CLI option for isolated mode In-Reply-To: <1353248771.63.0.703024605939.issue16499@psf.upfronthosting.co.za> Message-ID: <1357501607.31.0.859582663558.issue16499@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:49:15 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Jan 2013 19:49:15 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357501755.33.0.743815825748.issue16873@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Here is a version which uses epoll to service a number of pipes which is larger than maxevents. (If NUM_WRITERS is too large then I get "OSError: [Errno 24] Too many open files".) All pipes get serviced and the output is: Working with 20 FDs, 5 maxevents [5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39, 41, 43] [15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39, 41, 43] [25, 27, 29, 31, 33, 35, 37, 39, 41, 43] [35, 37, 39, 41, 43] The lists show the (sorted) unseen writers at each loop. ---------- Added file: http://bugs.python.org/file28594/test_epoll_2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:54:37 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 19:54:37 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357502077.67.0.763875790137.issue16873@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Of course it does, the write ends all get filled, so the number of ready writers drops to zero... That's not all at the problem I'm talking about (I may not be clear though, a script will make it more clear). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:55:34 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Jan 2013 19:55:34 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357502134.84.0.167751316598.issue16873@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Yes, but the problem is that between two epoll_wait() calls, the > readiness of the FDs can have changed: and if that happens, you'll get > the same list over and over. If an fd *was* ready but isn't anymore then why would you want to know about it? Trying to use the fd will fail with EAGAIN. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 20:59:24 2013 From: report at bugs.python.org (Ian Shields) Date: Sun, 06 Jan 2013 19:59:24 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357502364.51.0.401493883499.issue16877@psf.upfronthosting.co.za> Ian Shields added the comment: David, Tilde expansion is different to globbing. Globbing in Python doesn't automatically do tilde expansion either. >>> glob.glob("~") [] Looking at the documentation, I don't think it would be practical to add documentation to each affected function - there are too many. Apart from abspath and realpath (which started this conversation), there are join, isdir, isfile, isabs, and many others in os.path. posixpath and the other path handling modules. Maybe a note at the top of the module documentation (e.g. http://docs.python.org/3/library/os.path.html) which has two notes already. Something along the line of: Unlike many shells, Python does not automatically do tilde expansion or variable substitution in paths. Use expanduser for tilde expansion or expandvars for variable substitution. Or just simply Use expanduser for tilde expansion or expandvars for variable substitution in paths as the other path functions do not do this automatically. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:01:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 20:01:54 +0000 Subject: [issue16799] start using argparse.Namespace in regrtest In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za> Message-ID: <1357502514.63.0.432252193676.issue16799@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be it would be better to split the patch to two parts -- the fix of usage() bug and the enhancement. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:18:02 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2013 20:18:02 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357503482.6.0.280927927772.issue16877@psf.upfronthosting.co.za> Georg Brandl added the comment: Both are a kind of command-line expansion, see for example bash(1). Listed there are "brace expansion, tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, word splitting, and pathname expansion". Python does none of them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:20:16 2013 From: report at bugs.python.org (David Beazley) Date: Sun, 06 Jan 2013 20:20:16 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1357503616.56.0.972176154814.issue14965@psf.upfronthosting.co.za> David Beazley added the comment: Just as a note, there is a distinct possibility that a "property" in a superclass could be some other kind of descriptor object that's not a property. To handle that case, the solution of super(self.__class__, self.__class__).x.fset(self, value) would actually have to be rewritten as super(self.__class__, self.__class__).x.__set__(self, value) That said, I agree it would be nice to have a simplified means of accomplishing this. ---------- nosy: +dabeaz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:25:13 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 06 Jan 2013 20:25:13 +0000 Subject: [issue16799] start using argparse.Namespace in regrtest In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za> Message-ID: <1357503913.29.0.144109101229.issue16799@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Sure, I'd be happy to do that. I'll prepare the patch for the other issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:27:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 20:27:04 +0000 Subject: [issue9242] unicodeobject.c: use of uninitialized values In-Reply-To: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za> Message-ID: <1357504024.65.0.605847237922.issue9242@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 3.2 is affected too. The PEP-393 changes fixes this bug in 3.3+. Here is a simple patch. ---------- assignee: -> serhiy.storchaka keywords: +patch nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.2 Added file: http://bugs.python.org/file28595/issue9242.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:31:33 2013 From: report at bugs.python.org (Sven Brauch) Date: Sun, 06 Jan 2013 20:31:33 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357504293.56.0.208415393259.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Here's a new proposal, I adjusted the AST tests and fixed some small problems I encountered during that. It contains all the diffs for generated files, should I remove those for easier review? A remaining problem is that AST_Tests::_assertTrueorder now fails, I think because the condition it checks simply is not met any more (by design of the change). What's the correct way to deal with that? ---------- Added file: http://bugs.python.org/file28596/python2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:33:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 20:33:36 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1357504416.27.0.31380542855.issue10156@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Daniel's patch looks good for me. 2.7 looks affected too. ---------- nosy: +serhiy.storchaka stage: patch review -> commit review versions: +Python 2.7 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:37:39 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 20:37:39 +0000 Subject: [issue16873] increase epoll.poll() maxevents default value, and improve documentation In-Reply-To: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za> Message-ID: <1357504659.79.0.727657666388.issue16873@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: You're right, I just saw my mistake. Sorry for the noise (the extra performance arguement is not a good enough motivation to tune this dynaically). Closing. ---------- resolution: -> invalid stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:43:48 2013 From: report at bugs.python.org (Stefan Krah) Date: Sun, 06 Jan 2013 20:43:48 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1357505028.82.0.847532554699.issue10156@psf.upfronthosting.co.za> Stefan Krah added the comment: unicode-leak.patch doesn't fix #16143 though. unicode_empty and unicode_latin1 need to be initialized, too. Actually we could close this in favor of #16143. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:51:01 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Jan 2013 20:51:01 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357505461.77.0.903759642849.issue16877@psf.upfronthosting.co.za> R. David Murray added the comment: Here is a proposed doc patch. While not a necessary doc addition, I do think it provides some useful guidance, and is short enough that it doesn't weigh down the docs. ---------- keywords: +patch Added file: http://bugs.python.org/file28597/doc_no_default_expand.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:52:41 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 06 Jan 2013 20:52:41 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <1357505561.23.0.794845455465.issue16854@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I'm submitting a patch for this independent of issue 16799 on Serhiy's request. ---------- dependencies: -start using argparse.Namespace in regrtest keywords: +patch Added file: http://bugs.python.org/file28598/issue-16854-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 21:54:40 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 20:54:40 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357505680.13.0.893420206104.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:05:41 2013 From: report at bugs.python.org (Catalin Iacob) Date: Sun, 06 Jan 2013 21:05:41 +0000 Subject: [issue8745] zipimport is a bit slow In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za> Message-ID: <1357506341.0.0.87502395773.issue8745@psf.upfronthosting.co.za> Catalin Iacob added the comment: Attached v4 of patch with error checking for getc and some more comments. A real world example of the speedup is Calibre (http://calibre-ebook.com/) which on Windows comes with its own code, its dependecies and Python's stdlib all bundled in a 40MB zip. With the patch the time to create a zipimporter instance from that zip drops from around 60ms to around 15ms. ---------- Added file: http://bugs.python.org/file28599/zipimport-speedup-v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:06:33 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 21:06:33 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357506393.64.0.468982276467.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28600/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:06:44 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 21:06:44 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357506404.15.0.390234260264.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28589/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:07:01 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 Jan 2013 21:07:01 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357506421.1.0.841080954511.issue16877@psf.upfronthosting.co.za> Georg Brandl added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:15:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Jan 2013 21:15:21 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <3YfXZJ3CgJzS65@mail.python.org> Roundup Robot added the comment: New changeset 02e2fa22f8b7 by R David Murray in branch '3.2': #16877: Add mention that shell-style path expansions are not automatic. http://hg.python.org/cpython/rev/02e2fa22f8b7 New changeset 2ff547c165fd by R David Murray in branch '3.3': merge #16877: Add mention that shell-style path expansions are not automatic. http://hg.python.org/cpython/rev/2ff547c165fd New changeset b6284d2aaada by R David Murray in branch 'default': merge #16877: Add mention that shell-style path expansions are not automatic. http://hg.python.org/cpython/rev/b6284d2aaada New changeset 58ac62bc3cd5 by R David Murray in branch '2.7': #16877: Add mention that shell-style path expansions are not automatic. http://hg.python.org/cpython/rev/58ac62bc3cd5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:29:17 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 06 Jan 2013 21:29:17 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357507757.88.0.584053444043.issue9685@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:30:16 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 21:30:16 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357507816.55.0.114183787668.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28600/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:30:46 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jan 2013 21:30:46 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1357480758.84.0.686871679817.issue12939@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I don't like the idea of a specific I/O module for an OS. Is the public API different? Can't you reuse the io module? Le 6 janv. 2013 14:59, "Richard Oudkerk" a ?crit : > > Richard Oudkerk added the comment: > > Attached is a patch which adds a winio module which is a replacement for > io, but uses windows handles instead of fds. > > It reimplements FileIO and open(), and provides openhandle() and > closehandle() as replacements for os.open() and os.close(). > > test_io has been modified to exercise winio (in addition to _io and _pyio) > and all the tests pass. > > Note that some of the implementation (openhandle(), open(), > FileIO.__init__()) is still done in Python rather than C. > > ---------- > keywords: +patch > Added file: http://bugs.python.org/file28590/winfileio.patch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:30:48 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 21:30:48 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357507848.98.0.674143724594.issue16876@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Updated to reflect Richard's comment. ---------- Added file: http://bugs.python.org/file28601/epoll_realloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 22:36:13 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 06 Jan 2013 21:36:13 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357433950.15.0.97433595896.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > If you don't want to change the API back to separate register_*() methods for readers and writers, perhaps you can add a method that tells me, for a given fileobj, whether it is registered, and with which poll flags (SELECT_IN/OUT/both) and the user data. > > Also, I need a method that gives me the number of registered FDs. Does that look OK? def get_info(self, fileobj): """Return information about a registered file object. Returns: (events, data) associated to this file object Raises KeyError if the file object is not registered. """ def registered_count(self): """Return the number of registered file objects. Returns: number of currently registered file objects """ ---------- Added file: http://bugs.python.org/file28602/selector-6.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff --git a/Lib/select.py b/Lib/select.py new file mode 100644 --- /dev/null +++ b/Lib/select.py @@ -0,0 +1,309 @@ +"""Select module. + +This module supports asynchronous I/O on multiple file descriptors. +""" + + +from _select import * + + +# generic events, that must be mapped to implementation-specific ones +# read event +SELECT_IN = (1 << 0) +# write event +SELECT_OUT = (1 << 1) + + +def _fileobj_to_fd(fileobj): + """Return a file descriptor from a file object. + + Parameters: + fileobj -- file descriptor, or any object with a `fileno()` method + + Returns: + corresponding file descriptor + """ + if isinstance(fileobj, int): + fd = fileobj + else: + try: + fd = int(fileobj.fileno()) + except (ValueError, TypeError): + raise ValueError("Invalid file object: {!r}".format(fileobj)) + return fd + + +class _Key: + """Object used internally to associate a file object to its backing file + descriptor, selected event mask and attached data.""" + + def __init__(self, fileobj, events, data=None): + self.fileobj = fileobj + self.fd = _fileobj_to_fd(fileobj) + self.events = events + self.data = data + + +class _BaseSelector: + """Base selector class. + + A selector supports registering file objects to be monitored for specific + I/O events. + + A file object is a file descriptor or any object with a `fileno()` method. + An arbitrary object can be attached to the file object, which can be used + for example to store context information, a callback, etc. + + A selector can use various implementations (select(), poll(), epoll()...) + depending on the platform. The default `Selector` class uses the most + performant implementation on the current platform. + """ + + def __init__(self): + # this maps file descriptors to keys + self._fd_to_key = {} + # this maps file objects to keys - for fast (un)registering + self._fileobj_to_key = {} + + def register(self, fileobj, events, data=None): + """Register a file object. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + if (not events) or (events & ~(SELECT_IN|SELECT_OUT)): + raise ValueError("Invalid events: {}".format(events)) + + if fileobj in self._fileobj_to_key: + raise ValueError("{!r} is already registered".format(fileobj)) + + key = _Key(fileobj, events, data) + self._fd_to_key[key.fd] = key + self._fileobj_to_key[fileobj] = key + return key + + def unregister(self, fileobj): + """Unregister a file object. + + Parameters: + fileobj -- file object + """ + try: + key = self._fileobj_to_key[fileobj] + del self._fd_to_key[key.fd] + del self._fileobj_to_key[fileobj] + except KeyError: + raise ValueError("{!r} is not registered".format(fileobj)) + return key + + def modify(self, fileobj, events, data=None): + """Change a registered file object monitored events or attached data. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + self.unregister(fileobj) + self.register(fileobj, events, data) + + def select(self, timeout=None): + """Perform the actual selection, until some monitored file objects are + ready or a timeout expires. + + Parameters: + timeout -- if timeout > 0, this specifies the maximum wait time, in + seconds + if timeout == 0, the select() call won't block, and will + report the currently ready file objects + if timeout is None, select() will block until a monitored + file object becomes ready + + Returns: + list of (fileobj, events, attached data) for ready file objects + `events` is a bitwise mask of SELECT_IN|SELECT_OUT + """ + raise NotImplementedError() + + def close(self): + """Close the selector. + + This must be called to make sure that any underlying resource is freed. + """ + self._fd_to_key.clear() + self._fileobj_to_key.clear() + + def get_info(self, fileobj): + """Return information about a registered file object. + + Returns: + (events, data) associated to this file object + + Raises KeyError if the file object is not registered. + """ + try: + key = self._fileobj_to_key[fileobj] + except KeyError: + raise KeyError("{} is not registered".format(fileobj)) + return key.events, key.data + + def registered_count(self): + """Return the number of registered file objects. + + Returns: + number of currently registered file objects + """ + return len(self._fd_to_key) + + def __enter__(self): + return self + + def __exit__(self, *args): + self.close() + + def _key_from_fd(self, fd): + """Return the key associated to a given file descriptor. + + Parameters: + fd -- file descriptor + + Returns: + corresponding key + """ + try: + return self._fd_to_key[fd] + except KeyError: + raise RuntimeError("No key found for fd {}".format(fd)) + + +class SelectSelector(_BaseSelector): + """Select-based selector.""" + + def __init__(self): + super().__init__() + self._readers = set() + self._writers = set() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + if events & SELECT_IN: + self._readers.add(key.fd) + if events & SELECT_OUT: + self._writers.add(key.fd) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._readers.discard(key.fd) + self._writers.discard(key.fd) + + def select(self, timeout=None): + r, w, _ = select(self._readers, self._writers, [], timeout) + r = set(r) + w = set(w) + ready = [] + for fd in r | w: + events = 0 + if fd in r: + events |= SELECT_IN + if fd in w: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + +class PollSelector(_BaseSelector): + """Poll-based selector.""" + + def __init__(self): + super().__init__() + self._poll = poll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + poll_events = 0 + if events & SELECT_IN: + poll_events |= POLLIN + if events & SELECT_OUT: + poll_events |= POLLOUT + self._poll.register(key.fd, poll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._poll.unregister(key.fd) + + def select(self, timeout=None): + timeout = None if timeout is None else int(1000 * timeout) + ready = [] + for fd, event in self._poll.poll(timeout): + events = 0 + if event & (POLLERR|POLLNVAL): + # in case of error, signal read and write ready + events |= SELECT_IN|SELECT_OUT + else: + if event & (POLLIN|POLLHUP): + # in case of hangup, signal read ready + events |= SELECT_IN + if event & POLLOUT: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + +class EpollSelector(_BaseSelector): + """Epoll-based selector.""" + + def __init__(self): + super().__init__() + self._epoll = epoll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + epoll_events = 0 + if events & SELECT_IN: + epoll_events |= EPOLLIN + if events & SELECT_OUT: + epoll_events |= EPOLLOUT + self._epoll.register(key.fd, epoll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._epoll.unregister(key.fd) + + def select(self, timeout=None): + timeout = -1 if timeout is None else timeout + ready = [] + for fd, event in self._epoll.poll(timeout, self.registered_count()): + events = 0 + if event & EPOLLERR: + # in case of error, signal read and write ready + events |= SELECT_IN|SELECT_OUT + else: + if event & (EPOLLIN|EPOLLHUP): + # in case of hangup, signal read ready + events |= SELECT_IN + if event & EPOLLOUT: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + def close(self): + super().close() + self._epoll.close() + + +# Choose the best implementation: roughly, epoll|kqueue > poll > select. +# select() also can't accept a FD > FD_SETSIZE (usually around 1024) +if 'epoll' in globals(): + Selector = EpollSelector +elif 'poll' in globals(): + Selector = PollSelector +else: + Selector = SelectSelector diff --git a/Lib/test/test_select.py b/Lib/test/test_select.py --- a/Lib/test/test_select.py +++ b/Lib/test/test_select.py @@ -1,10 +1,25 @@ import errno import os +import random import select import sys import unittest from test import support +try: + import resource +except ImportError: + resource = None + + +def find_ready_matching(ready, flag): + match = [] + for fd, mode, data in ready: + if mode & flag: + match.append(fd) + return match + + @unittest.skipIf((sys.platform[:3]=='win'), "can't easily test on this system") class SelectTestCase(unittest.TestCase): @@ -75,9 +90,250 @@ a[:] = [F()] * 10 self.assertEqual(select.select([], a, []), ([], a[:5], [])) + +class BasicSelectorTestCase(unittest.TestCase): + + def test_constants(self): + select.SELECT_IN + select.SELECT_OUT + + +class BaseSelectorTestCase(unittest.TestCase): + + def test_error_conditions(self): + s = self.SELECTOR() + self.assertRaises(TypeError, s.register) + self.assertRaises(TypeError, s.register, 0) + self.assertRaises(ValueError, s.register, 0, 18) + self.assertRaises(TypeError, s.unregister, 0, 1) + self.assertRaises(TypeError, s.modify, 0) + self.assertRaises(TypeError, s.select, 0, 1) + + def test_basic(self): + with self.SELECTOR() as s: + rd, wr = os.pipe() + wro = os.fdopen(os.dup(wr), "wb") + self.addCleanup(os.close, rd) + self.addCleanup(os.close, wr) + self.addCleanup(wro.close) + + # test without attached data + s.register(wr, select.SELECT_OUT) + self.assertEqual(set(((wr, select.SELECT_OUT, None),)), set(s.select())) + + # test with attached data + s.unregister(wr) + s.register(wr, select.SELECT_OUT, sys.stdin) + self.assertEqual(set(((wr, select.SELECT_OUT, sys.stdin),)), set(s.select())) + + # test with file object + s.register(wro, select.SELECT_OUT) + self.assertEqual(set(((wro, select.SELECT_OUT, None), + (wr, select.SELECT_OUT, sys.stdin))), set(s.select())) + s.unregister(wro) + + # modify + s.modify(wr, select.SELECT_OUT, sys.stdout) + self.assertEqual(set(((wr, select.SELECT_OUT, sys.stdout),)), set(s.select())) + + # test timeout + s.register(rd, select.SELECT_IN, sys.stdin) + s.unregister(wr) + self.assertFalse(s.select(0.1)) + s.register(wr, select.SELECT_OUT) + self.assertEqual(set(((wr, select.SELECT_OUT, None),)), + set(s.select(0.1))) + + # registering twice should raise an error + self.assertRaises(ValueError, s.register, wr, select.SELECT_OUT) + + # test get_info() + self.assertEquals((select.SELECT_OUT, None), s.get_info(wr)) + self.assertEquals((select.SELECT_IN, sys.stdin), s.get_info(rd)) + self.assertRaises(KeyError, s.get_info, wro) + + s.unregister(rd) + s.unregister(wr) + + # test registered_count() + self.assertEquals(0, s.registered_count()) + s.register(rd, select.SELECT_IN) + s.register(wr, select.SELECT_OUT) + self.assertEquals(2, s.registered_count()) + s.modify(wr, select.SELECT_OUT, sys.stdout) + self.assertEquals(2, s.registered_count()) + s.unregister(rd) + s.unregister(wr) + self.assertEquals(0, s.registered_count()) + + # unregistering twice should raise an error + self.assertRaises(ValueError, s.unregister, wr) + + def test_selector(self): + s = self.SELECTOR() + self.addCleanup(s.close) + + NUM_PIPES = 12 + MSG = b" This is a test." + MSG_LEN = len(MSG) + readers = [] + writers = [] + r2w = {} + w2r = {} + + for i in range(NUM_PIPES): + rd, wr = os.pipe() + s.register(rd, select.SELECT_IN) + s.register(wr, select.SELECT_OUT) + readers.append(rd) + writers.append(wr) + r2w[rd] = wr + w2r[wr] = rd + + bufs = [] + + while writers: + ready = s.select() + ready_writers = find_ready_matching(ready, select.SELECT_OUT) + if not ready_writers: + self.fail("no pipes ready for writing") + wr = random.choice(ready_writers) + os.write(wr, MSG) + + ready = s.select() + ready_readers = find_ready_matching(ready, select.SELECT_IN) + if not ready_readers: + self.fail("no pipes ready for reading") + self.assertEqual([w2r[wr]], ready_readers) + rd = ready_readers[0] + buf = os.read(rd, MSG_LEN) + self.assertEqual(len(buf), MSG_LEN) + bufs.append(buf) + os.close(r2w[rd]) ; os.close(rd) + s.unregister(r2w[rd]) + s.unregister(rd) + writers.remove(r2w[rd]) + + self.assertEqual(bufs, [MSG] * NUM_PIPES) + + def test_timeout(self): + s = self.SELECTOR() + self.addCleanup(s.close) + + cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done' + p = os.popen(cmd, 'r') + s.register(p.fileno(), select.SELECT_IN, p) + + for tout in (0, 1, 2, 4, 8, 16) + (None,)*10: + if support.verbose: + print('timeout =', tout) + + ready = s.select(tout) + if not ready: + continue + if set(ready) == set(((p.fileno(), select.SELECT_IN, p),)): + line = p.readline() + if support.verbose: + print(repr(line)) + if not line: + if support.verbose: + print('EOF') + break + continue + self.fail('Unexpected return values from select(): %r' % ready) + p.close() + + def test_below_fd_setsize(self): + # No implementation should have a problem with less than FD_SETSIZE file + # descriptors. To be conservative, let's say 64. + NUM_FDS = 64 + + r, w = os.pipe() + self.addCleanup(os.close, r) + self.addCleanup(os.close, w) + + with self.SELECTOR() as s: + for i in range(NUM_FDS): + fd = os.dup(w) + self.addCleanup(os.close, fd) + + s.register(fd, select.SELECT_OUT) + self.assertEquals(NUM_FDS, len(s.select())) + + +class ScalableSelectorTestCase: + + # a mixin to test selector scalability + + @unittest.skipUnless(resource, "Test needs resource module") + def test_above_fd_setsize(self): + # A scalable implementation should have no problem with more than + # FD_SETSIZE file descriptors. Since we don't know the value, we just + # try to set the soft RLIMIT_NOFILE to the hard RLIMIT_NOFILE ceiling. + try: + soft, hard = resource.getrlimit(resource.RLIMIT_NOFILE) + resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard)) + self.addCleanup(resource.setrlimit, resource.RLIMIT_NOFILE, + (soft, hard)) + NUM_FDS = hard + except OSError: + NUM_FDS = soft + + # guard for already allocated FDs (stdin, stdout...) + NUM_FDS -= 16 + + r, w = os.pipe() + self.addCleanup(os.close, r) + self.addCleanup(os.close, w) + + with self.SELECTOR() as s: + for i in range(NUM_FDS): + try: + fd = os.dup(w) + except OSError as e: + if e.errno == errno.EMFILE: + # too many FD, skip + self.skipTest("FD limit reached") + raise + + self.addCleanup(os.close, fd) + s.register(fd, select.SELECT_OUT) + + self.assertEquals(NUM_FDS, len(s.select())) + + + at unittest.skipIf((sys.platform[:3]=='win'), + "can't easily test on this system") +class SelectorTestCase(BaseSelectorTestCase): + + SELECTOR = select.Selector + + +class SelectSelectorTestCase(BaseSelectorTestCase): + + SELECTOR = select.SelectSelector + + + at unittest.skipUnless(hasattr(select, 'poll'), "Test needs select.poll()") +class PollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorTestCase): + + SELECTOR = select.PollSelector + + + at unittest.skipUnless(hasattr(select, 'epoll'), "Test needs select.epoll()") +class EpollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorTestCase): + + SELECTOR = select.EpollSelector + + def test_main(): - support.run_unittest(SelectTestCase) + tests = [SelectTestCase] + tests.extend([BasicSelectorTestCase, SelectorTestCase, + SelectSelectorTestCase, PollSelectorTestCase, + EpollSelectorTestCase]) + support.run_unittest(*tests) support.reap_children() + if __name__ == "__main__": test_main() diff --git a/Modules/selectmodule.c b/Modules/selectmodule.c --- a/Modules/selectmodule.c +++ b/Modules/selectmodule.c @@ -2129,7 +2129,7 @@ static struct PyModuleDef selectmodule = { PyModuleDef_HEAD_INIT, - "select", + "_select", module_doc, -1, select_methods, @@ -2143,7 +2143,7 @@ PyMODINIT_FUNC -PyInit_select(void) +PyInit__select(void) { PyObject *m; m = PyModule_Create(&selectmodule); diff --git a/setup.py b/setup.py --- a/setup.py +++ b/setup.py @@ -623,7 +623,7 @@ missing.append('spwd') # select(2); not on ancient System V - exts.append( Extension('select', ['selectmodule.c']) ) + exts.append( Extension('_select', ['selectmodule.c']) ) # Fred Drake's interface to the Python parser exts.append( Extension('parser', ['parsermodule.c']) ) From report at bugs.python.org Sun Jan 6 22:43:02 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Jan 2013 21:43:02 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357508582.44.0.499524808095.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I don't like the idea of a specific I/O module for an OS. Is the public API > different? It was partly to make integration with the existing tests easier: _io, _pyio and winio are tested in parallel. > Can't you reuse the io module? In what sense? I don't really know how the API should be exposed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 23:12:29 2013 From: report at bugs.python.org (Todd Rovito) Date: Sun, 06 Jan 2013 22:12:29 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357510349.79.0.639382007607.issue16868@psf.upfronthosting.co.za> Todd Rovito added the comment: I agree with Meador it should be a specific amount of time. As a beginner at contributing to Python I thought "substantial amount of time" meant one month but it depends on interpretation. I think making it very specific makes the documentation more clear. Included in the new patch are the other suggestions made by Mr. Jerdonek. Thanks for the feedback! ---------- Added file: http://bugs.python.org/file28603/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 23:29:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 22:29:46 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1357505028.82.0.847532554699.issue10156@psf.upfronthosting.co.za> Message-ID: <201301070029.25360.storchaka@gmail.com> Serhiy Storchaka added the comment: > unicode-leak.patch doesn't fix #16143 though. unicode_empty and > unicode_latin1 need to be initialized, too. Indeed. I'll upload patches tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 23:38:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 22:38:11 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357511891.99.0.350694110615.issue9685@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My apologies once again, Raymond. I mistakenly thought that I unassigned the issue from you (it was a Roundup bug at this day). As for the issue, I totally agree with Tim. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 6 23:38:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Jan 2013 22:38:39 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <1357511919.92.0.658364885743.issue16854@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 00:02:01 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 06 Jan 2013 23:02:01 +0000 Subject: [issue16878] argparse: positional args with nargs='*' defaults to [] In-Reply-To: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za> Message-ID: <1357513321.14.0.853428224677.issue16878@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I agree it would be very likely to break working code. Can you elaborate on your point about 'append' though? I'm not sure I see it. Aside from consistency, I'm wondering if there is ever a case where it would help to return None for positional arguments. For example, unlike with optional arguments, it doesn't seem like it would ever make sense to distinguish between the option being present and the option being present with no values (which is why const is needed in the optional case). In other words, there is no loss of information by returning []. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 01:51:54 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 Jan 2013 00:51:54 +0000 Subject: [issue16878] argparse: positional args with nargs='*' defaults to [] In-Reply-To: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za> Message-ID: <1357519914.21.0.754775350458.issue16878@psf.upfronthosting.co.za> R. David Murray added the comment: >>> p.add_argument('-a', action="append", default=None) >>> p.parse_args([]) Namespace(a=None) >>> p.parse_args(['-a', '1', '-a', '2']) Namespace(a=['1', '2']) So there's a logical correspondence there (repeated option vs multiple values, each producing a list). I'm not sure what you mean by the difference between options and positionals. I note that you can use nargs with an optional, and in that case the default works, which is even more unfortunate than the difference with 'append'. But if you can articulate a logical difference between optionals and positional here, maybe we can make it look reasonable :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 02:04:31 2013 From: report at bugs.python.org (Ian Shields) Date: Mon, 07 Jan 2013 01:04:31 +0000 Subject: [issue16877] Odd behavior of ~ in os.path.abspath and os.path.realpath In-Reply-To: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za> Message-ID: <1357520671.7.0.582574600827.issue16877@psf.upfronthosting.co.za> Ian Shields added the comment: I think that's an excellent resolution to the problem. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 02:47:48 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 07 Jan 2013 01:47:48 +0000 Subject: [issue16878] argparse: positional args with nargs='*' defaults to [] In-Reply-To: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za> Message-ID: <1357523268.03.0.846318905725.issue16878@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I was referring to the fact that optionals have an additional case that positionals don't have: "Note that for optional arguments, there is an additional case -- the option string is present but not followed by a command-line argument." (from http://docs.python.org/dev/library/argparse.html#nargs ) >>> p.add_argument('--foo', nargs='*', default=None) >>> p.parse_args([]) Namespace(foo=None) >>> p.parse_args(['--foo']) Namespace(foo=[]) So it could be argued that positionals (at least by default) are behaving like the second case. But that's as far as the parallel goes apparently. *default* affects the first case and not the second case for optional arguments: >>> p.add_argument('--foo', nargs='*', default=False) >>> p.parse_args([]) Namespace(foo=False) >>> p.parse_args(['--foo']) Namespace(foo=[]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 03:46:45 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2013 02:46:45 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357526805.91.0.0874780324788.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: This seems okay. I am attaching the changes I had to make to Tulip to support this. However, two Tulip tests are now failing: - tulip.events_test.PollEventLoopTests.testCreateSslTransport fails with spurious file descriptors returned by poll() that aren't in the _fd_to_key dict (but the corresponding test with Select passes) - test_sock_client_fail() hangs completely. Can you see why? The first failure has this traceback: Traceback (most recent call last): File "/Users/guido/tulip/tulip/selectors.py", line 178, in _key_from_fd return self._fd_to_key[fd] KeyError: 0 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/guido/tulip/tulip/events_test.py", line 216, in testCreateSslTra\ nsport el.run() File "/Users/guido/tulip/tulip/unix_events.py", line 120, in run self._run_once() File "/Users/guido/tulip/tulip/unix_events.py", line 592, in _run_once event_list = self._selector.select(timeout) File "/Users/guido/tulip/tulip/selectors.py", line 255, in select key = self._key_from_fd(fd) File "/Users/guido/tulip/tulip/selectors.py", line 180, in _key_from_fd raise RuntimeError("No key found for fd {}".format(fd)) RuntimeError: No key found for fd 0 (But the fd value varies -- sometimes it is -2, sometimes a large number.) The other test busy-loops (keeps polling) and I have no useful traceback. Also notice the need for a third constant, SELECT_CONNECT. For details see the class WindowsPollPollster in the Tulip code. ---------- hgrepos: +167 Added file: http://bugs.python.org/file28604/tulip-selectors-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 03:59:13 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2013 02:59:13 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357527553.11.0.359716466909.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: Maybe I should explain the need for SELECT_CONNECT more. This is necessary so that on Windows the PollSelector can use WSAPoll(). The reason is that for async connect() calls, WSAPoll() doesn't return the FD as writable, just as having an exception. I didn't write the code (Richard Oudkerk did), and I've never run it (no access to Windows), but the workaround for the problem with WSAPoll() is apparently quite complex: http://code.google.com/p/tulip/source/browse/tulip/unix_events.py#236 The long and short of it is that portable code must use add_connector() and remove_connector() instead of add_writer() and remove_writer() for async connect() calls. So these need to be mapped to something different in the selector world. The right thing would seem to add a separate flag, SELECT_CONNECT, with a value distinct from SELECT_IN and SELECT_OUT. But I didn't write the code for that -- I made a hackish change so that the selector code exports SELECT_CONNECT as an alias for SELECT_OUT. I did write code for add_connector() and remove_connector() but these may have to be modified slightly again later once the selector code has SELECT_OUT != SELECT_CONNECT. Please do try to understand this -- it would not be possible to support WSAPoll() at all without distinguishing between write and connect readyness. Feel free to ping Richard Oudkerk (shibturn at gmail.com) for more information. I don't *think* the problems are in my code, since both tests pass when the SelectSelector is used. I can currently only test on OSX 10.7 (Mountain Lion); hopefully I have more platforms after tomorrow (my first day at the new job). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 04:00:36 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Jan 2013 03:00:36 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357527636.33.0.459908311616.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: (Adding Richard Oudkerk to the nosy list as I am pleading here for support of WSAPoll(), see last few messages.) ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 05:58:09 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Mon, 07 Jan 2013 04:58:09 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357534689.15.0.312196339878.issue16076@psf.upfronthosting.co.za> Daniel Shahaf added the comment: Eli Bendersky wrote on Thu, Jan 03, 2013 at 14:44:02 +0000: > If this change is required (even if we choose to name it > "xml.etree.ElementTree.Element" for Py compatibility to fix the pickling > regression, we may find ourselves in a need to change it between 3.3 and > 3.3.1 and I'm not sure if that's valid. I hope my question on pydev will be > resolved conclusively. > > Danial, could you investigate if such a change is absolutely required to > make pickling/unickling of Element work? There are a few options: - Change c-Element's tp_name to "xml.etree.ElementTree.Element". - Register a reduce function for c-Element's that serialises them by constructing an equivalent py-Element and returning the latter's .__dict__ via the third return value: http://docs.python.org/3/library/copyreg#copyreg.pickle - Add an entry mapping "builtins.Element" to "xml.etree.ElementTree.Element" to _compat_pickle.IMPORT_MAPPING (which is used by Lib/pickle.py:_Pickler.find_class()). I haven't tried to implement either of these approaches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 06:16:22 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 07 Jan 2013 05:16:22 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357535782.82.0.375149671088.issue16076@psf.upfronthosting.co.za> Eli Bendersky added the comment: I think that changing the _elementtree's Element's name to match the Python version, and then making sure the same serialized object is returned - is a worthy option to try. Then it will hopefully "just work". When pickle deserializes a user-defined object that says it's a xml.etree.ElementTree.Element, it will try to import Element from xml.etree.ElementTree and should get the accelerated class. On machines without acceleration it will get the Python class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 06:47:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 Jan 2013 05:47:58 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357537678.03.0.870414496305.issue16868@psf.upfronthosting.co.za> Ezio Melotti added the comment: A month sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 07:09:28 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 Jan 2013 06:09:28 +0000 Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches nothing. Ditto B and Z. In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za> Message-ID: <1357538968.27.0.788441315353.issue13899@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 07:24:34 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 Jan 2013 06:24:34 +0000 Subject: [issue16154] Some minor doc fixes in Doc/library In-Reply-To: <1349562325.82.0.0767622542031.issue16154@psf.upfronthosting.co.za> Message-ID: <1357539874.65.0.696904853302.issue16154@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 07:25:28 2013 From: report at bugs.python.org (Isaac (.ike) Levy) Date: Mon, 07 Jan 2013 06:25:28 +0000 Subject: [issue16882] Python 2.7 has 73 files with hard references to /usr/local when building on *NIX Message-ID: <1357539928.45.0.253239442495.issue16882@psf.upfronthosting.co.za> New submission from Isaac (.ike) Levy: There are currently 73 files with hard-coded references to /usr/local, To see what I'm talking about, unpack a source Python tarball, and check it out like so: # cd Python-2.7.3 # grep -Rl '\/usr\/local' ./* | wc -l 73 To read more detail, # grep -R '\/usr\/local' ./* Some of these hardcoded /usr/local lines are innocuous or merely misleading, ./README: 1) CONFIG_SHELL=/usr/local/bin/bash CC=cc RANLIB=: \ - or - ./Demo/tkinter/guido/ManPage.py: MANDIR = '/usr/local/man/mann' Yet, some of these create unexpected installation behavior when configuring using the --prefix flag to specify an alternative install location, ./setup.py: # Ensure that /usr/local is always used - or- ./setup.py: db_inc_paths.append('/usr/local/BerkeleyDB.4.%d/include' % x) (Are items installed outside of your --prefix? Which ones? What about dependencies compiled outside of /usr/local?) ################### A terrible solution It seems most UNIX package managers elect some form of finding and replace all occurances, for example, # dirty deeds, done dirt cheap for i in `grep -Rl '\/usr\/local' ./*` ; do safe sed -i 's#\/usr\/local#\/usr\/mypath#g' "$i" done ./configure --prefix="/usr/mypath" ...continue the make dance... ################# A better solution Prioritize some re-factoring work Python 2.7.3 installation, just enough to get sysadmins like myself by until Python3000 is commonplace... I'd be happy to help, but as a community outsider, I'm not sure how to make the cleanup work stick. ---------- components: Installation messages: 179246 nosy: ikeaxial priority: normal severity: normal status: open title: Python 2.7 has 73 files with hard references to /usr/local when building on *NIX type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 07:29:16 2013 From: report at bugs.python.org (Isaac (.ike) Levy) Date: Mon, 07 Jan 2013 06:29:16 +0000 Subject: [issue16883] "--enable-shared" during configure forces "2.7.3" to build as "2.7.2+" on Ubuntu 11.10 Message-ID: <1357540156.49.0.232787491234.issue16883@psf.upfronthosting.co.za> New submission from Isaac (.ike) Levy: Host OS: Ubuntu 11.10 (oneiric) --enable-shared flag during configure forces 2.7.3 to build as 2.7.2+ TO REPLICATE: unpack Python tarball, # cd Python-2.7.3/ # ./configure --enable-shared # make # ./python -V 2.7.2+ # make clean ; ./configure --enable-shared ; make ; ./python -V 2.7.3 -- Additionally, 2.7.2+ build seems to carry over a resolved urandom issue, # (post-install on Ubuntu 11.10) # /usr/local/bin/python Python 2.7.2+ (default, Oct 4 2011, 20:41:12) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from os import urandom Traceback (most recent call last): File "", line 1, in ImportError: cannot import name urandom >>> ---------- components: Installation messages: 179247 nosy: ikeaxial priority: normal severity: normal status: open title: "--enable-shared" during configure forces "2.7.3" to build as "2.7.2+" on Ubuntu 11.10 type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 09:40:53 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Jan 2013 08:40:53 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357548053.46.0.0887117744757.issue9685@psf.upfronthosting.co.za> Mark Dickinson added the comment: Given the responses so far, I suggest closing this as rejected. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 10:00:06 2013 From: report at bugs.python.org (Benno Leslie) Date: Mon, 07 Jan 2013 09:00:06 +0000 Subject: [issue16866] libainstall doesn't create $(BINDIR) directory In-Reply-To: <1357357650.4.0.164255645189.issue16866@psf.upfronthosting.co.za> Message-ID: <1357549206.63.0.905219639425.issue16866@psf.upfronthosting.co.za> Benno Leslie added the comment: In a similar manner the bininstall target relies on $(LIBPC), but does not create that. This makes me consider if the libainstall target should be installing pkg-config sciprt at all (and whether bininstall should be installing the .pc files). It is hard for me to determine what the exact intended goals of each of these targets is, so I can't really come up with the right fix. Naively for both targets ensuring that the directory exists solves the symptom, but to be it looks like there is probably a greater underlying thing to determine here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 10:10:28 2013 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2013 09:10:28 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357549828.44.0.559013003865.issue9685@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm not too worried about the slightly increased memory usage. For example one of our largest application instances consumes about 8 GB memory right now. It has just about 22k tuples in gc.get_objects(). An additional Py_hash_t in tuple's struct would increase the memory usage by less than 200kB. I've attached a simple patch. ---------- keywords: +patch nosy: +christian.heimes stage: needs patch -> patch review Added file: http://bugs.python.org/file28605/tuplehash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 10:14:47 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 07 Jan 2013 09:14:47 +0000 Subject: [issue16883] "--enable-shared" during configure forces "2.7.3" to build as "2.7.2+" on Ubuntu 11.10 In-Reply-To: <1357540156.49.0.232787491234.issue16883@psf.upfronthosting.co.za> Message-ID: <1357550087.2.0.241722943065.issue16883@psf.upfronthosting.co.za> Ned Deily added the comment: You need to be careful when using a Python with --enable-shared to ensure that the correct dynamic libraries are being used at execution time. Normally, after a "make", you use "make install" to install the Python executable and the shared library into the configured locations, by default in /usr/local. If you try to run a --enable-shared python executable from its build directory, you'll need to tell the dynamic loader where to find the shared library, i.e. the build directory itself. One way to do that is to use the LD_LIBRARY_PATH environment variable. Otherwise, the dynamic loader will search the standard paths, like /usr/local/lib/ and /usr/lib/ for a shared library with the proper name (like libpython2.7.so.1.0). If there is an older Python already installed with that name and if the ABI hasn't changed too much, you may be lucky and it will load and run. In your example, you undoubtedly had a Python 2.7.2+ already installed in either /usr or /usr/local. In this example, I have a shared 2.7.3rc2 installed in /usr/bin and am building a 2.7.3: $ ./configure --enable-shared ; make $ /usr/bin/python2.7 -V Python 2.7.3rc2 $ ./python -V Python 2.7.3rc2 $ LD_LIBRARY_PATH=. ./python -V Python 2.7.3 The "make clean" and rebuild step you show makes no difference by itself. Without installing or setting the library search path, the older installed library will still be picked up. What likely happened is that you did a "make install" in between the two steps. ---------- nosy: +ned.deily resolution: -> invalid stage: -> committed/rejected status: open -> closed type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 10:31:26 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 09:31:26 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357526805.91.0.0874780324788.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Also notice the need for a third constant, SELECT_CONNECT. For details see the class WindowsPollPollster in the Tulip code. I'll trust Richard on all Windows matter, so if you need a SELECT_CONNECT constant, I'll expose one. > However, two Tulip tests are now failing: I can't reproduce those failures on Linux (I had to adapt the hostnames because I'm at work and my test machine can't access the internet, but otherwise everything is the same). All tests pass with select, poll and epoll. Note that I had to fix a typo in the patch: EPollSelector -> EpollSelector. > - tulip.events_test.PollEventLoopTests.testCreateSslTransport fails with spurious file descriptors returned by poll() that aren't in the _fd_to_key dict (but the corresponding test with Select passes) > > The first failure has this traceback: > > Traceback (most recent call last): > File "/Users/guido/tulip/tulip/selectors.py", line 178, in _key_from_fd > return self._fd_to_key[fd] > KeyError: 0 > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "/Users/guido/tulip/tulip/events_test.py", line 216, in testCreateSslTra\ > nsport > el.run() > File "/Users/guido/tulip/tulip/unix_events.py", line 120, in run > self._run_once() > File "/Users/guido/tulip/tulip/unix_events.py", line 592, in _run_once > event_list = self._selector.select(timeout) > File "/Users/guido/tulip/tulip/selectors.py", line 255, in select > key = self._key_from_fd(fd) > File "/Users/guido/tulip/tulip/selectors.py", line 180, in _key_from_fd > raise RuntimeError("No key found for fd {}".format(fd)) > RuntimeError: No key found for fd 0 > > (But the fd value varies -- sometimes it is -2, sometimes a large number.) This failure is really weird, because the file descriptor is really just the value returned by poll.poll(): I don't know how this could possibly ever be negative, unless some sort of overflow in the poll.poll() code itself? I can however see why the previous version wouldn't fail: """ for fd, flags in self._poll.poll(msecs): if flags & ~select.POLLOUT: if fd in self.readers: events.append(self.readers[fd]) if flags & ~select.POLLIN: if fd in self.writers: events.append(self.writers[fd]) """ If a spurious fd is reported, it's silently ignored. The second test runs fine on Linux, and from a cursory look, I don't see how it could fail (the socket should be reported as write ready upon ECONNREFUSED). I'll try running the exact test case with the same hostnames from home, but I doubt it'll make a difference, so maybe it's really OS-X specific (if there's strace/dtrace on OS-X, it'll help see what's going on). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 10:54:53 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 07 Jan 2013 09:54:53 +0000 Subject: [issue16882] Python 2.7 has 73 files with hard references to /usr/local when building on *NIX In-Reply-To: <1357539928.45.0.253239442495.issue16882@psf.upfronthosting.co.za> Message-ID: <1357552493.6.0.821717499883.issue16882@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for your suggestion. However, the issue you've created is too wide in scope to be actionable. As you note, just because the string "/usr/local" appears in a file within the Python source distribution does not indicate a problem. Many of the cites are in documentation or examples where it is noted or understood that the correct path will need to be supplied or is supplied when the file is actually built and installed. The one real related issue I am aware of is that the main setup.py, which is used to build the standard library components, does have some hardwired sets of paths, usually including /usr/local, to find necessary third-party libraries and setup.py does not always provide a consistent way to augment those paths. This is also an issue for cross-compiling Python for other environments. There are various issues open regarding this, for example, Issue5575 "Add env vars for controlling building sqlite, hashlib and ssl". I would suggest contributing to those issues by creating or reviewing and testing existing patches. Also note that Python 2.7.x is open for bug fixes; new features are generally only accepted for the next major release, currently expected to be Python 3.4. Unless there are more specific items that are not already covered in another issue, I am inclined to close this one. ---------- nosy: +ned.deily status: open -> pending type: compile error -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 10:59:45 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 Jan 2013 09:59:45 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357552785.68.0.287729835845.issue9685@psf.upfronthosting.co.za> Georg Brandl added the comment: Still, actual benefits in some kind of benchmark will be needed to show that this is not a premature optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 11:50:13 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 10:50:13 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > The second test runs fine on Linux, and from a cursory look, I don't > see how it could fail (the socket should be reported as write ready > upon ECONNREFUSED). Hum, thinking about it, I wonder is OS-X doesn't report POLLPRI or some other esoteric event in case of ECONNREFUSED... Could you try the patch attached? ---------- Added file: http://bugs.python.org/file28606/selector_poll_events.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- --- tulip/selectors.py.orig 2013-01-07 11:33:56.035521000 +0100 +++ tulip/selectors.py 2013-01-07 11:46:04.351542000 +0100 @@ -242,15 +242,10 @@ ready = [] for fd, event in self._poll.poll(timeout): events = 0 - if event & (POLLERR|POLLNVAL): - # in case of error, signal read and write ready - events |= SELECT_IN|SELECT_OUT - else: - if event & (POLLIN|POLLHUP): - # in case of hangup, signal read ready - events |= SELECT_IN - if event & POLLOUT: - events |= SELECT_OUT + if event & ~POLLOUT: + events |= SELECT_IN + if event & ~POLLIN: + events |= SELECT_OUT key = self._key_from_fd(fd) ready.append((key.fileobj, events, key.data)) @@ -282,15 +277,10 @@ ready = [] for fd, event in self._epoll.poll(timeout, self.registered_count()): events = 0 - if event & EPOLLERR: - # in case of error, signal read and write ready - events |= SELECT_IN|SELECT_OUT - else: - if event & (EPOLLIN|EPOLLHUP): - # in case of hangup, signal read ready - events |= SELECT_IN - if event & EPOLLOUT: - events |= SELECT_OUT + if event & ~EPOLLOUT: + events |= SELECT_IN + if event & ~EPOLLIN: + events |= SELECT_OUT key = self._key_from_fd(fd) ready.append((key.fileobj, events, key.data)) From report at bugs.python.org Mon Jan 7 12:28:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 11:28:43 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1357505028.82.0.847532554699.issue10156@psf.upfronthosting.co.za> Message-ID: <201301071328.03031.storchaka@gmail.com> Serhiy Storchaka added the comment: Here are patches for all four Python versions. They fixes possible usage of the followed non-initialized global variables: free_list, numfree, interned, unicode_empty, static_strings, unicode_latin1, bloom_linebreak, unicode_default_encoding. ---------- Added file: http://bugs.python.org/file28607/unicode_globals-2.7.patch Added file: http://bugs.python.org/file28608/unicode_globals-3.2.patch Added file: http://bugs.python.org/file28609/unicode_globals-3.3.patch Added file: http://bugs.python.org/file28610/unicode_globals-3.4.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 0f24c65fb7e5 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sat Jan 05 07:37:47 2013 +0200 +++ b/Objects/unicodeobject.c Mon Jan 07 13:26:16 2013 +0200 @@ -93,15 +93,26 @@ #endif /* Free list for Unicode objects */ -static PyUnicodeObject *free_list; -static int numfree; +static PyUnicodeObject *free_list = NULL; +static int numfree = 0; /* The empty Unicode object is shared to improve performance. */ -static PyUnicodeObject *unicode_empty; +static PyUnicodeObject *unicode_empty = NULL; + +#define _Py_RETURN_UNICODE_EMPTY() do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = _PyUnicode_New(0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + return (PyObject *)unicode_empty; \ + } while (0) /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyUnicodeObject *unicode_latin1[256]; +static PyUnicodeObject *unicode_latin1[256] = {NULL}; /* Default encoding to use and assume when NULL is passed as encoding parameter; it is initialized by _PyUnicode_Init(). @@ -110,7 +121,7 @@ PyUnicode_GetDefaultEncoding() APIs to access this global. */ -static char unicode_default_encoding[100]; +static char unicode_default_encoding[100 + 1] = "ascii"; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -204,7 +215,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -448,10 +459,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -497,10 +506,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single characters are shared when using this constructor. Restrict to ASCII, since the input must be UTF-8. */ @@ -1162,13 +1169,10 @@ } /* Convert to Unicode */ - if (len == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *)unicode_empty; - } - else - v = PyUnicode_Decode(s, len, encoding, errors); - + if (len == 0) + _Py_RETURN_UNICODE_EMPTY(); + + v = PyUnicode_Decode(s, len, encoding, errors); return v; onError: @@ -1381,7 +1385,7 @@ Py_DECREF(v); strncpy(unicode_default_encoding, encoding, - sizeof(unicode_default_encoding)); + sizeof(unicode_default_encoding) - 1); return 0; onError: @@ -8838,8 +8842,6 @@ void _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UNICODE linebreak[] = { 0x000A, /* LINE FEED */ @@ -8853,15 +8855,10 @@ }; /* Init the implementation */ - free_list = NULL; - numfree = 0; unicode_empty = _PyUnicode_New(0); if (!unicode_empty) return; - strcpy(unicode_default_encoding, "ascii"); - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -8906,15 +8903,11 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); + (void)PyUnicode_ClearFreeList(); } -------------- next part -------------- diff -r d2867c430333 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sat Jan 05 07:37:47 2013 +0200 +++ b/Objects/unicodeobject.c Mon Jan 07 12:57:32 2013 +0200 @@ -98,18 +98,29 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* Free list for Unicode objects */ -static PyUnicodeObject *free_list; -static int numfree; +static PyUnicodeObject *free_list = NULL; +static int numfree = 0; /* The empty Unicode object is shared to improve performance. */ -static PyUnicodeObject *unicode_empty; +static PyUnicodeObject *unicode_empty = NULL; + +#define _Py_RETURN_UNICODE_EMPTY() do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = _PyUnicode_New(0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + return (PyObject *)unicode_empty; \ + } while (0) /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyUnicodeObject *unicode_latin1[256]; +static PyUnicodeObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -214,7 +225,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -479,10 +490,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -528,10 +537,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single characters are shared when using this constructor. Restrict to ASCII, since the input must be UTF-8. */ @@ -1393,15 +1400,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *) unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -1421,12 +1424,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *) unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -8315,10 +8317,8 @@ Py_ssize_t nchars; size_t nbytes; - if (len < 1) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); if (len == 1 && PyUnicode_CheckExact(str)) { /* no repeat, return original string */ @@ -10048,8 +10048,6 @@ void _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UNICODE linebreak[] = { 0x000A, /* LINE FEED */ @@ -10063,14 +10061,10 @@ }; /* Init the implementation */ - free_list = NULL; - numfree = 0; unicode_empty = _PyUnicode_New(0); if (!unicode_empty) return; - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -10115,15 +10109,11 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); + (void)PyUnicode_ClearFreeList(); } @@ -10242,8 +10232,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } -------------- next part -------------- diff -r 13c83199c211 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sun Jan 06 16:41:56 2013 +0100 +++ b/Objects/unicodeobject.c Mon Jan 07 12:57:36 2013 +0200 @@ -179,17 +179,32 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* The empty Unicode object is shared to improve performance. */ -static PyObject *unicode_empty; +static PyObject *unicode_empty = NULL; + +#define _Py_INCREF_UNICODE_EMPTY() do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = PyUnicode_New(0, 0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + } while (0) + +#define _Py_RETURN_UNICODE_EMPTY() do { \ + _Py_INCREF_UNICODE_EMPTY(); \ + return unicode_empty; \ + } while (0) /* List of static strings. */ -static _Py_Identifier *static_strings; +static _Py_Identifier *static_strings = NULL; /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyObject *unicode_latin1[256]; +static PyObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -416,9 +431,8 @@ len = _PyUnicode_WSTR_LENGTH(unicode); if (len == 0) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (len == 1) { @@ -450,8 +464,8 @@ length = PyUnicode_GET_LENGTH(unicode); if (length == 0) { if (unicode != unicode_empty) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); + _Py_RETURN_UNICODE_EMPTY(); } return unicode_empty; } @@ -528,7 +542,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -1582,9 +1596,9 @@ return 0; if (length == 0) { + _Py_INCREF_UNICODE_EMPTY(); Py_DECREF(*p_unicode); *p_unicode = unicode_empty; - Py_INCREF(*p_unicode); return 0; } @@ -1731,10 +1745,8 @@ some optimizations which share commonly used objects. */ /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -1890,10 +1902,8 @@ PyObject *res; unsigned char max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) return get_latin1_char(u[0]); @@ -1913,10 +1923,8 @@ PyObject *res; Py_UCS2 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -1951,10 +1959,8 @@ PyObject *res; Py_UCS4 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -2246,10 +2252,8 @@ PyUnicode_FromWideChar(register const wchar_t *w, Py_ssize_t size) { if (w == NULL) { - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); PyErr_BadInternalCall(); return NULL; } @@ -3004,15 +3008,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -3032,12 +3032,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -4717,8 +4716,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* ASCII is equivalent to the first 128 ordinals in Unicode. */ @@ -5229,8 +5227,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #ifdef BYTEORDER_IS_LITTLE_ENDIAN @@ -6551,10 +6548,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* ASCII is equivalent to the first 128 ordinals in Unicode. */ if (size == 1 && (unsigned char)s[0] < 128) @@ -6933,8 +6928,7 @@ if (chunk_size == 0 && done) { if (v != NULL) break; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } @@ -9493,9 +9487,7 @@ /* If empty sequence, return u"". */ if (seqlen == 0) { Py_DECREF(fseq); - Py_INCREF(unicode_empty); - res = unicode_empty; - return res; + _Py_RETURN_UNICODE_EMPTY(); } /* If singleton sequence with an exact Unicode, return that. */ @@ -10195,7 +10187,7 @@ } new_size = slen + n * (len2 - len1); if (new_size == 0) { - Py_INCREF(unicode_empty); + _Py_INCREF_UNICODE_EMPTY(); u = unicode_empty; goto done; } @@ -11662,10 +11654,8 @@ PyErr_SetString(PyExc_IndexError, "string index out of range"); return NULL; } - if (start >= length || end < start) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (start >= length || end < start) + _Py_RETURN_UNICODE_EMPTY(); length = end - start; if (PyUnicode_IS_ASCII(self)) { @@ -11792,10 +11782,8 @@ PyObject *u; Py_ssize_t nchars, n; - if (len < 1) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); /* no repeat, return original string */ if (len == 1) @@ -12914,8 +12902,7 @@ { if (writer->pos == 0) { Py_XDECREF(writer->buffer); - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (writer->readonly) { assert(PyUnicode_GET_LENGTH(writer->buffer) == writer->pos); @@ -13133,8 +13120,7 @@ } if (slicelength <= 0) { - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } else if (start == 0 && step == 1 && slicelength == PyUnicode_GET_LENGTH(self)) { return unicode_result_unchanged(self); @@ -13964,10 +13950,8 @@ if (!PyArg_ParseTupleAndKeywords(args, kwds, "|Oss:str", kwlist, &x, &encoding, &errors)) return NULL; - if (x == NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (x == NULL) + _Py_RETURN_UNICODE_EMPTY(); if (encoding == NULL && errors == NULL) return PyObject_Str(x); else @@ -14151,9 +14135,11 @@ }; /* Init the implementation */ - unicode_empty = PyUnicode_New(0, 0); - if (!unicode_empty) - Py_FatalError("Can't create empty string"); + if (unicode_empty == NULL) { + unicode_empty = PyUnicode_New(0, 0); + if (!unicode_empty) + Py_FatalError("Can't create empty string"); + } assert(_PyUnicode_CheckConsistency(unicode_empty, 1)); for (i = 0; i < 256; i++) @@ -14197,15 +14183,10 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); _PyUnicode_ClearStaticStrings(); (void)PyUnicode_ClearFreeList(); } @@ -14334,8 +14315,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } -------------- next part -------------- diff -r b6284d2aaada Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sun Jan 06 16:14:22 2013 -0500 +++ b/Objects/unicodeobject.c Mon Jan 07 13:06:23 2013 +0200 @@ -171,17 +171,32 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* The empty Unicode object is shared to improve performance. */ -static PyObject *unicode_empty; +static PyObject *unicode_empty = NULL; + +#define _Py_INCREF_UNICODE_EMPTY() do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = PyUnicode_New(0, 0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + } while (0) + +#define _Py_RETURN_UNICODE_EMPTY() do { \ + _Py_INCREF_UNICODE_EMPTY(); \ + return unicode_empty; \ + } while (0) /* List of static strings. */ -static _Py_Identifier *static_strings; +static _Py_Identifier *static_strings = NULL; /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyObject *unicode_latin1[256]; +static PyObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -406,9 +421,8 @@ len = _PyUnicode_WSTR_LENGTH(unicode); if (len == 0) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (len == 1) { @@ -442,8 +456,8 @@ length = PyUnicode_GET_LENGTH(unicode); if (length == 0) { if (unicode != unicode_empty) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); + _Py_RETURN_UNICODE_EMPTY(); } return unicode_empty; } @@ -520,7 +534,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -1602,9 +1616,9 @@ return 0; if (length == 0) { + _Py_INCREF_UNICODE_EMPTY(); Py_DECREF(*p_unicode); *p_unicode = unicode_empty; - Py_INCREF(*p_unicode); return 0; } @@ -1727,10 +1741,8 @@ some optimizations which share commonly used objects. */ /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -1886,10 +1898,8 @@ PyObject *res; unsigned char max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) return get_latin1_char(u[0]); @@ -1909,10 +1919,8 @@ PyObject *res; Py_UCS2 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -1947,10 +1955,8 @@ PyObject *res; Py_UCS4 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -2242,10 +2248,8 @@ PyUnicode_FromWideChar(register const wchar_t *w, Py_ssize_t size) { if (w == NULL) { - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); PyErr_BadInternalCall(); return NULL; } @@ -2822,15 +2826,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -2850,12 +2850,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -4198,8 +4197,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* Start off assuming it's all ASCII. Widen later as necessary. */ @@ -4606,8 +4604,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* ASCII is equivalent to the first 128 ordinals in Unicode. */ @@ -4865,8 +4862,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #ifdef WORDS_BIGENDIAN @@ -5105,8 +5101,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #if PY_LITTLE_ENDIAN @@ -5380,10 +5375,8 @@ Py_ssize_t len; len = length_of_escaped_ascii_string(s, size); - if (len == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len == 0) + _Py_RETURN_UNICODE_EMPTY(); /* After length_of_escaped_ascii_string() there are two alternatives, either the string is pure ASCII with named escapes like \n, etc. @@ -5774,10 +5767,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Escaped strings will always be longer than the resulting Unicode string, so we start with size here and then reduce the @@ -5981,10 +5972,8 @@ 1)) return NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* XXX overflow detection missing */ _PyUnicodeWriter_Init(&writer, 0); @@ -6432,10 +6421,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* ASCII is equivalent to the first 128 ordinals in Unicode. */ if (size == 1 && (unsigned char)s[0] < 128) @@ -6813,8 +6800,7 @@ if (chunk_size == 0 && done) { if (v != NULL) break; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } @@ -7291,10 +7277,8 @@ if (mapping == NULL) return PyUnicode_DecodeLatin1(s, size, errors); - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); _PyUnicodeWriter_Init(&writer, 0); if (_PyUnicodeWriter_Prepare(&writer, size, 127) == -1) goto onError; @@ -9333,9 +9317,7 @@ /* If empty sequence, return u"". */ if (seqlen == 0) { Py_DECREF(fseq); - Py_INCREF(unicode_empty); - res = unicode_empty; - return res; + _Py_RETURN_UNICODE_EMPTY(); } /* If singleton sequence with an exact Unicode, return that. */ @@ -10035,7 +10017,7 @@ } new_size = slen + n * (len2 - len1); if (new_size == 0) { - Py_INCREF(unicode_empty); + _Py_INCREF_UNICODE_EMPTY(); u = unicode_empty; goto done; } @@ -11538,10 +11520,8 @@ PyErr_SetString(PyExc_IndexError, "string index out of range"); return NULL; } - if (start >= length || end < start) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (start >= length || end < start) + _Py_RETURN_UNICODE_EMPTY(); length = end - start; if (PyUnicode_IS_ASCII(self)) { @@ -11668,10 +11648,8 @@ PyObject *u; Py_ssize_t nchars, n; - if (len < 1) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); /* no repeat, return original string */ if (len == 1) @@ -12811,8 +12789,7 @@ { if (writer->pos == 0) { Py_XDECREF(writer->buffer); - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (writer->readonly) { assert(PyUnicode_GET_LENGTH(writer->buffer) == writer->pos); @@ -13030,8 +13007,7 @@ } if (slicelength <= 0) { - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } else if (start == 0 && step == 1 && slicelength == PyUnicode_GET_LENGTH(self)) { return unicode_result_unchanged(self); @@ -14035,10 +14011,8 @@ if (!PyArg_ParseTupleAndKeywords(args, kwds, "|Oss:str", kwlist, &x, &encoding, &errors)) return NULL; - if (x == NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (x == NULL) + _Py_RETURN_UNICODE_EMPTY(); if (encoding == NULL && errors == NULL) return PyObject_Str(x); else @@ -14222,9 +14196,11 @@ }; /* Init the implementation */ - unicode_empty = PyUnicode_New(0, 0); - if (!unicode_empty) - Py_FatalError("Can't create empty string"); + if (unicode_empty == NULL) { + unicode_empty = PyUnicode_New(0, 0); + if (!unicode_empty) + Py_FatalError("Can't create empty string"); + } assert(_PyUnicode_CheckConsistency(unicode_empty, 1)); for (i = 0; i < 256; i++) @@ -14268,15 +14244,10 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); _PyUnicode_ClearStaticStrings(); (void)PyUnicode_ClearFreeList(); } @@ -14405,8 +14376,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } From report at bugs.python.org Mon Jan 7 12:34:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 11:34:18 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1357558458.03.0.0274945718656.issue10156@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: commit review -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 12:34:53 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 07 Jan 2013 11:34:53 +0000 Subject: [issue16884] logging handler automatically added starting in 3.2+ Message-ID: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Starting in 3.2, the logging module no longer outputs the following message when logging and no handlers are configured for the root logger: log = logging.getLogger() log.error('test') 'No handlers could be found for logger "root"' However, I can't seem to find any version-changed about this in the docs. The code change may be from this commit: c86dc2bd3ae8 Incidentally, I also noticed that three logging paragraphs begin with "PLEASE NOTE:" Those should probably be changed to ".. note::" etc. ---------- assignee: docs at python components: Documentation keywords: easy messages: 179257 nosy: chris.jerdonek, docs at python, vinay.sajip priority: normal severity: normal status: open title: logging handler automatically added starting in 3.2+ type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 13:04:54 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jan 2013 12:04:54 +0000 Subject: [issue16850] Add "x" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357560294.47.0.268153038642.issue16850@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Atomic open + close-and-exec -> Add "x" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 13:05:50 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jan 2013 12:05:50 +0000 Subject: [issue16850] Add "x" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357560350.72.0.721417529616.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, my patch doesn't check fcntl() error code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 13:20:27 2013 From: report at bugs.python.org (Isaac (.ike) Levy) Date: Mon, 07 Jan 2013 12:20:27 +0000 Subject: [issue16883] "--enable-shared" during configure forces "2.7.3" to build as "2.7.2+" on Ubuntu 11.10 In-Reply-To: <1357540156.49.0.232787491234.issue16883@psf.upfronthosting.co.za> Message-ID: <1357561227.02.0.338532385579.issue16883@psf.upfronthosting.co.za> Isaac (.ike) Levy added the comment: Ned, absolutely correct, thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 13:20:48 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 Jan 2013 12:20:48 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1357561248.4.0.235993097353.issue11816@psf.upfronthosting.co.za> Nick Coghlan added the comment: To clarify the vague allusion in my last comment, Ron's suggestion was along the lines of creating a dis.Bytecode object that encapsulated everything the dis module can figure out about a piece of compiled code. That would mean exposing the kind of info reported in a string by dis.code_info() as attributes/properties, and have the proposed "get_opinfo()" be the __iter__ method on the disassembled Bytecode objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 13:36:58 2013 From: report at bugs.python.org (Isaac (.ike) Levy) Date: Mon, 07 Jan 2013 12:36:58 +0000 Subject: [issue16882] Python 2.7 has 73 files with hard references to /usr/local when building on *NIX In-Reply-To: <1357539928.45.0.253239442495.issue16882@psf.upfronthosting.co.za> Message-ID: <1357562218.5.0.802738596409.issue16882@psf.upfronthosting.co.za> Isaac (.ike) Levy added the comment: Hi Ned, Thanks. Your logic is rational here, I'll close it, and open another if I can carve out time to attack this with an appropriate patch for setup.py - to attempt resolution of the 3rd party library build issues. However, off the top of your head if you know of any more related tickets, (like Issue5575), I'd love to know- I'll cull through to try to find as many related bug reports as possible to get a feel for what people have tried. Best, .ike ---------- resolution: -> wont fix status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 13:37:48 2013 From: report at bugs.python.org (Isaac (.ike) Levy) Date: Mon, 07 Jan 2013 12:37:48 +0000 Subject: [issue16882] Python 2.7 has 73 files with hard references to /usr/local when building on *NIX In-Reply-To: <1357539928.45.0.253239442495.issue16882@psf.upfronthosting.co.za> Message-ID: <1357562268.58.0.464096569841.issue16882@psf.upfronthosting.co.za> Changes by Isaac (.ike) Levy : ---------- resolution: wont fix -> duplicate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 13:38:20 2013 From: report at bugs.python.org (Isaac (.ike) Levy) Date: Mon, 07 Jan 2013 12:38:20 +0000 Subject: [issue16882] Python 2.7 has 73 files with hard references to /usr/local when building on *NIX In-Reply-To: <1357539928.45.0.253239442495.issue16882@psf.upfronthosting.co.za> Message-ID: <1357562300.23.0.942012518039.issue16882@psf.upfronthosting.co.za> Changes by Isaac (.ike) Levy : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 14:21:58 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 07 Jan 2013 13:21:58 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357564918.22.0.89874492606.issue16868@psf.upfronthosting.co.za> Todd Rovito added the comment: Ok I changed the time to one month...now the patch reads: "To begin with, please be patient! There are many more people submitting patches than there are people capable of reviewing your patch. Getting your patch reviewed requires a reviewer to have the spare time and motivation to look at your patch (we cannot force anyone to review patches). If your patch has not received any notice from reviewers (i.e., no comment made) after one month, first ?ping? the issue on the issue tracker to remind the nosy list that the patch needs a review. After the issue has been ?pinged? and if you don?t get a response after a few days then you may email python-dev at python.org asking for someone to review your patch." ---------- Added file: http://bugs.python.org/file28611/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 14:22:13 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 07 Jan 2013 13:22:13 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357564933.84.0.357661562564.issue16868@psf.upfronthosting.co.za> Changes by Todd Rovito : Removed file: http://bugs.python.org/file28573/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-dev.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 14:22:21 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 07 Jan 2013 13:22:21 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357564941.65.0.396285835066.issue16868@psf.upfronthosting.co.za> Changes by Todd Rovito : Removed file: http://bugs.python.org/file28603/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 14:42:40 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 07 Jan 2013 13:42:40 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357566160.05.0.0533987439416.issue16868@psf.upfronthosting.co.za> Brett Cannon added the comment: Wording LGTM ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 15:15:46 2013 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 07 Jan 2013 14:15:46 +0000 Subject: [issue16884] logging handler automatically added starting in 3.2+ In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za> Message-ID: <1357568146.62.0.306138951004.issue16884@psf.upfronthosting.co.za> Vinay Sajip added the comment: Although there is no versionadded directive, the HOWTO documentation does state that the behaviour relates to Python 3.2 and later, and how to obtain the earlier behaviour. I will add documentation (including a versionadded) to the reference docs and also update the "PLEASE NOTE:" occurrences to use ".. note::" directives instead. ---------- assignee: docs at python -> vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 15:19:23 2013 From: report at bugs.python.org (Isaac (.ike) Levy) Date: Mon, 07 Jan 2013 14:19:23 +0000 Subject: [issue5575] Add env vars for controlling building sqlite, hashlib and ssl In-Reply-To: <1238101680.27.0.350099709898.issue5575@psf.upfronthosting.co.za> Message-ID: <1357568363.23.0.983405652882.issue5575@psf.upfronthosting.co.za> Changes by Isaac (.ike) Levy : ---------- nosy: +ikeaxial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 15:19:28 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Jan 2013 14:19:28 +0000 Subject: [issue16884] logging handler automatically added starting in 3.2+ In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za> Message-ID: <3YfzHz6Rs4zS1s@mail.python.org> Roundup Robot added the comment: New changeset 95a4ff8c540b by Vinay Sajip in branch '3.2': Issue #16884: updated logging documentation to include lastResort and use 'note' directives where appropriate. http://hg.python.org/cpython/rev/95a4ff8c540b New changeset 3b5c4190e256 by Vinay Sajip in branch '3.3': Issue #16884: Merged logging documentation fixes from 3.2. http://hg.python.org/cpython/rev/3b5c4190e256 New changeset 9009178e08d9 by Vinay Sajip in branch 'default': Closes #16884: Merged logging documentation fixes from 3.3. http://hg.python.org/cpython/rev/9009178e08d9 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 15:41:54 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 07 Jan 2013 14:41:54 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357569714.34.0.760088945831.issue5066@psf.upfronthosting.co.za> Zachary Ware added the comment: I wonder, is there any really good reason to keep a separate Lib/idlelib/help.txt, or can Doc/library/idle.rst be used for its purpose (with or without a small amount of processing to, for instance, remove comments and extra backslashes)? Both have most of the same information, and reST is designed to be readable anyway, so I don't see much point in keeping them separate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 15:43:50 2013 From: report at bugs.python.org (Jamie Spence) Date: Mon, 07 Jan 2013 14:43:50 +0000 Subject: [issue16885] SQLite3 iterdump ordering Message-ID: <1357569830.11.0.727312766793.issue16885@psf.upfronthosting.co.za> New submission from Jamie Spence: After dumping a database with iterdump, trying to execute the dumped SQL sometimes results in an error because the statement order may be wrong. In my case, it is a view that is being created before the view it is referencing. Would ordering the sqlite_master table view query in dump.py by ID fix this issue? ---------- messages: 179267 nosy: Jamie.Spence priority: normal severity: normal status: open title: SQLite3 iterdump ordering type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 16:01:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 15:01:49 +0000 Subject: [issue8745] zipimport is a bit slow In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za> Message-ID: <1357570909.21.0.767502760112.issue8745@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In general, the patch LGTM, however I?can't try it on Windows, and on Linux it has no any performance effect. Can anyone try it on Windows? I?have re-uploaded the patch for review after converting it from UTF-16 and CRLF. ---------- Added file: http://bugs.python.org/file28612/zipimport-speedup-v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 16:56:21 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jan 2013 15:56:21 +0000 Subject: [issue16850] Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357574181.33.0.723803640491.issue16850@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Add "x" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT -> Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:01:55 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jan 2013 16:01:55 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1357574515.24.0.736417564507.issue12939@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, _get_osfhandle() was not mentionned in this issue. This function may be used to retrieve the internel file handle from a file descriptor. http://msdn.microsoft.com/en-us/library/ks2530z6%28v=vs.100%29.aspx There is also the opposite: _open_osfhandle(). This function may be used for fileno() method of the Windows implementation of FileIO. http://msdn.microsoft.com/en-us/library/bdts1c9x%28v=vs.100%29.aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:02:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 16:02:14 +0000 Subject: [issue13173] Default values for string.Template In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za> Message-ID: <1357574534.16.0.510624927867.issue13173@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:10:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 16:10:40 +0000 Subject: [issue13790] In str.format an incorrect error message for list, tuple, dict, set In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za> Message-ID: <1357575040.22.0.705677373472.issue13790@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:16:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 16:16:56 +0000 Subject: [issue15335] IDLE - debugger steps through run.py internals In-Reply-To: <1342111374.05.0.899363686539.issue15335@psf.upfronthosting.co.za> Message-ID: <1357575416.11.0.0526019009025.issue15335@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:19:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 16:19:34 +0000 Subject: [issue9522] xml.etree.ElementTree forgets the encoding In-Reply-To: <1281000730.31.0.804989593298.issue9522@psf.upfronthosting.co.za> Message-ID: <1357575574.27.0.662187945777.issue9522@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.4 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:27:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 16:27:15 +0000 Subject: [issue15438] document that math.pow is inappropriate for integers In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za> Message-ID: <1357576035.33.0.11223140367.issue15438@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:28:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 16:28:10 +0000 Subject: [issue15695] Correct __sizeof__ support for StgDict In-Reply-To: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za> Message-ID: <1357576090.87.0.817966447522.issue15695@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:29:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 16:29:56 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1357576196.52.0.627561442774.issue15972@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:46:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Jan 2013 16:46:02 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1357577162.72.0.526569829846.issue9374@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It may be fixing a bug, but the bug is not obvious and the fix is not > backward compatible. I therefore suggest to roll back the commits to > 3.2 and 2.7. Well, the bug is quite obvious to me :-) (just hit it here) The fix for those who want the old behaviour is obvious: just pass `allow_fragments=False` to urlparse(). OTOH, if you revert the fix, patching things manually is quite cumbersome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 17:58:07 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Jan 2013 16:58:07 +0000 Subject: [issue14072] urlparse on tel: URI-s misses the scheme in some cases In-Reply-To: <1329817524.78.0.223656665156.issue14072@psf.upfronthosting.co.za> Message-ID: <1357577887.62.0.172220983957.issue14072@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For the record, urlparse still doesn't handle bare "tel" URIs such as "tel:1234": >>> parse.urlparse("tel:1234") ParseResult(scheme='', netloc='', path='tel:1234', params='', query='', fragment='') This is not terribly important since these URLs are not RFC 3966-compliant (a tel URI must have either a global number starting with "+" - e.g. "tel:+1234" - or a local number with a phone-context parameter - e.g. "tel:1234;phone-context=python.org"). Yet, there actual telecom systems producing such non-compliant URIs, so they might be nice to support too. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:12:15 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Mon, 07 Jan 2013 17:12:15 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order Message-ID: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> New submission from Frank Wierzbicki: test_dictcomp hard codes the dict output of various tests of Dict Comprehensions. Since Jython has a different dict ordering we are currently altering this test. When we get to 3.x it will be nicer if we can use this test as is. Also I've seen some discussion on Python-Dev that CPython devs want to get rid of dict ordering in the tests anyway. Patch attached, which assigns the dict values to a variable and compares it in the tests instead of just dumping the output in the doctests. ---------- components: Tests files: test_dictcomp.patch keywords: patch messages: 179272 nosy: fwierzbicki priority: normal severity: normal status: open title: Doctests in test_dictcomp depend on dict order versions: Python 3.4 Added file: http://bugs.python.org/file28613/test_dictcomp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:20:45 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 07 Jan 2013 17:20:45 +0000 Subject: [issue16884] logging handler automatically added starting in 3.2+ In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za> Message-ID: <1357579245.03.0.832919502163.issue16884@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks a lot, Vinay. By the way, I noticed that the "PLEASE NOTE" reformatting can also be applied to 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:40:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 17:40:30 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1357580430.37.0.781637357662.issue15442@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:40:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 17:40:51 +0000 Subject: [issue15988] Inconsistency in overflow error messages of integer argument In-Reply-To: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za> Message-ID: <1357580451.63.0.0415542826122.issue15988@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:42:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 17:42:56 +0000 Subject: [issue2263] struct.pack() + numpy int raises SystemError In-Reply-To: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za> Message-ID: <1357580576.93.0.112311069286.issue2263@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:44:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 17:44:43 +0000 Subject: [issue16273] f.tell() returning negative number on Windows build In-Reply-To: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za> Message-ID: <1357580683.59.0.0250569265533.issue16273@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:47:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 17:47:19 +0000 Subject: [issue5803] email/quoprimime: encode and decode are very slow on large messages In-Reply-To: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za> Message-ID: <1357580839.78.0.225668895542.issue5803@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:51:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 17:51:10 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1357581070.64.0.710083971817.issue15027@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:54:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 17:54:49 +0000 Subject: [issue15278] UnicodeDecodeError when readline in codecs.py In-Reply-To: <1341674319.29.0.269195397783.issue15278@psf.upfronthosting.co.za> Message-ID: <1357581289.42.0.92253515005.issue15278@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate stage: patch review -> committed/rejected status: open -> closed superseder: -> UTF-16 incremental decoder doesn't support partial surrogate pair _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:55:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 17:55:37 +0000 Subject: [issue11461] UTF-16 incremental decoder doesn't support partial surrogate pair In-Reply-To: <1299752398.22.0.888282532941.issue11461@psf.upfronthosting.co.za> Message-ID: <1357581337.35.0.937919771634.issue11461@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 18:56:04 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 17:56:04 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled In-Reply-To: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> Message-ID: <1357581364.19.0.531210390752.issue16836@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 19:05:23 2013 From: report at bugs.python.org (Matthew Barnett) Date: Mon, 07 Jan 2013 18:05:23 +0000 Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches nothing. Ditto B and Z. In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za> Message-ID: <1357581923.34.0.19590593471.issue13899@psf.upfronthosting.co.za> Matthew Barnett added the comment: I've attached a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file28614/issue13899.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 19:33:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 18:33:46 +0000 Subject: [issue16096] Get rid of dangerous integer overflow tricks In-Reply-To: <1349030051.26.0.323672452753.issue16096@psf.upfronthosting.co.za> Message-ID: <1357583626.31.0.425469735996.issue16096@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 19:34:07 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 18:34:07 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1357583647.35.0.75355963304.issue14377@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 19:37:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 18:37:35 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <1357583855.62.0.049187454732.issue16335@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 19:39:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 18:39:23 +0000 Subject: [issue16404] Uses of PyLong_FromLong that don't check for errors In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za> Message-ID: <1357583963.18.0.415067802263.issue16404@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:09:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 19:09:18 +0000 Subject: [issue15845] Fixing some byte-to-string conversion warnings In-Reply-To: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za> Message-ID: <1357585758.25.0.143381668863.issue15845@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:11:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 19:11:26 +0000 Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3 In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za> Message-ID: <1357585886.92.0.880849576833.issue13153@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:27:45 2013 From: report at bugs.python.org (Christian Heimes) Date: Mon, 07 Jan 2013 19:27:45 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357586865.91.0.952230943858.issue9685@psf.upfronthosting.co.za> Christian Heimes added the comment: Benchmark doesn't show any serious improvements. Some test cases are even slower. Report on Linux freimann 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 Total CPU cores: 6 ### call_simple ### Min: 0.201824 -> 0.208248: 1.03x slower Avg: 0.210608 -> 0.217300: 1.03x slower Significant (t=-2.23) Stddev: 0.00818 -> 0.00829: 1.0134x larger Timeline: b'http://tinyurl.com/axqoqp4' ### go ### Min: 0.534641 -> 0.550004: 1.03x slower Avg: 0.537874 -> 0.552782: 1.03x slower Significant (t=-11.89) Stddev: 0.00184 -> 0.00211: 1.1495x larger Timeline: b'http://tinyurl.com/b5k3ua4' ### pathlib ### Min: 0.121589 -> 0.117025: 1.04x faster Avg: 0.126679 -> 0.122279: 1.04x faster Significant (t=3.64) Stddev: 0.00429 -> 0.00427: 1.0048x smaller Timeline: b'http://tinyurl.com/acbb69o' ### spectral_norm ### Min: 0.280749 -> 0.305213: 1.09x slower Avg: 0.281194 -> 0.305390: 1.09x slower Significant (t=-120.69) Stddev: 0.00044 -> 0.00011: 4.1101x smaller Timeline: b'http://tinyurl.com/awyeejp' The following not significant results are hidden, use -v to show them: call_method, call_method_slots, call_method_unknown, chaos, fannkuch, fastpickle, fastunpickle, float, formatted_logging, iterative_count, json_dump_v2, json_load, meteor_contest, nbody, normal_startup, nqueens, pidigits, raytrace, regex_compile, regex_effbot, regex_v8, richards, silent_logging, simple_logging, startup_nosite, telco, threaded_count, unpack_sequence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:31:42 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:31:42 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587102.43.0.226241495305.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28616/selector-8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:31:52 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:31:52 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587112.3.0.67783091102.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28615/tulip-selectors-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:32:01 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:32:01 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587121.56.0.29305734347.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28606/selector_poll_events.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:32:10 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:32:10 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587130.84.0.971608016727.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28602/selector-6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:32:47 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:32:47 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587167.88.0.201416694366.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28617/selector-8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:33:03 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:33:03 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587183.24.0.244328406299.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28618/tulip-selectors-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:35:41 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 07 Jan 2013 19:35:41 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <1357587341.26.0.0904439235847.issue9685@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:37:19 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:37:19 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587439.8.0.386971412573.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28618/tulip-selectors-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:37:44 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:37:44 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587464.29.0.474018245866.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28584/selector-5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:38:24 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:38:24 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587504.12.0.882094488699.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28619/tulip-selectors-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:38:34 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:38:34 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587514.54.0.227777344561.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28564/selector-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:38:43 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:38:43 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357587523.47.0.982936649206.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28575/selector-data.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:46:29 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 19:46:29 +0000 Subject: [issue15845] Fixing some byte-to-string conversion warnings In-Reply-To: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za> Message-ID: <1357587989.29.0.647097863961.issue15845@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > This will raise an error if curdir is a non-ascii str, so, unless the same error was already raised later in the code, this is backward incompatible. On all supported platforms curdir is a ascii str (':' on Mac Classic, '.' on all other). The same idiom used in glob module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 21:03:09 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 07 Jan 2013 20:03:09 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357588989.39.0.810104724067.issue5066@psf.upfronthosting.co.za> Todd Rovito added the comment: Zachary, I like your idea about joining idle.rst with help.txt but I think that should be covered under a separate bug issue. The way I see it this bug is about fixing the current documentation. So I suggest you open up a new issue and get people's take on it. I think a parser could be run at installation to convert idle.rst to help.txt or maybe IDLE could be modified to simply render idle.rst correctly. I am not sure what the best approach will be. PS Thanks for the review I should have your suggested changes integrating into a new patch today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 21:20:07 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 07 Jan 2013 20:20:07 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357590007.19.0.402089022243.issue5066@psf.upfronthosting.co.za> Zachary Ware added the comment: Right you are, Todd; I'll get another issue opened for that soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 21:24:30 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Jan 2013 20:24:30 +0000 Subject: [issue9685] tuples should remember their hash value In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za> Message-ID: <3Yg7P76PJMzQrX@mail.python.org> Roundup Robot added the comment: New changeset 17038de56fd4 by Christian Heimes in branch 'default': Add a comment about *not* caching the hash value. Issue #9685 suggested to memorize the hash value, but the feature request was rejected because no speed ups were found. http://hg.python.org/cpython/rev/17038de56fd4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 20:06:37 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 19:06:37 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: It works fine on Linux. I'm attaching the latest version that should hopefully fix the second failure, as a standalone diff and a diff for Tulip. It also adds a SELECT_CONNECT, and - untested - kqueue support. ---------- Added file: http://bugs.python.org/file28615/tulip-selectors-2.diff Added file: http://bugs.python.org/file28616/selector-8.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff --git a/runtests.py b/runtests.py --- a/runtests.py +++ b/runtests.py @@ -2,9 +2,12 @@ # Originally written by Beech Horn (for NDB). +import logging import sys import unittest +##logging.basicConfig(level=logging.DEBUG) + def load_tests(): mods = ['events', 'futures', 'tasks'] diff --git a/tulip/events_test.py b/tulip/events_test.py --- a/tulip/events_test.py +++ b/tulip/events_test.py @@ -10,6 +10,7 @@ from . import events from . import transports from . import protocols +from . import selectors from . import unix_events @@ -37,8 +38,8 @@ class EventLoopTestsMixin: def setUp(self): - pollster = self.POLLSTER_CLASS() - event_loop = unix_events.UnixEventLoop(pollster) + selector = self.SELECTOR_CLASS() + event_loop = unix_events.UnixEventLoop(selector) events.set_event_loop(event_loop) def testRun(self): @@ -229,24 +230,24 @@ el.run_once() -if hasattr(select, 'kqueue'): +if hasattr(selectors, 'KqueueSelector'): class KqueueEventLoopTests(EventLoopTestsMixin, unittest.TestCase): - POLLSTER_CLASS = unix_events.KqueuePollster + SELECTOR_CLASS = selectors.KqueueSelector -if hasattr(select, 'epoll'): +if hasattr(selectors, 'EpollSelector'): class EPollEventLoopTests(EventLoopTestsMixin, unittest.TestCase): - POLLSTER_CLASS = unix_events.EPollPollster + SELECTOR_CLASS = selectors.EpollSelector -if hasattr(select, 'poll'): +if hasattr(selectors, 'PollSelector'): class PollEventLoopTests(EventLoopTestsMixin, unittest.TestCase): - POLLSTER_CLASS = unix_events.PollPollster + SELECTOR_CLASS = selectors.PollSelector # Should always exist. class SelectEventLoopTests(EventLoopTestsMixin, unittest.TestCase): - POLLSTER_CLASS = unix_events.SelectPollster + SELECTOR_CLASS = selectors.SelectSelector class HandlerTests(unittest.TestCase): diff --git a/tulip/selectors.py b/tulip/selectors.py new file mode 100644 --- /dev/null +++ b/tulip/selectors.py @@ -0,0 +1,347 @@ +"""Select module. + +This module supports asynchronous I/O on multiple file descriptors. +""" + + +from select import * # XXX + + +# generic events, that must be mapped to implementation-specific ones +# read event +SELECT_IN = (1 << 0) +# write event +SELECT_OUT = (1 << 1) +# connect event +SELECT_CONNECT = SELECT_OUT + + +def _fileobj_to_fd(fileobj): + """Return a file descriptor from a file object. + + Parameters: + fileobj -- file descriptor, or any object with a `fileno()` method + + Returns: + corresponding file descriptor + """ + if isinstance(fileobj, int): + fd = fileobj + else: + try: + fd = int(fileobj.fileno()) + except (ValueError, TypeError): + raise ValueError("Invalid file object: {!r}".format(fileobj)) + return fd + + +class _Key: + """Object used internally to associate a file object to its backing file + descriptor, selected event mask and attached data.""" + + def __init__(self, fileobj, events, data=None): + self.fileobj = fileobj + self.fd = _fileobj_to_fd(fileobj) + self.events = events + self.data = data + + +class _BaseSelector: + """Base selector class. + + A selector supports registering file objects to be monitored for specific + I/O events. + + A file object is a file descriptor or any object with a `fileno()` method. + An arbitrary object can be attached to the file object, which can be used + for example to store context information, a callback, etc. + + A selector can use various implementations (select(), poll(), epoll()...) + depending on the platform. The default `Selector` class uses the most + performant implementation on the current platform. + """ + + def __init__(self): + # this maps file descriptors to keys + self._fd_to_key = {} + # this maps file objects to keys - for fast (un)registering + self._fileobj_to_key = {} + + def register(self, fileobj, events, data=None): + """Register a file object. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + if (not events) or (events & ~(SELECT_IN|SELECT_OUT)): + raise ValueError("Invalid events: {}".format(events)) + + if fileobj in self._fileobj_to_key: + raise ValueError("{!r} is already registered".format(fileobj)) + + key = _Key(fileobj, events, data) + self._fd_to_key[key.fd] = key + self._fileobj_to_key[fileobj] = key + return key + + def unregister(self, fileobj): + """Unregister a file object. + + Parameters: + fileobj -- file object + """ + try: + key = self._fileobj_to_key[fileobj] + del self._fd_to_key[key.fd] + del self._fileobj_to_key[fileobj] + except KeyError: + raise ValueError("{!r} is not registered".format(fileobj)) + return key + + def modify(self, fileobj, events, data=None): + """Change a registered file object monitored events or attached data. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + self.unregister(fileobj) + self.register(fileobj, events, data) + + def select(self, timeout=None): + """Perform the actual selection, until some monitored file objects are + ready or a timeout expires. + + Parameters: + timeout -- if timeout > 0, this specifies the maximum wait time, in + seconds + if timeout == 0, the select() call won't block, and will + report the currently ready file objects + if timeout is None, select() will block until a monitored + file object becomes ready + + Returns: + list of (fileobj, events, attached data) for ready file objects + `events` is a bitwise mask of SELECT_IN|SELECT_OUT + """ + raise NotImplementedError() + + def close(self): + """Close the selector. + + This must be called to make sure that any underlying resource is freed. + """ + self._fd_to_key.clear() + self._fileobj_to_key.clear() + + def get_info(self, fileobj): + """Return information about a registered file object. + + Returns: + (events, data) associated to this file object + + Raises KeyError if the file object is not registered. + """ + try: + key = self._fileobj_to_key[fileobj] + except KeyError: + raise KeyError("{} is not registered".format(fileobj)) + return key.events, key.data + + def registered_count(self): + """Return the number of registered file objects. + + Returns: + number of currently registered file objects + """ + return len(self._fd_to_key) + + def __enter__(self): + return self + + def __exit__(self, *args): + self.close() + + def _key_from_fd(self, fd): + """Return the key associated to a given file descriptor. + + Parameters: + fd -- file descriptor + + Returns: + corresponding key + """ + try: + return self._fd_to_key[fd] + except KeyError: + raise RuntimeError("No key found for fd {}".format(fd)) + + +class SelectSelector(_BaseSelector): + """Select-based selector.""" + + def __init__(self): + super().__init__() + self._readers = set() + self._writers = set() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + if events & SELECT_IN: + self._readers.add(key.fd) + if events & SELECT_OUT: + self._writers.add(key.fd) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._readers.discard(key.fd) + self._writers.discard(key.fd) + + def select(self, timeout=None): + r, w, _ = select(self._readers, self._writers, [], timeout) + r = set(r) + w = set(w) + ready = [] + for fd in r | w: + events = 0 + if fd in r: + events |= SELECT_IN + if fd in w: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + +if 'poll' in globals(): + + class PollSelector(_BaseSelector): + """Poll-based selector.""" + + def __init__(self): + super().__init__() + self._poll = poll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + poll_events = 0 + if events & SELECT_IN: + poll_events |= POLLIN + if events & SELECT_OUT: + poll_events |= POLLOUT + self._poll.register(key.fd, poll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._poll.unregister(key.fd) + + def select(self, timeout=None): + timeout = None if timeout is None else int(1000 * timeout) + ready = [] + for fd, event in self._poll.poll(timeout): + events = 0 + if event & ~POLLIN: + events |= SELECT_OUT + if event & ~POLLOUT: + events |= SELECT_IN + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + +if 'epoll' in globals(): + + class EpollSelector(_BaseSelector): + """Epoll-based selector.""" + + def __init__(self): + super().__init__() + self._epoll = epoll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + epoll_events = 0 + if events & SELECT_IN: + epoll_events |= EPOLLIN + if events & SELECT_OUT: + epoll_events |= EPOLLOUT + self._epoll.register(key.fd, epoll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._epoll.unregister(key.fd) + + def select(self, timeout=None): + timeout = -1 if timeout is None else timeout + max_ev = self.registered_count() + ready = [] + for fd, event in self._epoll.poll(timeout, max_ev): + events = 0 + if event & ~EPOLLIN: + events |= SELECT_OUT + if event & ~EPOLLOUT: + events |= SELECT_IN + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + def close(self): + super().close() + self._epoll.close() + + +if 'kqueue' in globals(): + + class KqueueSelector(_BaseSelector): + """Kqueue-based selector.""" + + def __init__(self): + super().__init__() + self._kqueue = kqueue() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + if events & SELECT_IN: + kev = select.kevent(fd, select.KQ_FILTER_READ, select.KQ_EV_ADD) + self._kqueue.control([kev], 0, 0) + if events & SELECT_OUT: + kev = select.kevent(fd, select.KQ_FILTER_WRITE, select.KQ_EV_ADD) + self._kqueue.control([kev], 0, 0) + + def select(self, timeout=None): + max_ev = self.registered_count() + ready = [] + for kev in self._kqueue.control(None, max_ev, timeout): + fd = kev.ident + flag = kev.filter + events = 0 + if flag == select.KQ_FILTER_READ: + events |= SELECT_IN + if flag == select.KQ_FILTER_WRITE: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return events + + def close(self): + super().close() + self._kqueue.close() + + +# Choose the best implementation: roughly, epoll|kqueue > poll > select. +# select() also can't accept a FD > FD_SETSIZE (usually around 1024) +if 'KqueueSelector' in globals(): + Selector = KqueueSelector +elif 'EpollSelector' in globals(): + Selector = EpollSelector +elif 'PollSelector' in globals(): + Selector = PollSelector +else: + Selector = SelectSelector diff --git a/tulip/unix_events.py b/tulip/unix_events.py --- a/tulip/unix_events.py +++ b/tulip/unix_events.py @@ -1,10 +1,8 @@ """UNIX event loop and related classes. -NOTE: The Pollster classes are not part of the published API. - -The event loop can be broken up into a pollster (the part responsible +The event loop can be broken up into a selector (the part responsible for telling us when file descriptors are ready) and the event loop -proper, which wraps a pollster with functionality for scheduling +proper, which wraps a selector with functionality for scheduling callbacks, immediately or at a given time in the future. Whenever a public API takes a callback, subsequent positional @@ -13,22 +11,6 @@ Keyword arguments for the callback are not supported; this is a conscious design decision, leaving the door open for keyword arguments to modify the meaning of the API call itself. - -There are several implementations of the pollster part, several using -esoteric system calls that exist only on some platforms. These are: - -- kqueue (most BSD systems) -- epoll (newer Linux systems) -- poll (most UNIX systems) -- select (all UNIX systems, and Windows) - -NOTE: We don't use select on systems where any of the others is -available, because select performs poorly as the number of file -descriptors goes up. The ranking is roughly: - - 1. kqueue, epoll, IOCP (best for each platform) - 2. poll (linear in number of file descriptors polled) - 3. select (linear in max number of file descriptors supported) """ import collections @@ -46,6 +28,7 @@ from . import events from . import futures from . import protocols +from . import selectors from . import tasks from . import transports @@ -73,352 +56,6 @@ _MAX_WORKERS = 5 -class PollsterBase: - """Base class for all polling implementations. - - This defines an interface to register and unregister readers and - writers for specific file descriptors, and an interface to get a - list of events. There's also an interface to check whether any - readers or writers are currently registered. - """ - - def __init__(self): - super().__init__() - self.readers = {} # {fd: handler, ...}. - self.writers = {} # {fd: handler, ...}. - - def pollable(self): - """Return the number readers and writers currently registered.""" - # The event loop needs the number since it must subtract one for - # the self-pipe. - return len(self.readers) + len(self.writers) - - # Subclasses are expected to extend the add/remove methods. - - def register_reader(self, fd, handler): - """Add or update a reader for a file descriptor.""" - self.readers[fd] = handler - - def register_writer(self, fd, handler): - """Add or update a writer for a file descriptor.""" - self.writers[fd] = handler - - def unregister_reader(self, fd): - """Remove the reader for a file descriptor.""" - del self.readers[fd] - - def unregister_writer(self, fd): - """Remove the writer for a file descriptor.""" - del self.writers[fd] - - def register_connector(self, fd, handler): - """Add or update a connector for a file descriptor.""" - # On Unix a connector is the same as a writer. - self.register_writer(fd, handler) - - def unregister_connector(self, fd): - """Remove the connector for a file descriptor.""" - # On Unix a connector is the same as a writer. - self.unregister_writer(fd) - - def poll(self, timeout=None): - """Poll for I/O events. A subclass must implement this. - - If timeout is omitted or None, this blocks until at least one - event is ready. Otherwise, timeout gives a maximum time to - wait (an int of float in seconds) -- the method returns as - soon as at least one event is ready or when the timeout is - expired. For a non-blocking poll, pass 0. - - The return value is a list of events; it is empty when the - timeout expired before any events were ready. Each event - is a handler previously passed to register_reader/writer(). - """ - raise NotImplementedError - - -if sys.platform != 'win32': - - class SelectPollster(PollsterBase): - """Pollster implementation using select.""" - - def poll(self, timeout=None): - readable, writable, _ = select.select(self.readers, self.writers, - [], timeout) - events = [] - events += (self.readers[fd] for fd in readable) - events += (self.writers[fd] for fd in writable) - return events - -else: - - class SelectPollster(PollsterBase): - """Pollster implementation using select.""" - - def __init__(self): - super().__init__() - self.exceptionals = {} - - def poll(self, timeout=None): - # Failed connections are reported as exceptional but not writable. - readable, writable, exceptional = select.select( - self.readers, self.writers, self.exceptionals, timeout) - writable = set(writable).union(exceptional) - events = [] - events += (self.readers[fd] for fd in readable) - events += (self.writers[fd] for fd in writable) - return events - - def register_connector(self, fd, token): - self.register_writer(fd, token) - self.exceptionals[fd] = token - - def unregister_connector(self, fd): - self.unregister_writer(fd) - try: - del self.exceptionals[fd] - except KeyError: - # remove_connector() does not check fd in self.exceptionals. - pass - - -class PollPollster(PollsterBase): - """Pollster implementation using poll.""" - - def __init__(self): - super().__init__() - self._poll = select.poll() - - def _update(self, fd): - assert isinstance(fd, int), fd - flags = 0 - if fd in self.readers: - flags |= select.POLLIN - if fd in self.writers: - flags |= select.POLLOUT - if flags: - self._poll.register(fd, flags) - else: - self._poll.unregister(fd) - - def register_reader(self, fd, handler): - super().register_reader(fd, handler) - self._update(fd) - - def register_writer(self, fd, handler): - super().register_writer(fd, handler) - self._update(fd) - - def unregister_reader(self, fd): - super().unregister_reader(fd) - self._update(fd) - - def unregister_writer(self, fd): - super().unregister_writer(fd) - self._update(fd) - - def poll(self, timeout=None): - # Timeout is in seconds, but poll() takes milliseconds. - msecs = None if timeout is None else int(round(1000 * timeout)) - events = [] - for fd, flags in self._poll.poll(msecs): - if flags & ~select.POLLOUT: - if fd in self.readers: - events.append(self.readers[fd]) - if flags & ~select.POLLIN: - if fd in self.writers: - events.append(self.writers[fd]) - return events - - -if sys.platform == 'win32': - - class WindowsPollPollster(PollPollster): - """Pollster implementation using WSAPoll. - - WSAPoll is only available on Windows Vista and later. Python - does not currently support WSAPoll, but there is a patch - available at http://bugs.python.org/issue16507. - """ - - # REAP_PERIOD is the maximum wait before checking for failed - # connections. This is necessary because WSAPoll() does notify us - # of failed connections. See - # daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/ - REAP_PERIOD = 5.0 - - # FD_SETSIZE is maximum number of sockets in an fd_set - FD_SETSIZE = 512 - - def __init__(self): - super().__init__() - self.exceptionals = {} - - def register_connector(self, fd, token): - self.register_writer(fd, token) - self.exceptionals[fd] = token - - def unregister_connector(self, fd): - self.unregister_writer(fd) - try: - del self.exceptionals[fd] - except KeyError: - # remove_connector() does not check fd in self.exceptionals. - pass - - def _get_failed_connector_events(self): - fds = [] - remaining = list(self.exceptionals) - while remaining: - fds += select.select([], [], remaining[:self.FD_SETSIZE], 0)[2] - del remaining[:self.FD_SETSIZE] - return [(fd, select.POLLOUT) for fd in fds] - - def poll(self, timeout=None): - if not self.exceptionals: - msecs = None if timeout is None else int(round(1000 * timeout)) - polled = self._poll.poll(msecs) - - elif timeout is None: - polled = None - while not polled: - polled = (self._get_failed_connector_events() or - self._poll.poll(self.REAP_PERIOD)) - - elif timeout == 0: - polled = (self._get_failed_connector_events() or - self._poll.poll(0)) - - else: - start = time.monotonic() - deadline = start + timeout - polled = None - while timeout >= 0: - msecs = int(round(1000 * min(self.REAP_PERIOD, timeout))) - polled = (self._get_failed_connector_events() or - self._poll.poll(self.REAP_PERIOD)) - if polled: - break - timemout = deadline - time.monotonic() - - events = [] - for fd, flags in polled: - if flags & ~select.POLLOUT: - if fd in self.readers: - events.append(self.readers[fd]) - if flags & ~select.POLLIN: - if fd in self.writers: - events.append(self.writers[fd]) - return events - - PollPollster = WindowsPollPollster - - -class EPollPollster(PollsterBase): - """Pollster implementation using epoll.""" - - def __init__(self): - super().__init__() - self._epoll = select.epoll() - - def _update(self, fd): - assert isinstance(fd, int), fd - eventmask = 0 - if fd in self.readers: - eventmask |= select.EPOLLIN - if fd in self.writers: - eventmask |= select.EPOLLOUT - if eventmask: - try: - self._epoll.register(fd, eventmask) - except IOError: - self._epoll.modify(fd, eventmask) - else: - self._epoll.unregister(fd) - - def register_reader(self, fd, handler): - super().register_reader(fd, handler) - self._update(fd) - - def register_writer(self, fd, handler): - super().register_writer(fd, handler) - self._update(fd) - - def unregister_reader(self, fd): - super().unregister_reader(fd) - self._update(fd) - - def unregister_writer(self, fd): - super().unregister_writer(fd) - self._update(fd) - - def poll(self, timeout=None): - if timeout is None: - timeout = -1 # epoll.poll() uses -1 to mean "wait forever". - events = [] - for fd, eventmask in self._epoll.poll(timeout): - if eventmask & ~select.EPOLLOUT: - if fd in self.readers: - events.append(self.readers[fd]) - if eventmask & ~select.EPOLLIN: - if fd in self.writers: - events.append(self.writers[fd]) - return events - - -class KqueuePollster(PollsterBase): - """Pollster implementation using kqueue.""" - - def __init__(self): - super().__init__() - self._kqueue = select.kqueue() - - def register_reader(self, fd, handler): - if fd not in self.readers: - kev = select.kevent(fd, select.KQ_FILTER_READ, select.KQ_EV_ADD) - self._kqueue.control([kev], 0, 0) - return super().register_reader(fd, handler) - - def register_writer(self, fd, handler): - if fd not in self.writers: - kev = select.kevent(fd, select.KQ_FILTER_WRITE, select.KQ_EV_ADD) - self._kqueue.control([kev], 0, 0) - return super().register_writer(fd, handler) - - def unregister_reader(self, fd): - super().unregister_reader(fd) - kev = select.kevent(fd, select.KQ_FILTER_READ, select.KQ_EV_DELETE) - self._kqueue.control([kev], 0, 0) - - def unregister_writer(self, fd): - super().unregister_writer(fd) - kev = select.kevent(fd, select.KQ_FILTER_WRITE, select.KQ_EV_DELETE) - self._kqueue.control([kev], 0, 0) - - def poll(self, timeout=None): - events = [] - max_ev = len(self.readers) + len(self.writers) - for kev in self._kqueue.control(None, max_ev, timeout): - fd = kev.ident - flag = kev.filter - if flag == select.KQ_FILTER_READ and fd in self.readers: - events.append(self.readers[fd]) - elif flag == select.KQ_FILTER_WRITE and fd in self.writers: - events.append(self.writers[fd]) - return events - - -# Pick the best pollster class for the platform. -if hasattr(select, 'kqueue'): - best_pollster = KqueuePollster -elif hasattr(select, 'epoll'): - best_pollster = EPollPollster -elif hasattr(select, 'poll'): - best_pollster = PollPollster -else: - best_pollster = SelectPollster - - class _StopError(BaseException): """Raised to stop the event loop.""" @@ -433,12 +70,13 @@ See events.EventLoop for API specification. """ - def __init__(self, pollster=None): + def __init__(self, selector=None): super().__init__() - if pollster is None: - logging.info('Using pollster: %s', best_pollster.__name__) - pollster = best_pollster() - self._pollster = pollster + if selector is None: + # pick the best selector class for the platform + selector = selectors.Selector() + logging.info('Using selector: %s', selector.__name__) + self._selector = selector self._ready = collections.deque() self._scheduled = [] self._everytime = [] @@ -465,7 +103,9 @@ TODO: Give this a timeout too? """ - while self._ready or self._scheduled or self._pollster.pollable() > 1: + while (self._ready or + self._scheduled or + self._selector.registered_count() > 1): try: self._run_once() except _StopError: @@ -702,36 +342,83 @@ def add_reader(self, fd, callback, *args): """Add a reader callback. Return a Handler instance.""" handler = events.Handler(None, callback, args) - self._pollster.register_reader(fd, handler) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + self._selector.register(fd, selectors.SELECT_IN, + (handler, None, None)) + else: + self._selector.modify(fd, mask | selectors.SELECT_IN, + (handler, writer, connector)) + return handler def remove_reader(self, fd): """Remove a reader callback.""" - if fd in self._pollster.readers: - self._pollster.unregister_reader(fd) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + pass + else: + mask &= ~selectors.SELECT_IN + if not mask: + self._selector.unregister(fd) + else: + self._selector.modify(fd, mask, (None, writer, connector)) def add_writer(self, fd, callback, *args): """Add a writer callback. Return a Handler instance.""" handler = events.Handler(None, callback, args) - self._pollster.register_writer(fd, handler) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + self._selector.register(fd, selectors.SELECT_OUT, + (None, handler, None)) + else: + self._selector.modify(fd, mask | selectors.SELECT_OUT, + (reader, handler, connector)) return handler def remove_writer(self, fd): """Remove a writer callback.""" - if fd in self._pollster.writers: - self._pollster.unregister_writer(fd) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + pass + else: + mask &= ~selectors.SELECT_OUT + if not mask: + self._selector.unregister(fd) + else: + self._selector.modify(fd, mask, (reader, None, connector)) def add_connector(self, fd, callback, *args): """Add a connector callback. Return a Handler instance.""" - dcall = events.Handler(None, callback, args) - self._pollster.register_connector(fd, dcall) - return dcall + # XXX As long as SELECT_CONNECT == SELECT_OUT, set the handler + # as both writer and connector. + handler = events.Handler(None, callback, args) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + self._selector.register(fd, selectors.SELECT_CONNECT, + (None, handler, handler)) + else: + self._selector.modify(fd, mask | selectors.SELECT_CONNECT, + (reader, handler, handler)) + return handler def remove_connector(self, fd): """Remove a connector callback.""" - # Every connector fd is in self._pollsters.writers. - if fd in self._pollster.writers: - self._pollster.unregister_connector(fd) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + pass + else: + mask &= ~selectors.SELECT_CONNECT + if not mask: + self._selector.unregister(fd) + else: + self._selector.modify(fd, mask, (reader, None, None)) def sock_recv(self, sock, n): """XXX""" @@ -743,7 +430,7 @@ fd = sock.fileno() if registered: # Remove the callback early. It should be rare that the - # pollster says the fd is ready but the call still returns + # selector says the fd is ready but the call still returns # EAGAIN, and I am willing to take a hit in that case in # order to simplify the common case. self.remove_reader(fd) @@ -876,10 +563,10 @@ while self._scheduled and self._scheduled[0].cancelled: heapq.heappop(self._scheduled) - # Inspect the poll queue. If there's exactly one pollable + # Inspect the poll queue. If there's exactly one selectable # file descriptor, it's the self-pipe, and if there's nothing # scheduled, we should ignore it. - if self._pollster.pollable() > 1 or self._scheduled: + if self._selector.registered_count() > 1 or self._scheduled: if self._ready: timeout = 0 elif self._scheduled: @@ -892,7 +579,7 @@ timeout = min(timeout, deadline) t0 = time.monotonic() - events = self._pollster.poll(timeout) + event_list = self._selector.select(timeout) t1 = time.monotonic() argstr = '' if timeout is None else ' %.3f' % timeout if t1-t0 >= 1: @@ -900,8 +587,13 @@ else: level = logging.DEBUG logging.log(level, 'poll%s took %.3f seconds', argstr, t1-t0) - for handler in events: - self._add_callback(handler) + for fileobj, mask, (reader, writer, connector) in event_list: + if mask & selectors.SELECT_IN and reader is not None: + self._add_callback(reader) + if mask & selectors.SELECT_OUT and writer is not None: + self._add_callback(writer) + elif mask & selectors.SELECT_CONNECT and connector is not None: + self._add_callback(connector) # Handle 'later' callbacks that are ready. now = time.monotonic() -------------- next part -------------- diff --git a/Lib/select.py b/Lib/select.py new file mode 100644 --- /dev/null +++ b/Lib/select.py @@ -0,0 +1,347 @@ +"""Select module. + +This module supports asynchronous I/O on multiple file descriptors. +""" + + +from _select import * + + +# generic events, that must be mapped to implementation-specific ones +# read event +SELECT_IN = (1 << 0) +# write event +SELECT_OUT = (1 << 1) +# connect event +SELECT_CONNECT = SELECT_OUT + + +def _fileobj_to_fd(fileobj): + """Return a file descriptor from a file object. + + Parameters: + fileobj -- file descriptor, or any object with a `fileno()` method + + Returns: + corresponding file descriptor + """ + if isinstance(fileobj, int): + fd = fileobj + else: + try: + fd = int(fileobj.fileno()) + except (ValueError, TypeError): + raise ValueError("Invalid file object: {!r}".format(fileobj)) + return fd + + +class _Key: + """Object used internally to associate a file object to its backing file + descriptor, selected event mask and attached data.""" + + def __init__(self, fileobj, events, data=None): + self.fileobj = fileobj + self.fd = _fileobj_to_fd(fileobj) + self.events = events + self.data = data + + +class _BaseSelector: + """Base selector class. + + A selector supports registering file objects to be monitored for specific + I/O events. + + A file object is a file descriptor or any object with a `fileno()` method. + An arbitrary object can be attached to the file object, which can be used + for example to store context information, a callback, etc. + + A selector can use various implementations (select(), poll(), epoll()...) + depending on the platform. The default `Selector` class uses the most + performant implementation on the current platform. + """ + + def __init__(self): + # this maps file descriptors to keys + self._fd_to_key = {} + # this maps file objects to keys - for fast (un)registering + self._fileobj_to_key = {} + + def register(self, fileobj, events, data=None): + """Register a file object. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + if (not events) or (events & ~(SELECT_IN|SELECT_OUT)): + raise ValueError("Invalid events: {}".format(events)) + + if fileobj in self._fileobj_to_key: + raise ValueError("{!r} is already registered".format(fileobj)) + + key = _Key(fileobj, events, data) + self._fd_to_key[key.fd] = key + self._fileobj_to_key[fileobj] = key + return key + + def unregister(self, fileobj): + """Unregister a file object. + + Parameters: + fileobj -- file object + """ + try: + key = self._fileobj_to_key[fileobj] + del self._fd_to_key[key.fd] + del self._fileobj_to_key[fileobj] + except KeyError: + raise ValueError("{!r} is not registered".format(fileobj)) + return key + + def modify(self, fileobj, events, data=None): + """Change a registered file object monitored events or attached data. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + self.unregister(fileobj) + self.register(fileobj, events, data) + + def select(self, timeout=None): + """Perform the actual selection, until some monitored file objects are + ready or a timeout expires. + + Parameters: + timeout -- if timeout > 0, this specifies the maximum wait time, in + seconds + if timeout == 0, the select() call won't block, and will + report the currently ready file objects + if timeout is None, select() will block until a monitored + file object becomes ready + + Returns: + list of (fileobj, events, attached data) for ready file objects + `events` is a bitwise mask of SELECT_IN|SELECT_OUT + """ + raise NotImplementedError() + + def close(self): + """Close the selector. + + This must be called to make sure that any underlying resource is freed. + """ + self._fd_to_key.clear() + self._fileobj_to_key.clear() + + def get_info(self, fileobj): + """Return information about a registered file object. + + Returns: + (events, data) associated to this file object + + Raises KeyError if the file object is not registered. + """ + try: + key = self._fileobj_to_key[fileobj] + except KeyError: + raise KeyError("{} is not registered".format(fileobj)) + return key.events, key.data + + def registered_count(self): + """Return the number of registered file objects. + + Returns: + number of currently registered file objects + """ + return len(self._fd_to_key) + + def __enter__(self): + return self + + def __exit__(self, *args): + self.close() + + def _key_from_fd(self, fd): + """Return the key associated to a given file descriptor. + + Parameters: + fd -- file descriptor + + Returns: + corresponding key + """ + try: + return self._fd_to_key[fd] + except KeyError: + raise RuntimeError("No key found for fd {}".format(fd)) + + +class SelectSelector(_BaseSelector): + """Select-based selector.""" + + def __init__(self): + super().__init__() + self._readers = set() + self._writers = set() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + if events & SELECT_IN: + self._readers.add(key.fd) + if events & SELECT_OUT: + self._writers.add(key.fd) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._readers.discard(key.fd) + self._writers.discard(key.fd) + + def select(self, timeout=None): + r, w, _ = select(self._readers, self._writers, [], timeout) + r = set(r) + w = set(w) + ready = [] + for fd in r | w: + events = 0 + if fd in r: + events |= SELECT_IN + if fd in w: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + +if 'poll' in globals(): + + class PollSelector(_BaseSelector): + """Poll-based selector.""" + + def __init__(self): + super().__init__() + self._poll = poll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + poll_events = 0 + if events & SELECT_IN: + poll_events |= POLLIN + if events & SELECT_OUT: + poll_events |= POLLOUT + self._poll.register(key.fd, poll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._poll.unregister(key.fd) + + def select(self, timeout=None): + timeout = None if timeout is None else int(1000 * timeout) + ready = [] + for fd, event in self._poll.poll(timeout): + events = 0 + if event & ~POLLIN: + events |= SELECT_OUT + if event & ~POLLOUT: + events |= SELECT_IN + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + +if 'epoll' in globals(): + + class EpollSelector(_BaseSelector): + """Epoll-based selector.""" + + def __init__(self): + super().__init__() + self._epoll = epoll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + epoll_events = 0 + if events & SELECT_IN: + epoll_events |= EPOLLIN + if events & SELECT_OUT: + epoll_events |= EPOLLOUT + self._epoll.register(key.fd, epoll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._epoll.unregister(key.fd) + + def select(self, timeout=None): + timeout = -1 if timeout is None else timeout + max_ev = self.registered_count() + ready = [] + for fd, event in self._epoll.poll(timeout, max_ev): + events = 0 + if event & ~EPOLLIN: + events |= SELECT_OUT + if event & ~EPOLLOUT: + events |= SELECT_IN + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return ready + + def close(self): + super().close() + self._epoll.close() + + +if 'kqueue' in globals(): + + class KqueueSelector(_BaseSelector): + """Kqueue-based selector.""" + + def __init__(self): + super().__init__() + self._kqueue = kqueue() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + if events & SELECT_IN: + kev = select.kevent(fd, select.KQ_FILTER_READ, select.KQ_EV_ADD) + self._kqueue.control([kev], 0, 0) + if events & SELECT_OUT: + kev = select.kevent(fd, select.KQ_FILTER_WRITE, select.KQ_EV_ADD) + self._kqueue.control([kev], 0, 0) + + def select(self, timeout=None): + max_ev = self.registered_count() + ready = [] + for kev in self._kqueue.control(None, max_ev, timeout): + fd = kev.ident + flag = kev.filter + events = 0 + if flag == select.KQ_FILTER_READ: + events |= SELECT_IN + if flag == select.KQ_FILTER_WRITE: + events |= SELECT_OUT + + key = self._key_from_fd(fd) + ready.append((key.fileobj, events, key.data)) + return events + + def close(self): + super().close() + self._kqueue.close() + + +# Choose the best implementation: roughly, epoll|kqueue > poll > select. +# select() also can't accept a FD > FD_SETSIZE (usually around 1024) +if 'KqueueSelector' in globals(): + Selector = KqueueSelector +elif 'EpollSelector' in globals(): + Selector = EpollSelector +elif 'PollSelector' in globals(): + Selector = PollSelector +else: + Selector = SelectSelector diff --git a/Lib/test/test_select.py b/Lib/test/test_select.py --- a/Lib/test/test_select.py +++ b/Lib/test/test_select.py @@ -1,10 +1,25 @@ import errno import os +import random import select import sys import unittest from test import support +try: + import resource +except ImportError: + resource = None + + +def find_ready_matching(ready, flag): + match = [] + for fd, mode, data in ready: + if mode & flag: + match.append(fd) + return match + + @unittest.skipIf((sys.platform[:3]=='win'), "can't easily test on this system") class SelectTestCase(unittest.TestCase): @@ -75,9 +90,260 @@ a[:] = [F()] * 10 self.assertEqual(select.select([], a, []), ([], a[:5], [])) + +class BasicSelectorTestCase(unittest.TestCase): + + def test_constants(self): + select.SELECT_IN + select.SELECT_OUT + + +class BaseSelectorTestCase(unittest.TestCase): + + def test_error_conditions(self): + s = self.SELECTOR() + self.assertRaises(TypeError, s.register) + self.assertRaises(TypeError, s.register, 0) + self.assertRaises(ValueError, s.register, 0, 18) + self.assertRaises(TypeError, s.unregister, 0, 1) + self.assertRaises(TypeError, s.modify, 0) + self.assertRaises(TypeError, s.select, 0, 1) + + def test_basic(self): + with self.SELECTOR() as s: + rd, wr = os.pipe() + wro = os.fdopen(os.dup(wr), "wb") + self.addCleanup(os.close, rd) + self.addCleanup(os.close, wr) + self.addCleanup(wro.close) + + # test without attached data + s.register(wr, select.SELECT_OUT) + self.assertEqual(set(((wr, select.SELECT_OUT, None),)), set(s.select())) + + # test with attached data + s.unregister(wr) + s.register(wr, select.SELECT_OUT, sys.stdin) + self.assertEqual(set(((wr, select.SELECT_OUT, sys.stdin),)), set(s.select())) + + # test with file object + s.register(wro, select.SELECT_OUT) + self.assertEqual(set(((wro, select.SELECT_OUT, None), + (wr, select.SELECT_OUT, sys.stdin))), set(s.select())) + s.unregister(wro) + + # modify + s.modify(wr, select.SELECT_OUT, sys.stdout) + self.assertEqual(set(((wr, select.SELECT_OUT, sys.stdout),)), set(s.select())) + + # test timeout + s.register(rd, select.SELECT_IN, sys.stdin) + s.unregister(wr) + self.assertFalse(s.select(0.1)) + s.register(wr, select.SELECT_OUT) + self.assertEqual(set(((wr, select.SELECT_OUT, None),)), + set(s.select(0.1))) + + # registering twice should raise an error + self.assertRaises(ValueError, s.register, wr, select.SELECT_OUT) + + # test get_info() + self.assertEquals((select.SELECT_OUT, None), s.get_info(wr)) + self.assertEquals((select.SELECT_IN, sys.stdin), s.get_info(rd)) + self.assertRaises(KeyError, s.get_info, wro) + + s.unregister(rd) + s.unregister(wr) + + # test registered_count() + self.assertEquals(0, s.registered_count()) + s.register(rd, select.SELECT_IN) + s.register(wr, select.SELECT_OUT) + self.assertEquals(2, s.registered_count()) + s.modify(wr, select.SELECT_OUT, sys.stdout) + self.assertEquals(2, s.registered_count()) + s.unregister(rd) + s.unregister(wr) + self.assertEquals(0, s.registered_count()) + + # unregistering twice should raise an error + self.assertRaises(ValueError, s.unregister, wr) + + def test_selector(self): + s = self.SELECTOR() + self.addCleanup(s.close) + + NUM_PIPES = 12 + MSG = b" This is a test." + MSG_LEN = len(MSG) + readers = [] + writers = [] + r2w = {} + w2r = {} + + for i in range(NUM_PIPES): + rd, wr = os.pipe() + s.register(rd, select.SELECT_IN) + s.register(wr, select.SELECT_OUT) + readers.append(rd) + writers.append(wr) + r2w[rd] = wr + w2r[wr] = rd + + bufs = [] + + while writers: + ready = s.select() + ready_writers = find_ready_matching(ready, select.SELECT_OUT) + if not ready_writers: + self.fail("no pipes ready for writing") + wr = random.choice(ready_writers) + os.write(wr, MSG) + + ready = s.select() + ready_readers = find_ready_matching(ready, select.SELECT_IN) + if not ready_readers: + self.fail("no pipes ready for reading") + self.assertEqual([w2r[wr]], ready_readers) + rd = ready_readers[0] + buf = os.read(rd, MSG_LEN) + self.assertEqual(len(buf), MSG_LEN) + bufs.append(buf) + os.close(r2w[rd]) ; os.close(rd) + s.unregister(r2w[rd]) + s.unregister(rd) + writers.remove(r2w[rd]) + + self.assertEqual(bufs, [MSG] * NUM_PIPES) + + def test_timeout(self): + s = self.SELECTOR() + self.addCleanup(s.close) + + cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done' + p = os.popen(cmd, 'r') + s.register(p.fileno(), select.SELECT_IN, p) + + for tout in (0, 1, 2, 4, 8, 16) + (None,)*10: + if support.verbose: + print('timeout =', tout) + + ready = s.select(tout) + if not ready: + continue + eof_seen = False + for fileobj, evt, data in ready: + if fileobj == p.fileno() and evt & select.SELECT_IN: + while True: + line = p.readline() + if support.verbose: + print(repr(line)) + if not line: + if support.verbose: + print('EOF') + eof_seen = True + break + if not eof_seen: + self.fail('Unexpected return values from select(): %r' % ready) + p.close() + + def test_below_fd_setsize(self): + # No implementation should have a problem with less than FD_SETSIZE file + # descriptors. To be conservative, let's say 64. + NUM_FDS = 64 + + r, w = os.pipe() + self.addCleanup(os.close, r) + self.addCleanup(os.close, w) + + with self.SELECTOR() as s: + for i in range(NUM_FDS): + fd = os.dup(w) + self.addCleanup(os.close, fd) + + s.register(fd, select.SELECT_OUT) + self.assertEquals(NUM_FDS, len(s.select())) + + +class ScalableSelectorTestCase: + + # a mixin to test selector scalability + + @unittest.skipUnless(resource, "Test needs resource module") + def test_above_fd_setsize(self): + # A scalable implementation should have no problem with more than + # FD_SETSIZE file descriptors. Since we don't know the value, we just + # try to set the soft RLIMIT_NOFILE to the hard RLIMIT_NOFILE ceiling. + try: + soft, hard = resource.getrlimit(resource.RLIMIT_NOFILE) + resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard)) + self.addCleanup(resource.setrlimit, resource.RLIMIT_NOFILE, + (soft, hard)) + NUM_FDS = hard + except OSError: + NUM_FDS = soft + + # guard for already allocated FDs (stdin, stdout...) + NUM_FDS -= 16 + + r, w = os.pipe() + self.addCleanup(os.close, r) + self.addCleanup(os.close, w) + + with self.SELECTOR() as s: + for i in range(NUM_FDS): + try: + fd = os.dup(w) + except OSError as e: + if e.errno == errno.EMFILE: + # too many FD, skip + self.skipTest("FD limit reached") + raise + + self.addCleanup(os.close, fd) + s.register(fd, select.SELECT_OUT) + + self.assertEquals(NUM_FDS, len(s.select())) + + + at unittest.skipIf((sys.platform[:3]=='win'), + "can't easily test on this system") +class SelectorTestCase(BaseSelectorTestCase): + + SELECTOR = select.Selector + + +class SelectSelectorTestCase(BaseSelectorTestCase): + + SELECTOR = select.SelectSelector + + + at unittest.skipUnless(hasattr(select, 'PollSelector'), "Test needs select.poll()") +class PollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorTestCase): + + SELECTOR = getattr(select, 'PollSelector', None) + + + at unittest.skipUnless(hasattr(select, 'EpollSelector'), "Test needs select.epoll()") +class EpollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorTestCase): + + SELECTOR = getattr(select, 'EpollSelector', None) + + + at unittest.skipUnless(hasattr(select, 'KqueueSelector'), "Test needs select.kqueue()") +class KqueueSelectorTestCase(BaseSelectorTestCase, ScalableSelectorTestCase): + + SELECTOR = getattr(select, 'KqueueSelector', None) + + def test_main(): - support.run_unittest(SelectTestCase) + tests = [SelectTestCase] + tests.extend([BasicSelectorTestCase, SelectorTestCase, + SelectSelectorTestCase, PollSelectorTestCase, + EpollSelectorTestCase, KqueueSelectorTestCase]) + support.run_unittest(*tests) support.reap_children() + if __name__ == "__main__": test_main() diff --git a/Modules/selectmodule.c b/Modules/selectmodule.c --- a/Modules/selectmodule.c +++ b/Modules/selectmodule.c @@ -2129,7 +2129,7 @@ static struct PyModuleDef selectmodule = { PyModuleDef_HEAD_INIT, - "select", + "_select", module_doc, -1, select_methods, @@ -2143,7 +2143,7 @@ PyMODINIT_FUNC -PyInit_select(void) +PyInit__select(void) { PyObject *m; m = PyModule_Create(&selectmodule); diff --git a/setup.py b/setup.py --- a/setup.py +++ b/setup.py @@ -623,7 +623,7 @@ missing.append('spwd') # select(2); not on ancient System V - exts.append( Extension('select', ['selectmodule.c']) ) + exts.append( Extension('_select', ['selectmodule.c']) ) # Fred Drake's interface to the Python parser exts.append( Extension('parser', ['parsermodule.c']) ) From report at bugs.python.org Mon Jan 7 21:57:42 2013 From: report at bugs.python.org (Roger Serwy) Date: Mon, 07 Jan 2013 20:57:42 +0000 Subject: [issue16887] IDLE - tabify/untabify applied when clicking Cancel Message-ID: <1357592262.2.0.644397432764.issue16887@psf.upfronthosting.co.za> New submission from Roger Serwy: Krystian Rosi?ski notified me about an error with Tabify/Untabify. Clicking cancel still performs the operation because the _asktabwidth function in Lib/idlelib/EditorWindow.py always returns a number, regardless of cancel being clicked. This bug is visibly noticeable with IdleX since it highlights all \t Tabs, but not with the original IDLE. The attached patch solves the problem. ---------- components: IDLE files: tabify.patch keywords: patch messages: 179282 nosy: serhiy.storchaka, serwy priority: low severity: normal stage: patch review status: open title: IDLE - tabify/untabify applied when clicking Cancel type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28620/tabify.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 22:18:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Jan 2013 21:18:25 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <3Yg8bN6xwqzQ92@mail.python.org> Roundup Robot added the comment: New changeset 1b68dc917321 by Serhiy Storchaka in branch '3.3': Issue #15972: Fix error messages when os functions expecting a file name or http://hg.python.org/cpython/rev/1b68dc917321 New changeset 71fb426ee972 by Serhiy Storchaka in branch 'default': Issue #15972: Fix error messages when os functions expecting a file name or http://hg.python.org/cpython/rev/71fb426ee972 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 22:20:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Jan 2013 21:20:17 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1357593617.54.0.197896916502.issue15972@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed. Thank you for report, John. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 22:57:22 2013 From: report at bugs.python.org (Matt Hickford) Date: Mon, 07 Jan 2013 21:57:22 +0000 Subject: [issue16675] Ship Python with a package manager In-Reply-To: <1355453782.76.0.977469174024.issue16675@psf.upfronthosting.co.za> Message-ID: Matt Hickford added the comment: Please could you share a link to a previous discussion about packaging? I'm interested in user experience 'Python should ship with first class package management like other languages' rather than technical details 'Python should ship with distutils rather than setuptools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:07:44 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 07 Jan 2013 22:07:44 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357596464.77.0.275087535855.issue16748@psf.upfronthosting.co.za> Zachary Ware added the comment: I've come up with a semi-comprehensive list of the tests that cause ugly failures with test discovery. Tests were run on 3.4 debug, on Windows 7 32bit without several of the 'external' projects built, using the command ``PCbuild\python_d.exe -m unittest discover Lib/test/ "test_x*.py"`` where 'x' was whatever it took to get a specific test or group of tests to run. There are two basic causes of failure, and a couple of oddballs. First up, tests that fail with discovery, but run fine with ``PCbuild\python_d.exe -m test test_name``: test_array test_asyncore test_bisect test_bufio test_bytes test_codecs test_concurrent_futures test_configparser test_ctypes test_dbm test_decimal test_file test_format test_ftplib test_future3 test_hash test_imaplib test_import test_index test_io test_iterlen test_locale test_multiprocessing test_module test_osx_env test_pickle test_random test_robotparser test_runpy test_set test_shelve test_socket test_sqlite test_sys test_tarfile test_time test_univnewlines test_warnings test_xml_etree These 39 should be relatively straightforward fixes like heapq and genericpath have been. The next group are tests that are properly skipped by the test package, but fail noisily with unittest discovery: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_crypt test_curses test_epoll test_fcntl test_gdb test_grp test_hashlib test_ioctl test_kqueue test_largefile test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_smtpnet test_socketserver test_ssl test_syslog test_tcl test_threadsignals test_tk test_ttk_guionly test_ttk_textonly test_urllib2net test_wait3 test_wait4 test_winsound test_zipfile64 Some of these are skipped due to certain resources not being allowed, some don't have the proper module available. In any case, discovery does not respond well to the skip methods used for each of them. The 'oddballs' I mentioned before are as follows: json_tests.test_fail leakers.test_gestalt test_glob test_json test_shutil test_urllib2_localnet Each of these fail on my machine whichever way I run them. I'm not sure if any of them actually have any issues with discovery, I'm merely listing them here for completeness' sake. I will try to test them again myself on Linux later, and report back what I find. If anyone else feels led to tackle any of these, please add me to the nosy list of any new issues filed. I plan to eventually work through all of these myself, but don't want to duplicate effort :) Thanks, Zach Ware ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:12:18 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 22:12:18 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357596738.05.0.000996340522014.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28621/selector-8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:12:32 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 22:12:32 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357596752.86.0.130021887031.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28622/tulip-selectors-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:12:42 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 22:12:42 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357596762.7.0.159036663023.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28617/selector-8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:12:52 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 22:12:52 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357596772.89.0.260475763933.issue16853@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file28619/tulip-selectors-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:15:45 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 Jan 2013 22:15:45 +0000 Subject: [issue16675] Ship Python with a package manager In-Reply-To: <1355435594.3.0.516927010626.issue16675@psf.upfronthosting.co.za> Message-ID: <1357596945.21.0.504011206305.issue16675@psf.upfronthosting.co.za> R. David Murray added the comment: I'm afraid the discussions are many and lengthly and on several lists (python-dev, distutils-sig, probably also python-list and python-ideas), and that you will rarely find a discussion of "whether" without an accompanying discussion of "what". I'm sorry I can't give you specific links. The thing to do is probably to look at the recent archives of distutils-sig, and sign up, and open a conversation there once you have a basic idea of the landscape. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:21:48 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 Jan 2013 22:21:48 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357597308.42.0.927191626887.issue16748@psf.upfronthosting.co.za> R. David Murray added the comment: Great list, thanks. The ones that fail to be run/skipped when run under discovery can probably be fixed by moving them to the more modern unittest 'skip' functions instead of depending on being run under regrtest and using the test.support resource functions. When run directly they should not skip due to a resource not being set, but when run under regrtest (I'm not sure how you detect that but if there isn't currently a way we should make one via test.support) they should respect the resources. Unittest doesn't yet have a concept of resources, but I believe there is an open issue for it, so at some point we will hopefully be able to move all resource management to unittest and out of regrtest. But not yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:29:31 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 07 Jan 2013 22:29:31 +0000 Subject: [issue16878] argparse: positional args with nargs='*' defaults to [] In-Reply-To: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za> Message-ID: <1357597771.74.0.235317754388.issue16878@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attached is a doc patch. I also improved some other aspects of the *default* section while I was there. We should probably make sure a test exists for the newly-documented behavior (i.e. for passing no arguments for a positional argument with nargs='*' and default=None). ---------- keywords: +patch Added file: http://bugs.python.org/file28623/issue-16878-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:35:13 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 07 Jan 2013 22:35:13 +0000 Subject: [issue13229] Improve tools for iterating over filesystem directories In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za> Message-ID: <1357598113.61.0.132396497801.issue13229@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Nick, I think this would be a great addition (I have often seen people trying to implement this in their own code, and I certainly did it myself). What's the status of walkdir, do you think it's mature enough to be merged? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:35:16 2013 From: report at bugs.python.org (Ronan Amicel) Date: Mon, 07 Jan 2013 22:35:16 +0000 Subject: [issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za> Message-ID: <1357598116.07.0.375608369132.issue13866@psf.upfronthosting.co.za> Changes by Ronan Amicel : ---------- nosy: +ronnix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:40:41 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 07 Jan 2013 22:40:41 +0000 Subject: [issue16888] Fix test discovery for test_array.py Message-ID: <1357598441.54.0.816719600523.issue16888@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's a patch to fix test_array.py ---------- components: Tests files: test_array.diff keywords: patch messages: 179291 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_array.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28624/test_array.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:42:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 Jan 2013 22:42:58 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357598578.76.0.322163776979.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: While we are at it, should we also move these tests to use unittest.main() instead of test_main() and similar? ---------- dependencies: +Fix test discovery for test_array.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:44:06 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jan 2013 22:44:06 +0000 Subject: [issue13229] Improve tools for iterating over filesystem directories In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za> Message-ID: <1357598646.38.0.537092405627.issue13229@psf.upfronthosting.co.za> STINNER Victor added the comment: pathlib and walkdir are two nice piece of code, but do we need two modules? It would be nice to merge them into one unique module :-) (Or is it a stupid idea?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:50:00 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jan 2013 22:50:00 +0000 Subject: [issue16850] Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357599000.58.0.480838101205.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch. I tested it on Linux Fedora (3.6), Linux Debian (3.0), Windows 7, FreeBSD 8.2 (don't support O_CLOEXEC), OpenIndiana (oi_148, SunOS 5.11), OpenBSD 4.9, OpenBSD 5.2, Mac OS X 10.8. test_builtin pass on all these platforms... except OpenBSD 4.9. The test fails on OpenBSD 4.9 for an unknown reason. fcntl(FD_CLOEXEC) + exec() works, but fcntl(FD_CLOSEXEC) + fork() + exec() fails. It looks like an OS bug, I don't see what Python can do for this case :-/ The "e" mode does correctly set FD_CLOEXEC, but FD_CLOEXEC doesn't work as expected. It's really an OS bug, because test_builtin pass on OpenBSD 5.2. I don't have other OSes to check if another platform doesn't support "e" mode (a platform where NotImplementedError would be raised). ---------- Added file: http://bugs.python.org/file28625/open_mode_e-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 7 23:54:27 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 Jan 2013 22:54:27 +0000 Subject: [issue16888] Fix test discovery for test_array.py In-Reply-To: <1357598441.54.0.816719600523.issue16888@psf.upfronthosting.co.za> Message-ID: <1357599267.14.0.0783669269519.issue16888@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 00:29:13 2013 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Jan 2013 23:29:13 +0000 Subject: [issue16143] Building with configure option "--without-doc-strings" crashes first time through PyUnicode_DecodeUTF8Stateful In-Reply-To: <1349455516.0.0.465126799391.issue16143@psf.upfronthosting.co.za> Message-ID: <1357601353.38.0.33213900327.issue16143@psf.upfronthosting.co.za> Stefan Krah added the comment: Closing as a duplicate of #10156, which has several patches. ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> Initialization of globals in unicodeobject.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 00:30:38 2013 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Jan 2013 23:30:38 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1357601438.88.0.495900523987.issue10156@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +Gregory.Andersen, georg.brandl, kushou, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 00:30:53 2013 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Jan 2013 23:30:53 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1357601453.77.0.955903110004.issue10156@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- priority: high -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 00:56:01 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Jan 2013 23:56:01 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357602961.78.0.256434935618.issue16748@psf.upfronthosting.co.za> Terry J. Reedy added the comment: test_main makes it trivial to import a test file and run the test. >>> import test/test_xxx as t; t.test_main() I do not know the implications of unittest.main(), but I would dislike losing the above ability. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 01:00:47 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Jan 2013 00:00:47 +0000 Subject: [issue16850] Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357603247.47.0.168555041393.issue16850@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file28561/open_mode_e.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 01:09:25 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Jan 2013 00:09:25 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357603765.53.0.186134367016.issue16748@psf.upfronthosting.co.za> R. David Murray added the comment: As we discussed in another issue, you just need to change your pattern to: >>> import unittest.main as runtest >>> import test.test_xxx as t >>> runtest(t) Which granted is more typing if you are running just one test, but not much more if you are running more than one. You could also put the import for unittest into your rc file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 01:13:54 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 00:13:54 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357604034.28.0.379216723633.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: Without test_main you would have to do unittest.main(t, exit=False). I'm not sure there's an easier way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 01:36:58 2013 From: report at bugs.python.org (Felipe Cruz) Date: Tue, 08 Jan 2013 00:36:58 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357605418.38.0.653389791218.issue16853@psf.upfronthosting.co.za> Felipe Cruz added the comment: Hi.. 2 comments related to Kqueue/OSX(16.8) 1 - In tulip/selectors.py L311 and L314 - is key.fd not fd 2 - In EventLoopTestsMixin::test_writer_callback if the writer socket isn't non-blocking, the test hangs forever.. 3 - Errors: ERROR: testCreateSslTransport (tulip.events_test.PollEventLoopTests) File "/Users/felipecruz/Projects/tulip3/tulip/selectors.py", line 180, in _key_from_fd raise RuntimeError("No key found for fd {}".format(fd)) RuntimeError: No key found for fd -2 ERROR: test_sock_client_ops (tulip.events_test.KqueueEventLoopTests) File "/Users/felipecruz/Projects/tulip3/tulip/selectors.py", line 180, in _key_from_fd raise RuntimeError("No key found for fd {}".format(fd)) RuntimeError: No key found for fd 77 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 01:45:47 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2013 00:45:47 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357605947.45.0.866793125965.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: There's a bug in the kqueue selector. The following code in your patch has 'fd' instead of 'key.fd', twice: if events & SELECT_IN: kev = kevent(key.fd, KQ_FILTER_READ, KQ_EV_ADD) self._kqueue.control([kev], 0, 0) if events & SELECT_OUT: kev = kevent(key.fd, KQ_FILTER_WRITE, KQ_EV_ADD) self._kqueue.control([kev], 0, 0) One kqueue test fails on OSX: ERROR: test_sock_client_ops (tulip.events_test.KqueueEventLoopTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/guido/tulip/tulip/selectors.py", line 178, in _key_from_fd return self._fd_to_key[fd] KeyError: 11 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/guido/tulip/tulip/events_test.py", line 167, in test_sock_client_ops el.run_until_complete(el.sock_sendall(sock, b'GET / HTTP/1.0\r\n\r\n')) File "/Users/guido/tulip/tulip/unix_events.py", line 146, in run_until_complete self.run() File "/Users/guido/tulip/tulip/unix_events.py", line 110, in run self._run_once() File "/Users/guido/tulip/tulip/unix_events.py", line 582, in _run_once event_list = self._selector.select(timeout) File "/Users/guido/tulip/tulip/selectors.py", line 329, in select key = self._key_from_fd(fd) File "/Users/guido/tulip/tulip/selectors.py", line 180, in _key_from_fd raise RuntimeError("No key found for fd {}".format(fd)) RuntimeError: No key found for fd 11 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 02:10:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Jan 2013 01:10:39 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <3YgFlL1XTszR5F@mail.python.org> Roundup Robot added the comment: New changeset ce99559efa46 by Chris Jerdonek in branch 'default': Issue #16854: Fix regrtest.usage() regression introduced in 6e2e5adc0400. http://hg.python.org/cpython/rev/ce99559efa46 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 02:10:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Jan 2013 01:10:39 +0000 Subject: [issue15302] Use argparse instead of getopt in test.regrtest In-Reply-To: <1341811583.87.0.73741220409.issue15302@psf.upfronthosting.co.za> Message-ID: <3YgFlM06QtzR4h@mail.python.org> Roundup Robot added the comment: New changeset ce99559efa46 by Chris Jerdonek in branch 'default': Issue #16854: Fix regrtest.usage() regression introduced in 6e2e5adc0400. http://hg.python.org/cpython/rev/ce99559efa46 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 02:13:00 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 01:13:00 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <1357607580.07.0.335133312835.issue16854@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 02:55:56 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 08 Jan 2013 01:55:56 +0000 Subject: [issue13229] Improve tools for iterating over filesystem directories In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za> Message-ID: <1357610156.97.0.171054866653.issue13229@psf.upfronthosting.co.za> Nick Coghlan added the comment: The problem with the current walkdir implementation is that without a rich path object you end up making a lot of redundant system calls. Combined with the inherent overhead of nested generators, it just *feels* bad (even in situations where worrying about the speed is truly a case of premature optimisation) The caching in pathlib should deal with the problem of redundant system calls, so rebasing walkdir on top of that would probably be a good idea (i.e. all walkdir APIs would produce pathlib paths, and implicit convert strings they encounter to paths). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 02:58:04 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 01:58:04 +0000 Subject: [issue16889] facilitate log output starting at beginning of line Message-ID: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> New submission from Chris Jerdonek: In certain situations (e.g. when logging while using unittest), log messages can start in the middle of a line, for example: ........................log: [INFO] foo .................................................. It was trickier than I thought it needed to be to get log messages to start at the beginning of a line, which seems like a reasonable expectation. It would be good if the logging module (or perhaps unittest for when running tests?) provided assistance here, either through documentation or an enhancement. The way I did this was wrap sys.stderr in a class that remembers the last written character, pass this to the test runner, and then subclass logging.StreamHandler to have emit() check whether a newline was the last character. But perhaps there is a much simpler way. ---------- components: Library (Lib) messages: 179304 nosy: chris.jerdonek, r.david.murray, vinay.sajip priority: normal severity: normal status: open title: facilitate log output starting at beginning of line type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 03:11:59 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 02:11:59 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357611119.31.0.229550288946.issue16748@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > >>> import test.test_xxx as t; t.test_main() As long as the module has "import unittest", you could also do the following, which has just 5 more characters :) >>> import test.test_xxx as t; t.unittest.main(t) ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 03:19:09 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 02:19:09 +0000 Subject: [issue16799] start using argparse.Namespace in regrtest In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za> Message-ID: <1357611549.28.0.485181427758.issue16799@psf.upfronthosting.co.za> Chris Jerdonek added the comment: FYI, the fix for issue 16854 committed most of this patch, so the patch should be updated before reviewing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 03:25:04 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Jan 2013 02:25:04 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357611904.8.0.489503725183.issue16613@psf.upfronthosting.co.za> R. David Murray added the comment: I agree that this would be useful. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 03:31:46 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 02:31:46 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357612306.03.0.835368361444.issue16748@psf.upfronthosting.co.za> Chris Jerdonek added the comment: One more. Since unittest imports strings, you can also do: >>> import unittest as u; u.main("test.test_xxx") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 03:58:47 2013 From: report at bugs.python.org (Javier Domingo) Date: Tue, 08 Jan 2013 02:58:47 +0000 Subject: [issue16890] minidom error Message-ID: <1357613927.36.0.626944272723.issue16890@psf.upfronthosting.co.za> New submission from Javier Domingo: Hi I found something like a bug, I can't get this working: import xml.dom.minidom as minidom document=""" """ dom = minidom.parseString(document) dom.childNodes dom.childNodes[0].childNodes dom.childNodes[0].childNodes[1].childNodes def delete_recursive(parent): for child in parent.childNodes: if child.hasChildNodes(): delete_recursive(child) else: parent.removeChild(child) delete_recursive(dom) dom.childNodes dom.childNodes[0].childNodes dom.childNodes[0].childNodes[0].childNodes Executes as: >>> import xml.dom.minidom as minidom >>> document=""" ... ... ... ... ... """ >>> dom = minidom.parseString(document) >>> >>> dom.childNodes [] >>> dom.childNodes[0].childNodes [, , ] >>> dom.childNodes[0].childNodes[1].childNodes [, , , , ] >>> >>> def delete_recursive(parent): ... for child in parent.childNodes: ... if child.hasChildNodes(): ... delete_recursive(child) ... else: ... parent.removeChild(child) ... >>> delete_recursive(dom) >>> >>> dom.childNodes [] >>> dom.childNodes[0].childNodes [] >>> dom.childNodes[0].childNodes[0].childNodes [, , , , ] The problem here is this last line, those text nodes shouldn't be here! I have traced the problem, and seem that the for loop is not correctly executed ---------- components: XML messages: 179309 nosy: txomon priority: normal severity: normal status: open title: minidom error versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 04:24:29 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 03:24:29 +0000 Subject: [issue16890] minidom error In-Reply-To: <1357613927.36.0.626944272723.issue16890@psf.upfronthosting.co.za> Message-ID: <1357615469.35.0.870569543752.issue16890@psf.upfronthosting.co.za> Ezio Melotti added the comment: The problem is that you are mutating parent.childNodes while you are iterating on it. Iterating over a copy seems to solve the problem. ---------- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 04:36:52 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 03:36:52 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> Message-ID: <1357616212.81.0.979770784026.issue16871@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm -1 on this, however parts of the patches could be extracted and applied on individual modules in the 'default' branch only. This could be done by the modules' maintainers if they think it's OK. Note that while it's generally not OK doing this kind of refactoring on the code in maintenance branches, it's usually acceptable doing so for the documentation. ---------- stage: -> patch review status: open -> pending type: -> enhancement versions: -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 06:06:53 2013 From: report at bugs.python.org (Todd Rovito) Date: Tue, 08 Jan 2013 05:06:53 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357621613.36.0.319783437001.issue5066@psf.upfronthosting.co.za> Todd Rovito added the comment: Zachary, Thanks for your excellent review!!!! Your feedback was very helpful for making the patch even better. ---------- Added file: http://bugs.python.org/file28626/5066IDLEocumentationforUnixObsoleteIncorrectVersion3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 06:08:50 2013 From: report at bugs.python.org (Todd Rovito) Date: Tue, 08 Jan 2013 05:08:50 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357621730.82.0.881511489853.issue5066@psf.upfronthosting.co.za> Todd Rovito added the comment: Based on Zachary's comments I have uploaded a new version of the patch which is version 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 06:30:34 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Tue, 08 Jan 2013 05:30:34 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357623034.32.0.753682175105.issue16076@psf.upfronthosting.co.za> Daniel Shahaf added the comment: In the meantime, unrelated question: should TreeBuilder be pickleable too, and interchangeably (pickle|unpickle)able between the Python and C implementations? Asking because the Python TreeBuilder has a _factory member which it initializes to 'Element', and I'm not quite sure how cross-pickling should handle that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 06:31:22 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 05:31:22 +0000 Subject: [issue14323] Normalize math precision in RGB/YIQ conversion In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za> Message-ID: <1357623082.37.0.537268791106.issue14323@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 07:31:49 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Tue, 08 Jan 2013 06:31:49 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357626709.05.0.992286878531.issue16076@psf.upfronthosting.co.za> Daniel Shahaf added the comment: New iteration. Open issues: - Share code with the init method. The issue with sharing code with either element_init() or create_new_element() would be malloc+realloc: unlike either of these methods, we know both the attributes and the number of children at allocation time, so we can allocate directly the right number of children. - C<->Py Interchangeable pickling of TreeBuilder (per above msg). Differences to previous version: - Skip C<->Py interchangeability testing of TreeBuilder --- because that one started failing with: _pickle.UnpicklingError: state is not a dictionary It can probably be fixed, but I'd like to address the above question about pickling the factory first. - Use __getstate__ rather than __reduce__ for Element. - Make Element pickling interchangeable between c/py Element (set tp_name to "xml.etree.ElementTree.Element" and match the pickled format). ---------- Added file: http://bugs.python.org/file28627/i16076-v7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 07:41:26 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 06:41:26 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357627286.31.0.0977005894565.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think that's the last nail in the coffin of test_main. Terry, do you agree? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 08:17:14 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 07:17:14 +0000 Subject: [issue15438] document that math.pow is inappropriate for integers In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za> Message-ID: <1357629434.9.0.901285594228.issue15438@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Well, the math.pow() doc could use a "seealso" pointing to the built-in > pow() function perhaps. Pointing to ``**`` is probably better. I think that a simple note that mentions the ** operator and when it's better to use it (and possibly the limitations of math.pow) is enough. Anyone wants to suggest a specific wording? ---------- assignee: rhettinger -> resolution: invalid -> stage: -> needs patch type: behavior -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 08:20:56 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 07:20:56 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1357629656.73.0.00946856508722.issue15442@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 08:49:14 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 07:49:14 +0000 Subject: [issue15988] Inconsistency in overflow error messages of integer argument In-Reply-To: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za> Message-ID: <1357631354.42.0.70460015924.issue15988@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 08:56:03 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 07:56:03 +0000 Subject: [issue16854] usage() is not defined in Lib/test/regrtest.py In-Reply-To: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za> Message-ID: <1357631763.39.0.296729646469.issue16854@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you, Chris. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 09:01:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 08:01:18 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357632078.56.0.200973264055.issue16748@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are tests outside of Lib/test/ hierarchy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 09:11:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 08:11:57 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> Message-ID: <1357632717.55.0.537539256288.issue16871@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agreed. Maintainers of asynchat, tkinter.tix, optparse and difflib must pay attention to this. ---------- nosy: +aronacher, giampaolo.rodola, gpolo, josiahcarlson, stutzbach resolution: -> rejected stage: patch review -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 09:14:31 2013 From: report at bugs.python.org (Dmitry Mugtasimov) Date: Tue, 08 Jan 2013 08:14:31 +0000 Subject: [issue16891] Fix docs about module search order Message-ID: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za> New submission from Dmitry Mugtasimov: http://docs.python.org/2/tutorial/modules.html should be rewritten. AS IS 6.1.2. The Module Search Path When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations: TO BE 6.1.2. The Module Search Path When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it looks in the containing package (the package of which the current module is a submodule). If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations: ------ Note that now "6.1.2. The Module Search Path" and "6.4.2. Intra-package References" are contradictary since in 6.4.2 it is said: "In fact, such references are so common that the import statement first looks in the containing package before looking in the standard module search path.", but this is not reflected in 6.1.2. ------ EXAMPLE (for more information see http://stackoverflow.com/questions/14183541/why-python-finds-module-instead-of-package-if-they-have-the-same-name#comment19687166_14183541 ): /home/dmugtasimov/tmp/name-res3/xyz __init__.py a.py b.py t.py xyz.py Files init.py, b.py and xyz.py are empty File a.py: import os, sys ROOT_DIRECTORY = os.path.abspath(os.path.join(os.path.dirname(__file__), '..')) if not sys.path or ROOT_DIRECTORY not in sys.path: print 'sys.path is modified in a.py' sys.path.insert(0, ROOT_DIRECTORY) else: print 'sys.path is NOT modified in a.py' print 'sys.path:', sys.path print 'BEFORE import xyz.b' import xyz.b print 'AFTER import xyz.b' File t.py: import os, sys ROOT_DIRECTORY = os.path.abspath(os.path.join(os.path.dirname(__file__), '..')) if not sys.path or ROOT_DIRECTORY not in sys.path: print 'sys.path is modified in t.py' sys.path.insert(0, ROOT_DIRECTORY) else: print 'sys.path is NOT modified in t.py' import xyz.a Run: python a.py Output: sys.path is modified in a.py sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/python2.7/dist-packages/ubuntu-sso-client'] BEFORE import xyz.b AFTER import xyz.b Run: python -vv a.py Output: import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc # trying /home/dmugtasimov/tmp/name-res3/xyz/b.so # trying /home/dmugtasimov/tmp/name-res3/xyz/bmodule.so # trying /home/dmugtasimov/tmp/name-res3/xyz/b.py # /home/dmugtasimov/tmp/name-res3/xyz/b.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/b.py import xyz.b # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/b.pyc Run: python t.py Output: sys.path is modified in t.py sys.path is NOT modified in a.py sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/python2.7/dist-packages/ubuntu-sso-client'] BEFORE import xyz.b Traceback (most recent call last): File "t.py", line 9, in import xyz.a File "/home/dmugtasimov/tmp/name-res3/xyz/a.py", line 11, in import xyz.b ImportError: No module named b Run: python -vv t.py Output: import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc # trying /home/dmugtasimov/tmp/name-res3/xyz/a.so # trying /home/dmugtasimov/tmp/name-res3/xyz/amodule.so # trying /home/dmugtasimov/tmp/name-res3/xyz/a.py # /home/dmugtasimov/tmp/name-res3/xyz/a.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/a.py import xyz.a # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/a.pyc # trying /home/dmugtasimov/tmp/name-res3/xyz/os.so # trying /home/dmugtasimov/tmp/name-res3/xyz/osmodule.so # trying /home/dmugtasimov/tmp/name-res3/xyz/os.py # trying /home/dmugtasimov/tmp/name-res3/xyz/os.pyc # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.so # trying /home/dmugtasimov/tmp/name-res3/xyz/sysmodule.so # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.py # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.pyc # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.so # trying /home/dmugtasimov/tmp/name-res3/xyz/xyzmodule.so # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.py # /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/xyz.py import xyz.xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc # clear[2] __file__ # clear[2] __package__ # clear[2] sys # clear[2] ROOT_DIRECTORY # clear[2] __name__ # clear[2] os sys.path is modified in t.py sys.path is NOT modified in a.py sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/python2.7/dist-packages/ubuntu-sso-client'] BEFORE import xyz.b Traceback (most recent call last): File "t.py", line 9, in import xyz.a File "/home/dmugtasimov/tmp/name-res3/xyz/a.py", line 11, in import xyz.b ImportError: No module named b As you see sys.path is the same for both cases: sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/python2.7/dist-packages/ubuntu-sso-client'] But the behaviour is different. For a.py python searches for package xyz first, and them for module b in it: import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc # trying /home/dmugtasimov/tmp/name-res3/xyz/b.so # trying /home/dmugtasimov/tmp/name-res3/xyz/bmodule.so # trying /home/dmugtasimov/tmp/name-res3/xyz/b.py # /home/dmugtasimov/tmp/name-res3/xyz/b.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/b.py import xyz.b # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/b.pyc In other words: Search PACKAGE xyz in directory sys.path[0] -> FOUND Search module b in PACKAGE xyz -> FOUND Continue execution For t.py it searches for moduel xyz in the same directory as a.py itself and then fails to find module b in module xyz: # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.so # trying /home/dmugtasimov/tmp/name-res3/xyz/xyzmodule.so # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.py # /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/xyz.py import xyz.xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc In other words: Search MODULE xyz in directory in the same directory as a.py (or sys.path[1] ?) -> FOUND Search MODULE b in MODULE xyz -> NOT FOUND ImportError So it looks like if "import xyz.b" bahaves different depending on how a.py was initially loaded as a script or imported from another module. ---------- assignee: docs at python components: Documentation messages: 179321 nosy: dmugtasimov, docs at python priority: normal severity: normal status: open title: Fix docs about module search order type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 09:17:13 2013 From: report at bugs.python.org (Dmitry Mugtasimov) Date: Tue, 08 Jan 2013 08:17:13 +0000 Subject: [issue16891] Fix docs about module search order In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za> Message-ID: <1357633033.1.0.702859092983.issue16891@psf.upfronthosting.co.za> Dmitry Mugtasimov added the comment: UPDATE: CHANGE http://stackoverflow.com/questions/14183541/why-python-finds-module-instead-of-package-if-they-have-the-same-name#comment19687166_14183541 TO http://stackoverflow.com/questions/14183541/why-python-finds-module-instead-of-package-if-they-have-the-same-name Because the whole question and replies are important. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 10:16:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 09:16:25 +0000 Subject: [issue14323] Normalize math precision in RGB/YIQ conversion In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za> Message-ID: <1357636585.02.0.490130673324.issue14323@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: According to Wikipedia FCC conversion is defined as: y = 0.30*r + 0.59*g + 0.11*b i = 0.5990*r - 0.2773*g - 0.3217*b q = 0.2130*r - 0.5251*g + 0.3121*b and non-FCC conversion is defined as: y = 0.299*r + 0.587*g + 0.114*b i = 0.595716*r - 0.274453*g - 0.321263*b q = 0.211456*r - 0.522591*g + 0.311135*b Our current code y = 0.30*r + 0.59*g + 0.11*b i = 0.60*r - 0.28*g - 0.32*b q = 0.21*r - 0.52*g + 0.31*b looks like FCC conversion with the precision of two decimal places. Actually with this precision the difference between the different conversions are almost absent. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 10:20:37 2013 From: report at bugs.python.org (David Lam) Date: Tue, 08 Jan 2013 09:20:37 +0000 Subject: [issue8489] Support UTF8SMTP as part of RFC 5336 in smptlib In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za> Message-ID: <1357636837.86.0.457457505361.issue8489@psf.upfronthosting.co.za> Changes by David Lam : ---------- nosy: +dlam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 10:29:51 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 09:29:51 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357637391.55.0.253677154555.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here is another iteration of the patch. I removed some of the old material, added half of the FAQs and the title and outline for the other FAQs. If the structure looks good I'll proceed. ---------- assignee: sandro.tosi -> ezio.melotti Added file: http://bugs.python.org/file28628/issue14468-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 10:32:21 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 09:32:21 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357637541.2.0.887682262806.issue14468@psf.upfronthosting.co.za> Changes by Ezio Melotti : Added file: http://bugs.python.org/file28629/committing.rst _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 10:41:11 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Jan 2013 09:41:11 +0000 Subject: [issue15845] Fixing some byte-to-string conversion warnings In-Reply-To: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za> Message-ID: <3YgT4Q3YM8zQt9@mail.python.org> Roundup Robot added the comment: New changeset 9458a516f769 by Serhiy Storchaka in branch '3.2': Issue #15845: Fix comparison between bytes and string. http://hg.python.org/cpython/rev/9458a516f769 New changeset f6cf2985348a by Serhiy Storchaka in branch '3.3': Issue #15845: Fix comparison between bytes and string. http://hg.python.org/cpython/rev/f6cf2985348a New changeset 51e60d9ee389 by Serhiy Storchaka in branch 'default': Issue #15845: Fix comparison between bytes and string. http://hg.python.org/cpython/rev/51e60d9ee389 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 10:43:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 09:43:37 +0000 Subject: [issue15845] Fixing some byte-to-string conversion warnings In-Reply-To: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za> Message-ID: <1357638217.91.0.593095302133.issue15845@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed. Thank your for report and patch, Alessandro. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 11:06:48 2013 From: report at bugs.python.org (Federico Reghenzani) Date: Tue, 08 Jan 2013 10:06:48 +0000 Subject: [issue16851] ismethod and isfunction methods error In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1357639608.8.0.785554974658.issue16851@psf.upfronthosting.co.za> Changes by Federico Reghenzani : ---------- keywords: +patch Added file: http://bugs.python.org/file28630/inspect.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 11:32:17 2013 From: report at bugs.python.org (Javier Domingo) Date: Tue, 08 Jan 2013 10:32:17 +0000 Subject: [issue16890] minidom error In-Reply-To: <1357615469.35.0.870569543752.issue16890@psf.upfronthosting.co.za> Message-ID: Javier Domingo added the comment: I know that is the problem, but that shouldn't happen! if you remove a item from a list, that doesn't happen. That is why I tagged the error as minidom's El 08/01/2013 04:24, "Ezio Melotti" escribi?: > > Ezio Melotti added the comment: > > The problem is that you are mutating parent.childNodes while you are > iterating on it. Iterating over a copy seems to solve the problem. > > ---------- > nosy: +ezio.melotti > resolution: -> invalid > stage: -> committed/rejected > status: open -> closed > type: -> behavior > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 11:49:28 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 08 Jan 2013 10:49:28 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357605418.38.0.653389791218.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: So I assume that the second failure is fixed, which means that OS-X returns a funny event (and not POLLIN/POLLHUP/POLLERR) in case of ECONNREFUSED :-( > 2 - In EventLoopTestsMixin::test_writer_callback if the writer socket isn't non-blocking, the test hangs forever.. This test is buggy: """ def test_writer_callback(self): el = events.get_event_loop() r, w = unix_events.socketpair() el.add_writer(w.fileno(), w.send, b'x'*100) el.call_later(0.1, el.remove_writer, w.fileno()) el.run() w.close() """ Because the writer socket isn't non-blocking, if the output socket buffer fills up in less than 0.1 seconds, the call to w.send(b'x'*100) will block. select()/poll()/kqueue() use a watermark to decide whether the FD is readable/writable: for a Unix domain socket, I guess OS-X returns that the socket is writable is there's at least one byte free in the output socket buffer: since send() tries to write 100 bytes at once, it blocks. I can reproduce the hang on Linux with vanilla (unpatched) tulip by increasing the number of bytes sent() in one syscall: """ --- tulip-bf4cb136c121/tulip/events_test.py 2092-08-05 00:00:00.000000000 +0200 +++ tulip/tulip/events_test.py 2013-01-08 11:35:27.400198000 +0100 @@ -149,7 +149,7 @@ def test_writer_callback(self): el = events.get_event_loop() r, w = unix_events.socketpair() - el.add_writer(w.fileno(), w.send, b'x'*100) + el.add_writer(w.fileno(), w.send, b'x'*(1<<18)) el.call_later(0.1, el.remove_writer, w.fileno()) el.run() w.close() """ (I have to do that because Linux uses an adaptive watermark, see http://lxr.free-electrons.com/source/net/unix/af_unix.c#L2156 and http://lxr.free-electrons.com/source/net/unix/af_unix.c#L319 ). That's why all FDs monitored with select()/poll()/epoll() must be non-blocking (and there's also the risk of spurious wakeups...). > 3 - Errors: > > ERROR: testCreateSslTransport (tulip.events_test.PollEventLoopTests) > File "/Users/felipecruz/Projects/tulip3/tulip/selectors.py", line 180, in _key_from_fd > raise RuntimeError("No key found for fd {}".format(fd)) > RuntimeError: No key found for fd -2 > > > ERROR: test_sock_client_ops (tulip.events_test.KqueueEventLoopTests) > File "/Users/felipecruz/Projects/tulip3/tulip/selectors.py", line 180, in _key_from_fd > raise RuntimeError("No key found for fd {}".format(fd)) > RuntimeError: No key found for fd 77 Yes, it's the same problem: poll()/kqueue() returning garbage. I guess I'll have to patch Selector to ignore unknown FDs, but that really looks like an OS-X bug. Could you dump the content of the returned kevent when the fd is not found? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 11:59:21 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 10:59:21 +0000 Subject: [issue16890] minidom error In-Reply-To: <1357613927.36.0.626944272723.issue16890@psf.upfronthosting.co.za> Message-ID: <1357642761.33.0.461039863784.issue16890@psf.upfronthosting.co.za> Ezio Melotti added the comment: It happens with lists too: >>> l = list(range(10)) >>> for x in l: ... l.remove(x) ... >>> l [1, 3, 5, 7, 9] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:02:25 2013 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 Jan 2013 11:02:25 +0000 Subject: [issue16889] facilitate log output starting at beginning of line In-Reply-To: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> Message-ID: <1357642945.97.0.641616888206.issue16889@psf.upfronthosting.co.za> Vinay Sajip added the comment: I agree this is a reasonable expectation, but I've not encountered this problem before. Can you provide a short script demonstrating the problem? Which platform did you encounter these problems on, and what was the logging configuration? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:07:20 2013 From: report at bugs.python.org (Javier Domingo) Date: Tue, 08 Jan 2013 11:07:20 +0000 Subject: [issue16890] minidom error In-Reply-To: <1357642761.33.0.461039863784.issue16890@psf.upfronthosting.co.za> Message-ID: Javier Domingo added the comment: Ok, sorry then. Javier Domingo 2013/1/8 Ezio Melotti > > Ezio Melotti added the comment: > > It happens with lists too: > >>> l = list(range(10)) > >>> for x in l: > ... l.remove(x) > ... > >>> l > [1, 3, 5, 7, 9] > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:20:22 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Jan 2013 11:20:22 +0000 Subject: [issue16884] logging handler automatically added starting in 3.2+ In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za> Message-ID: <3YgWGs28drzRmP@mail.python.org> Roundup Robot added the comment: New changeset 51138680b968 by Vinay Sajip in branch '2.7': Issue #16884: Updated docs to use 'note' directives. http://hg.python.org/cpython/rev/51138680b968 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:27:30 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Jan 2013 11:27:30 +0000 Subject: [issue16884] logging handler automatically added starting in 3.2+ In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za> Message-ID: <3YgWR60LhtzPMy@mail.python.org> Roundup Robot added the comment: New changeset 50af862d0625 by Vinay Sajip in branch '3.2': Issue #16884: Updated docs to use 'note' directives in a couple of places missed earlier. http://hg.python.org/cpython/rev/50af862d0625 New changeset b00c4a095b00 by Vinay Sajip in branch '3.3': Issue #16884: Merged doc fix from 3.2. http://hg.python.org/cpython/rev/b00c4a095b00 New changeset 4617b7ac302a by Vinay Sajip in branch 'default': Issue #16884: Merged doc fix from 3.3. http://hg.python.org/cpython/rev/4617b7ac302a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:29:15 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 11:29:15 +0000 Subject: [issue16889] facilitate log output starting at beginning of line In-Reply-To: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> Message-ID: <1357644555.37.0.171225397334.issue16889@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This can happen with any standard logging configuration when there are writes to sys.stderr that don't end with "\n". I'm using Mac OS X 10.7. A minimal script: import logging, unittest log = logging.getLogger() class Test(unittest.TestCase): def setUp(self): log.info("setting up") def test1(self): pass def test2(self): pass logging.basicConfig(level=logging.INFO) unittest.main() Output: INFO:root:setting up .INFO:root:setting up . ---------------------------------------------------------------------- Ran 2 tests in 0.001s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:32:53 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 11:32:53 +0000 Subject: [issue16884] logging handler automatically added starting in 3.2+ In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za> Message-ID: <1357644773.07.0.0781163544363.issue16884@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:35:08 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 08 Jan 2013 11:35:08 +0000 Subject: [issue16871] Cleanup a few minor things In-Reply-To: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za> Message-ID: <1357644908.77.0.0172962617184.issue16871@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Ok for asyncore/asynchat in 3.4 branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:36:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Jan 2013 11:36:15 +0000 Subject: [issue16889] facilitate log output starting at beginning of line In-Reply-To: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> Message-ID: <1357644975.12.0.767401374699.issue16889@psf.upfronthosting.co.za> Ezio Melotti added the comment: Note that for this specific problem you could call unittest.main(verbosity=0). ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:41:20 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 11:41:20 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1357645280.08.0.069182837107.issue15442@psf.upfronthosting.co.za> ?ric Araujo added the comment: > Should __pycache__ be ignored too? Sounds good. > I don't know how to compile python without having to install it See the devguide http://docs.python.org/devguide ---------- stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:42:50 2013 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 Jan 2013 11:42:50 +0000 Subject: [issue16889] facilitate log output starting at beginning of line In-Reply-To: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> Message-ID: <1357645370.48.0.0936903440732.issue16889@psf.upfronthosting.co.za> Vinay Sajip added the comment: Oh, I see what you mean now. I guess the approach you used is straightforward, and perhaps something could be added to test.support. It's only an aesthetic thing, though, IIUC. I normally don't run into this because I log to file when running unit tests, or run with -v so that the runner prints complete lines rather than just dots. And if you need to test that logging is happening, you can use the TestHandler and Matcher classes in test.support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 12:47:55 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 11:47:55 +0000 Subject: [issue16889] facilitate log output starting at beginning of line In-Reply-To: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> Message-ID: <1357645675.51.0.437533518481.issue16889@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Ezio, the use case is to add to the existing test output additional diagnostic logging. In particular, you might want to run tests even with verbosity=2 in addition to the log messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:08:59 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 12:08:59 +0000 Subject: [issue16889] facilitate log output starting at beginning of line In-Reply-To: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> Message-ID: <1357646939.78.0.555204060989.issue16889@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Yes, it's primarily for easier scanning/reading as well as aesthetic. With -v I get the following output though: test1 (test_logging.Test) ... INFO:root:setting up ok test2 (test_logging.Test) ... INFO:root:setting up ok ---------------------------------------------------------------------- Ran 2 tests in 0.000s At least it's good to know that I wasn't missing anything obvious. And yes, I did read about TestHandler/Matcher (for making assertions about logging) from the following informative thread a couple years ago (which I came across when filing issue 16884): http://mail.python.org/pipermail/python-dev/2010-December/106526.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:11:42 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:11:42 +0000 Subject: [issue13198] Remove duplicate definition of write_record_file In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za> Message-ID: <1357647102.22.0.845918553032.issue13198@psf.upfronthosting.co.za> ?ric Araujo added the comment: Please don?t; distutils2 still exists and is mutating into one or more projects where these bug reports will be useful. If it bothers Python core devs to have the bugs in this tracker, they will be migrated, but for the moment please leave them open so they can be found. ---------- resolution: out of date -> stage: -> patch review status: closed -> open versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:18:45 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:18:45 +0000 Subject: [issue12944] Accept arbitrary files for packaging's upload command In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za> Message-ID: <1357647525.27.0.350659537786.issue12944@psf.upfronthosting.co.za> ?ric Araujo added the comment: distutils2, while not actively developed any more for inclusion in the stdlib in 3.4, will mutate into one or more projects where these bug reports will be useful. Bugs will certainly be migrated (and closed in this tracker), but please keep them open for easy query. ---------- resolution: out of date -> status: closed -> open versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:23:47 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 12:23:47 +0000 Subject: [issue16889] facilitate log output starting at beginning of line In-Reply-To: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> Message-ID: <1357647827.08.0.497821647722.issue16889@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > and perhaps something could be added to test.support. Also, just to clarify, I had in mind outside projects and the larger community for this request rather than CPython development, so I'm not sure test.support would be the right location. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:27:12 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:27:12 +0000 Subject: [issue16842] Allow to override a function signature for pydoc with a docstring In-Reply-To: <1357157305.88.0.0239428638229.issue16842@psf.upfronthosting.co.za> Message-ID: <1357648032.03.0.204454012076.issue16842@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:30:35 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:30:35 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1357648235.62.0.183758199404.issue16805@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:32:11 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:32:11 +0000 Subject: [issue14470] Remove using of w9xopen in subprocess module In-Reply-To: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za> Message-ID: <1357648331.94.0.0239321302656.issue14470@psf.upfronthosting.co.za> ?ric Araujo added the comment: FTR, was the deprecation for 3.3 committed? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:48:23 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:48:23 +0000 Subject: [issue16814] use --directory option of make in describing how to build the docs In-Reply-To: <1356790311.86.0.00498941541992.issue16814@psf.upfronthosting.co.za> Message-ID: <1357649303.62.0.828736778259.issue16814@psf.upfronthosting.co.za> ?ric Araujo added the comment: FWIW I use make -C Doc all the time but agree with Georg?s point about conciseness. Ezio, I suggest you bookmark some make doc page if you can?t remember it :) ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:57:22 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:57:22 +0000 Subject: [issue16851] ismethod and isfunction methods error In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1357649842.15.0.669797067025.issue16851@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:57:52 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:57:52 +0000 Subject: [issue16851] Hint about correct ismethod and isfunction usage In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1357649872.63.0.154024870346.issue16851@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: ismethod and isfunction methods error -> Hint about correct ismethod and isfunction usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 13:58:35 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 12:58:35 +0000 Subject: [issue16891] Fix docs about module search order In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za> Message-ID: <1357649915.42.0.974797961878.issue16891@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +brett.cannon, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 14:03:41 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Jan 2013 13:03:41 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357650221.06.0.158202687068.issue16748@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, but not many, and not as many as there used to be. I'd like to see them all moved, but met resistance on that front. It may be that those just can't be run using unittest discovery, and perhaps that will eventually convince the maintainers to move them. But probably not until a number of years from now :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 14:03:59 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 13:03:59 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357650239.41.0.870883420235.issue5066@psf.upfronthosting.co.za> ?ric Araujo added the comment: Idle needs to find its text help files at runtime, so they are installed as data alongside with the code. The rst doc files however can be installed anywhere or not installed at all, so we can?t change Idle to look for them. An alternate idea to avoid duplication could be to copy the rst file to the code directory at build time. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 14:04:45 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Jan 2013 13:04:45 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357650285.63.0.567250932958.issue16748@psf.upfronthosting.co.za> R. David Murray added the comment: Also, it may be possible to add unittest discovery hooks to the stubs that *are* in Lib/test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 14:32:20 2013 From: report at bugs.python.org (Federico Reghenzani) Date: Tue, 08 Jan 2013 13:32:20 +0000 Subject: [issue16851] Hint about correct ismethod and isfunction usage In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1357651940.0.0.121823301508.issue16851@psf.upfronthosting.co.za> Changes by Federico Reghenzani : ---------- nosy: +federico.reghenzani _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 14:37:07 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 Jan 2013 13:37:07 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357652227.47.0.7014080554.issue16886@psf.upfronthosting.co.za> ?ric Araujo added the comment: Yes, we definitely want to eat our dogfood and stop relying on dict order, especially now that hashing is randomized. I would argue for backporting this to stable branches. Patch looks good. A semi-related improvement for this bug would be to switch these doctests to proper unit tests. ---------- keywords: +easy nosy: +eric.araujo stage: -> patch review versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 14:42:00 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 08 Jan 2013 13:42:00 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled In-Reply-To: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> Message-ID: <1357652520.04.0.950235613652.issue16836@psf.upfronthosting.co.za> Martin v. L?wis added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 14:44:24 2013 From: report at bugs.python.org (Robert Oeffner) Date: Tue, 08 Jan 2013 13:44:24 +0000 Subject: [issue16892] Windows bug picking up stdin from a pipe Message-ID: <1357652664.69.0.880454684679.issue16892@psf.upfronthosting.co.za> New submission from Robert Oeffner: Hi, This is a bug that seems to exist on python 2.7, python 3.3 on Windows versions XP, Vista, 7 and 8 and has been around for some years, presumably also in other python versions. It is only recently I have managed to better isolate it although not completely. My Windows PC is set up with some doskey macros that are loaded at each instance of the commandline interpreter cmd.exe with the registry key HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun\mymacros.cmd Unfortunately this seems to delete stdin when stdin is piped to python scripts that runs another executable invoked with subprocess. In this case the command: python32 testsubproc.py < mytextfile.txt will not work. The textfile mytextfile.txt will be ignored. If subprocess is invoked with shell=False the textfile does get piped into stdin. This is however not an option as our porgrams are distributed on other platforms. It would also give an inconsistent experience on the same OS (Windows). If mymacros.cmd is called interactively from the command prompt the problem does not exist and stdin can be piped into the python script with no problem. I have attached a working script below which includes a comment section with a small C++ program and the registry key in question to demonstrate the problem. I would be grateful if there are people who know how to get to the bottom of this bug or even fix it. Many thanks, Robert ---------- components: Build, Windows files: testsubproc.py messages: 179352 nosy: oeffner priority: normal severity: normal status: open title: Windows bug picking up stdin from a pipe type: behavior versions: Python 2.6, Python 2.7, Python 3.3 Added file: http://bugs.python.org/file28631/testsubproc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 15:12:43 2013 From: report at bugs.python.org (Dmitry Mugtasimov) Date: Tue, 08 Jan 2013 14:12:43 +0000 Subject: [issue16891] Fix docs about module search order In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za> Message-ID: <1357654363.9.0.534817595782.issue16891@psf.upfronthosting.co.za> Dmitry Mugtasimov added the comment: As I investigate it a little closer it seems to me that it is not a documentation issue, but an implementation issue. http://docs.python.org/2/reference/simple_stmts.html#import "A package can contain other packages and modules while modules cannot contain other modules or packages." The only why to import name from module is from xyz import b where "b" is name defined inside xyz module. Issuing import xyz.b means that "b" is module or package. Therefore xyz cannot be a module, since "...modules cannot contain other modules or packages." This means that xyz is package. The problem is that it is considered as module for case: python t.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 15:39:43 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 08 Jan 2013 14:39:43 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357655983.96.0.743600964042.issue16076@psf.upfronthosting.co.za> Eli Bendersky added the comment: Daniel, thanks for this patch, it looks very good. I had some comments in the code review. As for TreeBuilder, let's split it into a separate issue - I think it's much less critical. We can discuss it later once we're done with Element. If anything, it's more important to handle ElementTree itself first - it should be very easy (much simpler than Element). With the factory method I'm not sure how the Py pickling happens. I need to dig a bit in pickling for that, because I don't know how method reference pickling works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 15:43:17 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Jan 2013 14:43:17 +0000 Subject: [issue16891] Fix docs about module search order In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za> Message-ID: <1357656197.18.0.951392426646.issue16891@psf.upfronthosting.co.za> R. David Murray added the comment: > So it looks like if "import xyz.b" bahaves different depending on how > a.py was initially loaded as a script or imported from another module. There are several differences between importing a module and running a script, one of which is what is on sys.path. You constructed your example to mask the path difference. You are getting hit by the difference between absolute and relative imports. How implicit relative imports behave are one of the other things that are different between running a file as a script and importing it. This kind of confusion is one of the reasons implicit relative imports were dropped in Python3. If you add from __future__ import absolute_import to the top of your a and t files, t will no longer produce an import error. It could be that the documentation could be improved, but I'm not sure it is worth the effort for 2.7. If there are statements in the 3.x docs that are incorrect now that implicit relative imports are gone, those would definitely be worth fixing. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 16:00:42 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 08 Jan 2013 15:00:42 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357657242.34.0.55047373045.issue16076@psf.upfronthosting.co.za> Eli Bendersky added the comment: P = import_fresh_module('xml.etree.ElementTree', blocked=['_elementtree']) tb = P.TreeBuilder(element_factory=lambda a, b: [a, b]) print(pickle.dumps(tb)) Gives: _pickle.PicklingError: Can't pickle : attribute lookup builtins.function failed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 16:04:16 2013 From: report at bugs.python.org (Dmitry Mugtasimov) Date: Tue, 08 Jan 2013 15:04:16 +0000 Subject: [issue16891] Fix docs about module search order In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za> Message-ID: <1357657456.34.0.665470191827.issue16891@psf.upfronthosting.co.za> Dmitry Mugtasimov added the comment: A lot of people are still using python 2.7, even 2.6. For me it would be a nice fix in docs since I spent a plenty of time, trying to figure out what is going on. In my previous comment I also pointed out that implementation probably should be fixed too, since interpreter tries to import module from module, which should not be possible according to docs. It may be an issue for Python 3 too, but I did not check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 16:36:34 2013 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 Jan 2013 15:36:34 +0000 Subject: [issue16889] facilitate log output starting at beginning of line In-Reply-To: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za> Message-ID: <1357659394.35.0.590925146363.issue16889@psf.upfronthosting.co.za> Vinay Sajip added the comment: > I had in mind outside projects and the larger community for this request Fair enough - then the best place for the specialisation of stream and handler would seem to be unittest/unittest2. So I'll add Michael Foord to the nosy list. ---------- nosy: +michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 16:51:20 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 08 Jan 2013 15:51:20 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357660280.53.0.277314259144.issue5066@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Regardless of the topic of merge, the suggested improvements for both idle.rst and help.txt are great! Thanks for working the patch, Todd. I am +1 with the changes. If no else has any comments, I can go ahead with committing this. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 17:02:14 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 08 Jan 2013 16:02:14 +0000 Subject: [issue16730] _fill_cache in _bootstrap.py crashes without directory execute permissions In-Reply-To: <1355928901.47.0.243119596238.issue16730@psf.upfronthosting.co.za> Message-ID: <1357660934.17.0.0635746332217.issue16730@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 17:12:23 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Jan 2013 16:12:23 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357661543.72.0.976796230983.issue5066@psf.upfronthosting.co.za> Zachary Ware added the comment: I'd like to see ?ric, Ezio, and my comments on v3 in Rietveld addressed, but after that I'm good with it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 17:32:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 08 Jan 2013 16:32:43 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357662763.45.0.730178980725.issue16748@psf.upfronthosting.co.za> Brett Cannon added the comment: It's totally doable to set up stubs in Lib/test to use test discovery on those tests which exist outside of that directory. test_importlib actually has some code for that left over from when it lived in Lib/importlib/test: http://hg.python.org/cpython/file/4617b7ac302a/Lib/test/test_importlib/__init__.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 17:45:12 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Jan 2013 16:45:12 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst Message-ID: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> New submission from Zachary Ware: Lib/idlelib/help.txt and Doc/library/idle.rst contain almost exactly the same information, only formatted a bit differently. This issue is to suggest the merger of the two files, by way of creating help.txt from idle.rst as a part of the build or install process. This could be as simple as merely copying the one to the other, but that of course leaves in place all reST directives that mean nothing to a simple text document. Thus, idle.rst should be processed to create help.txt. This could be done with sphinx/docutils, but to avoid having the CPython build process (not just the doc build process) depend on those tools, I think a very simple dedicated script could be created to do the processing without much trouble. As far as I can tell, this new script would only have to do a few simple steps: - Remove comments (including index markers, etc.) - Remove reST roles (replace ":role:`" with "`", possibly remove "`" as well) - Remove backslash escapes - Remove (or undouble) double colons - Replace "#." with "1.", etc. Thoughts? ---------- assignee: docs at python components: Documentation, IDLE messages: 179362 nosy: Todd.Rovito, docs at python, eric.araujo, zach.ware priority: normal severity: normal status: open title: Create IDLE help.txt from Doc/library/idle.rst type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 17:45:35 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Jan 2013 16:45:35 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357663535.19.0.18600143266.issue5066@psf.upfronthosting.co.za> Zachary Ware added the comment: Issue 16893 has been filed to deal with the idea of merging the files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 19:43:12 2013 From: report at bugs.python.org (David Beazley) Date: Tue, 08 Jan 2013 18:43:12 +0000 Subject: [issue16894] Function attribute access doesn't invoke methods in dict subclasses Message-ID: <1357670592.25.0.470525675752.issue16894@psf.upfronthosting.co.za> New submission from David Beazley: Suppose you subclass a dictionary: class mdict(dict): def __getitem__(self, index): print('Getting:', index) return super().__getitem__(index) Now, suppose you define a function and perform these steps that reassign the function's attribute dictionary: >>> def foo(): ... pass ... >>> foo.__dict__ = mdict() >>> foo.x = 23 >>> foo.x # Observe: No output from overridden __getitem__ 23 >>> type(foo.__dict__) >>> foo.__dict__ {'x': 23} >>> Carefully observe that access to foo.x does not invoke the overridden __getitem__() method in mdict. Instead, it just directly accesses the default __getitem__() on dict. Admittedly, this is a really obscure corner case. However, if the __dict__ attribute of a function can be legally reassigned, it might be nice for inheritance to work ;-). ---------- components: Interpreter Core messages: 179364 nosy: dabeaz priority: normal severity: normal status: open title: Function attribute access doesn't invoke methods in dict subclasses type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 19:52:55 2013 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 08 Jan 2013 18:52:55 +0000 Subject: [issue16894] Function attribute access doesn't invoke methods in dict subclasses In-Reply-To: <1357670592.25.0.470525675752.issue16894@psf.upfronthosting.co.za> Message-ID: <1357671175.41.0.954812303988.issue16894@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 19:56:12 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2013 18:56:12 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357671372.67.0.737421563839.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ok, I fixed test_writer_callback() in the tulip repo. Indeed the error I reported first is gone now. I logged the value of kev on failure, and got this output: ERROR:root:kev = Traceback (most recent call last): File "/Users/guido/tulip/tulip/selectors.py", line 178, in _key_from_fd return self._fd_to_key[fd] KeyError: 83 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/guido/tulip/tulip/selectors.py", line 330, in select key = self._key_from_fd(fd) File "/Users/guido/tulip/tulip/selectors.py", line 180, in _key_from_fd raise RuntimeError("No key found for fd {}".format(fd)) RuntimeError: No key found for fd 83 The full traceback printed by the unittest framework was: ERROR: test_sock_client_ops (tulip.events_test.KqueueEventLoopTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/guido/tulip/tulip/selectors.py", line 178, in _key_from_fd return self._fd_to_key[fd] KeyError: 83 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/guido/tulip/tulip/events_test.py", line 168, in test_sock_client_ops el.run_until_complete(el.sock_sendall(sock, b'GET / HTTP/1.0\r\n\r\n')) File "/Users/guido/tulip/tulip/unix_events.py", line 146, in run_until_complete self.run() File "/Users/guido/tulip/tulip/unix_events.py", line 110, in run self._run_once() File "/Users/guido/tulip/tulip/unix_events.py", line 582, in _run_once event_list = self._selector.select(timeout) File "/Users/guido/tulip/tulip/selectors.py", line 330, in select key = self._key_from_fd(fd) File "/Users/guido/tulip/tulip/selectors.py", line 180, in _key_from_fd raise RuntimeError("No key found for fd {}".format(fd)) RuntimeError: No key found for fd 83 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 20:06:06 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 08 Jan 2013 19:06:06 +0000 Subject: [issue16894] Function attribute access doesn't invoke methods in dict subclasses In-Reply-To: <1357670592.25.0.470525675752.issue16894@psf.upfronthosting.co.za> Message-ID: <1357671966.91.0.474697608912.issue16894@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 20:08:19 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Jan 2013 19:08:19 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled In-Reply-To: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> Message-ID: <3Ygjfp131tzPCP@mail.python.org> Roundup Robot added the comment: New changeset 1d8effd379c3 by Charles-Fran?ois Natali in branch '2.7': Issue #16836: Enable IPv6 support even if IPv6 is disabled on the build host. http://hg.python.org/cpython/rev/1d8effd379c3 New changeset d5df9ed118c5 by Charles-Fran?ois Natali in branch '3.2': Issue #16836: Enable IPv6 support even if IPv6 is disabled on the build host. http://hg.python.org/cpython/rev/d5df9ed118c5 New changeset ebfd847bc15a by Charles-Fran?ois Natali in branch '3.3': Issue #16836: Enable IPv6 support even if IPv6 is disabled on the build host. http://hg.python.org/cpython/rev/ebfd847bc15a New changeset f7e563478349 by Charles-Fran?ois Natali in branch 'default': Issue #16836: Enable IPv6 support even if IPv6 is disabled on the build host. http://hg.python.org/cpython/rev/f7e563478349 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 20:35:32 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 08 Jan 2013 19:35:32 +0000 Subject: [issue16836] configure script disables support for IPv6 on a system where IPv6 is disabled In-Reply-To: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za> Message-ID: <1357673732.84.0.250860000764.issue16836@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Should be fixed now, thanks. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 21:03:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 20:03:02 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357675382.69.0.395349088188.issue16886@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be good actually get rid of doctests, turning them into unittests. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 21:43:41 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Jan 2013 20:43:41 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows Message-ID: <1357677821.21.0.151237367429.issue16895@psf.upfronthosting.co.za> New submission from Zachary Ware: I find myself frustrated with some of the hoops I have to jump through and extra things I have to remember when I want to play around with Python on Windows. To make things a little easier, I've created a 'make.bat' file that can sit in the root of the repository and do a few of the more common tasks: make [build] [-64] -- Runs Tools\buildbot\build[-amd64].bat make clean [-64] -- Runs Tools\buildbot\clean[-amd64].bat make doc [args] -- Runs Doc\make.bat [args] with %PYTHON% set to 'py.exe -2' make patchcheck -- Runs Tools\scripts\patchcheck.py make test [test args] -- Runs the test suite with passed arguments It seems to work pretty well for me and I think it could be very useful to others, particularly new contributors. I'm sure there's plenty of room for improvement, though :) I don't know if this script might interfere or conflict with Cygwin or other tools; if so and it were decided to include this file, it could easily be renamed to 'wmake.bat' or some such. Hope this is useful enough to include, or at least useful to someone else :) ---------- components: Windows files: Make.bat messages: 179369 nosy: zach.ware priority: normal severity: normal status: open title: Batch file to mimic 'make' on Windows type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28632/Make.bat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 21:47:46 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 08 Jan 2013 20:47:46 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357678066.04.0.685424572725.issue16748@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Also, it may be possible to add unittest discovery hooks to the stubs that *are* in Lib/test. The load_tests protocol (2.7, 3.2+) seems like the right approach for this: http://docs.python.org/dev/library/unittest.html#load-tests-protocol ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 21:51:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 20:51:21 +0000 Subject: [issue9242] unicodeobject.c: use of uninitialized values In-Reply-To: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za> Message-ID: <1357678281.63.0.255349193969.issue9242@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I?forgot mention the issue number in commit messages. See changeset3570e04f4ea9 and changesetbf347198fbaf. Is the issue fixed now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 21:51:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 20:51:57 +0000 Subject: [issue9242] unicodeobject.c: use of uninitialized values In-Reply-To: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za> Message-ID: <1357678317.68.0.855288040416.issue9242@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: changeset 3570e04f4ea9 and changeset bf347198fbaf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 22:07:48 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Jan 2013 21:07:48 +0000 Subject: [issue16896] Fix test discovery for test_asyncore.py Message-ID: <1357679268.03.0.58943461997.issue16896@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's the fix for test_asyncore.py. ---------- components: Tests files: test_asyncore_fix.diff keywords: patch messages: 179373 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_asyncore.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28633/test_asyncore_fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 22:39:05 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Jan 2013 21:39:05 +0000 Subject: [issue16897] Fix test discovery for test_bisect.py Message-ID: <1357681145.64.0.619169785001.issue16897@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's the fix for test_bisect.py. This one has an extra change, that of replacing the manual method of obtaining c_bisect and py_bisect with two calls to support.import_fresh_module. This one also has an extra wrench thrown in the gears by including a few doctests. I haven't changed anything in relation to those doctests, but I wonder if there's really any point to keeping them there considering they claim to be pulled from the docs but are in fact significantly different from what is in the docs these days. ---------- components: Tests files: test_bisect_fix.diff keywords: patch messages: 179374 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_bisect.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28634/test_bisect_fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 22:43:35 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Jan 2013 21:43:35 +0000 Subject: [issue16898] Fix test discovery for test_bufio.py Message-ID: <1357681415.26.0.614642834127.issue16898@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: Tests files: test_bufio_fix.diff keywords: patch nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_bufio.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28635/test_bufio_fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 22:47:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Jan 2013 21:47:35 +0000 Subject: [issue11461] UTF-16 incremental decoder doesn't support partial surrogate pair In-Reply-To: <1299752398.22.0.888282532941.issue11461@psf.upfronthosting.co.za> Message-ID: <3YgnBb03BxzMKB@mail.python.org> Roundup Robot added the comment: New changeset f2353e74b335 by Serhiy Storchaka in branch '2.7': Issue #11461: Fix the incremental UTF-16 decoder. Original patch by http://hg.python.org/cpython/rev/f2353e74b335 New changeset 4677c5f6fcf7 by Serhiy Storchaka in branch '3.2': Issue #11461: Fix the incremental UTF-16 decoder. Original patch by http://hg.python.org/cpython/rev/4677c5f6fcf7 New changeset eed1883b1974 by Serhiy Storchaka in branch '3.3': Issue #11461: Fix the incremental UTF-16 decoder. Original patch by http://hg.python.org/cpython/rev/eed1883b1974 New changeset 5e84d020d001 by Serhiy Storchaka in branch 'default': Issue #11461: Fix the incremental UTF-16 decoder. Original patch by http://hg.python.org/cpython/rev/5e84d020d001 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 22:49:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 21:49:54 +0000 Subject: [issue11461] UTF-16 incremental decoder doesn't support partial surrogate pair In-Reply-To: <1299752398.22.0.888282532941.issue11461@psf.upfronthosting.co.za> Message-ID: <1357681794.89.0.835982355385.issue11461@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:01:25 2013 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Jan 2013 22:01:25 +0000 Subject: [issue9242] unicodeobject.c: use of uninitialized values In-Reply-To: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za> Message-ID: <1357682485.52.0.722154595758.issue9242@psf.upfronthosting.co.za> Stefan Krah added the comment: The utf_32_le_decode invalid access is gone; for Valgrind the issue is fixed (I didn't look at the patch, no time ATM, sorry). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:02:10 2013 From: report at bugs.python.org (Piotr Dobrogost) Date: Tue, 08 Jan 2013 22:02:10 +0000 Subject: [issue4773] HTTPMessage not documented and has inconsistent API across Py2/Py3 In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za> Message-ID: <1357682530.61.0.509745759312.issue4773@psf.upfronthosting.co.za> Piotr Dobrogost added the comment: @joel.verhagen "Should HTTPResponse.getheaders() comma-separate the values (...)" No, it should not. RFC 2616 states: "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]." As field-values for some header fields ('Set-Cookie' being an example) are not defined as a comma-separated list such fields must not be merged. Side note: RFC 2616 is very soon to be obsoleted by the new RFC from httpbin working group. However, in the current/newest draft (http://trac.tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21#section-3.2) although wording is different the sense is the same. ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:06:03 2013 From: report at bugs.python.org (Vladimir Rutsky) Date: Tue, 08 Jan 2013 22:06:03 +0000 Subject: [issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex Message-ID: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za> New submission from Vladimir Rutsky: It would be nice if Python will be able to access variables with C99 complex types through ctypes module. ---------- components: ctypes messages: 179378 nosy: rutsky priority: normal severity: normal status: open title: Add support for C99 complex type (_Complex) as ctypes.c_complex type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:07:40 2013 From: report at bugs.python.org (Piotr Dobrogost) Date: Tue, 08 Jan 2013 22:07:40 +0000 Subject: [issue4773] HTTPMessage not documented and has inconsistent API across Py2/Py3 In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za> Message-ID: <1357682860.9.0.483114765909.issue4773@psf.upfronthosting.co.za> Piotr Dobrogost added the comment: ...continuing my previous comment Joining headers with the same name by ", " by HTTPResponse.getheaders() in Python 2.7 is wrong and there's a bug for this - see http://bugs.python.org/issue1660009 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:16:07 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Jan 2013 22:16:07 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> Message-ID: <3YgnqW16jNzPCZ@mail.python.org> Roundup Robot added the comment: New changeset ab36d3bb5996 by Serhiy Storchaka in branch '3.3': Issue #16843: Make concurrent tests for sched module deterministic. http://hg.python.org/cpython/rev/ab36d3bb5996 New changeset f65eae38f71e by Serhiy Storchaka in branch 'default': Issue #16843: Make concurrent tests for sched module deterministic. http://hg.python.org/cpython/rev/f65eae38f71e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:17:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 22:17:33 +0000 Subject: [issue16843] sporadic test_sched failure In-Reply-To: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za> Message-ID: <1357683453.12.0.266347538458.issue16843@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:22:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Jan 2013 22:22:10 +0000 Subject: [issue9242] unicodeobject.c: use of uninitialized values In-Reply-To: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za> Message-ID: <1357683730.68.0.827483737203.issue9242@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:22:25 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2013 22:22:25 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357683745.75.0.934833660685.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: Figured it out. KqueueSelector was missing the unregister() implementation. Here it is: def unregister(self, fileobj): key = super().unregister(fileobj) mask = 0 if key.events & SELECT_IN: mask |= KQ_FILTER_READ if key.events & SELECT_OUT: mask |= KQ_FILTER_WRITE kev = kevent(key.fd, mask, KQ_EV_DELETE) self._kqueue.control([kev], 0, 0) I also added a __repr__ to the _Key class: def __repr__(self): return '{}'.format( self.__class__.__name__, self.fileobj, self.fd, self.events, self.data) Attached a new patch for tulip (but no new patch for select.py). I think I may have left the debug logging in. I will submit this to the Tulip repo, but we still need the changes for SELECT_CONNECT (I can't really test that, still no Windows access). ---------- Added file: http://bugs.python.org/file28636/tulip-selectors-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:31:38 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 08 Jan 2013 22:31:38 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357671372.67.0.737421563839.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: This should fix some kqueue failures (the FDs were not unregistered, which could result in spurious FDs being reported at a later time). For the "negative FDs", all spurious events are now caught and logged (I think it's better than silently ignoring them as it is now). Hopefully we'll see an EV_ERROR with kev.data set to a sensible errno. The implementation should now be more or less complete, apart from the WSAPoll, which I'm unable to add/test. Richard, in Tulip's WSAPoll code, it reads: class WindowsPollPollster(PollPollster): """Pollster implementation using WSAPoll. WSAPoll is only available on Windows Vista and later. Python does not currently support WSAPoll, but there is a patch available at http://bugs.python.org/issue16507. """ Does this means that this code need the patch from issue #16507 to work? Also, I've read something about IOCP: is this a replacement for WSAPoll, are there plans to get it merged at some point to python (and if yes, would the select module be a proper home for this)? ---------- Added file: http://bugs.python.org/file28637/tulip-selectors-3.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff --git a/runtests.py b/runtests.py --- a/runtests.py +++ b/runtests.py @@ -2,9 +2,12 @@ # Originally written by Beech Horn (for NDB). +import logging import sys import unittest +##logging.basicConfig(level=logging.DEBUG) + def load_tests(): mods = ['events', 'futures', 'tasks'] diff --git a/tulip/events_test.py b/tulip/events_test.py --- a/tulip/events_test.py +++ b/tulip/events_test.py @@ -10,6 +10,7 @@ from . import events from . import transports from . import protocols +from . import selectors from . import unix_events @@ -37,8 +38,8 @@ class EventLoopTestsMixin: def setUp(self): - pollster = self.POLLSTER_CLASS() - event_loop = unix_events.UnixEventLoop(pollster) + selector = self.SELECTOR_CLASS() + event_loop = unix_events.UnixEventLoop(selector) events.set_event_loop(event_loop) def testRun(self): @@ -230,24 +231,24 @@ el.run_once() -if hasattr(select, 'kqueue'): +if hasattr(selectors, 'KqueueSelector'): class KqueueEventLoopTests(EventLoopTestsMixin, unittest.TestCase): - POLLSTER_CLASS = unix_events.KqueuePollster + SELECTOR_CLASS = selectors.KqueueSelector -if hasattr(select, 'epoll'): +if hasattr(selectors, 'EpollSelector'): class EPollEventLoopTests(EventLoopTestsMixin, unittest.TestCase): - POLLSTER_CLASS = unix_events.EPollPollster + SELECTOR_CLASS = selectors.EpollSelector -if hasattr(select, 'poll'): +if hasattr(selectors, 'PollSelector'): class PollEventLoopTests(EventLoopTestsMixin, unittest.TestCase): - POLLSTER_CLASS = unix_events.PollPollster + SELECTOR_CLASS = selectors.PollSelector # Should always exist. class SelectEventLoopTests(EventLoopTestsMixin, unittest.TestCase): - POLLSTER_CLASS = unix_events.SelectPollster + SELECTOR_CLASS = selectors.SelectSelector class HandlerTests(unittest.TestCase): diff --git a/tulip/selectors.py b/tulip/selectors.py new file mode 100644 --- /dev/null +++ b/tulip/selectors.py @@ -0,0 +1,372 @@ +"""Select module. + +This module supports asynchronous I/O on multiple file descriptors. +""" + + +import logging +from select import * + + +# generic events, that must be mapped to implementation-specific ones +# read event +SELECT_IN = (1 << 0) +# write event +SELECT_OUT = (1 << 1) +# connect event +SELECT_CONNECT = SELECT_OUT + + +def _fileobj_to_fd(fileobj): + """Return a file descriptor from a file object. + + Parameters: + fileobj -- file descriptor, or any object with a `fileno()` method + + Returns: + corresponding file descriptor + """ + if isinstance(fileobj, int): + fd = fileobj + else: + try: + fd = int(fileobj.fileno()) + except (ValueError, TypeError): + raise ValueError("Invalid file object: {}".format(fileobj)) + return fd + + +class _Key: + """Object used internally to associate a file object to its backing file + descriptor, selected event mask and attached data.""" + + def __init__(self, fileobj, events, data=None): + self.fileobj = fileobj + self.fd = _fileobj_to_fd(fileobj) + self.events = events + self.data = data + + +class _BaseSelector: + """Base selector class. + + A selector supports registering file objects to be monitored for specific + I/O events. + + A file object is a file descriptor or any object with a `fileno()` method. + An arbitrary object can be attached to the file object, which can be used + for example to store context information, a callback, etc. + + A selector can use various implementations (select(), poll(), epoll()...) + depending on the platform. The default `Selector` class uses the most + performant implementation on the current platform. + """ + + def __init__(self): + # this maps file descriptors to keys + self._fd_to_key = {} + # this maps file objects to keys - for fast (un)registering + self._fileobj_to_key = {} + + def register(self, fileobj, events, data=None): + """Register a file object. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + if (not events) or (events & ~(SELECT_IN|SELECT_OUT)): + raise ValueError("Invalid events: {}".format(events)) + + if fileobj in self._fileobj_to_key: + raise KeyError("{} is already registered".format(fileobj)) + + key = _Key(fileobj, events, data) + self._fd_to_key[key.fd] = key + self._fileobj_to_key[fileobj] = key + return key + + def unregister(self, fileobj): + """Unregister a file object. + + Parameters: + fileobj -- file object + """ + try: + key = self._fileobj_to_key[fileobj] + del self._fd_to_key[key.fd] + del self._fileobj_to_key[fileobj] + except KeyError: + raise KeyError("{} is not registered".format(fileobj)) + return key + + def modify(self, fileobj, events, data=None): + """Change a registered file object monitored events or attached data. + + Parameters: + fileobj -- file object + events -- events to monitor (bitwise mask of SELECT_IN|SELECT_OUT) + data -- attached data + """ + self.unregister(fileobj) + self.register(fileobj, events, data) + + def select(self, timeout=None): + """Perform the actual selection, until some monitored file objects are + ready or a timeout expires. + + Parameters: + timeout -- if timeout > 0, this specifies the maximum wait time, in + seconds + if timeout == 0, the select() call won't block, and will + report the currently ready file objects + if timeout is None, select() will block until a monitored + file object becomes ready + + Returns: + list of (fileobj, events, attached data) for ready file objects + `events` is a bitwise mask of SELECT_IN|SELECT_OUT + """ + raise NotImplementedError() + + def close(self): + """Close the selector. + + This must be called to make sure that any underlying resource is freed. + """ + self._fd_to_key.clear() + self._fileobj_to_key.clear() + + def get_info(self, fileobj): + """Return information about a registered file object. + + Returns: + (events, data) associated to this file object + + Raises KeyError if the file object is not registered. + """ + try: + key = self._fileobj_to_key[fileobj] + except KeyError: + raise KeyError("{} is not registered".format(fileobj)) + return key.events, key.data + + def registered_count(self): + """Return the number of registered file objects. + + Returns: + number of currently registered file objects + """ + return len(self._fd_to_key) + + def __enter__(self): + return self + + def __exit__(self, *args): + self.close() + + def _key_from_fd(self, fd): + """Return the key associated to a given file descriptor. + + Parameters: + fd -- file descriptor + + Returns: + corresponding key + """ + return self._fd_to_key[fd] + + +class SelectSelector(_BaseSelector): + """Select-based selector.""" + + def __init__(self): + super().__init__() + self._readers = set() + self._writers = set() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + if events & SELECT_IN: + self._readers.add(key.fd) + if events & SELECT_OUT: + self._writers.add(key.fd) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._readers.discard(key.fd) + self._writers.discard(key.fd) + + def select(self, timeout=None): + r, w, _ = select(self._readers, self._writers, [], timeout) + r = set(r) + w = set(w) + ready = [] + for fd in r | w: + events = 0 + if fd in r: + events |= SELECT_IN + if fd in w: + events |= SELECT_OUT + + try: + key = self._key_from_fd(fd) + except KeyError: + logging.warning("select: spurious fd={}".format(fd)) + else: + ready.append((key.fileobj, events, key.data)) + return ready + + +if 'poll' in globals(): + + class PollSelector(_BaseSelector): + """Poll-based selector.""" + + def __init__(self): + super().__init__() + self._poll = poll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + poll_events = 0 + if events & SELECT_IN: + poll_events |= POLLIN + if events & SELECT_OUT: + poll_events |= POLLOUT + self._poll.register(key.fd, poll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._poll.unregister(key.fd) + + def select(self, timeout=None): + timeout = None if timeout is None else int(1000 * timeout) + ready = [] + for fd, event in self._poll.poll(timeout): + events = 0 + if event & ~POLLIN: + events |= SELECT_OUT + if event & ~POLLOUT: + events |= SELECT_IN + + try: + key = self._key_from_fd(fd) + except KeyError: + logging.warning("poll: spurious fd={} " + "event={}".format(fd, event)) + else: + ready.append((key.fileobj, events, key.data)) + return ready + + +if 'epoll' in globals(): + + class EpollSelector(_BaseSelector): + """Epoll-based selector.""" + + def __init__(self): + super().__init__() + self._epoll = epoll() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + epoll_events = 0 + if events & SELECT_IN: + epoll_events |= EPOLLIN + if events & SELECT_OUT: + epoll_events |= EPOLLOUT + self._epoll.register(key.fd, epoll_events) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + self._epoll.unregister(key.fd) + + def select(self, timeout=None): + timeout = -1 if timeout is None else timeout + max_ev = self.registered_count() + ready = [] + for fd, event in self._epoll.poll(timeout, max_ev): + events = 0 + if event & ~EPOLLIN: + events |= SELECT_OUT + if event & ~EPOLLOUT: + events |= SELECT_IN + + try: + key = self._key_from_fd(fd) + except KeyError: + logging.warning("epoll: spurious fd={} " + "event={}".format(fd, event)) + else: + ready.append((key.fileobj, events, key.data)) + return ready + + def close(self): + super().close() + self._epoll.close() + + +if 'kqueue' in globals(): + + class KqueueSelector(_BaseSelector): + """Kqueue-based selector.""" + + def __init__(self): + super().__init__() + self._kqueue = kqueue() + + def register(self, fileobj, events, data=None): + key = super().register(fileobj, events, data) + if events & SELECT_IN: + kev = kevent(key.fd, KQ_FILTER_READ, KQ_EV_ADD) + self._kqueue.control([kev], 0, 0) + if events & SELECT_OUT: + kev = kevent(key.fd, KQ_FILTER_WRITE, KQ_EV_ADD) + self._kqueue.control([kev], 0, 0) + + def unregister(self, fileobj): + key = super().unregister(fileobj) + if key.events & SELECT_IN: + kev = select.kevent(key.fd, KQ_FILTER_READ, KQ_EV_DELETE) + self._kqueue.control([kev], 0, 0) + if key.events & SELECT_OUT: + kev = select.kevent(key.fd, KQ_FILTER_WRITE, KQ_EV_DELETE) + self._kqueue.control([kev], 0, 0) + + def select(self, timeout=None): + max_ev = self.registered_count() + ready = [] + for kev in self._kqueue.control(None, max_ev, timeout): + fd = kev.ident + flag = kev.filter + events = 0 + if flag == KQ_FILTER_READ: + events |= SELECT_IN + if flag == KQ_FILTER_WRITE: + events |= SELECT_OUT + + try: + key = self._key_from_fd(fd) + except KeyError: + logging.warning("kqueue: spurious kev={}".format(kev)) + else: + ready.append((key.fileobj, events, key.data)) + return ready + + def close(self): + super().close() + self._kqueue.close() + + +# Choose the best implementation: roughly, epoll|kqueue > poll > select. +# select() also can't accept a FD > FD_SETSIZE (usually around 1024) +if 'KqueueSelector' in globals(): + Selector = KqueueSelector +elif 'EpollSelector' in globals(): + Selector = EpollSelector +elif 'PollSelector' in globals(): + Selector = PollSelector +else: + Selector = SelectSelector diff --git a/tulip/unix_events.py b/tulip/unix_events.py --- a/tulip/unix_events.py +++ b/tulip/unix_events.py @@ -1,10 +1,8 @@ """UNIX event loop and related classes. -NOTE: The Pollster classes are not part of the published API. - -The event loop can be broken up into a pollster (the part responsible +The event loop can be broken up into a selector (the part responsible for telling us when file descriptors are ready) and the event loop -proper, which wraps a pollster with functionality for scheduling +proper, which wraps a selector with functionality for scheduling callbacks, immediately or at a given time in the future. Whenever a public API takes a callback, subsequent positional @@ -13,22 +11,6 @@ Keyword arguments for the callback are not supported; this is a conscious design decision, leaving the door open for keyword arguments to modify the meaning of the API call itself. - -There are several implementations of the pollster part, several using -esoteric system calls that exist only on some platforms. These are: - -- kqueue (most BSD systems) -- epoll (newer Linux systems) -- poll (most UNIX systems) -- select (all UNIX systems, and Windows) - -NOTE: We don't use select on systems where any of the others is -available, because select performs poorly as the number of file -descriptors goes up. The ranking is roughly: - - 1. kqueue, epoll, IOCP (best for each platform) - 2. poll (linear in number of file descriptors polled) - 3. select (linear in max number of file descriptors supported) """ import collections @@ -46,6 +28,7 @@ from . import events from . import futures from . import protocols +from . import selectors from . import tasks from . import transports @@ -73,352 +56,6 @@ _MAX_WORKERS = 5 -class PollsterBase: - """Base class for all polling implementations. - - This defines an interface to register and unregister readers and - writers for specific file descriptors, and an interface to get a - list of events. There's also an interface to check whether any - readers or writers are currently registered. - """ - - def __init__(self): - super().__init__() - self.readers = {} # {fd: handler, ...}. - self.writers = {} # {fd: handler, ...}. - - def pollable(self): - """Return the number readers and writers currently registered.""" - # The event loop needs the number since it must subtract one for - # the self-pipe. - return len(self.readers) + len(self.writers) - - # Subclasses are expected to extend the add/remove methods. - - def register_reader(self, fd, handler): - """Add or update a reader for a file descriptor.""" - self.readers[fd] = handler - - def register_writer(self, fd, handler): - """Add or update a writer for a file descriptor.""" - self.writers[fd] = handler - - def unregister_reader(self, fd): - """Remove the reader for a file descriptor.""" - del self.readers[fd] - - def unregister_writer(self, fd): - """Remove the writer for a file descriptor.""" - del self.writers[fd] - - def register_connector(self, fd, handler): - """Add or update a connector for a file descriptor.""" - # On Unix a connector is the same as a writer. - self.register_writer(fd, handler) - - def unregister_connector(self, fd): - """Remove the connector for a file descriptor.""" - # On Unix a connector is the same as a writer. - self.unregister_writer(fd) - - def poll(self, timeout=None): - """Poll for I/O events. A subclass must implement this. - - If timeout is omitted or None, this blocks until at least one - event is ready. Otherwise, timeout gives a maximum time to - wait (an int of float in seconds) -- the method returns as - soon as at least one event is ready or when the timeout is - expired. For a non-blocking poll, pass 0. - - The return value is a list of events; it is empty when the - timeout expired before any events were ready. Each event - is a handler previously passed to register_reader/writer(). - """ - raise NotImplementedError - - -if sys.platform != 'win32': - - class SelectPollster(PollsterBase): - """Pollster implementation using select.""" - - def poll(self, timeout=None): - readable, writable, _ = select.select(self.readers, self.writers, - [], timeout) - events = [] - events += (self.readers[fd] for fd in readable) - events += (self.writers[fd] for fd in writable) - return events - -else: - - class SelectPollster(PollsterBase): - """Pollster implementation using select.""" - - def __init__(self): - super().__init__() - self.exceptionals = {} - - def poll(self, timeout=None): - # Failed connections are reported as exceptional but not writable. - readable, writable, exceptional = select.select( - self.readers, self.writers, self.exceptionals, timeout) - writable = set(writable).union(exceptional) - events = [] - events += (self.readers[fd] for fd in readable) - events += (self.writers[fd] for fd in writable) - return events - - def register_connector(self, fd, token): - self.register_writer(fd, token) - self.exceptionals[fd] = token - - def unregister_connector(self, fd): - self.unregister_writer(fd) - try: - del self.exceptionals[fd] - except KeyError: - # remove_connector() does not check fd in self.exceptionals. - pass - - -class PollPollster(PollsterBase): - """Pollster implementation using poll.""" - - def __init__(self): - super().__init__() - self._poll = select.poll() - - def _update(self, fd): - assert isinstance(fd, int), fd - flags = 0 - if fd in self.readers: - flags |= select.POLLIN - if fd in self.writers: - flags |= select.POLLOUT - if flags: - self._poll.register(fd, flags) - else: - self._poll.unregister(fd) - - def register_reader(self, fd, handler): - super().register_reader(fd, handler) - self._update(fd) - - def register_writer(self, fd, handler): - super().register_writer(fd, handler) - self._update(fd) - - def unregister_reader(self, fd): - super().unregister_reader(fd) - self._update(fd) - - def unregister_writer(self, fd): - super().unregister_writer(fd) - self._update(fd) - - def poll(self, timeout=None): - # Timeout is in seconds, but poll() takes milliseconds. - msecs = None if timeout is None else int(round(1000 * timeout)) - events = [] - for fd, flags in self._poll.poll(msecs): - if flags & ~select.POLLOUT: - if fd in self.readers: - events.append(self.readers[fd]) - if flags & ~select.POLLIN: - if fd in self.writers: - events.append(self.writers[fd]) - return events - - -if sys.platform == 'win32': - - class WindowsPollPollster(PollPollster): - """Pollster implementation using WSAPoll. - - WSAPoll is only available on Windows Vista and later. Python - does not currently support WSAPoll, but there is a patch - available at http://bugs.python.org/issue16507. - """ - - # REAP_PERIOD is the maximum wait before checking for failed - # connections. This is necessary because WSAPoll() does notify us - # of failed connections. See - # daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/ - REAP_PERIOD = 5.0 - - # FD_SETSIZE is maximum number of sockets in an fd_set - FD_SETSIZE = 512 - - def __init__(self): - super().__init__() - self.exceptionals = {} - - def register_connector(self, fd, token): - self.register_writer(fd, token) - self.exceptionals[fd] = token - - def unregister_connector(self, fd): - self.unregister_writer(fd) - try: - del self.exceptionals[fd] - except KeyError: - # remove_connector() does not check fd in self.exceptionals. - pass - - def _get_failed_connector_events(self): - fds = [] - remaining = list(self.exceptionals) - while remaining: - fds += select.select([], [], remaining[:self.FD_SETSIZE], 0)[2] - del remaining[:self.FD_SETSIZE] - return [(fd, select.POLLOUT) for fd in fds] - - def poll(self, timeout=None): - if not self.exceptionals: - msecs = None if timeout is None else int(round(1000 * timeout)) - polled = self._poll.poll(msecs) - - elif timeout is None: - polled = None - while not polled: - polled = (self._get_failed_connector_events() or - self._poll.poll(self.REAP_PERIOD)) - - elif timeout == 0: - polled = (self._get_failed_connector_events() or - self._poll.poll(0)) - - else: - start = time.monotonic() - deadline = start + timeout - polled = None - while timeout >= 0: - msecs = int(round(1000 * min(self.REAP_PERIOD, timeout))) - polled = (self._get_failed_connector_events() or - self._poll.poll(self.REAP_PERIOD)) - if polled: - break - timemout = deadline - time.monotonic() - - events = [] - for fd, flags in polled: - if flags & ~select.POLLOUT: - if fd in self.readers: - events.append(self.readers[fd]) - if flags & ~select.POLLIN: - if fd in self.writers: - events.append(self.writers[fd]) - return events - - PollPollster = WindowsPollPollster - - -class EPollPollster(PollsterBase): - """Pollster implementation using epoll.""" - - def __init__(self): - super().__init__() - self._epoll = select.epoll() - - def _update(self, fd): - assert isinstance(fd, int), fd - eventmask = 0 - if fd in self.readers: - eventmask |= select.EPOLLIN - if fd in self.writers: - eventmask |= select.EPOLLOUT - if eventmask: - try: - self._epoll.register(fd, eventmask) - except IOError: - self._epoll.modify(fd, eventmask) - else: - self._epoll.unregister(fd) - - def register_reader(self, fd, handler): - super().register_reader(fd, handler) - self._update(fd) - - def register_writer(self, fd, handler): - super().register_writer(fd, handler) - self._update(fd) - - def unregister_reader(self, fd): - super().unregister_reader(fd) - self._update(fd) - - def unregister_writer(self, fd): - super().unregister_writer(fd) - self._update(fd) - - def poll(self, timeout=None): - if timeout is None: - timeout = -1 # epoll.poll() uses -1 to mean "wait forever". - events = [] - for fd, eventmask in self._epoll.poll(timeout): - if eventmask & ~select.EPOLLOUT: - if fd in self.readers: - events.append(self.readers[fd]) - if eventmask & ~select.EPOLLIN: - if fd in self.writers: - events.append(self.writers[fd]) - return events - - -class KqueuePollster(PollsterBase): - """Pollster implementation using kqueue.""" - - def __init__(self): - super().__init__() - self._kqueue = select.kqueue() - - def register_reader(self, fd, handler): - if fd not in self.readers: - kev = select.kevent(fd, select.KQ_FILTER_READ, select.KQ_EV_ADD) - self._kqueue.control([kev], 0, 0) - return super().register_reader(fd, handler) - - def register_writer(self, fd, handler): - if fd not in self.writers: - kev = select.kevent(fd, select.KQ_FILTER_WRITE, select.KQ_EV_ADD) - self._kqueue.control([kev], 0, 0) - return super().register_writer(fd, handler) - - def unregister_reader(self, fd): - super().unregister_reader(fd) - kev = select.kevent(fd, select.KQ_FILTER_READ, select.KQ_EV_DELETE) - self._kqueue.control([kev], 0, 0) - - def unregister_writer(self, fd): - super().unregister_writer(fd) - kev = select.kevent(fd, select.KQ_FILTER_WRITE, select.KQ_EV_DELETE) - self._kqueue.control([kev], 0, 0) - - def poll(self, timeout=None): - events = [] - max_ev = len(self.readers) + len(self.writers) - for kev in self._kqueue.control(None, max_ev, timeout): - fd = kev.ident - flag = kev.filter - if flag == select.KQ_FILTER_READ and fd in self.readers: - events.append(self.readers[fd]) - elif flag == select.KQ_FILTER_WRITE and fd in self.writers: - events.append(self.writers[fd]) - return events - - -# Pick the best pollster class for the platform. -if hasattr(select, 'kqueue'): - best_pollster = KqueuePollster -elif hasattr(select, 'epoll'): - best_pollster = EPollPollster -elif hasattr(select, 'poll'): - best_pollster = PollPollster -else: - best_pollster = SelectPollster - - class _StopError(BaseException): """Raised to stop the event loop.""" @@ -433,12 +70,13 @@ See events.EventLoop for API specification. """ - def __init__(self, pollster=None): + def __init__(self, selector=None): super().__init__() - if pollster is None: - logging.info('Using pollster: %s', best_pollster.__name__) - pollster = best_pollster() - self._pollster = pollster + if selector is None: + # pick the best selector class for the platform + selector = selectors.Selector() + logging.info('Using selector: %s', selector.__name__) + self._selector = selector self._ready = collections.deque() self._scheduled = [] self._everytime = [] @@ -465,7 +103,9 @@ TODO: Give this a timeout too? """ - while self._ready or self._scheduled or self._pollster.pollable() > 1: + while (self._ready or + self._scheduled or + self._selector.registered_count() > 1): try: self._run_once() except _StopError: @@ -702,36 +342,83 @@ def add_reader(self, fd, callback, *args): """Add a reader callback. Return a Handler instance.""" handler = events.Handler(None, callback, args) - self._pollster.register_reader(fd, handler) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + self._selector.register(fd, selectors.SELECT_IN, + (handler, None, None)) + else: + self._selector.modify(fd, mask | selectors.SELECT_IN, + (handler, writer, connector)) + return handler def remove_reader(self, fd): """Remove a reader callback.""" - if fd in self._pollster.readers: - self._pollster.unregister_reader(fd) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + pass + else: + mask &= ~selectors.SELECT_IN + if not mask: + self._selector.unregister(fd) + else: + self._selector.modify(fd, mask, (None, writer, connector)) def add_writer(self, fd, callback, *args): """Add a writer callback. Return a Handler instance.""" handler = events.Handler(None, callback, args) - self._pollster.register_writer(fd, handler) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + self._selector.register(fd, selectors.SELECT_OUT, + (None, handler, None)) + else: + self._selector.modify(fd, mask | selectors.SELECT_OUT, + (reader, handler, connector)) return handler def remove_writer(self, fd): """Remove a writer callback.""" - if fd in self._pollster.writers: - self._pollster.unregister_writer(fd) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + pass + else: + mask &= ~selectors.SELECT_OUT + if not mask: + self._selector.unregister(fd) + else: + self._selector.modify(fd, mask, (reader, None, connector)) def add_connector(self, fd, callback, *args): """Add a connector callback. Return a Handler instance.""" - dcall = events.Handler(None, callback, args) - self._pollster.register_connector(fd, dcall) - return dcall + # XXX As long as SELECT_CONNECT == SELECT_OUT, set the handler + # as both writer and connector. + handler = events.Handler(None, callback, args) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + self._selector.register(fd, selectors.SELECT_CONNECT, + (None, handler, handler)) + else: + self._selector.modify(fd, mask | selectors.SELECT_CONNECT, + (reader, handler, handler)) + return handler def remove_connector(self, fd): """Remove a connector callback.""" - # Every connector fd is in self._pollsters.writers. - if fd in self._pollster.writers: - self._pollster.unregister_connector(fd) + try: + mask, (reader, writer, connector) = self._selector.get_info(fd) + except KeyError: + pass + else: + mask &= ~selectors.SELECT_CONNECT + if not mask: + self._selector.unregister(fd) + else: + self._selector.modify(fd, mask, (reader, None, None)) def sock_recv(self, sock, n): """XXX""" @@ -743,7 +430,7 @@ fd = sock.fileno() if registered: # Remove the callback early. It should be rare that the - # pollster says the fd is ready but the call still returns + # selector says the fd is ready but the call still returns # EAGAIN, and I am willing to take a hit in that case in # order to simplify the common case. self.remove_reader(fd) @@ -876,10 +563,10 @@ while self._scheduled and self._scheduled[0].cancelled: heapq.heappop(self._scheduled) - # Inspect the poll queue. If there's exactly one pollable + # Inspect the poll queue. If there's exactly one selectable # file descriptor, it's the self-pipe, and if there's nothing # scheduled, we should ignore it. - if self._pollster.pollable() > 1 or self._scheduled: + if self._selector.registered_count() > 1 or self._scheduled: if self._ready: timeout = 0 elif self._scheduled: @@ -892,7 +579,7 @@ timeout = min(timeout, deadline) t0 = time.monotonic() - events = self._pollster.poll(timeout) + event_list = self._selector.select(timeout) t1 = time.monotonic() argstr = '' if timeout is None else ' %.3f' % timeout if t1-t0 >= 1: @@ -900,8 +587,13 @@ else: level = logging.DEBUG logging.log(level, 'poll%s took %.3f seconds', argstr, t1-t0) - for handler in events: - self._add_callback(handler) + for fileobj, mask, (reader, writer, connector) in event_list: + if mask & selectors.SELECT_IN and reader is not None: + self._add_callback(reader) + if mask & selectors.SELECT_OUT and writer is not None: + self._add_callback(writer) + elif mask & selectors.SELECT_CONNECT and connector is not None: + self._add_callback(connector) # Handle 'later' callbacks that are ready. now = time.monotonic() From report at bugs.python.org Tue Jan 8 23:44:20 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2013 22:44:20 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357685060.26.0.32819103296.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: Whoops, the unregister() function needs to return key. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:45:27 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2013 22:45:27 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357685127.73.0.538137593182.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: That ought to be added to the docstrings for register()/unregister() in _BaseSelector. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:47:49 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2013 22:47:49 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357685269.17.0.504090526337.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: A patch for making register()/unregister() return the key. ---------- Added file: http://bugs.python.org/file28638/return_key_fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:51:40 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Tue, 08 Jan 2013 22:51:40 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <1357657242.34.0.55047373045.issue16076@psf.upfronthosting.co.za> Message-ID: <20130108225134.GJ3822@lp-shahaf.local> Daniel Shahaf added the comment: Eli Bendersky wrote on Tue, Jan 08, 2013 at 15:00:42 +0000: > > Eli Bendersky added the comment: > > P = import_fresh_module('xml.etree.ElementTree', blocked=['_elementtree']) > tb = P.TreeBuilder(element_factory=lambda a, b: [a, b]) > print(pickle.dumps(tb)) > > Gives: _pickle.PicklingError: Can't pickle : attribute lookup builtins.function failed Is that with or without the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 8 23:52:52 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 08 Jan 2013 22:52:52 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357685572.97.0.27629205601.issue16853@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: As it is now, _Key is actually an implementation detail, that's why it's not part of the methods signature. Oonly the base register()/unregister() return the key because it's an easy way for the derived classes to get the FD without calling _fileobj_to_fd again (it's not really elegant, I'm open to suggestions). We could make it part of the API though, and maybe return it also from get_info() instead of the (fileobj, data) tuple. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:07:15 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Jan 2013 23:07:15 +0000 Subject: [issue16850] Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357686435.02.0.241406422699.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: According to the following script, FD_CLOEXEC is available on: * Solaris 8 * HP-UX 11 * Unicos 9.0 * Digital UNIX 4.0 * SunOS 4.1.1_U1 * IRIX 6.5 * Linux 2.0 and Linux 2.4 with glibc 2.2.3 * AIX 4.2 (Versions are tested versions, it doesn't mean that the flag didn't exist before) http://sam.nipl.net/ssh-fast/fsh/fshcompat.py -- Note: On Windows, it's possible to implement fcntl(fd, F_SETFD, FD_CLOEXEC) using: SetHandleInformation(fd, HANDLE_FLAG_INHERIT, 1). See for example: https://github.com/tav/pylibs/blob/master/tornado/win32_support.py#L36 I don't know if it's useful since it's possible to set the flag directly when the file is opened (using O_NOINHERIT). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:08:37 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Jan 2013 23:08:37 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357686517.45.0.197363274476.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please consider my patches instead; it seems our patches crossed. Merging is now difficult because I already submitted my version to Tulip. Your version still has a bug: it uses select.kevent(...) twice, where it should just use kevent(...). Also my version makes fewer syscalls when unregistering a FD that has both read and write events registered. Regarding the _Key return value: I think it's asking for trouble if the signature of the base class differs from that of the subclass. The return value may even be useful occasionally. Given that no spurious FD events are now reported by the unittests, I'm not sure that it is useful to log and ignore them; it may be better to have the exception be raised, as it might expose an app bug, and in my experience it usually ends up in an infinite busy-wait loop once it happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:09:52 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Jan 2013 23:09:52 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za> Message-ID: <1357686592.84.0.214083657272.issue12107@psf.upfronthosting.co.za> STINNER Victor added the comment: See also #5715 which asks for something similar. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:12:09 2013 From: report at bugs.python.org (Piotr Dobrogost) Date: Tue, 08 Jan 2013 23:12:09 +0000 Subject: [issue1660009] continuing problem with httplib multiple set-cookie headers Message-ID: <1357686728.99.0.509642082074.issue1660009@psf.upfronthosting.co.za> Piotr Dobrogost added the comment: @jjlee What you said re commas in 2007 was wrong and still is. Joining (with commas) multiple header field values having the same field name unconditionally (without knowing it's safe) was not allowed by RFC 2616 and still is not allowed by the upcoming new RFC. See my comment at http://bugs.python.org/issue4773#msg179377 This was fixed in Python 3 - see http://bugs.python.org/issue4773#msg154781 As this is backward incompatible change (and I guess weather this is private api or not does not matter here) and there's working alternative (although it's private api) nothing will be done here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:13:55 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 08 Jan 2013 23:13:55 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357686835.93.0.349875688591.issue16853@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Richard, in Tulip's WSAPoll code, it reads: > > class WindowsPollPollster(PollPollster): > """Pollster implementation using WSAPoll. > > WSAPoll is only available on Windows Vista and later. Python > does not currently support WSAPoll, but there is a patch > available at http://bugs.python.org/issue16507. > """ > > Does this means that this code need the patch from issue #16507 to work? Yes. > Also, I've read something about IOCP: is this a replacement for > WSAPoll, are there plans to get it merged at some point to python (and > if yes, would the select module be a proper home for this)? IOCP is not a replacement for WSAPoll (or select). Among other things it is not possible to use the current ssl module with IOCP (although Twisted manages to use IOCP with PyOpenSSL). Tulip should have IOCP support, so presumable when tulip is merged some support for IOCP will also be available in python. But I am not convinced that the select module is the proper home. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:13:59 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 08 Jan 2013 23:13:59 +0000 Subject: [issue16076] xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable In-Reply-To: <20130108225134.GJ3822@lp-shahaf.local> Message-ID: Eli Bendersky added the comment: On Tue, Jan 8, 2013 at 2:51 PM, Daniel Shahaf wrote: > > Daniel Shahaf added the comment: > > Eli Bendersky wrote on Tue, Jan 08, 2013 at 15:00:42 +0000: > > > > Eli Bendersky added the comment: > > > > P = import_fresh_module('xml.etree.ElementTree', > blocked=['_elementtree']) > > tb = P.TreeBuilder(element_factory=lambda a, b: [a, b]) > > print(pickle.dumps(tb)) > > > > Gives: _pickle.PicklingError: Can't pickle : attribute > lookup builtins.function failed > > Is that with or without the patch? > Without. Pickle can't handle functions that are not top-level, so bound methods, internal functions, lambdas are all out. So pickling probably wasn't a first priority for the Python version of TreeBuilder as well... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:17:40 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Jan 2013 23:17:40 +0000 Subject: [issue16900] SSL sockets don't give resource warnings Message-ID: <1357687060.67.0.213189094158.issue16900@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Python 3.3.0+ (3.3:ab36d3bb5996+, Jan 8 2013, 17:08:35) [GCC 4.5.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> del s __main__:1: ResourceWarning: unclosed >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> import ssl >>> ssl.wrap_socket(s) >>> del s We can just remove the __del__ on SSLSocket, right? ---------- messages: 179394 nosy: benjamin.peterson priority: normal severity: normal status: open title: SSL sockets don't give resource warnings type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:24:44 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Tue, 08 Jan 2013 23:24:44 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357687484.47.0.0828125202159.issue16076@psf.upfronthosting.co.za> Daniel Shahaf added the comment: Dissociating TreeBuilder from this issue per recent comments. ---------- title: xml.etree.ElementTree.Element and xml.etree.ElementTree.TreeBuilder are no longer pickleable -> xml.etree.ElementTree.Element is no longer pickleable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:26:00 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Jan 2013 23:26:00 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za> Message-ID: <1357687560.69.0.936289086978.issue12107@psf.upfronthosting.co.za> STINNER Victor added the comment: "Note that I don't like the idea of falling back to FD_CLOEXEC since it's not atomic, and some people might rely on this." There is a similar question (atomic or best effort) for the #16860 issue. It looks like more people prefer the best effort option. IMO most people prefer to use the best available method to set the close-on-exec flag, but doesn't really care if the method is not atomic (and the OS doesn't provide an atomic function). If someone cannot accept the best effort option: I guess that it is still possible to override TCPServer constructor to ensure that the action is atomic. "It would already be a nice piece of progress if you could request the SO_CLOEXEC (with fallback to FD_CLOEXEC), say, in the constructor, or even with a module variable." Yes, close-on-exec flag should be configurable, as TCPServer.allow_reuse_address for example. I like the class attribute, something like TCPServer.close_on_exec, False by default, for example. -- "I realize this bugreport cannot fix 35 years of a bad design decision in linux." Well... Ruby made a brave choice :-) Ruby (2.0?) does set close-on-exec flag on *ALL file descriptors (except 0, 1, 2) *by default*: http://bugs.ruby-lang.org/issues/5041 This change solves the problem of having to close all file descriptor after a fork to run a new program (see closed Python issues #11284 and #8052)... if you are not using C extensions creating file descriptors? Ruby applications relying on passing FD to child processes have to explicitly disable close-on-exec the flag: it was done in Unicorn for example. "But we can't simply change the default to FD_CLOEXEC, for two reasons: - we can't silently change the Unix semantics - this is going to break some applications: for example, FD inherited across exec is used by super servers such as inetd, and there are others very legitimate uses" Yes, changing the default value of the flag (enable close-on-exec by default) will break some applications. But if we chose to do it, developers of these applications can still disable close-on-exec (because the option must be configurable) to fix their application for Python 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:29:19 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Jan 2013 23:29:19 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za> Message-ID: <1357687759.87.0.521324368336.issue12107@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, by the way: I never understood why SimpleXMLRPCServer does set FD_CLOEXEC (since the issue #1222790), whereas TCPServer doesn't. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:37:01 2013 From: report at bugs.python.org (py.user) Date: Tue, 08 Jan 2013 23:37:01 +0000 Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work Message-ID: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za> New submission from py.user: >>> import http.cookiejar >>> cjf = http.cookiejar.FileCookieJar() >>> cjf.load('file.txt') Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load self._really_load(f, filename, ignore_discard, ignore_expires) AttributeError: 'FileCookieJar' object has no attribute '_really_load' >>> >>> >>> import http.cookiejar >>> cjf = http.cookiejar.FileCookieJar('file.txt') >>> cjf.load() Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load self._really_load(f, filename, ignore_discard, ignore_expires) AttributeError: 'FileCookieJar' object has no attribute '_really_load' >>> >>> >>> cjf.revert() Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.3/http/cookiejar.py", line 1789, in revert self.load(filename, ignore_discard, ignore_expires) File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load self._really_load(f, filename, ignore_discard, ignore_expires) AttributeError: 'FileCookieJar' object has no attribute '_really_load' >>> ---------- components: Library (Lib) messages: 179398 nosy: py.user priority: normal severity: normal status: open title: In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:40:01 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 08 Jan 2013 23:40:01 +0000 Subject: [issue16891] Fix docs about module search order In-Reply-To: <1357657456.34.0.665470191827.issue16891@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: The docs sometimes try to draw a sharp distinction between modules and packages, but it's essentially a lie - a package is really just a module with a __path__ attribute, and if you know what you are doing, you make even an ordinary module behave like a package (e.g. os.path) Until 3.3, the import system had too many internal inconsistencies for sane documentation. That's fixed in 3.3, but no comprehensive docs will be happening for earlier versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:48:35 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Tue, 08 Jan 2013 23:48:35 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357688915.69.0.6310525509.issue16076@psf.upfronthosting.co.za> Daniel Shahaf added the comment: v8 removes TreeBuilder handling (code + tests) and removes memcpy per review. (Outstanding issues in the review can be fixed post-v8, if needed.) ---------- Added file: http://bugs.python.org/file28639/i16076-v8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 00:49:27 2013 From: report at bugs.python.org (py.user) Date: Tue, 08 Jan 2013 23:49:27 +0000 Subject: [issue16715] Get rid of IOError. Use OSError instead In-Reply-To: <3YW0Xs2j15zRkN@mail.python.org> Message-ID: <1357688967.7.0.0581684235023.issue16715@psf.upfronthosting.co.za> py.user added the comment: found a typo (removed LoadError) commit 80f2b1273e8c0e1a28fabe537ae9c5acbbcee187 Author: Andrew Svetlov Date: Tue Dec 25 16:47:37 2012 +0200 Replace IOError with OSError (#16715) ... diff --git a/Lib/http/cookiejar.py b/Lib/http/cookiejar.py index a77dc3f..7928e9b 100644 --- a/Lib/http/cookiejar.py +++ b/Lib/http/cookiejar.py ... @@ -1786,7 +1786,7 @@ class FileCookieJar(CookieJar): self._cookies = {} try: self.load(filename, ignore_discard, ignore_expires) - except (LoadError, IOError): + except OSError: self._cookies = old_state raise ---------- nosy: +py.user _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 01:07:17 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Jan 2013 00:07:17 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za> Message-ID: <1357690037.94.0.786606736501.issue12107@psf.upfronthosting.co.za> STINNER Victor added the comment: socketserver_close_on_exec.patch: - Add TCPServer.close_on_exec class attribute: True by default if the fcntl module is present, False otherwise - Use SOCK_CLOEXEC if present, fcntl() + FD_CLOEXEC otherwise Even if SOCK_CLOEXEC is present, fcntl() is used to check the flag "works" (if FD_CLOEXEC was set). If SOCK_CLOEXEC works, fcntl() will not be called anymore, otherwise we fall back to fcntl() + FD_CLOEXEC. I implemented this fallback for Linux older than 2.6.27. I don't know if SOCK_CLOEXEC is simply ignored, as Linux did for O_CLOEXEC, but I don't have such old Linux version to test. I chose to set close-on-exec flag *by default*. If we chose to disable it by default, the following changes should be done on my patch: - TCPServer.close_on_exec : "close_on_exec = (fcntl is not None)" => "close_on_exec = False" - SimpleXMLRPCServer: add close_on_exec class attribute, "close_on_exec = (fcntl is not None)" (and restore try/except ImportError for fcntl) ---------- keywords: +patch Added file: http://bugs.python.org/file28640/socketserver_close_on_exec.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 01:07:26 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Jan 2013 00:07:26 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za> Message-ID: <1357690046.75.0.584603077864.issue12107@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 01:09:22 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Jan 2013 00:09:22 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za> Message-ID: <1357690162.6.0.497023163636.issue12107@psf.upfronthosting.co.za> STINNER Victor added the comment: > There is a similar question (atomic or best effort) for the #16860 issue. It looks like more people prefer the best effort option. Oops, it's the issue #16850: Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 01:36:58 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Jan 2013 00:36:58 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za> Message-ID: <1357691818.52.0.528231265113.issue12107@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I completly forgot the client socket for TCP servers: updated patch. The patch version 2 uses fcntl()+FD_CLOEXEC after accept(). It is not atomic, but I prefer to leave to problem to issue #10115: "can be fixed on systems that support it through accept4(), but it seems to break badly on some systems, see issue #10115" ---------- Added file: http://bugs.python.org/file28641/socketserver_close_on_exec-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 01:59:03 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 09 Jan 2013 00:59:03 +0000 Subject: [issue16891] Fix docs about module search order In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za> Message-ID: <1357693143.38.0.107908594805.issue16891@psf.upfronthosting.co.za> Nick Coghlan added the comment: That said, the originally proposed docs change looks like a solid improvement to me. It's still a lie, but an appropriate one for the tutorial. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 03:30:50 2013 From: report at bugs.python.org (Todd Rovito) Date: Wed, 09 Jan 2013 02:30:50 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357698650.88.0.369370940549.issue5066@psf.upfronthosting.co.za> Todd Rovito added the comment: Thanks Senthil but I don't deserve all the credit this issue is a team effort with lots of help from Zach, ?ric, and Ezio. All of which have improved the patch's quality a great deal. Hopefully we can address the issues then let you make the commit soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 04:29:41 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 03:29:41 +0000 Subject: [issue16814] use --directory option of make in describing how to build the docs In-Reply-To: <1356790311.86.0.00498941541992.issue16814@psf.upfronthosting.co.za> Message-ID: <1357702181.06.0.0623563610466.issue16814@psf.upfronthosting.co.za> Chris Jerdonek added the comment: For the record, we do have tutorial-like documentation and document more than one way to do things in multiple places throughout the devguide. For example: http://docs.python.org/devguide/faq.html#how-do-i-list-the-files-in-conflict-after-a-merge Unlike the short options for long commands, though, it's not obvious to look for something like `make -C` (because you don't already know it's there). That's why I think this option is more deserving. Personally, when working on doc patches, I frequently go back and forth between `make html` and `hg diff`. Knowing about -C means one doesn't have to cd up and down the directory each time or double-check what directory one is in. I think it's okay and should even be a goal of the devguide to point out more efficient ways to contribute, which may sometimes involve saying more than the minimum (e.g. saying how something works, or stating a more "advanced" way to do something). I still think we should strive for conciseness within those constraints. Here is a new patch that makes the current language more concise in addition to some other minor changes. ---------- Added file: http://bugs.python.org/file28642/issue-16814-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 06:14:22 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 05:14:22 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357708462.73.0.238396265486.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: I just noticed that the devguide already contains a section in the FAQ about Mercurial. Would it make sense to move/keep questions for committers only in the committing.rst page, and leave the generic question in faq.rst? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 06:29:19 2013 From: report at bugs.python.org (Todd Rovito) Date: Wed, 09 Jan 2013 05:29:19 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357709359.9.0.27263907082.issue5066@psf.upfronthosting.co.za> Todd Rovito added the comment: I took all the comments and created a new patch version 4 which should address all the issues. Thanks for the excellent review and support from everybody. I think this patch is a much higher quality now. ---------- Added file: http://bugs.python.org/file28643/5066IDLEocumentationforUnixObsoleteIncorrectVersion4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 06:39:07 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 05:39:07 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357709947.37.0.704429085436.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Since this patch is on the longer side, would it be possible to use the "Remote hg repo" feature so Rietveld will work? I assume this is possible for devguide patches. Regarding the FAQ, it seems preferable to me to keep all questions in the FAQ, even if non-committers might not need to know the answer. It seems like it would be difficult to draw that line anyways, unless the question is about the Python commit process itself -- in which case it's probably not a generic Mercurial question anyways. We also have the option of creating a new subsection of the FAQ if it makes sense to do so (e.g. a subsection about Committing). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 06:57:21 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 05:57:21 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357711041.96.0.313648603428.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Since this patch is on the longer side, would it be possible to use > the "Remote hg repo" feature so Rietveld will work? I was actually thinking about doing this for the devguide and for the peps repos, using the "components" to determine what repo should be used. I'm not sure the remote hg repo supports non-cpython repos. > Regarding the FAQ, it seems preferable to me to keep all questions in > the FAQ, even if non-committers might not need to know the answer. What I was doing was converting the current prose in smaller FAQ-like sections, so that it's easier to navigate and it's in the same page where "committing" is explained. Having all the "committers FAQs" here has the advantage that it's easier to search and that regular contributors can skip the whole page. OTOH some committers might want to still look at the regular FAQs for answers to more generic Mercurial questions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:03:20 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 06:03:20 +0000 Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches nothing. Ditto B and Z. In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za> Message-ID: <1357711400.15.0.143389690485.issue13899@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:06:55 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 06:06:55 +0000 Subject: [issue16851] Hint about correct ismethod and isfunction usage In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1357711615.94.0.484196998431.issue16851@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: docs at python -> ezio.melotti stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:10:59 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 06:10:59 +0000 Subject: [issue16896] Fix test discovery for test_asyncore.py In-Reply-To: <1357679268.03.0.58943461997.issue16896@psf.upfronthosting.co.za> Message-ID: <1357711859.6.0.883917686237.issue16896@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:15:01 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 06:15:01 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357712101.44.0.557687332283.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I'm not sure the remote hg repo supports non-cpython repos. Can you try? I would be surprised if it didn't. > What I was doing was converting the current prose in smaller FAQ-like sections Okay, then it sounds like they're more like sections that fit into the natural flow of the main body of text. That's fine with me. I got the impression you were moving questions in the current FAQ. It is good, though, to have the main instructions be smaller and easier to read through, with sections describing short-cuts and other non-essential info separated off into linkable chunks (in committers.rst or elsewhere). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:17:01 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 06:17:01 +0000 Subject: [issue16897] Fix test discovery for test_bisect.py In-Reply-To: <1357681145.64.0.619169785001.issue16897@psf.upfronthosting.co.za> Message-ID: <1357712221.86.0.251820179405.issue16897@psf.upfronthosting.co.za> Ezio Melotti added the comment: The best thing would be converting them to unittest (if there aren't already unittests for that). A general comment about these patches: I think it would be better to remove test_main() (and related unnecessary code) with unittest.main(). One of the advantage of doing it now is that you can simply test discovery by doing ./python Lib/test/test_foo.py. This is currently being discussed on #16748, but I think we pretty much agree on this. ---------- assignee: -> ezio.melotti stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:17:41 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 06:17:41 +0000 Subject: [issue16898] Fix test discovery for test_bufio.py Message-ID: <1357712261.61.0.622184624735.issue16898@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:27:44 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 06:27:44 +0000 Subject: [issue16814] use --directory option of make in describing how to build the docs In-Reply-To: <1356790311.86.0.00498941541992.issue16814@psf.upfronthosting.co.za> Message-ID: <1357712864.71.0.329384080589.issue16814@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I frequently go back and forth between `make html` and `hg diff`. Mercurial commands work on the whole repo, regardless on the dir you are in (unlike SVN ones). That's why I usually just cd in Doc/ and do everything (opening files with editor/browser, make *, hg *) from there. Even when I prepare a patch I can do `hg di > ../patch.diff` if I want it in the root. I don't think there's any harm in mentioning briefly `make -C Doc html` though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:38:45 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 06:38:45 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357713525.35.0.38971761707.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Can you try? I would be surprised if it didn't. IIRC it does a diff between the head of the cpython repo and the head of the linked one. > Okay, then it sounds like they're more like sections that fit into > the natural flow of the main body of text. Yes, the idea is that the first few FAQs describe the "regular" workflow in order (committing, merging, pushing), but than I was planning to mention a few other cases, e.g. null-merges or merge conflicts. Some of these might already be in the FAQs. FWIW I uploaded the rst file to make reviews easier. I moved two sections that were not related to Mercurial to the top (Handling Others' Code and Contributor Licensing Agreements). What I'm working on is the "Working with Mercurial" part. Everything in there is either new or an adaptation of the previous text. I also removed a couple of things (e.g. the differences between svnmerge and hg merge). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 07:47:22 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 06:47:22 +0000 Subject: [issue16897] Fix test discovery for test_bisect.py In-Reply-To: <1357712221.86.0.251820179405.issue16897@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: > A general comment about these patches: I think it would be better to remove test_main() (and related unnecessary code) with unittest.main(). One of the advantage of doing it now is that you can simply test discovery by doing ./python Lib/test/test_foo.py. > > This is currently being discussed on #16748, but I think we pretty much agree on this. > Ah yes, I meant to do that and completely forgot about it. I'll go through and do that on the ones I've made patches for so far in the morning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:03:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 07:03:15 +0000 Subject: [issue16897] Fix test discovery for test_bisect.py In-Reply-To: <1357681145.64.0.619169785001.issue16897@psf.upfronthosting.co.za> Message-ID: <1357714995.71.0.696766747692.issue16897@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think that here all the test_main() can be removed except support.run_doctest(test_bisect, verbose). This should probably be moved after unittest.main() (unless the doctests are removed/converted to unittest). Refcounting is already provided by regrtest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:18:18 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 07:18:18 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357715898.24.0.944438136849.issue14468@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- hgrepos: +168 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:19:25 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 07:19:25 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357715965.83.0.301673279312.issue14468@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- hgrepos: -168 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:20:04 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 07:20:04 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357716004.4.0.981544344154.issue14468@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- hgrepos: +169 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:21:14 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 07:21:14 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357716074.37.0.139997483655.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Sorry, my apologies for the mess-ups! ---------- hgrepos: +170 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:21:24 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 07:21:24 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357716084.39.0.61004959494.issue14468@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- hgrepos: -169 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:23:45 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 07:23:45 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357716225.98.0.384805344166.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Okay, it looks like you can't do it. It failed with a "repository is unrelated" error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:35:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Jan 2013 07:35:25 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <3Yh2Dr46G2zRxC@mail.python.org> Roundup Robot added the comment: New changeset 3f2637a6fbfa by Ezio Melotti in branch 'default': #16868: mention that you can "ping" issues before writing to python-dev. http://hg.python.org/devguide/rev/3f2637a6fbfa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:39:18 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 07:39:18 +0000 Subject: [issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za> Message-ID: <1357717158.5.0.235250073406.issue16868@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed with a slightly different wording (thanks Chris for the suggestion). Thanks Todd for the report and the initial patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 08:55:45 2013 From: report at bugs.python.org (Dmitry Mugtasimov) Date: Wed, 09 Jan 2013 07:55:45 +0000 Subject: [issue16891] Fix docs about module search order In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za> Message-ID: <1357718145.67.0.756708715287.issue16891@psf.upfronthosting.co.za> Dmitry Mugtasimov added the comment: Further investigation led me to the conclusion that "TO BE" should look like this: 6.1.2. The Module Search Path When a module named spam is imported, the interpreter first searches in the containing package (the package of which the current module is a submodule) if applicable (a module is not required to be a submodule of a package). If not found or module is not a part of any package it searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 09:02:21 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 09 Jan 2013 08:02:21 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357686517.45.0.197363274476.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Please consider my patches instead; it seems our patches crossed. Merging is now difficult because I already submitted my version to Tulip. That's fine, I don't think there's a point into maintaining a standalone patch for now: we can see how it goes with Tulip, flesh out the API and merge it when it's ready (or when Tulip goes in)? > Also my version makes fewer syscalls when unregistering a FD that has both read and write events registered. It did it on purpose, because I wasn't sure whether kqueue ops can accept more than one filter at a time. If that's the case, then you can do the same thing for register(). > Regarding the _Key return value: I think it's asking for trouble if the signature of the base class differs from that of the subclass. The return value may even be useful occasionally. Agreed (but then it might be better to change _Key to Key if it's public). > Given that no spurious FD events are now reported by the unittests, I'm not sure that it is useful to log and ignore them; it may be better to have the exception be raised, as it might expose an app bug, and in my experience it usually ends up in an infinite busy-wait loop once it happens. Sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 09:27:20 2013 From: report at bugs.python.org (brian-cameron-oracle) Date: Wed, 09 Jan 2013 08:27:20 +0000 Subject: [issue16902] Add OSS module support for Solaris Message-ID: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> New submission from brian-cameron-oracle: Solaris supports OSS, but the attached patch is needed to get it to build. Note that some of the EXPORT_INT lines in Modules/ossaudiodev.c need to be #ifndef'ed out on Sun since OSS on Solaris doesn't support them all. Does it make sense to use #ifndef like this, or should each EXPORT_INT be encapsulated by its own #ifdef? ---------- components: Extension Modules files: ossaudiodev.patch keywords: patch messages: 179424 nosy: brian-cameron-oracle priority: normal severity: normal status: open title: Add OSS module support for Solaris type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file28644/ossaudiodev.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 10:28:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 09:28:57 +0000 Subject: [issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 Message-ID: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: On 3.2 subprocess.Popen.communicate with universal_newlines=True accepts bytes and doesn't accept strings. $ ./python -c "import subprocess; subprocess.Popen(['cat'], stdin=subprocess.PIPE, stdout=subprocess.PIPE, universal_newlines=True).communicate('qwerty')" Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython3.2/Lib/subprocess.py", line 833, in communicate return self._communicate(input) File "/home/serhiy/py/cpython3.2/Lib/subprocess.py", line 1470, in _communicate stdout, stderr = self._communicate_with_poll(input) File "/home/serhiy/py/cpython3.2/Lib/subprocess.py", line 1537, in _communicate_with_poll input_offset += os.write(fd, chunk) TypeError: 'str' does not support the buffer interface On 3.3+ it accepts strings and doesn't accept bytes. ---------- components: IO, Library (Lib), Unicode messages: 179425 nosy: ezio.melotti, serhiy.storchaka priority: normal severity: normal status: open title: subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 10:29:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 09:29:45 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False In-Reply-To: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> Message-ID: <1357723785.31.0.141595546823.issue15649@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue16903. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 10:33:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 09:33:24 +0000 Subject: [issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za> Message-ID: <1357724004.3.0.547297536704.issue16903@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As quick fix I propose add support of strings (in additional to bytes) in 3.2. Perhaps we must also add support of bytes with warning in 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 10:38:29 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 09 Jan 2013 09:38:29 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1357687560.69.0.936289086978.issue12107@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > "I realize this bugreport cannot fix 35 years of a bad design decision in linux." > > Well... Ruby made a brave choice :-) Ruby (2.0?) does set > close-on-exec flag on *ALL file descriptors (except 0, 1, 2) *by > default*: > http://bugs.ruby-lang.org/issues/5041 > > This change solves the problem of having to close all file descriptor > after a fork to run a new program (see closed Python issues #11284 and > #8052)... if you are not using C extensions creating file descriptors? > "But we can't simply change the default to FD_CLOEXEC, for two reasons: > - we can't silently change the Unix semantics > - this is going to break some applications: for example, FD inherited across exec is used by super servers such as inetd, and there are others very legitimate uses" > > Yes, changing the default value of the flag (enable close-on-exec by default) will break some applications. But if we chose to do it, developers of these applications can still disable close-on-exec (because the option must be configurable) to fix their application for Python 3.4. Changing all FDs to close-on-exec by default would be a bold move (and even just for SocketServer). It ought to be default, but it's going to break some applications. That's definitely something which needs discussion (at not only on the tracker, I would could bring it up on python-dev). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 11:10:47 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 09 Jan 2013 10:10:47 +0000 Subject: [issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za> Message-ID: <1357726247.72.0.224409435904.issue16903@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 11:28:27 2013 From: report at bugs.python.org (Attila Gerendi) Date: Wed, 09 Jan 2013 10:28:27 +0000 Subject: [issue16904] Avoid unnecessary and possibly unsafe code from http.client.HTTPConnection.send Message-ID: <1357727307.69.0.69749124261.issue16904@psf.upfronthosting.co.za> New submission from Attila Gerendi: In http.client.HTTPConnection's send(data) method if data has attribute read after is handled correctly as file-like object and sent out successfully the code continues to what should be an else branch (~line 858) and tries to send out again the data. This is harmless in most situations but only by chance and also run's unnecessary code. I propose either to use an else branch for the code after line 858 or simply instead break return at line 853. Cheers, Sanyi ---------- components: Library (Lib) messages: 179429 nosy: sanyi priority: normal severity: normal status: open title: Avoid unnecessary and possibly unsafe code from http.client.HTTPConnection.send type: performance versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 11:29:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Jan 2013 10:29:25 +0000 Subject: [issue16491] IDLE and except: raise from In-Reply-To: <9C3C06E7F0934B209166A3DC454F8D19@HansPc> Message-ID: <3Yh65c2s7MzRwR@mail.python.org> Roundup Robot added the comment: New changeset f28aff31900a by Serhiy Storchaka in branch '3.2': Issue #16491: IDLE now prints chained exception tracebacks. http://hg.python.org/cpython/rev/f28aff31900a New changeset 3feead75c7a5 by Serhiy Storchaka in branch '3.3': Issue #16491: IDLE now prints chained exception tracebacks. http://hg.python.org/cpython/rev/3feead75c7a5 New changeset 0793d68a0eba by Serhiy Storchaka in branch 'default': Issue #16491: IDLE now prints chained exception tracebacks. http://hg.python.org/cpython/rev/0793d68a0eba ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 11:36:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 10:36:34 +0000 Subject: [issue16491] IDLE and except: raise from In-Reply-To: <9C3C06E7F0934B209166A3DC454F8D19@HansPc> Message-ID: <1357727794.8.0.677904926463.issue16491@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed. Thank you for report, Hans. ---------- components: +IDLE resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 12:13:37 2013 From: report at bugs.python.org (Berker Peksag) Date: Wed, 09 Jan 2013 11:13:37 +0000 Subject: [issue16905] Fix test discovery for test_warnings Message-ID: <1357730017.55.0.973895693576.issue16905@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: Tests files: test_warnings_discovery.diff keywords: patch nosy: berker.peksag, brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_warnings type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28645/test_warnings_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 12:31:39 2013 From: report at bugs.python.org (Prashant Kurnawal) Date: Wed, 09 Jan 2013 11:31:39 +0000 Subject: [issue16906] Bug in _PyUnicode_ClearStaticStrings() method of unicodeobject.c Message-ID: <1357731097.9.0.701098252698.issue16906@psf.upfronthosting.co.za> New submission from Prashant Kurnawal: I have embedded python3.3 in my application. I got a crash when I ran a python script containing sample TK window creation code in it. On interpreter shutdown, all strings are released (through _PyUnicode_ClearStaticStrings). (I Found this description in one of the comments of object.h header file) When I tried to debug python source, I found a defect in _PyUnicode_ClearStaticStrings() method. Existing function definition in python3.3 source (unicodeobject.c) is as follows void _PyUnicode_ClearStaticStrings() { _Py_Identifier *i; for (i = static_strings; i; i = i->next) { Py_DECREF(i->object); i->object = NULL; i->next = NULL; } } Here, for loop will not free all the static strings. It will free only the first static string in the list. This loop needs to be corrected. I corrected the loop in following way and its working fine for me. void _PyUnicode_ClearStaticStrings() { _Py_Identifier *i; while(static_strings->next != NULL) { i = static_strings; static_strings = static_strings->next; Py_DECREF(i->object); i->object = NULL; i->next = NULL; } Py_DECREF(static_strings->object); static_strings->object = NULL; static_strings = NULL; } Is this a bug or it is done so intentionally..? ---------- components: None files: unicodeobject.c messages: 179432 nosy: benjamin.peterson, brett.cannon, georg.brandl, goodger, larry, prashantkurnawal, python-dev priority: normal severity: normal status: open title: Bug in _PyUnicode_ClearStaticStrings() method of unicodeobject.c type: crash versions: Python 3.3 Added file: http://bugs.python.org/file28646/unicodeobject.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 12:36:58 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 09 Jan 2013 11:36:58 +0000 Subject: [issue16906] Bug in _PyUnicode_ClearStaticStrings() method of unicodeobject.c In-Reply-To: <1357731097.9.0.701098252698.issue16906@psf.upfronthosting.co.za> Message-ID: <1357731418.33.0.816906420492.issue16906@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's a bug; thanks for pointing this out. I always suspected that there was something wrong, but never found the time to look into it. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 13:22:42 2013 From: report at bugs.python.org (klo uo) Date: Wed, 09 Jan 2013 12:22:42 +0000 Subject: [issue16907] Distutils fails to build extension in path with spaces Message-ID: <1357734162.78.0.136546351961.issue16907@psf.upfronthosting.co.za> New submission from klo uo: I noticed this issue, while trying to compile Cython extension, when source file is in path with spaces. Extension wouldn't compile because LIBDIR is passed to MinGW g++ (though not to gcc) or MSVC compilers unquoted. I tracked the problem to "distutils/build_ext.py" in get_ext_fullpath() function. I patched it, this way: ======================================== --- build_ext.bak +++ build_ext.py @@ -647,6 +647,11 @@ package = '.'.join(modpath[0:-1]) build_py = self.get_finalized_command('build_py') package_dir = os.path.abspath(build_py.get_package_dir(package)) + try: + from win32api import GetShortPathName + package_dir = GetShortPathName(package_dir) + except: + pass # returning # package_dir/filename return os.path.join(package_dir, filename) ======================================== which is just one way to do it. ---------- assignee: eric.araujo components: Distutils messages: 179434 nosy: eric.araujo, klo.uo, tarek priority: normal severity: normal status: open title: Distutils fails to build extension in path with spaces versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 13:31:57 2013 From: report at bugs.python.org (Sworddragon) Date: Wed, 09 Jan 2013 12:31:57 +0000 Subject: [issue16908] Enhancing performance and memory usage Message-ID: <1357734717.89.0.0863381712936.issue16908@psf.upfronthosting.co.za> New submission from Sworddragon: On my system (Linux 64 Bit) I figured out that python 3 needs a little more memory than python 2 and it is a little bit slower. Here are some examples: sworddragon at ubuntu:~$ execution-time 'python2 -c print\("0"\)' 0.21738 sworddragon at ubuntu:~$ execution-time 'python2 -OO -c print\("0"\)' 0.22559 sworddragon at ubuntu:~$ execution-time 'python3 -c print\("0"\)' 0.37962 sworddragon at ubuntu:~$ execution-time 'python3 -OO -c print\("0"\)' 0.37825 Checking the memory usage after python 2 and python 3 are started in a terminal shows the following: python2: RES 4780 / SHR: 2212 python3: RES 6168 / SHR: 2660 ---------- components: Interpreter Core messages: 179435 nosy: Sworddragon priority: normal severity: normal status: open title: Enhancing performance and memory usage type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 13:50:07 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Jan 2013 12:50:07 +0000 Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za> Message-ID: <1357735807.92.0.118514552626.issue12107@psf.upfronthosting.co.za> STINNER Victor added the comment: > That's definitely something which needs discussion > (at not only on the tracker, I would could bring it up on python-dev). I agree, I started a thread on python-dev mailing list: https://mail.python.org/pipermail/python-dev/2013-January/123552.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 14:04:43 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 09 Jan 2013 13:04:43 +0000 Subject: [issue16908] Enhancing performance and memory usage In-Reply-To: <1357734717.89.0.0863381712936.issue16908@psf.upfronthosting.co.za> Message-ID: <1357736683.58.0.511639706031.issue16908@psf.upfronthosting.co.za> Ramchandra Apte added the comment: What is the problem? Python 3 uses more memory because many things that were earlier ASCII strings in Python 2 are Unicode strings. Same reason for performance AFAIK. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 14:09:44 2013 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 Jan 2013 13:09:44 +0000 Subject: [issue16908] Enhancing performance and memory usage In-Reply-To: <1357734717.89.0.0863381712936.issue16908@psf.upfronthosting.co.za> Message-ID: <1357736984.4.0.151055843678.issue16908@psf.upfronthosting.co.za> Georg Brandl added the comment: The "performance" you're measuring here is mostly startup, i.e. loading all necessary modules. On Python 3, there is more to load, e.g. the filesystem encoding, therefore startup takes a little longer. There are efforts to improve startup time, see e.g. #16101. The memory consumption is expected, again due to more modules loaded. You cannot make any statement about the memory usage of a real-world application by just measuring the overhead of the interpreter. The memory usage due to strings should be very similar to Python 2 starting with Python 3.3, due to PEP 393. ---------- nosy: +georg.brandl resolution: -> works for me status: open -> closed superseder: -> Verify all imported modules at startup are needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 14:17:22 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 09 Jan 2013 13:17:22 +0000 Subject: [issue16907] Distutils fails to build extension in path with spaces In-Reply-To: <1357734162.78.0.136546351961.issue16907@psf.upfronthosting.co.za> Message-ID: <1357737442.34.0.362637153412.issue16907@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Can you fix the bare except? ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 14:22:14 2013 From: report at bugs.python.org (klo uo) Date: Wed, 09 Jan 2013 13:22:14 +0000 Subject: [issue16907] Distutils fails to build extension in path with spaces In-Reply-To: <1357737442.34.0.362637153412.issue16907@psf.upfronthosting.co.za> Message-ID: <4510526198.20130109142211@gmail.com> klo uo added the comment: > Can you fix the bare except? ======================================== ... except ImportError: pass ======================================== ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 14:47:15 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 09 Jan 2013 13:47:15 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1357739235.5.0.30198713176.issue16261@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Here's a patch on revision 75fe7f5fda9a (I did it on a trip without an internet connection) There might be some mistakes of this type: I incorrectly changed instances like this ` try: something except: close file raise ` to ` try: something finally: close file ` (the incorrect version closes the file always) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 14:51:07 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 09 Jan 2013 13:51:07 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1357739467.3.0.862983283808.issue16261@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Sorry, I entered the wrong filename for the patch and so it didn't get attached. Now I have attached it. ---------- keywords: +patch Added file: http://bugs.python.org/file28647/patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 15:12:45 2013 From: report at bugs.python.org (Prashant Kurnawal) Date: Wed, 09 Jan 2013 14:12:45 +0000 Subject: [issue16906] Bug in _PyUnicode_ClearStaticStrings() method of unicodeobject.c In-Reply-To: <1357731097.9.0.701098252698.issue16906@psf.upfronthosting.co.za> Message-ID: <1357740765.57.0.173649297626.issue16906@psf.upfronthosting.co.za> Prashant Kurnawal added the comment: When are you planning to submit a fix for it..? This bug will be fixed in python3.3 and a new version of python3.3 will be released..? Or it will be fixed in python3.4..? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 15:24:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 14:24:33 +0000 Subject: [issue16907] Distutils fails to build extension in path with spaces In-Reply-To: <1357734162.78.0.136546351961.issue16907@psf.upfronthosting.co.za> Message-ID: <1357741473.88.0.225670999277.issue16907@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: get_ext_fullpath() has no relations to this bug. The bug is probably in spawn()?functions, perhaps in _nt_quote_args() or something like. It looks as Windows specific bug (Posix passes command arguments as a list, not joining it into string). ---------- components: +Windows nosy: +serhiy.storchaka stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 15:33:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 14:33:58 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1357742038.2.0.373287594034.issue16261@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unhappy Rietveld hasn't recognize your patch. I have regenerated it. ---------- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file28648/bare_except.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 15:45:16 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 14:45:16 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1357742716.88.0.18400141987.issue5066@psf.upfronthosting.co.za> Zachary Ware added the comment: Version 4 looks good to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 15:46:51 2013 From: report at bugs.python.org (Olof Johansson) Date: Wed, 09 Jan 2013 14:46:51 +0000 Subject: [issue16909] urlparse: add userinfo attribute Message-ID: <1357742811.51.0.916599948648.issue16909@psf.upfronthosting.co.za> New submission from Olof Johansson: Hi, The urlparse library's "netloc" attribute is today further split into the following attributes: username, password, hostname, port. The attributes preceding the @ (username, password) are refered to in RFC 3986 [1] as "userinfo", the format of which is scheme dependant. E.g. the (expired) internet draft for SSH/SFTP urls [2] have connection parameters within the userinfo (user;cparams at host). In some cases, the deprecated "username:password" syntax is required to be supported even with, e.g. "connection parameters". For this reason, I propose a new attribute, "userinfo", that exposes the "raw" userinfo string, without any splitting on : etc. I've had a go at a patch, with updated unit tests and documentation. Any feedback is welcome! Regards, 1: http://tools.ietf.org/rfc/rfc3986.txt 2: http://tools.ietf.org/id/draft-ietf-secsh-scp-sftp-ssh-uri-04.txt ---------- components: None files: urlparse_userinfo.diff keywords: patch messages: 179447 nosy: olof priority: normal severity: normal status: open title: urlparse: add userinfo attribute type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file28649/urlparse_userinfo.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:00:18 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 09 Jan 2013 15:00:18 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1357743618.08.0.0566752737068.issue16261@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > try: > _MAXFD = os.sysconf("SC_OPEN_MAX") > -except: > +except ValueError: > _MAXFD = 256 os.sysconf() might raise OSError. I think ValueError is only raised if _SC_OPEN_MAX was undefined when the module was compiled. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:05:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 15:05:43 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1357743943.64.0.420338962123.issue16261@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See my comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:17:56 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 15:17:56 +0000 Subject: [issue16852] Fix test discovery for test_genericpath.py In-Reply-To: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za> Message-ID: <1357744676.7.0.765588595956.issue16852@psf.upfronthosting.co.za> Zachary Ware added the comment: Version 4 replaces test_main() with unittest.main() ---------- Added file: http://bugs.python.org/file28650/issue16852.v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:25:38 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 09 Jan 2013 15:25:38 +0000 Subject: [issue3073] Cookie.Morsel breaks in parsing cookie values with whitespace In-Reply-To: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za> Message-ID: <1357745138.77.0.649025121202.issue3073@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:27:28 2013 From: report at bugs.python.org (Lars Buitinck) Date: Wed, 09 Jan 2013 15:27:28 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1357745248.03.0.878685850953.issue9369@psf.upfronthosting.co.za> Lars Buitinck added the comment: Any reason why this issue is still open? I just got a lot of compiler warnings when building Numpy, so this isn't just relevant to C++ programmers. (Btw., I did RTFM: the issue's Resolution is "accepted" but that option is not documented.) ---------- nosy: +larsmans _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:30:56 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 09 Jan 2013 15:30:56 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357745456.07.0.34348152011.issue16902@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Brian, is this supported in Solaris 10 or Solaris 11?. How can I actually try it?. I use Solaris on servers, and have Solaris 10/11 virtual machines in my laptop but never ever used sound under Solaris... Also, I am unsure about this being a new feature (available in future Python 3.4) or a bugfix (to be available on 2.7, 3.2, 3.3 and 3.4). Opinions? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:31:24 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 09 Jan 2013 15:31:24 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1357745484.25.0.209735771763.issue9369@psf.upfronthosting.co.za> Christian Heimes added the comment: Let's try this again for 3.4 ---------- nosy: +christian.heimes versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:31:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 15:31:49 +0000 Subject: [issue3073] Cookie.Morsel breaks in parsing cookie values with whitespace In-Reply-To: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za> Message-ID: <1357745509.0.0.566826375825.issue3073@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: fixed -> out of date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:33:43 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 15:33:43 +0000 Subject: [issue16897] Fix test discovery for test_bisect.py In-Reply-To: <1357681145.64.0.619169785001.issue16897@psf.upfronthosting.co.za> Message-ID: <1357745623.48.0.775790753512.issue16897@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's version 2 of the patch, which converts the doctests to a standard testcase and removes test_main(). ---------- Added file: http://bugs.python.org/file28651/test_bisect_fix.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:38:01 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 15:38:01 +0000 Subject: [issue16896] Fix test discovery for test_asyncore.py In-Reply-To: <1357679268.03.0.58943461997.issue16896@psf.upfronthosting.co.za> Message-ID: <1357745881.34.0.603109853306.issue16896@psf.upfronthosting.co.za> Zachary Ware added the comment: Patch v2, in which test_main() goes away. ---------- Added file: http://bugs.python.org/file28652/test_asyncore_fix.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:45:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 15:45:36 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1357746336.06.0.947416715554.issue16261@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Want to make a few warnings. Accepting your confirmation may take a long time. And it is very unlikely that your patch can be applied as a whole. The maintainers of the individual modules can apply it by parts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:46:33 2013 From: report at bugs.python.org (Lars Buitinck) Date: Wed, 09 Jan 2013 15:46:33 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1357746393.69.0.235636710808.issue9369@psf.upfronthosting.co.za> Lars Buitinck added the comment: Redid the patch. ---------- Added file: http://bugs.python.org/file28653/constness.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:47:26 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 15:47:26 +0000 Subject: [issue16888] Fix test discovery for test_array.py In-Reply-To: <1357598441.54.0.816719600523.issue16888@psf.upfronthosting.co.za> Message-ID: <1357746446.84.0.269849502849.issue16888@psf.upfronthosting.co.za> Zachary Ware added the comment: Version 2 removes test_main() and associated ``tests`` list. ---------- Added file: http://bugs.python.org/file28654/test_array.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:48:27 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 09 Jan 2013 15:48:27 +0000 Subject: [issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex In-Reply-To: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za> Message-ID: <1357746507.29.0.509197631586.issue16899@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: libffi still has no support for _Complex. Did you try with a pure Python solution, like the one suggested in http://objectmix.com/python/112374-re-ctypes-c99-complex-numbers.html ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:52:36 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Jan 2013 15:52:36 +0000 Subject: [issue16906] Bug in _PyUnicode_ClearStaticStrings() method of unicodeobject.c In-Reply-To: <1357731097.9.0.701098252698.issue16906@psf.upfronthosting.co.za> Message-ID: <3YhFGW1XgyzMMQ@mail.python.org> Roundup Robot added the comment: New changeset 3e18ccaa537e by Benjamin Peterson in branch '3.3': correct static string clearing loop (closes #16906) http://hg.python.org/cpython/rev/3e18ccaa537e New changeset 0c04ed40eeaf by Benjamin Peterson in branch 'default': merge 3.3 (#16906) http://hg.python.org/cpython/rev/0c04ed40eeaf ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:53:33 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 15:53:33 +0000 Subject: [issue16898] Fix test discovery for test_bufio.py Message-ID: <1357746813.11.0.421928307293.issue16898@psf.upfronthosting.co.za> New submission from Zachary Ware: Version 2 replaces test_main() with unittest.main(). ---------- Added file: http://bugs.python.org/file28655/test_bufio_fix.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 16:55:52 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 15:55:52 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1357746952.63.0.851553924464.issue9369@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Docs update needed. Perhaps some other functions which accepts char* (i.e. PyObject_CallMethodObjArgs or PyDict_GetItemString) should be fixed. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:01:17 2013 From: report at bugs.python.org (Lars Buitinck) Date: Wed, 09 Jan 2013 16:01:17 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1357747277.23.0.558206139474.issue9369@psf.upfronthosting.co.za> Lars Buitinck added the comment: Oops, forgot to save changes to Doc/c-api/object.rst. PyObject_CallMethodObjArgs takes a PyObject*, mustn't that be non-const for reference counting to work? PyDict_GetItemString already has const, just not in refcounts.dat. Fixed. ---------- Added file: http://bugs.python.org/file28656/constness.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:05:18 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 16:05:18 +0000 Subject: [issue16905] Fix test discovery for test_warnings Message-ID: <1357747518.54.0.674409174407.issue16905@psf.upfronthosting.co.za> New submission from Zachary Ware: Patch looks good to me. Thank you, Berker! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:05:43 2013 From: report at bugs.python.org (Trent Nelson) Date: Wed, 09 Jan 2013 16:05:43 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357747543.01.0.0105087508335.issue16902@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:07:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 16:07:11 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1357747631.74.0.764287556829.issue15239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Georg, now Tools/unicode/mkstringprep.py is broken in all Python 3 branches (it not usable at all, under 3.2 it even raises SyntaxError). Do you object against fixing it in 3.2 and 3.3? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:10:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 16:10:11 +0000 Subject: [issue13454] crash when deleting one pair from tee() In-Reply-To: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za> Message-ID: <1357747811.59.0.313846636567.issue13454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If no one objects I will commit this next week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:13:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 16:13:48 +0000 Subject: [issue6975] symlinks incorrectly resolved on Linux In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1357748028.51.0.857825315535.issue6975@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If no one objects I will commit this next week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:14:47 2013 From: report at bugs.python.org (brian-cameron-oracle) Date: Wed, 09 Jan 2013 16:14:47 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357748087.23.0.731772868379.issue16902@psf.upfronthosting.co.za> brian-cameron-oracle added the comment: OSS is the default audio system in Solaris 11 and 12. In Solaris 10 and earlier, the sunaudio (or SADA) interfaces are still used. You can only test this if you are using Solaris 11 or later, on a machine with a sound card supported by OSS. I would say this is really more of a bugfix. The main problem is that the configure script was avoiding even trying to build the OSS module on Solaris, and that the code only builds if the ioctls unsupported on Solaris are #ifdef'ed out on Solaris. So it would make sense to support the ability to build the OSS module in 2.7, 3.x and onwards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:16:43 2013 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 Jan 2013 16:16:43 +0000 Subject: [issue6975] symlinks incorrectly resolved on Linux In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1357748203.06.0.900793290169.issue6975@psf.upfronthosting.co.za> Georg Brandl added the comment: I'd like to see a review first. I don't have time to do it myself right now though. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:19:04 2013 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 Jan 2013 16:19:04 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1357748344.73.0.294938654716.issue15239@psf.upfronthosting.co.za> Georg Brandl added the comment: No need to hurry; no one apparently needs it anyway, and if there is a change let Martin review it before commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:25:58 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 09 Jan 2013 16:25:58 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357748758.98.0.105240189143.issue16902@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Brian, then this module should be compiled only under Solaris 11 and up and, presumably, OpenSolaris/Illumos derivatives. Does your patch compiles cleanly under previous Solaris versions?. I am +1 to consider this a bugfix. Any other python-dev opinion? PS: My virtual machines are configured with AC97 sound. Is that supported under Solaris 11?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:27:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 16:27:26 +0000 Subject: [issue6975] symlinks incorrectly resolved on Linux In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1357748846.04.0.44329653808.issue6975@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OK. Perhaps I?will prepare similar patches for ntpath and macpath. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:27:58 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 09 Jan 2013 16:27:58 +0000 Subject: [issue16907] Distutils fails to build extension in path with spaces In-Reply-To: <1357734162.78.0.136546351961.issue16907@psf.upfronthosting.co.za> Message-ID: <1357748878.53.0.223103031822.issue16907@psf.upfronthosting.co.za> Martin v. L?wis added the comment: klo.uo: can you kindly provide a working (or, rather, failing) example? A trivial "hello-world" kind of package could do, along with a report what path you unpacked it in, and what error you get. Your patch is not applicable to Python, since it requires the win32 extensions, which we cannot assume to be present. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 17:37:15 2013 From: report at bugs.python.org (brian-cameron-oracle) Date: Wed, 09 Jan 2013 16:37:15 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357749435.56.0.462959832823.issue16902@psf.upfronthosting.co.za> brian-cameron-oracle added the comment: Correct, OSS should work out-of-the-box on Solaris 11 and up since it is the default audio system there. OSS was also integrated into OpenSolaris, so it is probably the most sensible audio plugin to use there also. Some end-users may build and install their own OSS code on Solaris 10 or earlier, so it should not hurt to try and build the OSS plugin even on older versions of Solaris. Also, I'm not sure if the way I'm doing the #ifndef's in the patch is right. Looking at the rest of the code, I see that each EXPORT_INT is surrounded by its own #ifdef. I added similar #ifdef's around SNDCTL_DSP_BIND_CHANNEL SNDCTL_DSP_MAPINBUF, and SNDCTL_DSP_MAPOUTBUF. However I just put "#ifndef __sun" around the SNDCTL_COPR_* and SNDCTL_DSP_* ioctls because it seemed to make the patch more simple. But, I'm not sure this was the right decision. Maybe it just might be more consistent to use an #ifdef around each one separately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 18:00:17 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 17:00:17 +0000 Subject: [issue16910] Fix test discovery for bytes/string tests Message-ID: <1357750817.34.0.0240998301281.issue16910@psf.upfronthosting.co.za> New submission from Zachary Ware: This patch fixes discovery for test_bytes.py. That fix changes string_tests.py, which breaks test_unicode.py and test_userstring.py, so those two files have been changed as well. All three test files also use unittest.main() now instead of test_main(). ---------- components: Tests files: bytes_string_tests_discovery.diff keywords: patch messages: 179475 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for bytes/string tests versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28657/bytes_string_tests_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 18:00:24 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 09 Jan 2013 17:00:24 +0000 Subject: [issue16910] Fix test discovery for bytes/string tests In-Reply-To: <1357750817.34.0.0240998301281.issue16910@psf.upfronthosting.co.za> Message-ID: <1357750824.03.0.542520367919.issue16910@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 18:07:00 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 09 Jan 2013 17:07:00 +0000 Subject: [issue16909] urlparse: add userinfo attribute In-Reply-To: <1357742811.51.0.916599948648.issue16909@psf.upfronthosting.co.za> Message-ID: <1357751220.8.0.488344180018.issue16909@psf.upfronthosting.co.za> Senthil Kumaran added the comment: If it does go in, due the RFC requirement, then it would be only in 3.4 (default branch) and the feature may not be backported. Without reading the RFC section, I have an intuitive -1 for this proposal because the suggestion may be a corner case rather than a default scenario. It is a bad idea to change parsing logic for corner cases. ---------- nosy: +orsenthil versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 18:08:52 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 09 Jan 2013 17:08:52 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357751332.78.0.0468864124234.issue16902@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: The problem with your approach is that different Solaris release could support different flags. So I rather prefer specific #ifdef's. I wonder about compiling OSS module under Solaris without OSS support. Compiling a module acting as "NULL" is OK, compiling a node that will crash on import, for instance, it is not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 18:13:12 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 09 Jan 2013 17:13:12 +0000 Subject: [issue16904] Avoid unnecessary and possibly unsafe code from http.client.HTTPConnection.send In-Reply-To: <1357727307.69.0.69749124261.issue16904@psf.upfronthosting.co.za> Message-ID: <1357751592.95.0.176249304536.issue16904@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 18:17:52 2013 From: report at bugs.python.org (brian-cameron-oracle) Date: Wed, 09 Jan 2013 17:17:52 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357751872.87.0.704791290049.issue16902@psf.upfronthosting.co.za> brian-cameron-oracle added the comment: Sure, doing multiple #ifdef's makes sense. Do you need me to provide an updated patch, or is this something easier for someone who has commit access to the source code repository to just go ahead and do. I would think this Module would fail to compile if OSS isn't present, no? So I guess I do not understand your comment about this possibly causing any sort of crash on import at runtime. The Modules/ossaudiodev.c file should not compile if /usr/include/sys/soundcard.h isn't available with OSS definitions. It wouldn't be on Solaris 10 or earlier. Is it okay to try and compile this plugin and let it fail if it does? Or does the configure script need to check this first and only try building it on Solaris 11 or later? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 18:21:34 2013 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 09 Jan 2013 17:21:34 +0000 Subject: [issue6975] symlinks incorrectly resolved on Linux In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1357752094.61.0.797016880998.issue6975@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I will review this first thing tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 19:00:54 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Jan 2013 18:00:54 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <3YhJ6Y4rwlzRwd@mail.python.org> Roundup Robot added the comment: New changeset be8e6b81284e by Charles-Fran?ois Natali in branch 'default': Issue #16876: Optimize epoll.poll() by keeping a per-instance epoll events http://hg.python.org/cpython/rev/be8e6b81284e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 19:04:46 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2013 18:04:46 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357754686.23.0.593475114282.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: - How shall we go forward? I've made a variety of small changes to the Tulip version (selector.py) now. Can you work those into a fresh unified patch for CPython 3.4? - I tried making a single combined kqueue call in register(), and it caused the SSL test to hang, so I reverted that and changed my unregister code to make two syscalls as wel. (This makes me think however that KqueueSelector should override modify() to avoid redundant syscalls when flipping only one of the two bits.) - I'll change _Key to Key in the Tulip copy (though I wonder if maybe it should be a longer name -- 'Key' is rather generic). - Are you going to implement the SELECT_CONNECT flag? - Thanks for being so responsive! It's great to be able to factor the selector functionality out of Tulip. - Have you submitted a PSF contributor form yet? (Probably yes, years ago, just making sure. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 19:06:22 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 09 Jan 2013 18:06:22 +0000 Subject: [issue16907] Distutils fails to build extension in path with spaces In-Reply-To: <1357734162.78.0.136546351961.issue16907@psf.upfronthosting.co.za> Message-ID: <1357754782.86.0.145001916053.issue16907@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think this is a duplicate report; could you please search for an existing open report for the same bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 19:10:57 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 09 Jan 2013 18:10:57 +0000 Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with -E In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za> Message-ID: <1357755057.91.0.438804884321.issue16826@psf.upfronthosting.co.za> ?ric Araujo added the comment: Code patch looks good, but for tests, I prefer to run subprocesses with the options and output I want, instead of changing the expected results depending on the python-running-tests? options (and thus, having two tests into one, but always running only one). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 19:15:50 2013 From: report at bugs.python.org (klo uo) Date: Wed, 09 Jan 2013 18:15:50 +0000 Subject: [issue16907] Distutils fails to build extension in path with spaces In-Reply-To: <1357748878.53.0.223103031822.issue16907@psf.upfronthosting.co.za> Message-ID: <49237470.20130109191545@gmail.com> klo uo added the comment: > klo.uo: can you kindly provide a working (or, rather, failing) > example? A trivial "hello-world" kind of package could do, along > with a report what path you unpacked it in, and what error you get. As mentioned in opening thread, this doesn't happen with Cython's "hello world" example, as `gcc` somehow doesn't trigger this problem. Maybe because it's handled by Cython's own distutils copies, maybe it's handled by Numpy's distutils version or it could be by Python's distutils. I noticed this issue while using Numpy with Cython. Here is simple example: C:\Documents and Settings\klo\My Documents\code\python\misc\test.pyx: ======================================== cimport numpy def sum(x): cdef numpy.ndarray[int, ndim=1] arr = x cdef int i, s = 0 for i in range(arr.shape[0]): s += arr[i] return s ======================================== C:\Documents and Settings\klo\My Documents\code\python\misc\setup.py: ======================================== from distutils.core import setup from distutils.extension import Extension from Cython.Distutils import build_ext from numpy.distutils.misc_util import get_numpy_include_dirs setup( cmdclass = {'build_ext': build_ext}, ext_modules = [Extension("test", ["test.pyx"], include_dirs=get_numpy_include_dirs())] ) ======================================== command line: `python setup.py build_ext --inplace` MinGW result: ======================================== ... g++ -shared build\temp.win32-2.7\Release\test.o -LC:\Python27\libs -LC:\Python27\PCbuild -lpython27 -lmsvcr90 -o C:\Documents and Settings\klo\My Documents\code\python\misc\test.pyd Found executable C:\MinGW\bin\g++.exe g++.exe: error: and: No such file or directory g++.exe: error: Settings\klo\My: No such file or directory g++.exe: error: Documents\code\python\misc\test.pyd: No such file or directory error: Command "g++ -shared build\temp.win32-2.7\Release\test.o -LC:\Python27\libs -LC:\Python27\PCbuild -lpython27 -lmsvcr90 -o C:\Documents and Settings\klo\My Documents\code\python\misc\test.pyd" failed with exit status 1 ======================================== Similar result if I use MSVC compiler: MSVC result: ======================================== building 'test' extension c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC /Tctest.c /Fobuild\temp.win32-2.7\Release\test.obj Found executable c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\cl.exe c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python27\libs /LIBPATH:C:\Python27\PCbuild /EXPORT:inittest build\temp.win32-2.7\Release\test.obj /OUT:C:\Documents and Settings\klo\My Documents\code\python\misc\test.pyd /IMPLIB:build\temp.win32-2.7\Release\test.lib /MANIFESTFILE:build\temp.win32-2.7\Release\test.pyd.manifest /MANIFEST Found executable c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\link.exe LINK : fatal error LNK1181: cannot open input file 'and.obj' error: Command "c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python27\libs /LIBPATH:C:\Python27\PCbuild /EXPORT:inittest build\temp.win32-2.7\Release\test.obj /OUT:C:\Documents and Settings\klo\My Documents\code\python\misc\test.pyd /IMPLIB:build\temp.win32-2.7\Release\test.lib /MANIFESTFILE:build\temp.win32-2.7\Release\test.pyd.manifest /MANIFEST" failed with exit status 1181 ======================================== So issue is with unquoted path for output file, and not for LIBDIR as I wrote previously (perhaps I misread the logs, as I was trying to fix similar issue for Theano, at the same time) > Your patch is not applicable to Python, since it requires the win32 > extensions, which we cannot assume to be present. Yes, I provided patch that worked for me temporarily, as I'm not familiar with distutils, and that's as far as I went. But source issue is probably elsewhere, as Serhiy suggested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 19:21:32 2013 From: report at bugs.python.org (klo uo) Date: Wed, 09 Jan 2013 18:21:32 +0000 Subject: [issue16907] Distutils fails to build extension in path with spaces In-Reply-To: <1357754782.86.0.145001916053.issue16907@psf.upfronthosting.co.za> Message-ID: <1389592532.20130109192130@gmail.com> klo uo added the comment: I found two similar issues: 1. distutils compiler not handling spaces in path to output/src files: http://bugs.python.org/issue4508 with patches for unix compiler and cygwin compiler 2. Distutils does not put quotes around paths that contain spaces when compiling with MSVC: http://bugs.python.org/issue13765 with some patch for MSVC Problem seems to be deeper than provided patches, as evident also from my report ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 21:21:28 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 09 Jan 2013 20:21:28 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <1357762888.92.0.158533936475.issue16876@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 21:47:31 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 09 Jan 2013 20:47:31 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357754686.23.0.593475114282.issue16853@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > - How shall we go forward? I've made a variety of small changes to the > Tulip version (selector.py) now. Can you work those into a fresh unified > patch for CPython 3.4? Yes, but I think we could wait a little, to make sure the API is good enough to fulfill all tulip's need? There are a couple things I'm not completely happy with: - if we add a CONNECT event, then I think SELECT_IN/SELECT_OUT aren't good names anymore: I think that EVENT_READ/EVENT_WRITE/EVENT_CONNECT would be more consistent (since it embeds the operation that should now succeed on the socket). Maybe even shorter names like EVT_READ? - right now, selectors don't handle EINTR, which means that upon reception of a signal, Selector.select() can fail with EINTR (the original tulip implementation also had this problem). I've been more or less midly advocating to change all Python syscalls wrappers to handle EINTR because it's really just a nuisance, but I think Selector.select() should definitely handle EINTR and retry the syscalls (with an updated timeout). Note: the test testAddSignalHandler() added recently doesn't demonstrate this problem because os.kill(os.getpid(), signal.SIGINT) because the signal is delivered synchronously (when kill() syscall returns to user-space), before select()/poll()/epoll() gets called. > - I'll change _Key to Key in the Tulip copy (though I wonder if maybe it > should be a longer name -- 'Key' is rather generic). SelectorKey, or something along those lines? > - Are you going to implement the SELECT_CONNECT flag? Unfortunately, I don't know anything about Windows, so I won't be able to. But I guess that porting Pollster.WSAPollster to selectors shouldn't be too hard. > - Have you submitted a PSF contributor form yet? (Probably yes, years ago, > just making sure. :-) Actually, I already have commit rights ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 22:04:26 2013 From: report at bugs.python.org (Ronnie Ghose) Date: Wed, 09 Jan 2013 21:04:26 +0000 Subject: [issue16911] Socket Documentation Error Message-ID: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za> New submission from Ronnie Ghose: Running the example given in the docs gives the following: In [8]: socket.getaddrinfo('www.python.org',80) Out[8]: [(2, 1, 6, '', ('82.94.164.162', 80)), (2, 2, 17, '', ('82.94.164.162', 80)), (2, 3, 0, '', ('82.94.164.162', 80)), (10, 1, 6, '', ('2001:888:2000:d::a2', 80, 0, 0)), (10, 2, 17, '', ('2001:888:2000:d::a2', 80, 0, 0)), (10, 3, 0, '', ('2001:888:2000:d::a2', 80, 0, 0))] In [9]: socket.getaddrinfo('www.python.org',80,socket.SOL_TCP) --------------------------------------------------------------------------- gaierror Traceback (most recent call last) /home/sghose/ADAPT/dns/ in () ----> 1 socket.getaddrinfo('www.python.org',80,socket.SOL_TCP) gaierror: [Errno -6] ai_family not supported ---------- assignee: docs at python components: Documentation messages: 179487 nosy: docs at python, sghose priority: normal severity: normal status: open title: Socket Documentation Error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 22:11:43 2013 From: report at bugs.python.org (Ronnie Ghose) Date: Wed, 09 Jan 2013 21:11:43 +0000 Subject: [issue16911] Socket Documentation Error In-Reply-To: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za> Message-ID: <1357765903.86.0.843266560466.issue16911@psf.upfronthosting.co.za> Changes by Ronnie Ghose : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 22:11:59 2013 From: report at bugs.python.org (Ronnie Ghose) Date: Wed, 09 Jan 2013 21:11:59 +0000 Subject: [issue16911] Socket Documentation Error In-Reply-To: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za> Message-ID: <1357765919.12.0.365854849363.issue16911@psf.upfronthosting.co.za> Ronnie Ghose added the comment: sorry - my error. accidentally omitted somethings ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 22:12:06 2013 From: report at bugs.python.org (Ronnie Ghose) Date: Wed, 09 Jan 2013 21:12:06 +0000 Subject: [issue16911] Socket Documentation Error In-Reply-To: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za> Message-ID: <1357765926.82.0.621731823134.issue16911@psf.upfronthosting.co.za> Changes by Ronnie Ghose : ---------- nosy: -docs at python, sghose _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 22:28:28 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2013 21:28:28 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: Message-ID: Guido van Rossum added the comment: On Wed, Jan 9, 2013 at 12:47 PM, Charles-Fran?ois Natali wrote: >> - How shall we go forward? I've made a variety of small changes to the >> Tulip version (selector.py) now. Can you work those into a fresh unified >> patch for CPython 3.4? > > Yes, but I think we could wait a little, to make sure the API is good > enough to fulfill all tulip's need? Sure. I think in terms of API, it is pretty good except for the 'connect' issue below (and the related issue of a WSAPoll() wrapper, which Tulip had before the switch). In terms of implementation, I expect there's plenty to do, but it will be a long time before we'll know. It's probably best to do this incrementally. There's also the question of IOCP support, but I expect that it is too unwieldy to add to the select module -- it'll be a separate project. Hopefully Richard can help with this. > There are a couple things I'm not completely happy with: > - if we add a CONNECT event, then I think SELECT_IN/SELECT_OUT aren't > good names anymore: I think that EVENT_READ/EVENT_WRITE/EVENT_CONNECT > would be more consistent (since it embeds the operation that should > now succeed on the socket). Maybe even shorter names like EVT_READ? I like the longer names, EVENT_READ; they aren't used enough to need abbreviating, and it's always hard to remember exactly what abbreviation is used. > - right now, selectors don't handle EINTR, which means that upon > reception of a signal, Selector.select() can fail with EINTR (the > original tulip implementation also had this problem). I've been more > or less midly advocating to change all Python syscalls wrappers to > handle EINTR because it's really just a nuisance, but I think > Selector.select() should definitely handle EINTR and retry the > syscalls (with an updated timeout). I'm not sure what the pros and cons would be of doing this for all syscall wrappers, but I do know I want Tulip to work with Python 3.3 out of the box, so we need to add this to the select() calls. I imagine it's a bit tricky to test... Maybe I could use alarm() or setitimer() for testing? > Note: the test testAddSignalHandler() added recently doesn't > demonstrate this problem because os.kill(os.getpid(), signal.SIGINT) > because the signal is delivered synchronously (when kill() syscall > returns to user-space), before select()/poll()/epoll() gets called. I know. :-( >> - I'll change _Key to Key in the Tulip copy (though I wonder if maybe it >> should be a longer name -- 'Key' is rather generic). > > SelectorKey, or something along those lines? Sounds good. >> - Are you going to implement the SELECT_CONNECT flag? > > Unfortunately, I don't know anything about Windows, so I won't be able to. > But I guess that porting Pollster.WSAPollster to selectors shouldn't > be too hard. Just check out the last rev of Tulip before I switched: http://code.google.com/p/tulip/source/browse/tulip/unix_events.py?spec=svn28b7efd465b8529cdaa34e6b710f291c835c657b&r=28b7efd465b8529cdaa34e6b710f291c835c657b >> - Have you submitted a PSF contributor form yet? (Probably yes, years ago, >> just making sure. :-) > > Actually, I already have commit rights ;-) Doesn't surprise me. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 22:43:15 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 09 Jan 2013 21:43:15 +0000 Subject: [issue16911] Socket Documentation Error In-Reply-To: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za> Message-ID: <1357767795.89.0.98621163524.issue16911@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 22:43:32 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2013 21:43:32 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357767812.9.0.149797411954.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've fixed the signal handling issue. Please check Tulip revision 1c4db3d1a688: http://code.google.com/p/tulip/source/detail?r=1c4db3d1a68874dc22c84f9c1c376c5371037f09 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 22:45:04 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Jan 2013 21:45:04 +0000 Subject: [issue16853] add a Selector to the select module In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za> Message-ID: <1357767904.52.0.254814761969.issue16853@psf.upfronthosting.co.za> Guido van Rossum added the comment: And the next Tulip rev renames Key to SelectorKey. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 23:13:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 22:13:59 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1357769639.4.0.466857970342.issue9369@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > PyObject_CallMethodObjArgs takes a PyObject*, mustn't that be non-const for reference counting to work? Then refcounts.dat wrong. >?PyDict_GetItemString already has const, just not in refcounts.dat. Fixed. There are a lot of char* arguments in refcounts.dat. If refcounts.dat differs from actual function signature, this is a bug, and fix must be applied to other versions too. If they conform, perhaps this argument can be enhanced to "const char*" in 3.4. Therefore two issues are needed, one for the new feature, and one for the bugfixing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 23:54:13 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 09 Jan 2013 22:54:13 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1357772053.04.0.661587544729.issue10156@psf.upfronthosting.co.za> Stefan Krah added the comment: Nick, I'm adding you to the nosy list since this issue seems related to PEP 432. Quick summary: Globals are used in unicodeobject.c before they are initialized. Also, Unicode objects are created before PyType_Ready(&PyUnicode_Type) has been called. This happens during startup: _Py_InitializeEx_Private(): _Py_ReadyTypes(): PyType_Ready(&PyType_Type); [...] Many Unicode objects like "" or "__add__" are created. Uninitialized globals have led to a crash (#16143). This is fixed by Serhiy's patch, which always dynamically checks all globals for NULL before using them. However, Unicode objects are still created at this point. [...] PyType_Ready(&PyUnicode_Type); /* Called for the first time */ [...] _PyUnicode_Init: for (i = 0; i < 256; i++) /* Could leak if latin1 strings unicode_latin1[i] = NULL; have already been created. */ PyType_Ready(&PyUnicode_Type); /* Called a second time! */ So, considering PEP 432: Are these "pre-type-ready" Unicode objects safe to use, or should something be done about it? ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 23:57:44 2013 From: report at bugs.python.org (fenrirsoul) Date: Wed, 09 Jan 2013 22:57:44 +0000 Subject: [issue16912] Wrong float sum w/ 10.14+10.1 and 10.24+10.2 Message-ID: <1357772264.12.0.237958866341.issue16912@psf.upfronthosting.co.za> New submission from fenrirsoul: When 10.14+10.1 is typed, it's result is 20.240000000000002 and when 10.24+10.2 is typed, it's result is 20.439999999999998, i just found these two occurences. ---------- components: None messages: 179495 nosy: fenrirsoul priority: normal severity: normal status: open title: Wrong float sum w/ 10.14+10.1 and 10.24+10.2 type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 23:58:54 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 22:58:54 +0000 Subject: [issue16912] Wrong float sum w/ 10.14+10.1 and 10.24+10.2 In-Reply-To: <1357772264.12.0.237958866341.issue16912@psf.upfronthosting.co.za> Message-ID: <1357772334.32.0.306478938696.issue16912@psf.upfronthosting.co.za> Ezio Melotti added the comment: See http://docs.python.org/3/tutorial/floatingpoint.html ---------- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 00:01:02 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 Jan 2013 23:01:02 +0000 Subject: [issue16912] Wrong float sum w/ 10.14+10.1 and 10.24+10.2 In-Reply-To: <1357772264.12.0.237958866341.issue16912@psf.upfronthosting.co.za> Message-ID: <1357772462.02.0.625184760295.issue16912@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also http://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 00:04:19 2013 From: report at bugs.python.org (John O'Connor) Date: Wed, 09 Jan 2013 23:04:19 +0000 Subject: [issue16465] dict creation performance regression In-Reply-To: <1352823544.31.0.485629860142.issue16465@psf.upfronthosting.co.za> Message-ID: <1357772659.9.0.0184886446697.issue16465@psf.upfronthosting.co.za> Changes by John O'Connor : ---------- nosy: +jcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 00:06:02 2013 From: report at bugs.python.org (John O'Connor) Date: Wed, 09 Jan 2013 23:06:02 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1357772762.3.0.157082940521.issue16398@psf.upfronthosting.co.za> Changes by John O'Connor : ---------- nosy: +jcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 00:10:52 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 09 Jan 2013 23:10:52 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1357772053.04.0.661587544729.issue10156@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: There should still be a check in tp_new (IIRC) that calls PyType_Ready on unready types. While doing something systematic about this kind of problem is part of the rationale of PEP 432, that won't help earlier versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 00:33:19 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 09 Jan 2013 23:33:19 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357774399.63.0.924237611291.issue16902@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Brian, this patch would try to compile OSS module on any Solaris machine, even if not OSS support is provided. That is, compilation would fail in that case. That is not acceptable. Some kind of OSS detection is needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 00:43:11 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Jan 2013 23:43:11 +0000 Subject: [issue16850] Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1357774991.37.0.200703089046.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: There is another way to set close-on-exec flag on a file descriptor: "ioctl(fd, FIOCLEX, 0);" (and "ioctl(fd, FIONCLEX, 0);" to unset the flag). It is interesting because it avoids the need to get the flags before setting new flags (old | FD_CLOEXEC): 1 syscall instead of 2. ioctl(fd, FIOCLEX) is available on at least: Linux, Mac OS X, QNX, NetBSD, OpenBSD, FreeBSD. I don't know if it's available in old versions of these operating systems. (It is *not* supported by Interix.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 00:49:12 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Wed, 09 Jan 2013 23:49:12 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357775352.96.0.97155987922.issue16886@psf.upfronthosting.co.za> Frank Wierzbicki added the comment: Making these into real unit tests and switching the patch to 3.3 should be no problem. Is 2.7 still open for changes to tests? I might back port to 2.7 as well so that I can delete the customized Jython test in 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 01:12:39 2013 From: report at bugs.python.org (Roger Serwy) Date: Thu, 10 Jan 2013 00:12:39 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357776759.08.0.299102864943.issue16829@psf.upfronthosting.co.za> Roger Serwy added the comment: The attached patch changes %%s to %%r. This should handle file names containing quotes automatically. Ramchandra's point of using a subprocess instead would fix the issue as well. That would require changing "print_window" in Lib/idlelib/IOBinding.py Terry's observation about Windows' Notepad omitting the file extension is just a behavior of Notepad. ---------- keywords: +patch Added file: http://bugs.python.org/file28662/16829_print.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 01:14:52 2013 From: report at bugs.python.org (Roger Serwy) Date: Thu, 10 Jan 2013 00:14:52 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357776892.45.0.591280402633.issue16829@psf.upfronthosting.co.za> Roger Serwy added the comment: See also issue12274. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 01:21:25 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 10 Jan 2013 00:21:25 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: Message-ID: <20130110002127.GA7233@sleipnir.bytereef.org> Stefan Krah added the comment: Nick Coghlan wrote: > There should still be a check in tp_new (IIRC) that calls PyType_Ready on > unready types. Indeed there is one in type_new(), but that isn't used here AFAICS. If you apply this patch and start up python, there are many "str: not ready" instances: diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c --- a/Objects/unicodeobject.c +++ b/Objects/unicodeobject.c @@ -14282,6 +14282,10 @@ PyUnicode_InternFromString(const char *cp) { PyObject *s = PyUnicode_FromString(cp); + + fprintf(stderr, "%s: %s\n", PyUnicode_Type.tp_name, + (PyUnicode_Type.tp_flags & Py_TPFLAGS_READY) ? "ready" : "not ready"); + if (s == NULL) return NULL; PyUnicode_InternInPlace(&s); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 01:41:29 2013 From: report at bugs.python.org (brian-cameron-oracle) Date: Thu, 10 Jan 2013 00:41:29 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357778489.06.0.245277674907.issue16902@psf.upfronthosting.co.za> brian-cameron-oracle added the comment: I'm not sure how to write such OSS detection code. I do know that OSS is only on Solaris systems that have this OSS-specific file: /usr/include/sys/soundcard.h So that's probably the best way to check and it should work even on Solaris 10 if OSS is already installed by the end-user. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 01:58:10 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 10 Jan 2013 00:58:10 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357779490.17.0.352808657635.issue16902@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Brian, Linux has that include file too. So, yes, I think that detection would be appropiate. If we could confirm that all platforms with OSS support have that file, we could have something :-). If not, or we are not sure, just check for that file *IF* the platform is "sunos5. Could you possibly provide a new patch with that test and independent #ifdef's? I am assigning this issue to me. Lets move :-). ---------- assignee: -> jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 01:59:56 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 10 Jan 2013 00:59:56 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357779596.09.0.992494390499.issue16902@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: For user installed packages, the usual path would be "/usr/local/include/sys/soundcard.h". So, maybe check both paths. Do you agree? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 02:30:06 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 01:30:06 +0000 Subject: [issue16852] Fix test discovery for test_genericpath.py In-Reply-To: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za> Message-ID: <3YhV4p32c1zLpw@mail.python.org> Roundup Robot added the comment: New changeset 6f71e6aa9041 by Ezio Melotti in branch '3.3': #16852: test_genericpath, test_posixpath, test_ntpath, and test_macpath now work with unittest test discovery. Patch by Zachary Ware. http://hg.python.org/cpython/rev/6f71e6aa9041 New changeset 3a7cd8efc19f by Ezio Melotti in branch 'default': #16852: merge with 3.3. http://hg.python.org/cpython/rev/3a7cd8efc19f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 02:32:07 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 01:32:07 +0000 Subject: [issue16852] Fix test discovery for test_genericpath.py In-Reply-To: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za> Message-ID: <1357781527.6.0.998290703056.issue16852@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 02:39:30 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 10 Jan 2013 01:39:30 +0000 Subject: [issue16406] move the "Uploading Packages" section to distutils/packageindex.rst In-Reply-To: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za> Message-ID: <1357781970.67.0.753726189941.issue16406@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attached is a proposed patch. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file28663/issue-16406-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 03:22:57 2013 From: report at bugs.python.org (Roy Smith) Date: Thu, 10 Jan 2013 02:22:57 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1357784577.14.0.195592422417.issue14452@psf.upfronthosting.co.za> Changes by Roy Smith : ---------- nosy: +roysmith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 03:25:59 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 10 Jan 2013 02:25:59 +0000 Subject: [issue16878] argparse: positional args with nargs='*' defaults to [] In-Reply-To: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za> Message-ID: <1357784759.27.0.245836561634.issue16878@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It turns out that there is already a test case: http://hg.python.org/cpython/file/05183ce544be/Lib/test/test_argparse.py#l799 (at the line "('', NS(foo=[])),") I've updated the patch with a note to reflect this. ---------- Added file: http://bugs.python.org/file28664/issue-16878-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 03:33:36 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 02:33:36 +0000 Subject: [issue16897] Fix test discovery for test_bisect.py In-Reply-To: <1357681145.64.0.619169785001.issue16897@psf.upfronthosting.co.za> Message-ID: <3YhWV80sknzP1y@mail.python.org> Roundup Robot added the comment: New changeset f32cb5389a4b by Ezio Melotti in branch '3.3': #16897: test_bisect now works with unittest test discovery. Initial patch by Zachary Ware. http://hg.python.org/cpython/rev/f32cb5389a4b New changeset cfd8d99ae645 by Ezio Melotti in branch 'default': #16897: merge with 3.3. http://hg.python.org/cpython/rev/cfd8d99ae645 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 03:34:40 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 02:34:40 +0000 Subject: [issue16897] Fix test discovery for test_bisect.py In-Reply-To: <1357681145.64.0.619169785001.issue16897@psf.upfronthosting.co.za> Message-ID: <1357785280.57.0.316319907913.issue16897@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! While I was at it I also added the other example from the doc. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 04:29:53 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 03:29:53 +0000 Subject: [issue16896] Fix test discovery for test_asyncore.py In-Reply-To: <1357679268.03.0.58943461997.issue16896@psf.upfronthosting.co.za> Message-ID: <3YhXl43l4WzQwm@mail.python.org> Roundup Robot added the comment: New changeset 4976bf1d751c by Ezio Melotti in branch '3.3': #16896: test_asyncore now works with unittest test discovery. Patch by Zachary Ware. http://hg.python.org/cpython/rev/4976bf1d751c New changeset e7a965a075f5 by Ezio Melotti in branch 'default': #16896: merge with 3.3. http://hg.python.org/cpython/rev/e7a965a075f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 04:30:30 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 03:30:30 +0000 Subject: [issue16896] Fix test discovery for test_asyncore.py In-Reply-To: <1357679268.03.0.58943461997.issue16896@psf.upfronthosting.co.za> Message-ID: <1357788630.56.0.150351633053.issue16896@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:06:53 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 04:06:53 +0000 Subject: [issue16888] Fix test discovery for test_array.py In-Reply-To: <1357598441.54.0.816719600523.issue16888@psf.upfronthosting.co.za> Message-ID: <3YhYYm3NCXzMKg@mail.python.org> Roundup Robot added the comment: New changeset 1538307c06c0 by Ezio Melotti in branch '3.3': #16888: test_array now works with unittest test discovery. Patch by Zachary Ware. http://hg.python.org/cpython/rev/1538307c06c0 New changeset 16c58eeca0f8 by Ezio Melotti in branch 'default': #16888: merge with 3.3. http://hg.python.org/cpython/rev/16c58eeca0f8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:07:29 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 04:07:29 +0000 Subject: [issue16888] Fix test discovery for test_array.py In-Reply-To: <1357598441.54.0.816719600523.issue16888@psf.upfronthosting.co.za> Message-ID: <1357790849.48.0.122737322517.issue16888@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:13:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 04:13:01 +0000 Subject: [issue16898] Fix test discovery for test_bufio.py In-Reply-To: <1357746813.11.0.421928307293.issue16898@psf.upfronthosting.co.za> Message-ID: <3YhYhr4nwpzS1T@mail.python.org> Roundup Robot added the comment: New changeset 09d4b690b504 by Ezio Melotti in branch '3.3': #16898: test_bufio now works with unittest test discovery. Patch by Zachary Ware. http://hg.python.org/cpython/rev/09d4b690b504 New changeset 9a6e28350645 by Ezio Melotti in branch 'default': #16898: merge with 3.3. http://hg.python.org/cpython/rev/9a6e28350645 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:13:50 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 04:13:50 +0000 Subject: [issue16898] Fix test discovery for test_bufio.py In-Reply-To: <1357746813.11.0.421928307293.issue16898@psf.upfronthosting.co.za> Message-ID: <1357791230.94.0.799807361312.issue16898@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:33:47 2013 From: report at bugs.python.org (John O'Connor) Date: Thu, 10 Jan 2013 04:33:47 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1357792427.12.0.242378102397.issue1508475@psf.upfronthosting.co.za> Changes by John O'Connor : ---------- nosy: +jcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:41:26 2013 From: report at bugs.python.org (John O'Connor) Date: Thu, 10 Jan 2013 04:41:26 +0000 Subject: [issue11695] Improve argparse usage/help customization In-Reply-To: <1301234745.11.0.232414036754.issue11695@psf.upfronthosting.co.za> Message-ID: <1357792886.42.0.121285417898.issue11695@psf.upfronthosting.co.za> Changes by John O'Connor : ---------- nosy: +jcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:43:58 2013 From: report at bugs.python.org (John O'Connor) Date: Thu, 10 Jan 2013 04:43:58 +0000 Subject: [issue16445] SEGFAULT when deleting Exception.message In-Reply-To: <1352415910.77.0.640632287013.issue16445@psf.upfronthosting.co.za> Message-ID: <1357793038.26.0.910777192678.issue16445@psf.upfronthosting.co.za> Changes by John O'Connor : ---------- nosy: +jcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:50:16 2013 From: report at bugs.python.org (John O'Connor) Date: Thu, 10 Jan 2013 04:50:16 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1357793416.53.0.718114995292.issue15948@psf.upfronthosting.co.za> Changes by John O'Connor : ---------- nosy: +jcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 05:55:12 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 04:55:12 +0000 Subject: [issue16905] Fix test discovery for test_warnings In-Reply-To: <1357747518.54.0.674409174407.issue16905@psf.upfronthosting.co.za> Message-ID: <3YhZdW2FNrzS0J@mail.python.org> Roundup Robot added the comment: New changeset 20e44464eb86 by Ezio Melotti in branch '3.3': #16905: test_bufio now works with unittest test discovery. Initial patch by Berker Peksag. http://hg.python.org/cpython/rev/20e44464eb86 New changeset 6ee721029fd5 by Ezio Melotti in branch 'default': #16905: merge with 3.3. http://hg.python.org/cpython/rev/6ee721029fd5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 06:00:41 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 05:00:41 +0000 Subject: [issue16905] Fix test discovery for test_warnings In-Reply-To: <1357747518.54.0.674409174407.issue16905@psf.upfronthosting.co.za> Message-ID: <1357794041.56.0.30638801243.issue16905@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! However I had to change a couple of things: 1) test_main contained c/py_warnings.onceregistry.clear(), and removing that breaks when running the test twice in a row. I now added it to setUpModule, and that seems to be called both when the tests are run via regrtest and also when they are run via unittest. 2) Since the onceregistry wasn't cleared at the end of the tests, I also added a tearDownModule to take care of it. 3) I reorganized a bit the inheritance trees of the classes because they were inconsistent. Now all the tests use BaseTest -> TestFoo(BaseTest) -> C/PyTestFoo(TestFoo, Unittest). Previously some of the tests used BaseTest | TestFoo -> C/PyTestFoo(BaseTest, TestFoo, Unittest). ---------- assignee: -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 06:10:57 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 10 Jan 2013 05:10:57 +0000 Subject: [issue11695] Improve argparse usage/help customization In-Reply-To: <1301234745.11.0.232414036754.issue11695@psf.upfronthosting.co.za> Message-ID: <1357794657.26.0.912841362349.issue11695@psf.upfronthosting.co.za> Chris Jerdonek added the comment: +1 to the feature. A closely-related use case is customizing the message displayed by error(), which is normally the usage string followed by the error message. I wanted to append instructions on how to invoke --help, and implemented it this way for CPython's regrtest: http://hg.python.org/cpython/file/6ee721029fd5/Lib/test/regrtest.py#l205 Also take a look at how regrtest formats its usage string as another use case to satisfy: http://hg.python.org/cpython/file/6ee721029fd5/Lib/test/regrtest.py#l9 It seems like many argparse customizations take the form of "override this method." Would it make sense for the API to be for customizers to override string-returning methods like make_usage() and make_error() (and that accept a dictionary)? That may give a bit more control than a format string. ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 06:20:09 2013 From: report at bugs.python.org (Frank) Date: Thu, 10 Jan 2013 05:20:09 +0000 Subject: [issue16913] ElementTree tostring error when method='text' Message-ID: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> New submission from Frank: Since upgrading to python 3.3 the tostring method fails when the output method is requested as text. Code like this: with open(fp, mode='rt') as f: data = f.read() tree, idmap = ET.XMLID(data) print(ET.tostring(tree, method='text', encoding='unicode')) Generates the following error: Traceback (most recent call last): File "/home/john/Desktop/docs/Pear/pear.py", line 64, in pass_four print(ET.tostring(tree, method='text', encoding='unicode')) File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 1171, in tostring ElementTree(element).write(stream, encoding, method=method) File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 824, in write _serialize_text(write, self._root) File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 1057, in _serialize_text write(part) TypeError: string argument expected, got 'list' Whereas it used to return plain text with formatting tags stripped from the root element on prior versions of python. ---------- components: XML messages: 179523 nosy: Frank priority: normal severity: normal status: open title: ElementTree tostring error when method='text' versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 06:21:22 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 05:21:22 +0000 Subject: [issue16913] ElementTree tostring error when method='text' In-Reply-To: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> Message-ID: <1357795282.51.0.669307581063.issue16913@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +3.3regression nosy: +eli.bendersky, ezio.melotti stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 06:46:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 05:46:48 +0000 Subject: [issue16910] Fix test discovery for bytes/string tests In-Reply-To: <1357750817.34.0.0240998301281.issue16910@psf.upfronthosting.co.za> Message-ID: <3Yhbn31pfkzS1T@mail.python.org> Roundup Robot added the comment: New changeset 55383912c225 by Ezio Melotti in branch '3.3': #16910: test_bytes, test_unicode, and test_userstring now work with unittest test discovery. Patch by Zachary Ware. http://hg.python.org/cpython/rev/55383912c225 New changeset 6478c4259ce3 by Ezio Melotti in branch 'default': #16910: merge with 3.3. http://hg.python.org/cpython/rev/6478c4259ce3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 06:47:34 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 05:47:34 +0000 Subject: [issue16910] Fix test discovery for bytes/string tests In-Reply-To: <1357750817.34.0.0240998301281.issue16910@psf.upfronthosting.co.za> Message-ID: <1357796854.73.0.676506796026.issue16910@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 07:00:38 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 10 Jan 2013 06:00:38 +0000 Subject: [issue16406] move the "Uploading Packages" section to distutils/packageindex.rst In-Reply-To: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za> Message-ID: <1357797638.61.0.390553982388.issue16406@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updating patch with use of the :orphan: directive (so that the old page can be excluded from the table of contents/toctree without issuing a Sphinx warning). ---------- Added file: http://bugs.python.org/file28665/issue-16406-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 07:05:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 06:05:25 +0000 Subject: [issue15782] Compile error for a number of Mac modules with recent Xcode In-Reply-To: <1345889130.68.0.165099119682.issue15782@psf.upfronthosting.co.za> Message-ID: <3YhcBX2KtNzQrX@mail.python.org> Roundup Robot added the comment: New changeset ae1d34142a2a by Ned Deily in branch '2.7': Issue #15782: Prevent compile errors of OS X Carbon modules _Fm, _Qd, and http://hg.python.org/cpython/rev/ae1d34142a2a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 07:09:05 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 10 Jan 2013 06:09:05 +0000 Subject: [issue15782] Compile error for a number of Mac modules with recent Xcode In-Reply-To: <1345889130.68.0.165099119682.issue15782@psf.upfronthosting.co.za> Message-ID: <1357798145.83.0.717332578837.issue15782@psf.upfronthosting.co.za> Ned Deily added the comment: LGTM. I've committed the patch along with expanded warnings in the Standard Library doc pages for "Mac OS X specific services" and "Mac OS Toolbox Modules". ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 08:25:33 2013 From: report at bugs.python.org (Erik Cederstrand) Date: Thu, 10 Jan 2013 07:25:33 +0000 Subject: [issue12006] strptime should implement %V or %u directive from libc In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1357802733.24.0.970875444868.issue12006@psf.upfronthosting.co.za> Erik Cederstrand added the comment: Ping. Is anyone willing to take this? I'm not a committer nor know anyone with commit access. ---------- nosy: +Erik Cederstrand _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 08:42:18 2013 From: report at bugs.python.org (Eric Snow) Date: Thu, 10 Jan 2013 07:42:18 +0000 Subject: [issue16894] Function attribute access doesn't invoke methods in dict subclasses In-Reply-To: <1357670592.25.0.470525675752.issue16894@psf.upfronthosting.co.za> Message-ID: <1357803738.76.0.563936077039.issue16894@psf.upfronthosting.co.za> Eric Snow added the comment: Looks like a case where the concrete dict API is ignoring subtype implementations. In your example the attribute access will be handled by a LOAD_ATTR which calls PyObject_GetAttr() (Python/ceval.c:2369). That ends up calling PyFunction_Type.tp_getattro (inherited from PyBaseObject_Type). That ends up just being PyObject_GenericGetAttr() (Objects/object.c:1061). The dict gets pulled from foo using PyFunction_Type.->tp_dictoffset and then PyDict_GetItem() gets called on it. Unfortunately, PyDict_GetItem() is hard-coded to the dict implementation. At this point your __getitem__() has been entirely circumvented! FYI, this is a pain point for myself right now so it's been on my mind (COrderedDict and kwargs). This came up in 2011. See issue 10977. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 09:10:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 08:10:28 +0000 Subject: [issue16913] ElementTree tostring error when method='text' In-Reply-To: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> Message-ID: <1357805428.89.0.178323723449.issue16913@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can you please provide an example of data for which the tostring method fails? I can't reproduce this on simple data. >>> import xml.etree.ElementTree as ET >>> ET.tostring(ET.XML('qwerty'), method='text', encoding='unicode') 'qwerty' ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 9 23:09:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Jan 2013 22:09:10 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1356818840.92.0.438442207272.issue15989@psf.upfronthosting.co.za> Message-ID: <201301100008.13249.storchaka@gmail.com> Serhiy Storchaka added the comment: Here are minimized patches. All included changes have tests (i.e. overflow bugs are observable). I drop grp module changes even with tests, because there are other issues for this (issue2005, issue4591). New tests for fcntl added (they test PyObject_AsFileDescriptor). If patches look good in general, I going first commit to 3.4, and if this will not break any buildbot, then I'll commit the rest patches. After that I'll continue with not included changes (if I can write tests for them). ---------- Added file: http://bugs.python.org/file28658/long_aslong_overflow-2.7_3.patch Added file: http://bugs.python.org/file28659/long_aslong_overflow-3.2_3.patch Added file: http://bugs.python.org/file28660/long_aslong_overflow-3.3_3.patch Added file: http://bugs.python.org/file28661/long_aslong_overflow-3.4_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r f2353e74b335 Include/intobject.h --- a/Include/intobject.h Tue Jan 08 23:12:00 2013 +0200 +++ b/Include/intobject.h Wed Jan 09 23:37:32 2013 +0200 @@ -40,6 +40,7 @@ PyAPI_FUNC(PyObject *) PyInt_FromSsize_t(Py_ssize_t); PyAPI_FUNC(long) PyInt_AsLong(PyObject *); PyAPI_FUNC(Py_ssize_t) PyInt_AsSsize_t(PyObject *); +PyAPI_FUNC(int) _PyInt_AsInt(PyObject *); PyAPI_FUNC(unsigned long) PyInt_AsUnsignedLongMask(PyObject *); #ifdef HAVE_LONG_LONG PyAPI_FUNC(unsigned PY_LONG_LONG) PyInt_AsUnsignedLongLongMask(PyObject *); diff -r f2353e74b335 Include/longobject.h --- a/Include/longobject.h Tue Jan 08 23:12:00 2013 +0200 +++ b/Include/longobject.h Wed Jan 09 23:37:32 2013 +0200 @@ -25,6 +25,7 @@ PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLong(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLongMask(PyObject *); PyAPI_FUNC(Py_ssize_t) PyLong_AsSsize_t(PyObject *); +PyAPI_FUNC(int) _PyLong_AsInt(PyObject *); PyAPI_FUNC(PyObject *) PyLong_GetInfo(void); /* For use by intobject.c only */ diff -r f2353e74b335 Lib/ctypes/test/test_structures.py --- a/Lib/ctypes/test/test_structures.py Tue Jan 08 23:12:00 2013 +0200 +++ b/Lib/ctypes/test/test_structures.py Wed Jan 09 23:37:32 2013 +0200 @@ -1,6 +1,7 @@ import unittest from ctypes import * from struct import calcsize +import _testcapi class SubclassesTest(unittest.TestCase): def test_subclass(self): @@ -199,6 +200,14 @@ "_pack_": -1} self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + # Issue 15989 + d = {"_fields_": [("a", c_byte)], + "_pack_": _testcapi.INT_MAX + 1} + self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + d = {"_fields_": [("a", c_byte)], + "_pack_": _testcapi.UINT_MAX + 2} + self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + def test_initializers(self): class Person(Structure): _fields_ = [("name", c_char*6), diff -r f2353e74b335 Lib/test/string_tests.py --- a/Lib/test/string_tests.py Tue Jan 08 23:12:00 2013 +0200 +++ b/Lib/test/string_tests.py Wed Jan 09 23:37:32 2013 +0200 @@ -5,6 +5,7 @@ import unittest, string, sys, struct from test import test_support from UserList import UserList +import _testcapi class Sequence: def __init__(self, seq='wxyz'): self.seq = seq @@ -1113,6 +1114,20 @@ self.checkraises(TypeError, '%10.*f', '__mod__', ('foo', 42.)) self.checkraises(ValueError, '%10', '__mod__', (42,)) + if _testcapi.PY_SSIZE_T_MAX < sys.maxint: + self.checkraises(OverflowError, '%*s', '__mod__', + (_testcapi.PY_SSIZE_T_MAX + 1, '')) + if _testcapi.INT_MAX < sys.maxint: + self.checkraises(OverflowError, '%.*f', '__mod__', + (_testcapi.INT_MAX + 1, 1. / 7)) + # Issue 15989 + if 1 << (_testcapi.PY_SSIZE_T_MAX.bit_length() + 1) <= sys.maxint: + self.checkraises(OverflowError, '%*s', '__mod__', + (1 << (_testcapi.PY_SSIZE_T_MAX.bit_length() + 1), '')) + if _testcapi.UINT_MAX < sys.maxint: + self.checkraises(OverflowError, '%.*f', '__mod__', + (_testcapi.UINT_MAX + 1, 1. / 7)) + class X(object): pass self.checkraises(TypeError, 'abc', '__mod__', X()) diff -r f2353e74b335 Lib/test/test_fcntl.py --- a/Lib/test/test_fcntl.py Tue Jan 08 23:12:00 2013 +0200 +++ b/Lib/test/test_fcntl.py Wed Jan 09 23:37:32 2013 +0200 @@ -6,6 +6,7 @@ import os import struct import sys +import _testcapi import unittest from test.test_support import (verbose, TESTFN, unlink, run_unittest, import_module) @@ -81,6 +82,26 @@ rv = fcntl.fcntl(self.f, fcntl.F_SETLKW, lockdata) self.f.close() + def test_fcntl_bad_file(self): + class F: + def __init__(self, fn): + self.fn = fn + def fileno(self): + return self.fn + self.assertRaises(ValueError, fcntl.fcntl, -1, fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(ValueError, fcntl.fcntl, F(-1), fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(TypeError, fcntl.fcntl, 'spam', fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(TypeError, fcntl.fcntl, F('spam'), fcntl.F_SETFL, os.O_NONBLOCK) + # Issue 15989 + self.assertRaises(ValueError, fcntl.fcntl, _testcapi.INT_MAX + 1, + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(ValueError, fcntl.fcntl, F(_testcapi.INT_MAX + 1), + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(ValueError, fcntl.fcntl, _testcapi.INT_MIN - 1, + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(ValueError, fcntl.fcntl, F(_testcapi.INT_MIN - 1), + fcntl.F_SETFL, os.O_NONBLOCK) + def test_fcntl_64_bit(self): # Issue #1309352: fcntl shouldn't fail when the third arg fits in a # C 'long' but not in a C 'int'. diff -r f2353e74b335 Lib/test/test_fileio.py --- a/Lib/test/test_fileio.py Tue Jan 08 23:12:00 2013 +0200 +++ b/Lib/test/test_fileio.py Wed Jan 09 23:37:32 2013 +0200 @@ -10,6 +10,7 @@ from weakref import proxy from functools import wraps from UserList import UserList +import _testcapi from test.test_support import TESTFN, check_warnings, run_unittest, make_bad_fd from test.test_support import py3k_bytes as bytes @@ -343,6 +344,9 @@ if sys.platform == 'win32': import msvcrt self.assertRaises(IOError, msvcrt.get_osfhandle, make_bad_fd()) + # Issue 15989 + self.assertRaises(TypeError, _FileIO, _testcapi.INT_MAX + 1) + self.assertRaises(TypeError, _FileIO, _testcapi.INT_MIN - 1) def testBadModeArgument(self): # verify that we get a sensible error message for bad mode argument diff -r f2353e74b335 Lib/test/test_io.py --- a/Lib/test/test_io.py Tue Jan 08 23:12:00 2013 +0200 +++ b/Lib/test/test_io.py Wed Jan 09 23:37:32 2013 +0200 @@ -32,6 +32,7 @@ import abc import signal import errno +import _testcapi from itertools import cycle, count from collections import deque from UserList import UserList @@ -1873,6 +1874,14 @@ t.write("A\rB") self.assertEqual(r.getvalue(), b"XY\nZA\rB") + # Issue 15989 + def test_device_encoding(self): + b = self.BytesIO() + b.fileno = lambda: _testcapi.INT_MAX + 1 + self.assertRaises(OverflowError, self.TextIOWrapper, b) + b.fileno = lambda: _testcapi.UINT_MAX + 1 + self.assertRaises(OverflowError, self.TextIOWrapper, b) + def test_encoding(self): # Check the encoding attribute is always set, and valid b = self.BytesIO() diff -r f2353e74b335 Lib/test/test_poll.py --- a/Lib/test/test_poll.py Tue Jan 08 23:12:00 2013 +0200 +++ b/Lib/test/test_poll.py Wed Jan 09 23:37:32 2013 +0200 @@ -1,6 +1,7 @@ # Test case for the os.poll() function import os, select, random, unittest +import _testcapi from test.test_support import TESTFN, run_unittest try: @@ -150,6 +151,15 @@ if x != 5: self.fail('Overflow must have occurred') + pollster = select.poll() + # Issue 15989 + self.assertRaises(OverflowError, pollster.register, 0, + _testcapi.SHRT_MAX + 1) + self.assertRaises(OverflowError, pollster.register, 0, + _testcapi.USHRT_MAX + 1) + self.assertRaises(OverflowError, pollster.poll, _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, pollster.poll, _testcapi.UINT_MAX + 1) + def test_main(): run_unittest(PollTests) diff -r f2353e74b335 Lib/test/test_socket.py --- a/Lib/test/test_socket.py Tue Jan 08 23:12:00 2013 +0200 +++ b/Lib/test/test_socket.py Wed Jan 09 23:37:32 2013 +0200 @@ -6,6 +6,7 @@ import errno import socket import select +import _testcapi import time import traceback import Queue @@ -700,11 +701,17 @@ def test_sendall_interrupted_with_timeout(self): self.check_sendall_interrupted(True) - def testListenBacklog0(self): + def test_listen_backlog(self): + for backlog in 0, -1: + srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + srv.bind((HOST, 0)) + srv.listen(backlog) + srv.close() + + # Issue 15989 srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.bind((HOST, 0)) - # backlog = 0 - srv.listen(0) + self.assertRaises(OverflowError, srv.listen, _testcapi.INT_MAX + 1) srv.close() @unittest.skipUnless(SUPPORTS_IPV6, 'IPv6 required for this test.') @@ -808,6 +815,11 @@ def _testShutdown(self): self.serv_conn.send(MSG) + # Issue 15989 + self.assertRaises(OverflowError, self.serv_conn.shutdown, + _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, self.serv_conn.shutdown, + 2 + (_testcapi.UINT_MAX + 1)) self.serv_conn.shutdown(2) @unittest.skipUnless(thread, 'Threading required for this test.') @@ -891,6 +903,11 @@ pass end = time.time() self.assertTrue((end - start) < 1.0, "Error setting non-blocking mode.") + # Issue 15989 + self.assertRaises(OverflowError, self.serv.setblocking, + _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, self.serv.setblocking, + _testcapi.UINT_MAX + 1) def _testSetBlocking(self): pass diff -r f2353e74b335 Modules/_ctypes/stgdict.c --- a/Modules/_ctypes/stgdict.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/_ctypes/stgdict.c Wed Jan 09 23:37:32 2013 +0200 @@ -343,7 +343,7 @@ isPacked = PyObject_GetAttrString(type, "_pack_"); if (isPacked) { - pack = PyInt_AsLong(isPacked); + pack = _PyInt_AsInt(isPacked); if (pack < 0 || PyErr_Occurred()) { Py_XDECREF(isPacked); PyErr_SetString(PyExc_ValueError, diff -r f2353e74b335 Modules/_io/_iomodule.c --- a/Modules/_io/_iomodule.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/_io/_iomodule.c Wed Jan 09 23:37:32 2013 +0200 @@ -300,7 +300,8 @@ int text = 0, binary = 0, universal = 0; char rawmode[5], *m; - int line_buffering, isatty; + int line_buffering; + long isatty; PyObject *raw, *modeobj = NULL, *buffer = NULL, *wrapper = NULL; @@ -443,12 +444,12 @@ #ifdef HAVE_STRUCT_STAT_ST_BLKSIZE { struct stat st; - long fileno; + int fileno; PyObject *res = PyObject_CallMethod(raw, "fileno", NULL); if (res == NULL) goto error; - fileno = PyInt_AsLong(res); + fileno = _PyInt_AsInt(res); Py_DECREF(res); if (fileno == -1 && PyErr_Occurred()) goto error; diff -r f2353e74b335 Modules/_io/fileio.c --- a/Modules/_io/fileio.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/_io/fileio.c Wed Jan 09 23:37:32 2013 +0200 @@ -211,7 +211,7 @@ return -1; } - fd = PyLong_AsLong(nameobj); + fd = _PyLong_AsInt(nameobj); if (fd < 0) { if (!PyErr_Occurred()) { PyErr_SetString(PyExc_ValueError, diff -r f2353e74b335 Modules/selectmodule.c --- a/Modules/selectmodule.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/selectmodule.c Wed Jan 09 23:37:32 2013 +0200 @@ -343,10 +343,13 @@ i = pos = 0; while (PyDict_Next(self->dict, &pos, &key, &value)) { - self->ufds[i].fd = PyInt_AsLong(key); + assert(i < self->ufd_len); + /* Never overflow */ + self->ufds[i].fd = (int)PyInt_AsLong(key); self->ufds[i].events = (short)PyInt_AsLong(value); i++; } + assert(i == self->ufd_len); self->ufd_uptodate = 1; return 1; } @@ -362,10 +365,11 @@ poll_register(pollObject *self, PyObject *args) { PyObject *o, *key, *value; - int fd, events = POLLIN | POLLPRI | POLLOUT; + int fd; + short events = POLLIN | POLLPRI | POLLOUT; int err; - if (!PyArg_ParseTuple(args, "O|i:register", &o, &events)) { + if (!PyArg_ParseTuple(args, "O|h:register", &o, &events)) { return NULL; } @@ -503,7 +507,7 @@ tout = PyNumber_Int(tout); if (!tout) return NULL; - timeout = PyInt_AsLong(tout); + timeout = _PyInt_AsInt(tout); Py_DECREF(tout); if (timeout == -1 && PyErr_Occurred()) return NULL; diff -r f2353e74b335 Modules/socketmodule.c --- a/Modules/socketmodule.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/socketmodule.c Wed Jan 09 23:37:32 2013 +0200 @@ -1713,7 +1713,7 @@ static PyObject * sock_setblocking(PySocketSockObject *s, PyObject *arg) { - int block; + long block; block = PyInt_AsLong(arg); if (block == -1 && PyErr_Occurred()) @@ -2243,7 +2243,7 @@ int backlog; int res; - backlog = PyInt_AsLong(arg); + backlog = _PyInt_AsInt(arg); if (backlog == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS @@ -2894,7 +2894,7 @@ int how; int res; - how = PyInt_AsLong(arg); + how = _PyInt_AsInt(arg); if (how == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS diff -r f2353e74b335 Objects/fileobject.c --- a/Objects/fileobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/fileobject.c Wed Jan 09 23:37:32 2013 +0200 @@ -2659,10 +2659,10 @@ PyObject *meth; if (PyInt_Check(o)) { - fd = PyInt_AsLong(o); + fd = _PyInt_AsInt(o); } else if (PyLong_Check(o)) { - fd = PyLong_AsLong(o); + fd = _PyLong_AsInt(o); } else if ((meth = PyObject_GetAttrString(o, "fileno")) != NULL) { @@ -2672,11 +2672,11 @@ return -1; if (PyInt_Check(fno)) { - fd = PyInt_AsLong(fno); + fd = _PyInt_AsInt(fno); Py_DECREF(fno); } else if (PyLong_Check(fno)) { - fd = PyLong_AsLong(fno); + fd = _PyLong_AsInt(fno); Py_DECREF(fno); } else { diff -r f2353e74b335 Objects/intobject.c --- a/Objects/intobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/intobject.c Wed Jan 09 23:37:32 2013 +0200 @@ -189,6 +189,20 @@ return val; } +int +_PyInt_AsInt(PyObject *obj) +{ + long result = PyInt_AsLong(obj); + if (result == -1 && PyErr_Occurred()) + return -1; + if (result > INT_MAX || result < INT_MIN) { + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to C int"); + return -1; + } + return (int)result; +} + Py_ssize_t PyInt_AsSsize_t(register PyObject *op) { diff -r f2353e74b335 Objects/longobject.c --- a/Objects/longobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/longobject.c Wed Jan 09 23:37:32 2013 +0200 @@ -339,6 +339,24 @@ return result; } +/* Get a C int from a long int object or any object that has an __int__ + method. Return -1 and set an error if overflow occurs. */ + +int +_PyLong_AsInt(PyObject *obj) +{ + int overflow; + long result = PyLong_AsLongAndOverflow(obj, &overflow); + if (overflow || result > INT_MAX || result < INT_MIN) { + /* XXX: could be cute and give a different + message for overflow == -1 */ + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to C int"); + return -1; + } + return (int)result; +} + /* Get a Py_ssize_t from a long int object. Returns -1 and sets an error condition if overflow occurs. */ diff -r f2353e74b335 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/unicodeobject.c Wed Jan 09 23:37:32 2013 +0200 @@ -8407,7 +8407,9 @@ "* wants int"); goto onError; } - width = PyInt_AsLong(v); + width = PyInt_AsSsize_t(v); + if (width == -1 && PyErr_Occurred()) + goto onError; if (width < 0) { flags |= F_LJUST; width = -width; @@ -8442,7 +8444,9 @@ "* wants int"); goto onError; } - prec = PyInt_AsLong(v); + prec = _PyInt_AsInt(v); + if (prec == -1 && PyErr_Occurred()) + goto onError; if (prec < 0) prec = 0; if (--fmtcnt >= 0) -------------- next part -------------- diff -r f28aff31900a Include/longobject.h --- a/Include/longobject.h Wed Jan 09 12:21:57 2013 +0200 +++ b/Include/longobject.h Wed Jan 09 23:37:21 2013 +0200 @@ -26,6 +26,9 @@ PyAPI_FUNC(size_t) PyLong_AsSize_t(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLong(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLongMask(PyObject *); +#ifndef Py_LIMITED_API +PyAPI_FUNC(int) _PyLong_AsInt(PyObject *); +#endif PyAPI_FUNC(PyObject *) PyLong_GetInfo(void); /* It may be useful in the future. I've added it in the PyInt -> PyLong diff -r f28aff31900a Lib/ctypes/test/test_structures.py --- a/Lib/ctypes/test/test_structures.py Wed Jan 09 12:21:57 2013 +0200 +++ b/Lib/ctypes/test/test_structures.py Wed Jan 09 23:37:21 2013 +0200 @@ -1,6 +1,7 @@ import unittest from ctypes import * from struct import calcsize +import _testcapi class SubclassesTest(unittest.TestCase): def test_subclass(self): @@ -199,6 +200,14 @@ "_pack_": -1} self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + # Issue 15989 + d = {"_fields_": [("a", c_byte)], + "_pack_": _testcapi.INT_MAX + 1} + self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + d = {"_fields_": [("a", c_byte)], + "_pack_": _testcapi.UINT_MAX + 2} + self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + def test_initializers(self): class Person(Structure): _fields_ = [("name", c_char*6), diff -r f28aff31900a Lib/test/string_tests.py --- a/Lib/test/string_tests.py Wed Jan 09 12:21:57 2013 +0200 +++ b/Lib/test/string_tests.py Wed Jan 09 23:37:21 2013 +0200 @@ -5,6 +5,7 @@ import unittest, string, sys, struct from test import support from collections import UserList +import _testcapi class Sequence: def __init__(self, seq='wxyz'): self.seq = seq @@ -1142,6 +1143,16 @@ self.checkraises(TypeError, '%10.*f', '__mod__', ('foo', 42.)) self.checkraises(ValueError, '%10', '__mod__', (42,)) + self.checkraises(OverflowError, '%*s', '__mod__', + (_testcapi.PY_SSIZE_T_MAX + 1, '')) + self.checkraises(OverflowError, '%.*f', '__mod__', + (_testcapi.INT_MAX + 1, 1. / 7)) + # Issue 15989 + self.checkraises(OverflowError, '%*s', '__mod__', + (1 << (_testcapi.PY_SSIZE_T_MAX.bit_length() + 1), '')) + self.checkraises(OverflowError, '%.*f', '__mod__', + (_testcapi.UINT_MAX + 1, 1. / 7)) + class X(object): pass self.checkraises(TypeError, 'abc', '__mod__', X()) diff -r f28aff31900a Lib/test/test_fcntl.py --- a/Lib/test/test_fcntl.py Wed Jan 09 12:21:57 2013 +0200 +++ b/Lib/test/test_fcntl.py Wed Jan 09 23:37:21 2013 +0200 @@ -6,6 +6,7 @@ import os import struct import sys +import _testcapi import unittest from test.support import verbose, TESTFN, unlink, run_unittest, import_module @@ -76,6 +77,26 @@ rv = fcntl.fcntl(self.f, fcntl.F_SETLKW, lockdata) self.f.close() + def test_fcntl_bad_file(self): + class F: + def __init__(self, fn): + self.fn = fn + def fileno(self): + return self.fn + self.assertRaises(ValueError, fcntl.fcntl, -1, fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(ValueError, fcntl.fcntl, F(-1), fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(TypeError, fcntl.fcntl, 'spam', fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(TypeError, fcntl.fcntl, F('spam'), fcntl.F_SETFL, os.O_NONBLOCK) + # Issue 15989 + self.assertRaises(OverflowError, fcntl.fcntl, _testcapi.INT_MAX + 1, + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, F(_testcapi.INT_MAX + 1), + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, _testcapi.INT_MIN - 1, + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, F(_testcapi.INT_MIN - 1), + fcntl.F_SETFL, os.O_NONBLOCK) + def test_fcntl_64_bit(self): # Issue #1309352: fcntl shouldn't fail when the third arg fits in a # C 'long' but not in a C 'int'. diff -r f28aff31900a Lib/test/test_fileio.py --- a/Lib/test/test_fileio.py Wed Jan 09 12:21:57 2013 +0200 +++ b/Lib/test/test_fileio.py Wed Jan 09 23:37:21 2013 +0200 @@ -7,6 +7,7 @@ from array import array from weakref import proxy from functools import wraps +import _testcapi from test.support import TESTFN, check_warnings, run_unittest, make_bad_fd from collections import UserList @@ -346,6 +347,9 @@ if sys.platform == 'win32': import msvcrt self.assertRaises(IOError, msvcrt.get_osfhandle, make_bad_fd()) + # Issue 15989 + self.assertRaises(TypeError, _FileIO, _testcapi.INT_MAX + 1) + self.assertRaises(TypeError, _FileIO, _testcapi.INT_MIN - 1) def testBadModeArgument(self): # verify that we get a sensible error message for bad mode argument diff -r f28aff31900a Lib/test/test_io.py --- a/Lib/test/test_io.py Wed Jan 09 12:21:57 2013 +0200 +++ b/Lib/test/test_io.py Wed Jan 09 23:37:21 2013 +0200 @@ -31,6 +31,7 @@ import errno import warnings import pickle +import _testcapi from itertools import cycle, count from collections import deque, UserList from test import support @@ -1903,6 +1904,14 @@ t.write("A\rB") self.assertEqual(r.getvalue(), b"XY\nZA\rB") + # Issue 15989 + def test_device_encoding(self): + b = self.BytesIO() + b.fileno = lambda: _testcapi.INT_MAX + 1 + self.assertRaises(OverflowError, self.TextIOWrapper, b) + b.fileno = lambda: _testcapi.UINT_MAX + 1 + self.assertRaises(OverflowError, self.TextIOWrapper, b) + def test_encoding(self): # Check the encoding attribute is always set, and valid b = self.BytesIO() diff -r f28aff31900a Lib/test/test_poll.py --- a/Lib/test/test_poll.py Wed Jan 09 12:21:57 2013 +0200 +++ b/Lib/test/test_poll.py Wed Jan 09 23:37:21 2013 +0200 @@ -1,6 +1,7 @@ # Test case for the os.poll() function import os, select, random, unittest +import _testcapi from test.support import TESTFN, run_unittest try: @@ -150,6 +151,15 @@ if x != 5: self.fail('Overflow must have occurred') + pollster = select.poll() + # Issue 15989 + self.assertRaises(OverflowError, pollster.register, 0, + _testcapi.SHRT_MAX + 1) + self.assertRaises(OverflowError, pollster.register, 0, + _testcapi.USHRT_MAX + 1) + self.assertRaises(OverflowError, pollster.poll, _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, pollster.poll, _testcapi.UINT_MAX + 1) + def test_main(): run_unittest(PollTests) diff -r f28aff31900a Lib/test/test_socket.py --- a/Lib/test/test_socket.py Wed Jan 09 12:21:57 2013 +0200 +++ b/Lib/test/test_socket.py Wed Jan 09 23:37:21 2013 +0200 @@ -7,6 +7,7 @@ import io import socket import select +import _testcapi import time import traceback import queue @@ -850,11 +851,17 @@ self.assertRaises(ValueError, fp.writable) self.assertRaises(ValueError, fp.seekable) - def testListenBacklog0(self): + def test_listen_backlog(self): + for backlog in 0, -1: + srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + srv.bind((HOST, 0)) + srv.listen(backlog) + srv.close() + + # Issue 15989 srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.bind((HOST, 0)) - # backlog = 0 - srv.listen(0) + self.assertRaises(OverflowError, srv.listen, _testcapi.INT_MAX + 1) srv.close() @unittest.skipUnless(SUPPORTS_IPV6, 'IPv6 required for this test.') @@ -954,6 +961,11 @@ def _testShutdown(self): self.serv_conn.send(MSG) + # Issue 15989 + self.assertRaises(OverflowError, self.serv_conn.shutdown, + _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, self.serv_conn.shutdown, + 2 + (_testcapi.UINT_MAX + 1)) self.serv_conn.shutdown(2) def testDetach(self): @@ -1075,6 +1087,11 @@ pass end = time.time() self.assertTrue((end - start) < 1.0, "Error setting non-blocking mode.") + # Issue 15989 + self.assertRaises(OverflowError, self.serv.setblocking, + _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, self.serv.setblocking, + _testcapi.UINT_MAX + 1) def _testSetBlocking(self): pass diff -r f28aff31900a Modules/_ctypes/stgdict.c --- a/Modules/_ctypes/stgdict.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/_ctypes/stgdict.c Wed Jan 09 23:37:21 2013 +0200 @@ -335,7 +335,7 @@ isPacked = PyObject_GetAttrString(type, "_pack_"); if (isPacked) { - pack = PyLong_AsLong(isPacked); + pack = _PyLong_AsInt(isPacked); if (pack < 0 || PyErr_Occurred()) { Py_XDECREF(isPacked); PyErr_SetString(PyExc_ValueError, diff -r f28aff31900a Modules/_io/_iomodule.c --- a/Modules/_io/_iomodule.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/_io/_iomodule.c Wed Jan 09 23:37:21 2013 +0200 @@ -303,7 +303,8 @@ int text = 0, binary = 0, universal = 0; char rawmode[5], *m; - int line_buffering, isatty; + int line_buffering; + long isatty; PyObject *raw, *modeobj = NULL, *buffer = NULL, *wrapper = NULL; @@ -441,12 +442,12 @@ #ifdef HAVE_STRUCT_STAT_ST_BLKSIZE { struct stat st; - long fileno; + int fileno; PyObject *res = PyObject_CallMethod(raw, "fileno", NULL); if (res == NULL) goto error; - fileno = PyLong_AsLong(res); + fileno = _PyLong_AsInt(res); Py_DECREF(res); if (fileno == -1 && PyErr_Occurred()) goto error; diff -r f28aff31900a Modules/_io/fileio.c --- a/Modules/_io/fileio.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/_io/fileio.c Wed Jan 09 23:37:21 2013 +0200 @@ -240,7 +240,7 @@ return -1; } - fd = PyLong_AsLong(nameobj); + fd = _PyLong_AsInt(nameobj); if (fd < 0) { if (!PyErr_Occurred()) { PyErr_SetString(PyExc_ValueError, diff -r f28aff31900a Modules/selectmodule.c --- a/Modules/selectmodule.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/selectmodule.c Wed Jan 09 23:37:21 2013 +0200 @@ -340,10 +340,13 @@ i = pos = 0; while (PyDict_Next(self->dict, &pos, &key, &value)) { - self->ufds[i].fd = PyLong_AsLong(key); + assert(i < self->ufd_len); + /* Never overflow */ + self->ufds[i].fd = (int)PyLong_AsLong(key); self->ufds[i].events = (short)PyLong_AsLong(value); i++; } + assert(i == self->ufd_len); self->ufd_uptodate = 1; return 1; } @@ -359,10 +362,11 @@ poll_register(pollObject *self, PyObject *args) { PyObject *o, *key, *value; - int fd, events = POLLIN | POLLPRI | POLLOUT; + int fd; + short events = POLLIN | POLLPRI | POLLOUT; int err; - if (!PyArg_ParseTuple(args, "O|i:register", &o, &events)) { + if (!PyArg_ParseTuple(args, "O|h:register", &o, &events)) { return NULL; } @@ -501,7 +505,7 @@ tout = PyNumber_Long(tout); if (!tout) return NULL; - timeout = PyLong_AsLong(tout); + timeout = _PyLong_AsInt(tout); Py_DECREF(tout); if (timeout == -1 && PyErr_Occurred()) return NULL; diff -r f28aff31900a Modules/socketmodule.c --- a/Modules/socketmodule.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/socketmodule.c Wed Jan 09 23:37:21 2013 +0200 @@ -1737,7 +1737,7 @@ static PyObject * sock_setblocking(PySocketSockObject *s, PyObject *arg) { - int block; + long block; block = PyLong_AsLong(arg); if (block == -1 && PyErr_Occurred()) @@ -2219,7 +2219,7 @@ int backlog; int res; - backlog = PyLong_AsLong(arg); + backlog = _PyLong_AsInt(arg); if (backlog == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS @@ -2822,7 +2822,7 @@ int how; int res; - how = PyLong_AsLong(arg); + how = _PyLong_AsInt(arg); if (how == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS diff -r f28aff31900a Objects/fileobject.c --- a/Objects/fileobject.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Objects/fileobject.c Wed Jan 09 23:37:21 2013 +0200 @@ -200,7 +200,7 @@ PyObject *meth; if (PyLong_Check(o)) { - fd = PyLong_AsLong(o); + fd = _PyLong_AsInt(o); } else if ((meth = PyObject_GetAttrString(o, "fileno")) != NULL) { @@ -210,7 +210,7 @@ return -1; if (PyLong_Check(fno)) { - fd = PyLong_AsLong(fno); + fd = _PyLong_AsInt(fno); Py_DECREF(fno); } else { diff -r f28aff31900a Objects/longobject.c --- a/Objects/longobject.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Objects/longobject.c Wed Jan 09 23:37:21 2013 +0200 @@ -424,6 +424,24 @@ return result; } +/* Get a C int from a long int object or any object that has an __int__ + method. Return -1 and set an error if overflow occurs. */ + +int +_PyLong_AsInt(PyObject *obj) +{ + int overflow; + long result = PyLong_AsLongAndOverflow(obj, &overflow); + if (overflow || result > INT_MAX || result < INT_MIN) { + /* XXX: could be cute and give a different + message for overflow == -1 */ + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to C int"); + return -1; + } + return (int)result; +} + /* Get a Py_ssize_t from a long int object. Returns -1 and sets an error condition if overflow occurs. */ diff -r f28aff31900a Objects/unicodeobject.c --- a/Objects/unicodeobject.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Objects/unicodeobject.c Wed Jan 09 23:37:21 2013 +0200 @@ -9636,7 +9636,7 @@ "* wants int"); goto onError; } - width = PyLong_AsLong(v); + width = PyLong_AsSsize_t(v); if (width == -1 && PyErr_Occurred()) goto onError; if (width < 0) { @@ -9673,7 +9673,7 @@ "* wants int"); goto onError; } - prec = PyLong_AsLong(v); + prec = _PyLong_AsInt(v); if (prec == -1 && PyErr_Occurred()) goto onError; if (prec < 0) -------------- next part -------------- diff -r 3e18ccaa537e Include/longobject.h --- a/Include/longobject.h Wed Jan 09 09:52:01 2013 -0600 +++ b/Include/longobject.h Wed Jan 09 23:37:13 2013 +0200 @@ -26,6 +26,9 @@ PyAPI_FUNC(size_t) PyLong_AsSize_t(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLong(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLongMask(PyObject *); +#ifndef Py_LIMITED_API +PyAPI_FUNC(int) _PyLong_AsInt(PyObject *); +#endif PyAPI_FUNC(PyObject *) PyLong_GetInfo(void); /* It may be useful in the future. I've added it in the PyInt -> PyLong diff -r 3e18ccaa537e Lib/ctypes/test/test_structures.py --- a/Lib/ctypes/test/test_structures.py Wed Jan 09 09:52:01 2013 -0600 +++ b/Lib/ctypes/test/test_structures.py Wed Jan 09 23:37:13 2013 +0200 @@ -1,6 +1,7 @@ import unittest from ctypes import * from struct import calcsize +import _testcapi class SubclassesTest(unittest.TestCase): def test_subclass(self): @@ -199,6 +200,14 @@ "_pack_": -1} self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + # Issue 15989 + d = {"_fields_": [("a", c_byte)], + "_pack_": _testcapi.INT_MAX + 1} + self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + d = {"_fields_": [("a", c_byte)], + "_pack_": _testcapi.UINT_MAX + 2} + self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + def test_initializers(self): class Person(Structure): _fields_ = [("name", c_char*6), diff -r 3e18ccaa537e Lib/test/string_tests.py --- a/Lib/test/string_tests.py Wed Jan 09 09:52:01 2013 -0600 +++ b/Lib/test/string_tests.py Wed Jan 09 23:37:13 2013 +0200 @@ -5,6 +5,7 @@ import unittest, string, sys, struct from test import support from collections import UserList +import _testcapi class Sequence: def __init__(self, seq='wxyz'): self.seq = seq @@ -1206,6 +1207,16 @@ self.checkraises(ValueError, '%%%df' % (2**64), '__mod__', (3.2)) self.checkraises(ValueError, '%%.%df' % (2**64), '__mod__', (3.2)) + self.checkraises(OverflowError, '%*s', '__mod__', + (_testcapi.PY_SSIZE_T_MAX + 1, '')) + self.checkraises(OverflowError, '%.*f', '__mod__', + (_testcapi.INT_MAX + 1, 1. / 7)) + # Issue 15989 + self.checkraises(OverflowError, '%*s', '__mod__', + (1 << (_testcapi.PY_SSIZE_T_MAX.bit_length() + 1), '')) + self.checkraises(OverflowError, '%.*f', '__mod__', + (_testcapi.UINT_MAX + 1, 1. / 7)) + class X(object): pass self.checkraises(TypeError, 'abc', '__mod__', X()) diff -r 3e18ccaa537e Lib/test/test_fcntl.py --- a/Lib/test/test_fcntl.py Wed Jan 09 09:52:01 2013 -0600 +++ b/Lib/test/test_fcntl.py Wed Jan 09 23:37:13 2013 +0200 @@ -6,6 +6,7 @@ import os import struct import sys +import _testcapi import unittest from test.support import verbose, TESTFN, unlink, run_unittest, import_module @@ -76,6 +77,26 @@ rv = fcntl.fcntl(self.f, fcntl.F_SETLKW, lockdata) self.f.close() + def test_fcntl_bad_file(self): + class F: + def __init__(self, fn): + self.fn = fn + def fileno(self): + return self.fn + self.assertRaises(ValueError, fcntl.fcntl, -1, fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(ValueError, fcntl.fcntl, F(-1), fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(TypeError, fcntl.fcntl, 'spam', fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(TypeError, fcntl.fcntl, F('spam'), fcntl.F_SETFL, os.O_NONBLOCK) + # Issue 15989 + self.assertRaises(OverflowError, fcntl.fcntl, _testcapi.INT_MAX + 1, + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, F(_testcapi.INT_MAX + 1), + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, _testcapi.INT_MIN - 1, + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, F(_testcapi.INT_MIN - 1), + fcntl.F_SETFL, os.O_NONBLOCK) + def test_fcntl_64_bit(self): # Issue #1309352: fcntl shouldn't fail when the third arg fits in a # C 'long' but not in a C 'int'. diff -r 3e18ccaa537e Lib/test/test_fileio.py --- a/Lib/test/test_fileio.py Wed Jan 09 09:52:01 2013 -0600 +++ b/Lib/test/test_fileio.py Wed Jan 09 23:37:13 2013 +0200 @@ -8,6 +8,7 @@ from array import array from weakref import proxy from functools import wraps +import _testcapi from test.support import TESTFN, check_warnings, run_unittest, make_bad_fd from collections import UserList @@ -347,6 +348,9 @@ if sys.platform == 'win32': import msvcrt self.assertRaises(IOError, msvcrt.get_osfhandle, make_bad_fd()) + # Issue 15989 + self.assertRaises(TypeError, _FileIO, _testcapi.INT_MAX + 1) + self.assertRaises(TypeError, _FileIO, _testcapi.INT_MIN - 1) def testBadModeArgument(self): # verify that we get a sensible error message for bad mode argument diff -r 3e18ccaa537e Lib/test/test_io.py --- a/Lib/test/test_io.py Wed Jan 09 09:52:01 2013 -0600 +++ b/Lib/test/test_io.py Wed Jan 09 23:37:13 2013 +0200 @@ -32,6 +32,7 @@ import unittest import warnings import weakref +import _testcapi from collections import deque, UserList from itertools import cycle, count from test import support @@ -1962,6 +1963,14 @@ os.environ.clear() os.environ.update(old_environ) + # Issue 15989 + def test_device_encoding(self): + b = self.BytesIO() + b.fileno = lambda: _testcapi.INT_MAX + 1 + self.assertRaises(OverflowError, self.TextIOWrapper, b) + b.fileno = lambda: _testcapi.UINT_MAX + 1 + self.assertRaises(OverflowError, self.TextIOWrapper, b) + def test_encoding(self): # Check the encoding attribute is always set, and valid b = self.BytesIO() diff -r 3e18ccaa537e Lib/test/test_poll.py --- a/Lib/test/test_poll.py Wed Jan 09 09:52:01 2013 -0600 +++ b/Lib/test/test_poll.py Wed Jan 09 23:37:13 2013 +0200 @@ -1,6 +1,7 @@ # Test case for the os.poll() function import os, select, random, unittest +import _testcapi from test.support import TESTFN, run_unittest try: @@ -150,6 +151,15 @@ if x != 5: self.fail('Overflow must have occurred') + pollster = select.poll() + # Issue 15989 + self.assertRaises(OverflowError, pollster.register, 0, + _testcapi.SHRT_MAX + 1) + self.assertRaises(OverflowError, pollster.register, 0, + _testcapi.USHRT_MAX + 1) + self.assertRaises(OverflowError, pollster.poll, _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, pollster.poll, _testcapi.UINT_MAX + 1) + def test_main(): run_unittest(PollTests) diff -r 3e18ccaa537e Lib/test/test_posix.py --- a/Lib/test/test_posix.py Wed Jan 09 09:52:01 2013 -0600 +++ b/Lib/test/test_posix.py Wed Jan 09 23:37:13 2013 +0200 @@ -17,6 +17,7 @@ import tempfile import unittest import warnings +import _testcapi _DUMMY_SYMLINK = os.path.join(tempfile.gettempdir(), support.TESTFN + '-dummy-symlink') @@ -537,6 +538,10 @@ except OSError: pass + # Issue 15989 + self.assertRaises(OverflowError, os.pipe2, _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, os.pipe2, _testcapi.UINT_MAX + 1) + def test_utime(self): if hasattr(posix, 'utime'): now = time.time() diff -r 3e18ccaa537e Lib/test/test_socket.py --- a/Lib/test/test_socket.py Wed Jan 09 09:52:01 2013 -0600 +++ b/Lib/test/test_socket.py Wed Jan 09 23:37:13 2013 +0200 @@ -1262,11 +1262,17 @@ for protocol in range(pickle.HIGHEST_PROTOCOL + 1): self.assertRaises(TypeError, pickle.dumps, sock, protocol) - def test_listen_backlog0(self): + def test_listen_backlog(self): + for backlog in 0, -1: + srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + srv.bind((HOST, 0)) + srv.listen(backlog) + srv.close() + + # Issue 15989 srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.bind((HOST, 0)) - # backlog = 0 - srv.listen(0) + self.assertRaises(OverflowError, srv.listen, _testcapi.INT_MAX + 1) srv.close() @unittest.skipUnless(support.IPV6_ENABLED, 'IPv6 required for this test.') @@ -1582,6 +1588,11 @@ def _testShutdown(self): self.serv_conn.send(MSG) + # Issue 15989 + self.assertRaises(OverflowError, self.serv_conn.shutdown, + _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, self.serv_conn.shutdown, + 2 + (_testcapi.UINT_MAX + 1)) self.serv_conn.shutdown(2) def testDetach(self): @@ -3563,6 +3574,11 @@ pass end = time.time() self.assertTrue((end - start) < 1.0, "Error setting non-blocking mode.") + # Issue 15989 + self.assertRaises(OverflowError, self.serv.setblocking, + _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, self.serv.setblocking, + _testcapi.UINT_MAX + 1) def _testSetBlocking(self): pass diff -r 3e18ccaa537e Modules/_ctypes/stgdict.c --- a/Modules/_ctypes/stgdict.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Modules/_ctypes/stgdict.c Wed Jan 09 23:37:13 2013 +0200 @@ -335,7 +335,7 @@ isPacked = PyObject_GetAttrString(type, "_pack_"); if (isPacked) { - pack = PyLong_AsLong(isPacked); + pack = _PyLong_AsInt(isPacked); if (pack < 0 || PyErr_Occurred()) { Py_XDECREF(isPacked); PyErr_SetString(PyExc_ValueError, diff -r 3e18ccaa537e Modules/_io/fileio.c --- a/Modules/_io/fileio.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Modules/_io/fileio.c Wed Jan 09 23:37:13 2013 +0200 @@ -244,7 +244,7 @@ return -1; } - fd = PyLong_AsLong(nameobj); + fd = _PyLong_AsInt(nameobj); if (fd < 0) { if (!PyErr_Occurred()) { PyErr_SetString(PyExc_ValueError, @@ -382,7 +382,7 @@ goto error; } - self->fd = PyLong_AsLong(fdobj); + self->fd = _PyLong_AsInt(fdobj); Py_DECREF(fdobj); if (self->fd == -1) { goto error; diff -r 3e18ccaa537e Modules/_io/textio.c --- a/Modules/_io/textio.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Modules/_io/textio.c Wed Jan 09 23:37:13 2013 +0200 @@ -881,7 +881,7 @@ } } else { - int fd = (int) PyLong_AsLong(fileno); + int fd = _PyLong_AsInt(fileno); Py_DECREF(fileno); if (fd == -1 && PyErr_Occurred()) { goto error; diff -r 3e18ccaa537e Modules/parsermodule.c --- a/Modules/parsermodule.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Modules/parsermodule.c Wed Jan 09 23:37:13 2013 +0200 @@ -725,7 +725,7 @@ /* elem must always be a sequence, however simple */ PyObject* elem = PySequence_GetItem(tuple, i); int ok = elem != NULL; - long type = 0; + int type = 0; char *strn = 0; if (ok) @@ -736,8 +736,14 @@ ok = 0; else { ok = PyLong_Check(temp); - if (ok) - type = PyLong_AS_LONG(temp); + if (ok) { + type = _PyLong_AsInt(temp); + if (type == -1 && PyErr_Occurred()) { + Py_DECREF(temp); + Py_DECREF(elem); + return 0; + } + } Py_DECREF(temp); } } @@ -773,8 +779,16 @@ if (len == 3) { PyObject *o = PySequence_GetItem(elem, 2); if (o != NULL) { - if (PyLong_Check(o)) - *line_num = PyLong_AS_LONG(o); + if (PyLong_Check(o)) { + int num = _PyLong_AsInt(o); + if (num == -1 && PyErr_Occurred()) { + Py_DECREF(o); + Py_DECREF(temp); + Py_DECREF(elem); + return 0; + } + *line_num = num; + } else { PyErr_Format(parser_error, "third item in terminal node must be an" diff -r 3e18ccaa537e Modules/posixmodule.c --- a/Modules/posixmodule.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Modules/posixmodule.c Wed Jan 09 23:37:13 2013 +0200 @@ -8174,7 +8174,7 @@ int fds[2]; int res; - flags = PyLong_AsLong(arg); + flags = _PyLong_AsInt(arg); if (flags == -1 && PyErr_Occurred()) return NULL; diff -r 3e18ccaa537e Modules/selectmodule.c --- a/Modules/selectmodule.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Modules/selectmodule.c Wed Jan 09 23:37:13 2013 +0200 @@ -357,10 +357,13 @@ i = pos = 0; while (PyDict_Next(self->dict, &pos, &key, &value)) { - self->ufds[i].fd = PyLong_AsLong(key); + assert(i < self->ufd_len); + /* Never overflow */ + self->ufds[i].fd = (int)PyLong_AsLong(key); self->ufds[i].events = (short)PyLong_AsLong(value); i++; } + assert(i == self->ufd_len); self->ufd_uptodate = 1; return 1; } @@ -376,10 +379,11 @@ poll_register(pollObject *self, PyObject *args) { PyObject *o, *key, *value; - int fd, events = POLLIN | POLLPRI | POLLOUT; + int fd; + short events = POLLIN | POLLPRI | POLLOUT; int err; - if (!PyArg_ParseTuple(args, "O|i:register", &o, &events)) { + if (!PyArg_ParseTuple(args, "O|h:register", &o, &events)) { return NULL; } @@ -518,7 +522,7 @@ tout = PyNumber_Long(tout); if (!tout) return NULL; - timeout = PyLong_AsLong(tout); + timeout = _PyLong_AsInt(tout); Py_DECREF(tout); if (timeout == -1 && PyErr_Occurred()) return NULL; diff -r 3e18ccaa537e Modules/socketmodule.c --- a/Modules/socketmodule.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Modules/socketmodule.c Wed Jan 09 23:37:13 2013 +0200 @@ -2073,7 +2073,7 @@ static PyObject * sock_setblocking(PySocketSockObject *s, PyObject *arg) { - int block; + long block; block = PyLong_AsLong(arg); if (block == -1 && PyErr_Occurred()) @@ -2555,7 +2555,7 @@ int backlog; int res; - backlog = PyLong_AsLong(arg); + backlog = _PyLong_AsInt(arg); if (backlog == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS @@ -3712,7 +3712,7 @@ int how; int res; - how = PyLong_AsLong(arg); + how = _PyLong_AsInt(arg); if (how == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS diff -r 3e18ccaa537e Objects/fileobject.c --- a/Objects/fileobject.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Objects/fileobject.c Wed Jan 09 23:37:13 2013 +0200 @@ -200,7 +200,7 @@ _Py_IDENTIFIER(fileno); if (PyLong_Check(o)) { - fd = PyLong_AsLong(o); + fd = _PyLong_AsInt(o); } else if ((meth = _PyObject_GetAttrId(o, &PyId_fileno)) != NULL) { @@ -210,7 +210,7 @@ return -1; if (PyLong_Check(fno)) { - fd = PyLong_AsLong(fno); + fd = _PyLong_AsInt(fno); Py_DECREF(fno); } else { diff -r 3e18ccaa537e Objects/longobject.c --- a/Objects/longobject.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Objects/longobject.c Wed Jan 09 23:37:13 2013 +0200 @@ -434,6 +434,24 @@ return result; } +/* Get a C int from a long int object or any object that has an __int__ + method. Return -1 and set an error if overflow occurs. */ + +int +_PyLong_AsInt(PyObject *obj) +{ + int overflow; + long result = PyLong_AsLongAndOverflow(obj, &overflow); + if (overflow || result > INT_MAX || result < INT_MIN) { + /* XXX: could be cute and give a different + message for overflow == -1 */ + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to C int"); + return -1; + } + return (int)result; +} + /* Get a Py_ssize_t from a long int object. Returns -1 and sets an error condition if overflow occurs. */ diff -r 3e18ccaa537e Objects/unicodeobject.c --- a/Objects/unicodeobject.c Wed Jan 09 09:52:01 2013 -0600 +++ b/Objects/unicodeobject.c Wed Jan 09 23:37:13 2013 +0200 @@ -13566,7 +13566,7 @@ "* wants int"); goto onError; } - width = PyLong_AsLong(v); + width = PyLong_AsSsize_t(v); if (width == -1 && PyErr_Occurred()) goto onError; if (width < 0) { @@ -13606,7 +13606,7 @@ "* wants int"); goto onError; } - prec = PyLong_AsLong(v); + prec = _PyLong_AsInt(v); if (prec == -1 && PyErr_Occurred()) goto onError; if (prec < 0) -------------- next part -------------- diff -r be8e6b81284e Include/longobject.h --- a/Include/longobject.h Wed Jan 09 19:00:26 2013 +0100 +++ b/Include/longobject.h Thu Jan 10 00:03:37 2013 +0200 @@ -26,6 +26,9 @@ PyAPI_FUNC(size_t) PyLong_AsSize_t(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLong(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLongMask(PyObject *); +#ifndef Py_LIMITED_API +PyAPI_FUNC(int) _PyLong_AsInt(PyObject *); +#endif PyAPI_FUNC(PyObject *) PyLong_GetInfo(void); /* It may be useful in the future. I've added it in the PyInt -> PyLong diff -r be8e6b81284e Lib/ctypes/test/test_structures.py --- a/Lib/ctypes/test/test_structures.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/ctypes/test/test_structures.py Thu Jan 10 00:03:37 2013 +0200 @@ -1,6 +1,7 @@ import unittest from ctypes import * from struct import calcsize +import _testcapi class SubclassesTest(unittest.TestCase): def test_subclass(self): @@ -199,6 +200,14 @@ "_pack_": -1} self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + # Issue 15989 + d = {"_fields_": [("a", c_byte)], + "_pack_": _testcapi.INT_MAX + 1} + self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + d = {"_fields_": [("a", c_byte)], + "_pack_": _testcapi.UINT_MAX + 2} + self.assertRaises(ValueError, type(Structure), "X", (Structure,), d) + def test_initializers(self): class Person(Structure): _fields_ = [("name", c_char*6), diff -r be8e6b81284e Lib/test/string_tests.py --- a/Lib/test/string_tests.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/test/string_tests.py Thu Jan 10 00:03:37 2013 +0200 @@ -5,6 +5,7 @@ import unittest, string, sys, struct from test import support from collections import UserList +import _testcapi class Sequence: def __init__(self, seq='wxyz'): self.seq = seq @@ -1206,6 +1207,16 @@ self.checkraises(ValueError, '%%%df' % (2**64), '__mod__', (3.2)) self.checkraises(ValueError, '%%.%df' % (2**64), '__mod__', (3.2)) + self.checkraises(OverflowError, '%*s', '__mod__', + (_testcapi.PY_SSIZE_T_MAX + 1, '')) + self.checkraises(OverflowError, '%.*f', '__mod__', + (_testcapi.INT_MAX + 1, 1. / 7)) + # Issue 15989 + self.checkraises(OverflowError, '%*s', '__mod__', + (1 << (_testcapi.PY_SSIZE_T_MAX.bit_length() + 1), '')) + self.checkraises(OverflowError, '%.*f', '__mod__', + (_testcapi.UINT_MAX + 1, 1. / 7)) + class X(object): pass self.checkraises(TypeError, 'abc', '__mod__', X()) diff -r be8e6b81284e Lib/test/test_fcntl.py --- a/Lib/test/test_fcntl.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/test/test_fcntl.py Thu Jan 10 00:03:37 2013 +0200 @@ -3,6 +3,7 @@ import os import struct import sys +import _testcapi import unittest from test.support import verbose, TESTFN, unlink, run_unittest, import_module @@ -69,6 +70,26 @@ rv = fcntl.fcntl(self.f, fcntl.F_SETLKW, lockdata) self.f.close() + def test_fcntl_bad_file(self): + class F: + def __init__(self, fn): + self.fn = fn + def fileno(self): + return self.fn + self.assertRaises(ValueError, fcntl.fcntl, -1, fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(ValueError, fcntl.fcntl, F(-1), fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(TypeError, fcntl.fcntl, 'spam', fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(TypeError, fcntl.fcntl, F('spam'), fcntl.F_SETFL, os.O_NONBLOCK) + # Issue 15989 + self.assertRaises(OverflowError, fcntl.fcntl, _testcapi.INT_MAX + 1, + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, F(_testcapi.INT_MAX + 1), + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, _testcapi.INT_MIN - 1, + fcntl.F_SETFL, os.O_NONBLOCK) + self.assertRaises(OverflowError, fcntl.fcntl, F(_testcapi.INT_MIN - 1), + fcntl.F_SETFL, os.O_NONBLOCK) + def test_fcntl_64_bit(self): # Issue #1309352: fcntl shouldn't fail when the third arg fits in a # C 'long' but not in a C 'int'. diff -r be8e6b81284e Lib/test/test_fileio.py --- a/Lib/test/test_fileio.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/test/test_fileio.py Thu Jan 10 00:03:37 2013 +0200 @@ -8,6 +8,7 @@ from array import array from weakref import proxy from functools import wraps +import _testcapi from test.support import TESTFN, check_warnings, run_unittest, make_bad_fd from collections import UserList @@ -347,6 +348,9 @@ if sys.platform == 'win32': import msvcrt self.assertRaises(OSError, msvcrt.get_osfhandle, make_bad_fd()) + # Issue 15989 + self.assertRaises(TypeError, _FileIO, _testcapi.INT_MAX + 1) + self.assertRaises(TypeError, _FileIO, _testcapi.INT_MIN - 1) def testBadModeArgument(self): # verify that we get a sensible error message for bad mode argument diff -r be8e6b81284e Lib/test/test_io.py --- a/Lib/test/test_io.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/test/test_io.py Thu Jan 10 00:03:37 2013 +0200 @@ -32,6 +32,7 @@ import unittest import warnings import weakref +import _testcapi from collections import deque, UserList from itertools import cycle, count from test import support @@ -1970,6 +1971,14 @@ os.environ.clear() os.environ.update(old_environ) + # Issue 15989 + def test_device_encoding(self): + b = self.BytesIO() + b.fileno = lambda: _testcapi.INT_MAX + 1 + self.assertRaises(OverflowError, self.TextIOWrapper, b) + b.fileno = lambda: _testcapi.UINT_MAX + 1 + self.assertRaises(OverflowError, self.TextIOWrapper, b) + def test_encoding(self): # Check the encoding attribute is always set, and valid b = self.BytesIO() diff -r be8e6b81284e Lib/test/test_poll.py --- a/Lib/test/test_poll.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/test/test_poll.py Thu Jan 10 00:03:37 2013 +0200 @@ -1,6 +1,11 @@ # Test case for the os.poll() function +<<<<<<< import os, select, random, unittest, subprocess +======= +import os, select, random, unittest +import _testcapi +>>>>>>> from test.support import TESTFN, run_unittest try: @@ -151,6 +156,15 @@ if x != 5: self.fail('Overflow must have occurred') + pollster = select.poll() + # Issue 15989 + self.assertRaises(OverflowError, pollster.register, 0, + _testcapi.SHRT_MAX + 1) + self.assertRaises(OverflowError, pollster.register, 0, + _testcapi.USHRT_MAX + 1) + self.assertRaises(OverflowError, pollster.poll, _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, pollster.poll, _testcapi.UINT_MAX + 1) + def test_main(): run_unittest(PollTests) diff -r be8e6b81284e Lib/test/test_posix.py --- a/Lib/test/test_posix.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/test/test_posix.py Thu Jan 10 00:03:37 2013 +0200 @@ -17,6 +17,7 @@ import tempfile import unittest import warnings +import _testcapi _DUMMY_SYMLINK = os.path.join(tempfile.gettempdir(), support.TESTFN + '-dummy-symlink') @@ -537,6 +538,10 @@ except OSError: pass + # Issue 15989 + self.assertRaises(OverflowError, os.pipe2, _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, os.pipe2, _testcapi.UINT_MAX + 1) + def test_utime(self): if hasattr(posix, 'utime'): now = time.time() diff -r be8e6b81284e Lib/test/test_socket.py --- a/Lib/test/test_socket.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/test/test_socket.py Thu Jan 10 00:03:37 2013 +0200 @@ -1262,11 +1262,17 @@ for protocol in range(pickle.HIGHEST_PROTOCOL + 1): self.assertRaises(TypeError, pickle.dumps, sock, protocol) - def test_listen_backlog0(self): + def test_listen_backlog(self): + for backlog in 0, -1: + srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + srv.bind((HOST, 0)) + srv.listen(backlog) + srv.close() + + # Issue 15989 srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.bind((HOST, 0)) - # backlog = 0 - srv.listen(0) + self.assertRaises(OverflowError, srv.listen, _testcapi.INT_MAX + 1) srv.close() @unittest.skipUnless(support.IPV6_ENABLED, 'IPv6 required for this test.') @@ -1582,6 +1588,11 @@ def _testShutdown(self): self.serv_conn.send(MSG) + # Issue 15989 + self.assertRaises(OverflowError, self.serv_conn.shutdown, + _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, self.serv_conn.shutdown, + 2 + (_testcapi.UINT_MAX + 1)) self.serv_conn.shutdown(2) def testDetach(self): @@ -3563,6 +3574,11 @@ pass end = time.time() self.assertTrue((end - start) < 1.0, "Error setting non-blocking mode.") + # Issue 15989 + self.assertRaises(OverflowError, self.serv.setblocking, + _testcapi.INT_MAX + 1) + self.assertRaises(OverflowError, self.serv.setblocking, + _testcapi.UINT_MAX + 1) def _testSetBlocking(self): pass diff -r be8e6b81284e Modules/_ctypes/stgdict.c --- a/Modules/_ctypes/stgdict.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Modules/_ctypes/stgdict.c Thu Jan 10 00:03:37 2013 +0200 @@ -335,7 +335,7 @@ isPacked = PyObject_GetAttrString(type, "_pack_"); if (isPacked) { - pack = PyLong_AsLong(isPacked); + pack = _PyLong_AsInt(isPacked); if (pack < 0 || PyErr_Occurred()) { Py_XDECREF(isPacked); PyErr_SetString(PyExc_ValueError, diff -r be8e6b81284e Modules/_io/fileio.c --- a/Modules/_io/fileio.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Modules/_io/fileio.c Thu Jan 10 00:03:37 2013 +0200 @@ -244,7 +244,7 @@ return -1; } - fd = PyLong_AsLong(nameobj); + fd = _PyLong_AsInt(nameobj); if (fd < 0) { if (!PyErr_Occurred()) { PyErr_SetString(PyExc_ValueError, @@ -382,7 +382,7 @@ goto error; } - self->fd = PyLong_AsLong(fdobj); + self->fd = _PyLong_AsInt(fdobj); Py_DECREF(fdobj); if (self->fd == -1) { goto error; diff -r be8e6b81284e Modules/_io/textio.c --- a/Modules/_io/textio.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Modules/_io/textio.c Thu Jan 10 00:03:37 2013 +0200 @@ -881,7 +881,7 @@ } } else { - int fd = (int) PyLong_AsLong(fileno); + int fd = _PyLong_AsInt(fileno); Py_DECREF(fileno); if (fd == -1 && PyErr_Occurred()) { goto error; diff -r be8e6b81284e Modules/parsermodule.c --- a/Modules/parsermodule.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Modules/parsermodule.c Thu Jan 10 00:03:37 2013 +0200 @@ -725,7 +725,7 @@ /* elem must always be a sequence, however simple */ PyObject* elem = PySequence_GetItem(tuple, i); int ok = elem != NULL; - long type = 0; + int type = 0; char *strn = 0; if (ok) @@ -736,8 +736,14 @@ ok = 0; else { ok = PyLong_Check(temp); - if (ok) - type = PyLong_AS_LONG(temp); + if (ok) { + type = _PyLong_AsInt(temp); + if (type == -1 && PyErr_Occurred()) { + Py_DECREF(temp); + Py_DECREF(elem); + return 0; + } + } Py_DECREF(temp); } } @@ -773,8 +779,16 @@ if (len == 3) { PyObject *o = PySequence_GetItem(elem, 2); if (o != NULL) { - if (PyLong_Check(o)) - *line_num = PyLong_AS_LONG(o); + if (PyLong_Check(o)) { + int num = _PyLong_AsInt(o); + if (num == -1 && PyErr_Occurred()) { + Py_DECREF(o); + Py_DECREF(temp); + Py_DECREF(elem); + return 0; + } + *line_num = num; + } else { PyErr_Format(parser_error, "third item in terminal node must be an" diff -r be8e6b81284e Modules/posixmodule.c --- a/Modules/posixmodule.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Modules/posixmodule.c Thu Jan 10 00:03:37 2013 +0200 @@ -7647,7 +7647,7 @@ int fds[2]; int res; - flags = PyLong_AsLong(arg); + flags = _PyLong_AsInt(arg); if (flags == -1 && PyErr_Occurred()) return NULL; diff -r be8e6b81284e Modules/selectmodule.c --- a/Modules/selectmodule.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Modules/selectmodule.c Thu Jan 10 00:03:37 2013 +0200 @@ -352,10 +352,13 @@ i = pos = 0; while (PyDict_Next(self->dict, &pos, &key, &value)) { - self->ufds[i].fd = PyLong_AsLong(key); + assert(i < self->ufd_len); + /* Never overflow */ + self->ufds[i].fd = (int)PyLong_AsLong(key); self->ufds[i].events = (short)PyLong_AsLong(value); i++; } + assert(i == self->ufd_len); self->ufd_uptodate = 1; return 1; } @@ -371,10 +374,11 @@ poll_register(pollObject *self, PyObject *args) { PyObject *o, *key, *value; - int fd, events = POLLIN | POLLPRI | POLLOUT; + int fd; + short events = POLLIN | POLLPRI | POLLOUT; int err; - if (!PyArg_ParseTuple(args, "O|i:register", &o, &events)) { + if (!PyArg_ParseTuple(args, "O|h:register", &o, &events)) { return NULL; } @@ -513,7 +517,7 @@ tout = PyNumber_Long(tout); if (!tout) return NULL; - timeout = PyLong_AsLong(tout); + timeout = _PyLong_AsInt(tout); Py_DECREF(tout); if (timeout == -1 && PyErr_Occurred()) return NULL; diff -r be8e6b81284e Modules/socketmodule.c --- a/Modules/socketmodule.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Modules/socketmodule.c Thu Jan 10 00:03:37 2013 +0200 @@ -2013,7 +2013,7 @@ static PyObject * sock_setblocking(PySocketSockObject *s, PyObject *arg) { - int block; + long block; block = PyLong_AsLong(arg); if (block == -1 && PyErr_Occurred()) @@ -2495,7 +2495,7 @@ int backlog; int res; - backlog = PyLong_AsLong(arg); + backlog = _PyLong_AsInt(arg); if (backlog == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS @@ -3647,7 +3647,7 @@ int how; int res; - how = PyLong_AsLong(arg); + how = _PyLong_AsInt(arg); if (how == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS diff -r be8e6b81284e Objects/fileobject.c --- a/Objects/fileobject.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Objects/fileobject.c Thu Jan 10 00:03:37 2013 +0200 @@ -200,7 +200,7 @@ _Py_IDENTIFIER(fileno); if (PyLong_Check(o)) { - fd = PyLong_AsLong(o); + fd = _PyLong_AsInt(o); } else if ((meth = _PyObject_GetAttrId(o, &PyId_fileno)) != NULL) { @@ -210,7 +210,7 @@ return -1; if (PyLong_Check(fno)) { - fd = PyLong_AsLong(fno); + fd = _PyLong_AsInt(fno); Py_DECREF(fno); } else { diff -r be8e6b81284e Objects/longobject.c --- a/Objects/longobject.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Objects/longobject.c Thu Jan 10 00:03:37 2013 +0200 @@ -434,6 +434,24 @@ return result; } +/* Get a C int from a long int object or any object that has an __int__ + method. Return -1 and set an error if overflow occurs. */ + +int +_PyLong_AsInt(PyObject *obj) +{ + int overflow; + long result = PyLong_AsLongAndOverflow(obj, &overflow); + if (overflow || result > INT_MAX || result < INT_MIN) { + /* XXX: could be cute and give a different + message for overflow == -1 */ + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to C int"); + return -1; + } + return (int)result; +} + /* Get a Py_ssize_t from a long int object. Returns -1 and sets an error condition if overflow occurs. */ diff -r be8e6b81284e Objects/unicodeobject.c --- a/Objects/unicodeobject.c Wed Jan 09 19:00:26 2013 +0100 +++ b/Objects/unicodeobject.c Thu Jan 10 00:03:37 2013 +0200 @@ -13521,7 +13521,7 @@ "* wants int"); return -1; } - arg->width = PyLong_AsLong(v); + arg->width = PyLong_AsSsize_t(v); if (arg->width == -1 && PyErr_Occurred()) return -1; if (arg->width < 0) { @@ -13568,7 +13568,7 @@ "* wants int"); return -1; } - arg->prec = PyLong_AsLong(v); + arg->prec = _PyLong_AsInt(v); if (arg->prec == -1 && PyErr_Occurred()) return -1; if (arg->prec < 0) From report at bugs.python.org Thu Jan 10 09:16:10 2013 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 10 Jan 2013 08:16:10 +0000 Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1357805770.84.0.409443832068.issue6975@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- title: symlinks incorrectly resolved on Linux -> symlinks incorrectly resolved on POSIX platforms _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 09:21:07 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 08:21:07 +0000 Subject: [issue16913] ElementTree tostring error when method='text' In-Reply-To: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> Message-ID: <1357806067.79.0.352083513309.issue16913@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I found such example. It happens when the data contains XML entity. >>> ET.tostring(ET.XML('a&'), method='text', encoding='unicode') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/xml/etree/ElementTree.py", line 1171, in tostring ElementTree(element).write(stream, encoding, method=method) File "/home/serhiy/py/cpython/Lib/xml/etree/ElementTree.py", line 824, in write _serialize_text(write, self._root) File "/home/serhiy/py/cpython/Lib/xml/etree/ElementTree.py", line 1057, in _serialize_text write(part) TypeError: string argument expected, got 'list' Indeed, itertext()?returns a list of lists instead of list of strings. >>> list(ET.XML('a&').itertext()) [['a', '&']] The bug is in the C?implementation of itertext(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 09:24:21 2013 From: report at bugs.python.org (Olof Johansson) Date: Thu, 10 Jan 2013 08:24:21 +0000 Subject: [issue16909] urlparse: add userinfo attribute In-Reply-To: <1357742811.51.0.916599948648.issue16909@psf.upfronthosting.co.za> Message-ID: <1357806261.44.0.00514180264563.issue16909@psf.upfronthosting.co.za> Olof Johansson added the comment: Thank you for you feedback. I agree, the reason I wanted this was because of a corner case, but otoh, the username:password syntax is the real corner case imho. Of course, I understand that this must be supported for backwards compatability. (For fully RFC compliant URLs however, userinfo would be the same as user since : in userinfo isn't allowed, so again, you have a very valid point for your corner case argument.) The patch was developed against 2.7, so it won't apply on 3.4, but looking at 3.4, urlparse already has a _userinfo property method, but it splits the userinfo in a tuple of (username, password). It would be easy to adapt the change to 3.4, but I'll wait until I get additional feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 09:34:44 2013 From: report at bugs.python.org (Frank) Date: Thu, 10 Jan 2013 08:34:44 +0000 Subject: [issue16913] ElementTree tostring error when method='text' In-Reply-To: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> Message-ID: <1357806884.35.0.527634642691.issue16913@psf.upfronthosting.co.za> Frank added the comment: It happens whenever the method is called, regardless of input. I'm using HTML that has been tidied first with HTML entities (if any) converted to unicode values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 09:43:19 2013 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Jan 2013 08:43:19 +0000 Subject: [issue16912] Wrong float sum w/ 10.14+10.1 and 10.24+10.2 In-Reply-To: <1357772264.12.0.237958866341.issue16912@psf.upfronthosting.co.za> Message-ID: <1357807399.83.0.521544522125.issue16912@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 09:57:58 2013 From: report at bugs.python.org (Frank) Date: Thu, 10 Jan 2013 08:57:58 +0000 Subject: [issue16913] ElementTree tostring error when method='text' In-Reply-To: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> Message-ID: <1357808278.45.0.856010006137.issue16913@psf.upfronthosting.co.za> Frank added the comment: Scratch that, it happens whenever there are XML entities (<, " and friends) that are appearing the text as you pointed out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 10:10:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 09:10:56 +0000 Subject: [issue16913] ElementTree tostring error when method='text' In-Reply-To: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> Message-ID: <1357809056.62.0.454603182623.issue16913@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch for 3.3+. 2.7 and 3.2 are not affected. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file28666/etree_itertext.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 10:12:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 09:12:17 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1357809137.37.0.573293943944.issue15948@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 10:56:02 2013 From: report at bugs.python.org (Daniel Urban) Date: Thu, 10 Jan 2013 09:56:02 +0000 Subject: [issue16894] Function attribute access doesn't invoke methods in dict subclasses In-Reply-To: <1357670592.25.0.470525675752.issue16894@psf.upfronthosting.co.za> Message-ID: <1357811762.04.0.661000589351.issue16894@psf.upfronthosting.co.za> Changes by Daniel Urban : ---------- nosy: +daniel.urban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 13:14:15 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 10 Jan 2013 12:14:15 +0000 Subject: [issue16865] ctypes arrays >=2GB in length causes exception In-Reply-To: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za> Message-ID: <1357820055.07.0.339541100302.issue16865@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: In _ctypes.c there are (only!) two occurrences of the "long" type... both are related to ctypes arrays and look suspect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 13:41:48 2013 From: report at bugs.python.org (gac) Date: Thu, 10 Jan 2013 12:41:48 +0000 Subject: [issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays Message-ID: <1357821708.32.0.469925509105.issue16914@psf.upfronthosting.co.za> New submission from gac: I had cause to use smtplib to help me pinpoint why some outgoing mail was failing, but found that while it offered verbose logging (via debuglevel 1) this was without timestamps, making it difficult to make my case to the server operator that it was a server-side delay causing the issue. I've changed smtplib.py to add a second debugging level which includes timestamps down to microsecond granularity so that the debug log produced can pinpoint when a server isn't responding promptly. debuglevel 1 is unchanged, so anyone depending on the output from this being in a particular format won't be affected (either by setting debuglevel to "1" or "true"), but if debuglevel 2 is used explicitly then the standard output is preceded by a timestamp. ---------- components: Library (Lib) files: smtplib.py.patch keywords: patch messages: 179538 nosy: gac priority: normal severity: normal status: open title: timestamping in smtplib.py to help troubleshoot server timeouts/delays type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28667/smtplib.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 13:54:42 2013 From: report at bugs.python.org (=?utf-8?q?Marek_=C5=A0uppa?=) Date: Thu, 10 Jan 2013 12:54:42 +0000 Subject: [issue16874] setup.py upload option repeated in docs In-Reply-To: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za> Message-ID: <1357822482.18.0.849148842335.issue16874@psf.upfronthosting.co.za> Marek ?uppa added the comment: So what do you think should be done here? Just removing the "or --repository=" part? ---------- nosy: +mrshu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 14:19:38 2013 From: report at bugs.python.org (Berker Peksag) Date: Thu, 10 Jan 2013 13:19:38 +0000 Subject: [issue16874] setup.py upload option repeated in docs In-Reply-To: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za> Message-ID: <1357823978.1.0.01439059526.issue16874@psf.upfronthosting.co.za> Berker Peksag added the comment: I think the problem is the usage of `:option:`. |:option:`--repository=` or :option:`--repository=

`| should be written like |:option:`--repository=*url*` or :option:`--repository=*section*`| See: - http://hg.python.org/cpython/file/default/Doc/distutils/uploading.rst#l39 - http://hg.python.org/cpython/file/default/Doc/distutils/uploading.rst#l28 Patch attached. ---------- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file28668/distutils-upload-markup.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 14:29:50 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 10 Jan 2013 13:29:50 +0000 Subject: [issue16715] Get rid of IOError. Use OSError instead In-Reply-To: <3YW0Xs2j15zRkN@mail.python.org> Message-ID: <1357824590.78.0.138234641133.issue16715@psf.upfronthosting.co.za> Andrew Svetlov added the comment: It's not a typo. 1. LoadError is inherited from OSError so LoadError exception is also caught. 2. Pointed code just resets cookie state and reraises exception, exception type is saved. The code is correct from my perspective. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 14:34:48 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 10 Jan 2013 13:34:48 +0000 Subject: [issue13198] Remove duplicate definition of write_record_file In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za> Message-ID: <1357824888.77.0.339663959485.issue13198@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Eric, if you want to keep distutils2 issues on the tracker for a while ? I'm ok with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 14:40:17 2013 From: report at bugs.python.org (Antoon Pardon) Date: Thu, 10 Jan 2013 13:40:17 +0000 Subject: [issue16915] mode of socket.makefile is more limited than documentation suggests Message-ID: <1357825217.2.0.655032840521.issue16915@psf.upfronthosting.co.za> New submission from Antoon Pardon: The documentation of socket.makefile states that its arguments are interpreted the same way as by the built-in open() function. However the mode argument of socket.makefile only allows 'r', 'w' and 'b'. That some options are not allowed seems perfectly normal, like there being no use of an 'x' option but the documentation should probably reflect that. But I don't see why the 't' should cause trouble. If people can open a file explicitly in text mode, I don't see why it wouldn't be possible to explicitly ask for text mode in socket.makefile ---------- components: Library (Lib) messages: 179543 nosy: Antoon.Pardon priority: normal severity: normal status: open title: mode of socket.makefile is more limited than documentation suggests type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:07:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 14:07:34 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <3Yhptr68cZzRw7@mail.python.org> Roundup Robot added the comment: New changeset 8d6dadfecf22 by Eli Bendersky in branch '3.3': Issue #16076: make _elementtree.Element pickle-able in a way that is compatible http://hg.python.org/cpython/rev/8d6dadfecf22 New changeset 4c268b7c86e6 by Eli Bendersky in branch 'default': Issue #16076: make _elementtree.Element pickle-able in a way that is compatible http://hg.python.org/cpython/rev/4c268b7c86e6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:08:15 2013 From: report at bugs.python.org (Marco Buttu) Date: Thu, 10 Jan 2013 14:08:15 +0000 Subject: [issue16916] The Extended Iterable Unpacking (PEP-3132) for byte strings doesn't match the specification Message-ID: <1357826895.67.0.646270991721.issue16916@psf.upfronthosting.co.za> New submission from Marco Buttu: The PEP 3132 said: """ ... if seq is a slicable sequence, all the following assignments are equivalent if seq has at least three elements: a, b, c = seq[0], seq[1:-1], seq[-1] a, *b, c = seq [a, *b, c] = seq """ But this doesn't happen for byte strings: >>> seq = b'xyz' >>> a, b, c = seq[0], seq[1:-1], seq[-1] >>> a, b, c (120, b'y', 122) >>> a, *b, c = seq >>> a, b, c (120, [121], 122) Tested on Python3.3 and Python3.2 (Linux Ubuntu 11.04) ---------- components: Interpreter Core messages: 179545 nosy: marco.buttu priority: normal severity: normal status: open title: The Extended Iterable Unpacking (PEP-3132) for byte strings doesn't match the specification type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:08:46 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 10 Jan 2013 14:08:46 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357826926.39.0.295772403856.issue16076@psf.upfronthosting.co.za> Eli Bendersky added the comment: Fixed in 3.3 and default. Thanks for the good work, Daniel. A separate issue can be opened for TreeBuilder. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:09:31 2013 From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=) Date: Thu, 10 Jan 2013 14:09:31 +0000 Subject: [issue16917] Misleading missing parenthesis syntax error Message-ID: <1357826971.05.0.673810917447.issue16917@psf.upfronthosting.co.za> New submission from Dra?en Lu?anin: When running this script: things = ['a', 'b'] things.append('c' for a in things: print a I get the following output: $ python script.py File "script.py", line 3 for a in things: ^ SyntaxError: invalid syntax the SyntaxError is very misguiding. The error is in a missing parenthesis after the append call, but the error output points to the colon in the for loop. It got me looking for some invisible characters around the colon (which sometimes do pop up in my IPython notebook in OS X). Expected behaviour - the interpreter should warn me that I have an unmatched parenthesis or at least give some hint as to what possible tokens were expected instead of a colon to help me identify the faulty expression. It is hard to match all parentheses as it is, let alone when the error caused by them shows up in a different line pointing to a token of a different expression with a very vague description. ---------- components: Interpreter Core messages: 179547 nosy: kermit666 priority: normal severity: normal status: open title: Misleading missing parenthesis syntax error type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:12:57 2013 From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=) Date: Thu, 10 Jan 2013 14:12:57 +0000 Subject: [issue16917] Misleading missing parenthesis syntax error In-Reply-To: <1357826971.05.0.673810917447.issue16917@psf.upfronthosting.co.za> Message-ID: <1357827177.98.0.258989147806.issue16917@psf.upfronthosting.co.za> Changes by Dra?en Lu?anin : ---------- type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:22:57 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 14:22:57 +0000 Subject: [issue16917] Misleading missing parenthesis syntax error In-Reply-To: <1357826971.05.0.673810917447.issue16917@psf.upfronthosting.co.za> Message-ID: <1357827777.72.0.927311587324.issue16917@psf.upfronthosting.co.za> Ezio Melotti added the comment: The colon is the first invalid char, for example this is valid python and works: >>> things = ['a', 'b'] >>> things.append('c' ... for a in things) >>> things ['a', 'b', at 0xb76dacfc>] In your case Python expects a genexp like things.append('c' for a in things), and when it finds the ':' it gives error. If you use e.g. a 'while', you will see the error earlier: >>> things = ['a', 'b'] >>> things.append('c' ... while True: File "", line 2 while True: ^ SyntaxError: invalid syntax ---------- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:23:42 2013 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Jan 2013 14:23:42 +0000 Subject: [issue16917] Misleading missing parenthesis syntax error In-Reply-To: <1357826971.05.0.673810917447.issue16917@psf.upfronthosting.co.za> Message-ID: <1357827822.07.0.441786306982.issue16917@psf.upfronthosting.co.za> Mark Dickinson added the comment: > The error is in a missing parenthesis after the append call Well, that's one *possible* cause of the error. But fixing that missing parenthesis isn't the only way to make the code correct, and Python doesn't have any reasonable way to guess which of the various possible errors you made or what you intended to write. For example, the following is valid code: things = ['a', 'b'] things.append('c' for a in things) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:31:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 14:31:27 +0000 Subject: [issue16913] ElementTree tostring error when method='text' In-Reply-To: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> Message-ID: <3YhqQM26w0zQlT@mail.python.org> Roundup Robot added the comment: New changeset d965ff47cf94 by Eli Bendersky in branch '3.3': Issue #16913: Fix Element.itertext()'s handling of text with XML entities. http://hg.python.org/cpython/rev/d965ff47cf94 New changeset 9ab8632e7213 by Eli Bendersky in branch 'default': Issue #16913: Fix Element.itertext()'s handling of text with XML entities. http://hg.python.org/cpython/rev/9ab8632e7213 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:31:55 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 10 Jan 2013 14:31:55 +0000 Subject: [issue16913] ElementTree tostring error when method='text' In-Reply-To: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za> Message-ID: <1357828315.79.0.25413896861.issue16913@psf.upfronthosting.co.za> Eli Bendersky added the comment: Fixed. Thanks. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:36:20 2013 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 10 Jan 2013 14:36:20 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357828580.69.0.115357446947.issue16613@psf.upfronthosting.co.za> Walter D?rwald added the comment: I'd like to have this feature too. However the code should use d if d is not None else {} instead of d or {} For example I might want to use a subclass of dict (lowerdict) that converts all keys to lowercase. When I use an empty lowerdict in new_child(), new_child() would silently use a normal dict instead: class lowerdict(dict): def __getitem__(self, key): return dict.__getitem__( self, key.lower() if isinstance(key, str) else key ) import collections cm = collections.ChainMap(lowerdict(), lowerdict()) cm2 = cm.new_child(lowerdict()) print(type(cm2.maps[0])) This would print . ---------- nosy: +doerwalter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:36:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 14:36:27 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <3YhqX86SBPzRxd@mail.python.org> Roundup Robot added the comment: New changeset c46054b49b6c by Eli Bendersky in branch '3.3': Update Misc/NEWS for issue #16076 http://hg.python.org/cpython/rev/c46054b49b6c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 15:59:52 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 10 Jan 2013 14:59:52 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1357829992.37.0.791173709537.issue15442@psf.upfronthosting.co.za> Eli Bendersky added the comment: Attaching an alternative patch, that goes one (little) step further. Instead of repeating the ignored list all over the place (code, docstrings, ReST docs), the module exposes DEFAULT_IGNORES so everything can refer to it. Also added some tests for this feature. The patch is only vs. default (3.4), of course. ---------- Added file: http://bugs.python.org/file28669/eli_issue15442.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 16:04:15 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 10 Jan 2013 15:04:15 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1357830255.36.0.269453341189.issue14377@psf.upfronthosting.co.za> Eli Bendersky added the comment: Ariel, are you interested in pursuing this issue? Serhiy, I see you assigned this to yourself - would you like to submit a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 16:07:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 15:07:43 +0000 Subject: [issue16917] Misleading missing parenthesis syntax error In-Reply-To: <1357826971.05.0.673810917447.issue16917@psf.upfronthosting.co.za> Message-ID: <1357830463.26.0.28040559572.issue16917@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For better syntax error messages see issue1634034. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 16:13:32 2013 From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=) Date: Thu, 10 Jan 2013 15:13:32 +0000 Subject: [issue16917] Misleading missing parenthesis syntax error In-Reply-To: <1357827822.07.0.441786306982.issue16917@psf.upfronthosting.co.za> Message-ID: Dra?en Lu?anin added the comment: Yes, sure, I agree with both comments. Fors are a bit disambiguous in this context in comparison to while loops. But something in the style of Ezio's explanation might come in handy in the error output. e.g. SyntaxError: invalid syntax. "," or ")" expected in the argument list of the method append, but ':' found instead. (or the equivalent that's possible on that syntactic tree level) Something that might explain that it's some sort of list being parsed, not a for-loop command. It would point the coder in the right direction, speeding him up. This would all be a bit simpler if an indent was obligatory after inserting a newline in the middle of a command. Then this would pass OK things.append('c' for a in things) while this would fail things.append('c' for a in things) with a syntax error on the first line, because the second line would've been interpreted as a new command, not a continuation of the first one. I don't know if something like that would be possible, due to some other aspects, though... On Thu, Jan 10, 2013 at 3:23 PM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > >> The error is in a missing parenthesis after the append call > > Well, that's one *possible* cause of the error. But fixing that missing parenthesis isn't the only way to make the code correct, and Python doesn't have any reasonable way to guess which of the various possible errors you made or what you intended to write. For example, the following is valid code: > > things = ['a', 'b'] > things.append('c' > for a in things) > > ---------- > nosy: +mark.dickinson > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 16:20:31 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Jan 2013 15:20:31 +0000 Subject: [issue16509] sqlite3 docs do not explain check_same_thread In-Reply-To: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za> Message-ID: <1357831231.88.0.454443603886.issue16509@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 16:29:39 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 15:29:39 +0000 Subject: [issue16917] Misleading missing parenthesis syntax error In-Reply-To: <1357826971.05.0.673810917447.issue16917@psf.upfronthosting.co.za> Message-ID: <1357831779.28.0.575634681694.issue16917@psf.upfronthosting.co.za> Ezio Melotti added the comment: > This would all be a bit simpler if an indent was obligatory after > inserting a newline in the middle of a command. This is not such a bad idea, but it is not backward-compatible and it would be inconsistent with how parentheses works in other situations. Developers usually learn that they should look back at least till the previous line while investigating syntax errors. Even in C (and similar languages) it's common that errors reported on one line are caused by e.g. a missing ';' on the previous line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 16:33:52 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Jan 2013 15:33:52 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row In-Reply-To: <1343981372.87.0.323193257201.issue15545@psf.upfronthosting.co.za> Message-ID: <1357832031.91.0.45181586021.issue15545@psf.upfronthosting.co.za> R. David Murray added the comment: For the record, this is a regression introduced by the fix for issue 9750. I plan to commit the fix shortly, thanks for the report and patch. ---------- nosy: +r.david.murray stage: -> commit review type: crash -> behavior versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 16:34:56 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Jan 2013 15:34:56 +0000 Subject: [issue9750] sqlite3 iterdump fails on column with reserved name In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za> Message-ID: <1357832096.42.0.925740557097.issue9750@psf.upfronthosting.co.za> R. David Murray added the comment: For the record, this patch also introduced another regression (issue 15545). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:21:47 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 10 Jan 2013 16:21:47 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <1357834907.76.0.281909038152.issue10182@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Note that this change is causing problems with genshi due to API backward incompatibility. This is reported here: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1097783 The reason the user found it in Ubuntu first is that we track hg tip, but I've reproduced it in my own hg tip, and the diff of r80680 makes it pretty obvious. I'm not saying the change should necessarily be reverted, but it *is* a backward incompatibility, and at a minimum the NEWS file (and release notes for 2.7.4) should make it clear that the return types have changed. As we're seeing, it breaks at least one existing package. ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:26:40 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 10 Jan 2013 16:26:40 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <1357835200.34.0.670154594823.issue10182@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:28:23 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 10 Jan 2013 16:28:23 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <1357835303.21.0.320696576421.issue10182@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Nosied Benjamin since this is a release issue. Re-opened, assigned to him, and release blocked for 2.7.4. ---------- assignee: -> benjamin.peterson nosy: +georg.brandl, larry priority: normal -> release blocker status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:28:59 2013 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 10 Jan 2013 16:28:59 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357835339.32.0.742722536134.issue16613@psf.upfronthosting.co.za> Vinay Sajip added the comment: > d if d is not None else {} Your intention makes sense, though I would prefer to write it as: if d is None: d = {} return self.__class__(d, *self.maps) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:29:29 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 10 Jan 2013 16:29:29 +0000 Subject: [issue16218] Python launcher does not support unicode characters In-Reply-To: <1350138278.8.0.551817049969.issue16218@psf.upfronthosting.co.za> Message-ID: <1357835368.95.0.415093815172.issue16218@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:31:33 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 16:31:33 +0000 Subject: [issue9750] sqlite3 iterdump fails on column with reserved name In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za> Message-ID: <3Yht4y1nFMzRyf@mail.python.org> Roundup Robot added the comment: New changeset 2cdb599172ab by R David Murray in branch '3.2': #15545: fix sqlite3.iterdump regression on unsortable row_factory objects. http://hg.python.org/cpython/rev/2cdb599172ab New changeset 6a85894c428f by R David Murray in branch '3.3': merge #15545: fix sqlite3.iterdump regression on unsortable row_factory objects. http://hg.python.org/cpython/rev/6a85894c428f New changeset 7a62b5ee32ec by R David Murray in branch 'default': merge #15545: fix sqlite3.iterdump regression on unsortable row_factory objects. http://hg.python.org/cpython/rev/7a62b5ee32ec New changeset bb4e4f0cec2e by R David Murray in branch '2.7': #15545: sort iterdump via SQL instead of in python code http://hg.python.org/cpython/rev/bb4e4f0cec2e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:31:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 16:31:34 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row In-Reply-To: <1343981372.87.0.323193257201.issue15545@psf.upfronthosting.co.za> Message-ID: <3Yht4x2KFszRwy@mail.python.org> Roundup Robot added the comment: New changeset 2cdb599172ab by R David Murray in branch '3.2': #15545: fix sqlite3.iterdump regression on unsortable row_factory objects. http://hg.python.org/cpython/rev/2cdb599172ab New changeset 6a85894c428f by R David Murray in branch '3.3': merge #15545: fix sqlite3.iterdump regression on unsortable row_factory objects. http://hg.python.org/cpython/rev/6a85894c428f New changeset 7a62b5ee32ec by R David Murray in branch 'default': merge #15545: fix sqlite3.iterdump regression on unsortable row_factory objects. http://hg.python.org/cpython/rev/7a62b5ee32ec New changeset bb4e4f0cec2e by R David Murray in branch '2.7': #15545: sort iterdump via SQL instead of in python code http://hg.python.org/cpython/rev/bb4e4f0cec2e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:33:40 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 Jan 2013 16:33:40 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <1357835620.47.0.304850093731.issue10182@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Actually, 2.7 should just use PyInt_FromSsize_t, which only promotes when needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:36:00 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Jan 2013 16:36:00 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row In-Reply-To: <1343981372.87.0.323193257201.issue15545@psf.upfronthosting.co.za> Message-ID: <1357835759.3.0.183459708653.issue15545@psf.upfronthosting.co.za> R. David Murray added the comment: Peter, I see you've made contributions before, but you don't show as having a contributor agreement on file according to the tracker. Have you sent one in? If not, would you, please? Thanks again for the fix. ---------- components: +Library (Lib) -None resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:38:00 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 16:38:00 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <3YhtDN6L8zzP1y@mail.python.org> Roundup Robot added the comment: New changeset 0f5067d9e1d8 by Benjamin Peterson in branch '2.7': use PyInt_FromSsize_t instead of PyLong_FromSsize_t (#10182) http://hg.python.org/cpython/rev/0f5067d9e1d8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:38:37 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 Jan 2013 16:38:37 +0000 Subject: [issue10182] match_start truncates large values In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za> Message-ID: <1357835917.02.0.696167556684.issue10182@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It's good you were able to report this before we released anything. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:39:57 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 10 Jan 2013 16:39:57 +0000 Subject: [issue16918] Fix test discovery for test_codecs.py Message-ID: <1357835997.28.0.488005818919.issue16918@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's the fix for test_codecs.py, I believe. I had a few headaches trying to get this patch created without changing some of the characters or adding a BOM to the file, and at one point the test was failing for no apparent reason. This version of the patch seems to work on my machine, though. ---------- components: Tests files: test_codecs_discovery.diff keywords: patch messages: 179571 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_codecs.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28670/test_codecs_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:49:34 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Jan 2013 16:49:34 +0000 Subject: [issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays In-Reply-To: <1357821708.32.0.469925509105.issue16914@psf.upfronthosting.co.za> Message-ID: <1357836574.42.0.493138383869.issue16914@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry, r.david.murray stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:51:23 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 10 Jan 2013 16:51:23 +0000 Subject: [issue16919] Fix test discovery for test_crypt.py Message-ID: <1357836683.17.0.872052983842.issue16919@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's a fix for test_crypt.py, inspired by Ezio's mention of using setUpModule in issue 16905. I can't test this on a platform that actually has _crypt at the moment, but I should be able to later today if nobody else has before then. Some tinkering has shown me that it /should/ work, though. ---------- components: Tests files: test_crypt_discovery.diff keywords: patch messages: 179572 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_crypt.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28671/test_crypt_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:51:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 16:51:39 +0000 Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1357836699.01.0.174059573373.issue6975@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch rewritten using recursion. Non-recursive version is not stack limited (and a little faster), but recursive version is perhaps more understandable. Some comments added. ---------- Added file: http://bugs.python.org/file28672/posix_realpath_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:52:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 16:52:44 +0000 Subject: [issue1634034] Show "expected" token on syntax error Message-ID: <1357836764.55.0.703862673369.issue1634034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > >>> dict(a = i for i in range(10)) > + SyntaxError: invalid syntax - ')' expected > > The () are ok, the message is misleading. "dict(a = i)" is valid syntax, the compiler expects ")" instead of invalid "for". > 'name' here is a bit vague. The compiler actually expects a name (using Python terminology, see for example NameError). Of course you can propose an other name for "name" (this is just an entity in _PyParser_TokenDescs array). > >>> def f(x, None): > ... pass > +SyntaxError: invalid syntax - ')' expected > > >>> def f(*None): > ... pass > +SyntaxError: invalid syntax - ')' expected > > Here the () are ok too. The compiler means "def f(x,)" and "def f(*)", not "def f()" as you possible expects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:58:07 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 16:58:07 +0000 Subject: [issue16919] Fix test discovery for test_crypt.py In-Reply-To: <1357836683.17.0.872052983842.issue16919@psf.upfronthosting.co.za> Message-ID: <1357837087.39.0.520793642227.issue16919@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:58:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 16:58:15 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1357837095.27.0.97800744806.issue14377@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Serhiy, I see you assigned this to yourself - would you like to submit a patch? Not right now. This is low priority for me too. But I want to see this feature in 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 17:59:05 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 16:59:05 +0000 Subject: [issue16918] Fix test discovery for test_codecs.py In-Reply-To: <1357835997.28.0.488005818919.issue16918@psf.upfronthosting.co.za> Message-ID: <1357837145.63.0.245666193198.issue16918@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 18:04:31 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Jan 2013 17:04:31 +0000 Subject: [issue1634034] Show "expected" token on syntax error Message-ID: <1357837471.8.0.139073361411.issue1634034@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm not saying that these errors are wrong -- just that they are misleading (i.e. they might lead the user on the wrong path, and make finding the actual problem more difficult). It should be noted that the examples I pasted don't include a full traceback though. The presence of the caret (^) in the right place will definitely make things clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 18:19:32 2013 From: report at bugs.python.org (John Brearley) Date: Thu, 10 Jan 2013 17:19:32 +0000 Subject: [issue16920] multiprocessing.connection listener gets MemoryError on recv Message-ID: <1357838372.36.0.779855402088.issue16920@psf.upfronthosting.co.za> New submission from John Brearley: Using a multiprocessing.connection listener, I can accept an incoming socket OK, but when I do conn.recv(), I get memory error. The attached script mpl_bug.py will readily reproduce the issues on WinXP & WinVista, see sample output below: 
c:\>python mpl_bug.py
main server listening on host  port 10500
main created simple_client 
simple_client connecting to host localhost port 10500
main conn:  waiting
for data
simple_client sending: b'abcd'
simple_client waiting for data
Traceback (most recent call last):
  File "mpl_bug.py", line 61, in 
    data=conn.recv()   ;# Memory Error occurs here <<<==========================
======================
  File "c:\python33\lib\multiprocessing\connection.py", line 251, in recv
    buf = self._recv_bytes()
  File "c:\python33\lib\multiprocessing\connection.py", line 405, in _recv_bytes

    return self._recv(size)
  File "c:\python33\lib\multiprocessing\connection.py", line 380, in _recv
    chunk = read(handle, remaining)
MemoryError
---------- files: mpl_bug.py messages: 179577 nosy: jbrearley priority: normal severity: normal status: open title: multiprocessing.connection listener gets MemoryError on recv versions: Python 3.3 Added file: http://bugs.python.org/file28673/mpl_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 18:41:27 2013 From: report at bugs.python.org (John Brearley) Date: Thu, 10 Jan 2013 17:41:27 +0000 Subject: [issue16920] multiprocessing.connection listener gets MemoryError on recv In-Reply-To: <1357838372.36.0.779855402088.issue16920@psf.upfronthosting.co.za> Message-ID: <1357839687.31.0.365422174077.issue16920@psf.upfronthosting.co.za> Changes by John Brearley : ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 18:42:20 2013 From: report at bugs.python.org (Torsten Landschoff) Date: Thu, 10 Jan 2013 17:42:20 +0000 Subject: [issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong Message-ID: <1357839740.51.0.95267360969.issue16921@psf.upfronthosting.co.za> New submission from Torsten Landschoff: The documentation of CREATE_NEW_CONSOLE at http://docs.python.org/3/library/subprocess.html#subprocess.CREATE_NEW_CONSOLE states: This flag is always set when Popen is created with shell=True. This does not fit the code which does if (_subprocess.GetVersion() >= 0x80000000 or os.path.basename(comspec).lower() == "command.com"): # Win9x, or using command.com on NT. We need to creationflags |= _subprocess.CREATE_NEW_CONSOLE So the statement is only true on very old versions on Windows. I suggest to fix the documentation (patch attached) or to remove that obsolete hack (and drop support for Windows <= NT). ---------- components: Windows files: create_new_console.diff keywords: patch messages: 179578 nosy: torsten priority: normal severity: normal status: open title: Docs of subprocess.CREATE_NEW_CONSOLE are wrong versions: Python 3.5 Added file: http://bugs.python.org/file28674/create_new_console.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 18:45:17 2013 From: report at bugs.python.org (John Brearley) Date: Thu, 10 Jan 2013 17:45:17 +0000 Subject: [issue16920] multiprocessing.connection listener gets MemoryError on recv In-Reply-To: <1357838372.36.0.779855402088.issue16920@psf.upfronthosting.co.za> Message-ID: <1357839917.96.0.875386652246.issue16920@psf.upfronthosting.co.za> John Brearley added the comment: In V3.2.2.3, the conn.accept() was failing to resolve the socket address. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 19:10:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 18:10:33 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string Message-ID: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import xml.etree.cElementTree as ET >>> ET.XML('').findtext('empty') b'' ---------- components: XML files: etree_finditer_empty.patch keywords: patch messages: 179580 nosy: eli.bendersky, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: ElementTree.findtext() returns empty bytes object instead of empty string type: behavior versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28675/etree_finditer_empty.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 19:14:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 18:14:42 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1357841682.93.0.693994305905.issue16922@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I?see yet one possible bug, using PyBytes_FromString() in list_join() on 3.2. But I?can't demonstrate an example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 19:17:26 2013 From: report at bugs.python.org (brian-cameron-oracle) Date: Thu, 10 Jan 2013 18:17:26 +0000 Subject: [issue16902] Add OSS module support for Solaris In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za> Message-ID: <1357841846.57.0.717755011541.issue16902@psf.upfronthosting.co.za> brian-cameron-oracle added the comment: Since Modules/ossaudiodev.c has the following line (which is not surrounded by any conditional #ifdef sort of things): #include This means that the OSS plugin will only build on a system that has this header file, so it is safe to check for on any system. How can the Module code build if the header can't be found? The code will only compile if the CFLAGS used when building the module is setup to include /usr/include or /usr/local/include, but this is normally taken care of by default. If users need to specify their OSS headers are in some weird non-standard location, then they can use CFLAGS or other Makefile mechanisms to specify the compiler arguments they would then need to build anything that uses their non-standard OSS. Or am I just confused by your question? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 19:46:11 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Jan 2013 18:46:11 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1357843571.77.0.941493274692.issue8145@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 20:14:01 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Jan 2013 19:14:01 +0000 Subject: [issue10572] Move test sub-packages to Lib/test In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za> Message-ID: <1357845241.39.0.714823074291.issue10572@psf.upfronthosting.co.za> R. David Murray added the comment: I believe that the complete list of test files still located outside of Lib/test are: tkinter/test distutils/tests ctypes/tests lib2to3/tests sqlite3/test unittest/test That last is somewhat ironic since Michael opened the issue :). I'm considering working on some of the uncommitted patches for sqlite3, so I may take on moving those tests. ---------- components: +Tests nosy: +asvetlov, benjamin.peterson stage: -> needs patch type: behavior -> enhancement versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 20:18:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 19:18:47 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1357845527.12.0.803579462543.issue15948@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Some general notes. Nitpick: check foo() < 0 is more used than foo() == 0. An exception raised after failed close() can hide original exception raised before. I left more specific comments on Rietveld. Only a small part of the proposed changes may be approved by me. About the majority of changes only the module maintainer can say how they are safe and how to do correctly (they looks too risky for me). Some of the changes are obviously wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 20:21:43 2013 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Jan 2013 19:21:43 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1357845703.68.0.584032103924.issue11205@psf.upfronthosting.co.za> Guido van Rossum added the comment: I am sticking with my opinion from before: the code should be fixed. It doesn't look like assignment to me. I am fine with making this a "feature" only fixed in 3.4. (You can even fix the docs in 3.3 as long as you fix them back for 3.4.) Minor note for Ezio: dict(k=v, ...) doesn't have this problem because k is just a keyword, not an expression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 20:34:29 2013 From: report at bugs.python.org (=?utf-8?q?Marek_=C5=A0uppa?=) Date: Thu, 10 Jan 2013 19:34:29 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1357846469.01.0.231436828666.issue15948@psf.upfronthosting.co.za> Marek ?uppa added the comment: Thanks for the review. Do you think I should split it into multiple patches to make it easier to look through? It might be that some changes are completely wrong. This is the first time I did something with cpython core code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 20:37:49 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Jan 2013 19:37:49 +0000 Subject: [issue10572] Move test sub-packages to Lib/test In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za> Message-ID: <1357846669.54.0.848911990862.issue10572@psf.upfronthosting.co.za> R. David Murray added the comment: Talked to Michael in IRC. He isn't particularly in favor of the move of the unittest tests, but doesn't object if someone else wants to do it. So, unassigning the issue from him. ---------- assignee: michael.foord -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 20:45:18 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 10 Jan 2013 19:45:18 +0000 Subject: [issue10572] Move test sub-packages to Lib/test In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za> Message-ID: <1357847118.92.0.348157295414.issue10572@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: ctypes/tests is within my area of interests and may prove to be one of the harder pieces. I'll try to move it and report the results. I have not worked with the rest, so unless it is truly trivial this will have to wait for another volunteer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 20:58:31 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 Jan 2013 19:58:31 +0000 Subject: [issue10572] Move test sub-packages to Lib/test In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za> Message-ID: <1357847911.74.0.403351057468.issue10572@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I honestly don't see the point of moving tests around. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 21:03:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Jan 2013 20:03:16 +0000 Subject: [issue16900] SSL sockets don't give resource warnings In-Reply-To: <1357687060.67.0.213189094158.issue16900@psf.upfronthosting.co.za> Message-ID: <1357848196.13.0.68194070791.issue16900@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, SSLSocket.__del__ doesn't seem to have a point. ---------- nosy: +pitrou stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 21:13:04 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Thu, 10 Jan 2013 20:13:04 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357848784.68.0.0963901798073.issue16886@psf.upfronthosting.co.za> Frank Wierzbicki added the comment: Switched to unittest style away from doctests and created patch against 3.3. Note that at this time test_dictcomp.py is identical in 3.3 and 3.4 so merging should be pretty easy :) ---------- Added file: http://bugs.python.org/file28676/dictcomp3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 21:15:06 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Thu, 10 Jan 2013 20:15:06 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357848906.63.0.474274766651.issue16886@psf.upfronthosting.co.za> Frank Wierzbicki added the comment: This patch of test_dict_comp.py was made against 2.7. It differs from the 3.3 version only one line "from test import test_support as support" ---------- Added file: http://bugs.python.org/file28677/dictcomp2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 21:17:07 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Jan 2013 20:17:07 +0000 Subject: [issue16900] SSL sockets don't give resource warnings In-Reply-To: <1357687060.67.0.213189094158.issue16900@psf.upfronthosting.co.za> Message-ID: <3Yhz570LlHzS7Y@mail.python.org> Roundup Robot added the comment: New changeset c8105251cc1f by Benjamin Peterson in branch '3.3': remove __del__ because it's evil and also prevents the ResourceWarning on the socket from happening (closes #16900) http://hg.python.org/cpython/rev/c8105251cc1f New changeset e23d51f17cce by Benjamin Peterson in branch 'default': merge 3.3 (#16900) http://hg.python.org/cpython/rev/e23d51f17cce ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 21:18:15 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 Jan 2013 20:18:15 +0000 Subject: [issue16923] test_ssl kicks up a lot of ResourceWarnings Message-ID: <1357849095.58.0.0656533205618.issue16923@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Now #16900 is fixed, we get gunk like this: $ ./python -Wall Lib/test/regrtest.py -uall test_ssl [1/1] test_ssl /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() /home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:211: ResourceWarning: unclosed del ss /home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:232: ResourceWarning: unclosed ss = ssl.wrap_socket(s) /home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:232: ResourceWarning: unclosed ss = ssl.wrap_socket(s) /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() /home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:374: ResourceWarning: unclosed ss = ssl.wrap_socket(s, server_side=True, certfile=CERTFILE) /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() /home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:874: ResourceWarning: unclosed cert_reqs=ssl.CERT_NONE, ciphers="DEFAULT") /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() Resource 'ipv6.google.com' is not available /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() /home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed function() 1 test OK. This should be fixed. ---------- keywords: easy messages: 179594 nosy: benjamin.peterson priority: normal severity: normal stage: needs patch status: open title: test_ssl kicks up a lot of ResourceWarnings type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 21:40:55 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 20:40:55 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1357850455.67.0.56611921948.issue14377@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, here is a patch which add short_empty_elements flag (as for XMLGenerator) to write(), tostring() and tostringlist() methods of ElementTree. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 21:42:52 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 10 Jan 2013 20:42:52 +0000 Subject: [issue10572] Move test sub-packages to Lib/test In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za> Message-ID: <1357850571.98.0.335613182712.issue10572@psf.upfronthosting.co.za> Brett Cannon added the comment: Two reasons for collecting all of the tests in a single location: 1) Facilitates test discovery 2) It makes packaging of CPython easier for Linux distros that prefer to leave the tests out of the core package ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 21:56:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 20:56:31 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1357851391.54.0.410817403142.issue15948@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, I forgot press "Push All My Drafts" button. Actually only patch for _cursesmodule.c looks safe at first glance (but curses maintainer can decide better). You can split the patch on several patches, but be very careful. You should research the entire module to understand to what effects the changes will lead and what changes should be. I would not recommend this task for beginners. ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 22:12:08 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Jan 2013 21:12:08 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1357852328.14.0.299537052828.issue14377@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file28678/etree_short_empty_elements.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 22:15:02 2013 From: report at bugs.python.org (=?utf-8?q?Marek_=C5=A0uppa?=) Date: Thu, 10 Jan 2013 21:15:02 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1357852502.84.0.695951959182.issue15948@psf.upfronthosting.co.za> Marek ?uppa added the comment: That is probably right. I was way too foolish to start with this but won't stop now. I'll try to iterate on your feedback. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 22:55:08 2013 From: report at bugs.python.org (py.user) Date: Thu, 10 Jan 2013 21:55:08 +0000 Subject: [issue16715] Get rid of IOError. Use OSError instead In-Reply-To: <3YW0Xs2j15zRkN@mail.python.org> Message-ID: <1357854908.76.0.257096857858.issue16715@psf.upfronthosting.co.za> py.user added the comment: Andrew Svetlov wrote: > LoadError is inherited from OSError the comment for the function doesn't tell it today it's inherited from OSError and tomorrow it may inherit from ANYError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 23:07:04 2013 From: report at bugs.python.org (Sven Brauch) Date: Thu, 10 Jan 2013 22:07:04 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357855624.14.0.1845600363.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Here's another version now which I think could be used like this. All tests have been adjusted. I'll append two patches, one just containing the changes to the parser for ease of review, and one full diff which also contains changes to the generated files and the test adjustments. Please point out any remaining problems you see with this so I can fix them. ---------- Added file: http://bugs.python.org/file28679/readable.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 23:07:27 2013 From: report at bugs.python.org (Sven Brauch) Date: Thu, 10 Jan 2013 22:07:27 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357855647.91.0.643791235086.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Attached is the full diff this time. ---------- Added file: http://bugs.python.org/file28680/full.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 23:18:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Jan 2013 22:18:23 +0000 Subject: [issue16923] test_ssl kicks up a lot of ResourceWarnings In-Reply-To: <1357849095.58.0.0656533205618.issue16923@psf.upfronthosting.co.za> Message-ID: <1357856303.76.0.164443565235.issue16923@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 23:19:02 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Jan 2013 22:19:02 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1357856342.43.0.893664504312.issue15948@psf.upfronthosting.co.za> STINNER Victor added the comment: ./Python/traceback.c: write(fd, &c, 1); ./Python/traceback.c: write(fd, "\"", 1); ./Python/traceback.c: write(fd, "\"", 1); ./Python/traceback.c: write(fd, "\n", 1); ./Python/traceback.c: write(fd, "\n", 1); Oh, I wrote these ones. It is code called by the faulthandle module, from a signal handler. So only async-safe functions can be called (no thread, no memory allocation, no lock!, etc.). A simple fix would be to mark that we don't care if write() fails, but (void)write(fd, ...); doesn't make the warning quiet. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 10 23:25:18 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Jan 2013 22:25:18 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1357856718.75.0.166472675822.issue15948@psf.upfronthosting.co.za> STINNER Victor added the comment: diff -r 0acc5626a578 Modules/faulthandler.c @@ -445,7 +445,10 @@ - write(thread.fd, thread.header, thread.header_len); + if (write(thread.fd, thread.header, thread.header_len) == -1) { + PyErr_SetFromErrno(PyExc_IOError); + return; + } I wrote faulthandler to debug deadlocks, memory corruptions and other cases where Python internals are no consistency anymore. faulthandler_thread() is not a Python thread, but a C thread. I don't know if it's legal to call PyErr_SetFromErrno(). And it would be really surprising to get a Python exception whereas it does not come from Python code. I would prefer to just ignore if write() failed here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 00:36:10 2013 From: report at bugs.python.org (Sven Brauch) Date: Thu, 10 Jan 2013 23:36:10 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357860970.14.0.545739275424.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: The patch review tool currently throws errors on submitting any form (http://pastie.org/pastes/5665048/text) so please forgive me for answering here once more. I'll copy this information (patch + message) to the review as soon as the website is working again. > In ast.c, use the LINENO macro for n_lineno. Done. > http://bugs.python.org/review/16795/diff/7080/Lib/test/test_ast.py#newcode183 > Lib/test/test_ast.py:183: def _assertTrueorder(self, ast_node, parent_pos, reverse_check = False): > Wrap everything here by 80 chars. Done. > http://bugs.python.org/review/16795/diff/7080/Lib/test/test_ast.py#newcode198 > Lib/test/test_ast.py:198: self.assertTrue(node_pos <= parent_pos if > reverse_check else node_pos >= parent_pos) > Lift the condition out of the assert call. Done. > http://bugs.python.org/review/16795/diff/7080/Lib/test/test_ast.py#newcode467 > Lib/test/test_ast.py:467: self.maxDiff = None > A comment explaining what this is for would be nice. Sorry, this was for testing purposes only, and I forgot to remove it. > http://bugs.python.org/review/16795/diff/7080/Lib/test/test_ast.py#newcode589 > Lib/test/test_ast.py:589: 0, 0, 0, 0) > These extra parameters are optional now, right? They needn't be passed > then. Unfortunately not: Altough the question mark in the asdl file is present and I made fairly sure to regenerate all the derived files, the parameters are still mandatory. URL of the patch review: http://bugs.python.org/review/16795/ ---------- Added file: http://bugs.python.org/file28681/full2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 00:51:23 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 Jan 2013 23:51:23 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357861883.65.0.652592362963.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Could you post an example of the error, please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 01:01:36 2013 From: report at bugs.python.org (Sven Brauch) Date: Fri, 11 Jan 2013 00:01:36 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357862496.55.0.606727825541.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: The above post has an example for trying to add a patch, here's what happens when I try to post a reply: http://pastie.org/pastes/5665144/text I also tried with another web browser, so it's unlikely that it's the browser's fault (but maybe the user's? ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 01:02:20 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 11 Jan 2013 00:02:20 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357862540.05.0.177220678705.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Ah, sorry, I was talking about the failure of optional arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 01:04:22 2013 From: report at bugs.python.org (Sven Brauch) Date: Fri, 11 Jan 2013 00:04:22 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357862662.14.0.361487736115.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Ah, whops, I misunderstood that. The error is rather generic: Traceback (most recent call last): File "./Lib/test/test_ast.py", line 796, in test_lambda self._check_arguments(fac, self.expr) File "./Lib/test/test_ast.py", line 596, in _check_arguments check(arguments(args=args), "must have Load context") File "./Lib/test/test_ast.py", line 593, in arguments kwarg, kwargannotation, defaults, kw_defaults) TypeError: arguments constructor takes either 0 or 12 positional arguments It's very generic in C too: Python/ast.c:1571:42: error: macro "arguments" requires 13 arguments, but only 9 given ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 01:45:12 2013 From: report at bugs.python.org (Vladimir Rutsky) Date: Fri, 11 Jan 2013 00:45:12 +0000 Subject: [issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex In-Reply-To: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za> Message-ID: <1357865112.38.0.0342714962435.issue16899@psf.upfronthosting.co.za> Vladimir Rutsky added the comment: Yes, I managed to pass and operate with matrices of complex numbers to pure C and Fortran programs by using Numpy and their ctype adapters (only for whole matrices, they don't provide c_complex type; in general see http://www.scipy.org/Cookbook/Ctypes for details). I suppose pure python solution that suggested in provided by you link works too: class Complex64(Structure): _fields_ = [("real", c_float), ("imag", c_float)] But I'm unsure is this is expected behavior or luck, and on some platform this code will not work due to different complex numbers internal representation. Any way this should be implemented in libffi first, and then in ctypes, so this feature request should be postponed, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 02:05:56 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 11 Jan 2013 01:05:56 +0000 Subject: [issue16920] multiprocessing.connection listener gets MemoryError on recv In-Reply-To: <1357838372.36.0.779855402088.issue16920@psf.upfronthosting.co.za> Message-ID: <1357866356.83.0.954557409074.issue16920@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Why are you connecting to a multiprocessing listener with a raw socket? You should be using multiprocessing.connection.Client to create a client connection. Connection.send(obj) writes a 32 bit unsigned int (in network order) to the socket representing the length of the pickled data for obj, followed by the pickled data itself. Since you are doing a raw socket write, the server connection is misenterpreting the first 4 bytes of your message "abcd" as the length of the message. So the receiving end needs to allocate space for struct.unpack("!I", "abcd")[0] == 1633837924 ~ 1.5Gb causing the MemoryError. ---------- nosy: +sbt resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 02:23:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 01:23:21 +0000 Subject: [issue13934] sqlite3 test typo In-Reply-To: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za> Message-ID: <3Yj5tT1nQtzR0b@mail.python.org> Roundup Robot added the comment: New changeset b8b26feb3e1a by R David Murray in branch '3.2': #13934: document sqlite version strings, use correct one in test. http://hg.python.org/cpython/rev/b8b26feb3e1a New changeset cdf9142a0c84 by R David Murray in branch '3.3': merge #13934: document sqlite version strings, use correct one in test. http://hg.python.org/cpython/rev/cdf9142a0c84 New changeset aef7db0d3893 by R David Murray in branch 'default': merge #13934: document sqlite version strings, use correct one in test. http://hg.python.org/cpython/rev/aef7db0d3893 New changeset 315949b1842e by R David Murray in branch '2.7': #13934: document sqlite version strings. http://hg.python.org/cpython/rev/315949b1842e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 02:25:44 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Jan 2013 01:25:44 +0000 Subject: [issue13934] sqlite3 test typo In-Reply-To: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za> Message-ID: <1357867543.98.0.118310761671.issue13934@psf.upfronthosting.co.za> R. David Murray added the comment: These patches are small enough a contributor agreement is not required, but it would still be great if you would submit one, poq. ---------- nosy: +r.david.murray stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 03:06:26 2013 From: report at bugs.python.org (Justin Eittreim) Date: Fri, 11 Jan 2013 02:06:26 +0000 Subject: [issue16924] try: except: ordering error Message-ID: <1357869986.79.0.0900594167753.issue16924@psf.upfronthosting.co.za> New submission from Justin Eittreim: When running multiple nested loops (to emulate the circumstances of a program running multiple different modules at once,) each with their own try: except: block (in this case for KeyboardInterrupt,) the order of operations seems to fall out of place. As you can see in the screenshot, even though the inner-most loop should never have been left (or ended for that matter,) the parent loop catches the exception in its place on occasion. While this isn't necessarily a huge issue, for certain things it can be rather annoying and downright confusing. For most all other languages, for example, the inner-most loop would, of course, catch the exception first. Requesting more insight on this issue. ---------- components: None files: 2013-01-10 17_55_13-Python Shell.png messages: 179613 nosy: DivinityArcane priority: normal severity: normal status: open title: try: except: ordering error type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file28682/2013-01-10 17_55_13-Python Shell.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 03:12:17 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 02:12:17 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <3Yj6z42fTLzQyb@mail.python.org> Roundup Robot added the comment: New changeset 2a417ad8bfbf by R David Murray in branch '2.7': #15109: revert '%'->'format' changes in 4b105d328fe7 to fix regression. http://hg.python.org/cpython/rev/2a417ad8bfbf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 03:13:00 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Jan 2013 02:13:00 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1357870380.84.0.803707688333.issue15109@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 03:16:37 2013 From: report at bugs.python.org (Todd Rovito) Date: Fri, 11 Jan 2013 02:16:37 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1357870597.24.0.267164923813.issue16893@psf.upfronthosting.co.za> Todd Rovito added the comment: I think getting this issue fixed makes sense, it would save time and remove duplication. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 03:51:46 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Jan 2013 02:51:46 +0000 Subject: [issue16924] try: except: ordering error In-Reply-To: <1357869986.79.0.0900594167753.issue16924@psf.upfronthosting.co.za> Message-ID: <1357872706.69.0.144922723297.issue16924@psf.upfronthosting.co.za> R. David Murray added the comment: Print b happens when the interpreter is processing the loop condition for loop c. print c happens when it is processing the body of the loop (ie: is inside the try/except in the body of the loop). Presumably if you set your keyboard autorepeat interval short enough you could manage to get it to print a, too, while it was processing the loop condition for loop b after a keyboard interrupt that prints b. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 04:20:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 03:20:21 +0000 Subject: [issue16919] Fix test discovery for test_crypt.py In-Reply-To: <1357836683.17.0.872052983842.issue16919@psf.upfronthosting.co.za> Message-ID: <3Yj8Tc0fvhzR5K@mail.python.org> Roundup Robot added the comment: New changeset 15ddd683c321 by Ezio Melotti in branch '3.3': #16919: test_crypt now works with unittest test discovery. Patch by Zachary Ware. http://hg.python.org/cpython/rev/15ddd683c321 New changeset 5345f515e03b by Ezio Melotti in branch 'default': #16919: merge with 3.3. http://hg.python.org/cpython/rev/5345f515e03b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 04:22:13 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 03:22:13 +0000 Subject: [issue16919] Fix test discovery for test_crypt.py In-Reply-To: <1357836683.17.0.872052983842.issue16919@psf.upfronthosting.co.za> Message-ID: <1357874533.19.0.168229887539.issue16919@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! I tested it with and without crypt and with and without test discovery and all the combinations seem to work fine. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 04:24:30 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 11 Jan 2013 03:24:30 +0000 Subject: [issue16925] Fix test discovery for test_configparser.py Message-ID: <1357874670.05.0.375078566106.issue16925@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: Tests files: test_configparser_discovery.diff keywords: patch nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_configparser.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28683/test_configparser_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 04:32:10 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 11 Jan 2013 03:32:10 +0000 Subject: [issue16919] Fix test discovery for test_crypt.py In-Reply-To: <1357836683.17.0.872052983842.issue16919@psf.upfronthosting.co.za> Message-ID: <1357875130.49.0.980374248555.issue16919@psf.upfronthosting.co.za> Zachary Ware added the comment: I was just about to test it at home and couldn't find it in my list of open issues. Thanks, Ezio :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 04:38:11 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 03:38:11 +0000 Subject: [issue16918] Fix test discovery for test_codecs.py In-Reply-To: <1357835997.28.0.488005818919.issue16918@psf.upfronthosting.co.za> Message-ID: <1357875491.53.0.986951556447.issue16918@psf.upfronthosting.co.za> Ezio Melotti added the comment: FTR, the failure you saw while switching to unittest.main() seems to be caused by a broken test that wasn't run. Unittest test discovery simply revealed the problem -- I'm working on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 04:52:54 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 11 Jan 2013 03:52:54 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357876374.79.0.0742383923357.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Ah, yes. This is part of the annoying inconsistency in our asdl framework. Here's what I think should happen: - on arguments, vararg and kwarg should get the "arg" type, killing some of the numerous fields on arguments - asdl needs to be hacked, so "arg" can have a lineno and col_offset attributes like the "expr" type. Sorry this is getting so painful and involved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:06:12 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 04:06:12 +0000 Subject: [issue16918] Fix test discovery for test_codecs.py In-Reply-To: <1357835997.28.0.488005818919.issue16918@psf.upfronthosting.co.za> Message-ID: <3Yj9VW0YnTzR5r@mail.python.org> Roundup Robot added the comment: New changeset 11e7d0936fa2 by Ezio Melotti in branch '3.3': #16918: test_codecs now works with unittest test discovery. Patch by Zachary Ware. http://hg.python.org/cpython/rev/11e7d0936fa2 New changeset 02180599a99f by Ezio Melotti in branch 'default': #16918: merge with 3.3. http://hg.python.org/cpython/rev/02180599a99f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:10:57 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 04:10:57 +0000 Subject: [issue16918] Fix test discovery for test_codecs.py In-Reply-To: <1357835997.28.0.488005818919.issue16918@psf.upfronthosting.co.za> Message-ID: <1357877457.69.0.659843165913.issue16918@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! Apparently the broken test was ported from Python 2 to Python 3 in 4747ef9640ae (back in the SVN days), but the name of the test class was not added to the list of tests in test_main. Without the test class in the list, the test was not run, so no one noticed it was broken (it was a simply bytes/unicode issue). I now re-enabled it and fix it. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:24:01 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 04:24:01 +0000 Subject: [issue16926] setup.py register does not always respect --repository Message-ID: <1357878241.89.0.365738814483.issue16926@psf.upfronthosting.co.za> New submission from Chris Jerdonek: $ python setup.py --dry-run register --repository http://testpypi.python.org/pypi ... Registering Foo to http://pypi.python.org/pypi Server response (200): OK This is with a .pypirc file with a [server-login] section. It seems like this can cause unintended registrations on PyPI, etc. It also makes it unclear how to get the URL that setup() will use prior to the real invocation (e.g. if you would like to prompt the user with the URL they will be pushing to). ---------- assignee: eric.araujo components: Distutils, Library (Lib) messages: 179624 nosy: chris.jerdonek, eric.araujo, tarek priority: normal severity: normal status: open title: setup.py register does not always respect --repository type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:32:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 04:32:25 +0000 Subject: [issue16925] Fix test discovery for test_configparser.py Message-ID: <3YjB4m4VTHzR4h@mail.python.org> New submission from Roundup Robot: New changeset 7dbdd7204d0a by Ezio Melotti in branch '3.3': #16925: test_configparser now works with unittest test discovery. Patch by Zachary Ware. http://hg.python.org/cpython/rev/7dbdd7204d0a New changeset 680a855ec91e by Ezio Melotti in branch 'default': #16925: merge with 3.3. http://hg.python.org/cpython/rev/680a855ec91e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:34:00 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Jan 2013 04:34:00 +0000 Subject: [issue16926] setup.py register does not always respect --repository In-Reply-To: <1357878241.89.0.365738814483.issue16926@psf.upfronthosting.co.za> Message-ID: <1357878840.88.0.506271707478.issue16926@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think this is a duplicate, could you check? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:34:02 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 04:34:02 +0000 Subject: [issue16925] Fix test discovery for test_configparser.py In-Reply-To: <3YjB4m4VTHzR4h@mail.python.org> Message-ID: <1357878842.58.0.127483501792.issue16925@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:42:03 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 04:42:03 +0000 Subject: [issue8840] truncate() semantics changed in 3.1.2 In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za> Message-ID: <1357879323.85.0.24927129784.issue8840@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.3, Python 3.4 -Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:42:23 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 04:42:23 +0000 Subject: [issue16926] setup.py register does not always respect --repository In-Reply-To: <1357878241.89.0.365738814483.issue16926@psf.upfronthosting.co.za> Message-ID: <1357879343.67.0.0968567964022.issue16926@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I did before and double-checked again. I searched for "setup repository" and "register repository," for example. Issue 16926 seemed the most similar, but appears to be different. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:45:47 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 04:45:47 +0000 Subject: [issue16926] setup.py register does not always respect --repository In-Reply-To: <1357878241.89.0.365738814483.issue16926@psf.upfronthosting.co.za> Message-ID: <1357879547.33.0.85093962123.issue16926@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This is in part because register.run() calls self._set_config() after calling self.finalize_options(): http://hg.python.org/cpython/file/680a855ec91e/Lib/distutils/command/register.py#l43 And _set_config() doesn't seem to look at already-finalized options. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 05:51:06 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 04:51:06 +0000 Subject: [issue16926] setup.py register does not always respect --repository In-Reply-To: <1357878241.89.0.365738814483.issue16926@psf.upfronthosting.co.za> Message-ID: <1357879866.4.0.315592181004.issue16926@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Issue 16926 seemed the most similar, but appears to be different. I meant issue 13615. It is different but is also about --repository. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 06:07:28 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 05:07:28 +0000 Subject: [issue12901] Nest class/methods directives in documentation In-Reply-To: <1315241119.9.0.996780726209.issue12901@psf.upfronthosting.co.za> Message-ID: <1357880848.1.0.302470764677.issue12901@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 06:08:24 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 05:08:24 +0000 Subject: [issue16874] setup.py upload option repeated in docs In-Reply-To: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za> Message-ID: <1357880904.47.0.0810322147528.issue16874@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I will take care of this (formatting issue). ---------- assignee: eric.araujo -> chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 06:50:12 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 05:50:12 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst Message-ID: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> New submission from Ezio Melotti: http://docs.python.org/3/library/functions.html currently lists all the builtin objects. This include two main groups that should be separated in two different sections: built-in types and functions. In addition, similar/related functions should be grouped together. This will make it easier to find similar functions, and will allow us to factor out some documentation that is repeated[0]. A possible division might be: built-in types: dict, int, str, list, tuple, bytes, bool, object, float, complex, bytearray, set, frozenset, memoryview, range, slice functions: base conversion: bin, oct, hex attribute-related: getattr, setattr, hasattr, delattr math-related: abs, pow, round, divmod, hash string-related: ascii, repr, format, chr, ord IO: input, print, open, OOP: staticmethod, classmethod, property, super introspection: isinstance, issubclass, callable, dir, help, vars, id, type, locals, globals sequence/iterable-related: len, min, max, sum, all, any, next, iter, sorted, reversed, enumerate, filter, zip, map code-related: eval, exec, compile, __import__ This is just to give an idea -- the important thing is to rearrange the functions so that e.g. min/max, any/all, chr/ord, hex/oct/bin, getattr/setattr/hasattr/delattr, etc. are close to each other -- having separate sections is not strictly necessary though. Some functions can also be listed on their own. The table at the beginning of functions.rst and ctrl+f are enough to find functions, so I don't think that preserving the current alphabetical order is too useful -- grouping is more important. [0] see e.g #16665. What is reported for hex() there is valid for bin() and oct() too, so a paragraph about how to use format() and its format codes can be added once at the top of the section. This also came up on other issues where we were discussing about documenting the built-in types as "functions" (e.g. in str(someobj)), or as types (e.g. isinstance(someobj, type)). A paragraph to explain this "duality" will help solve the problem. ---------- assignee: ezio.melotti messages: 179632 nosy: chris.jerdonek, eric.araujo, ezio.melotti, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Separate built-in types from functions and group similar functions in functions.rst type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 06:50:41 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 05:50:41 +0000 Subject: [issue13963] dev guide has no mention of mechanics of patch review In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za> Message-ID: <1357883439.97.0.0413489978035.issue13963@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I asked on the Mercurial tracker about suppressing git-style diffs when git is configured on, and there is a work-around: http://bz.selenic.com/show_bug.cgi?id=3761 We could mention this in the devguide somewhere (e.g. in a FAQ about how to use Rietveld with patches to non-default branches). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 06:54:23 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 05:54:23 +0000 Subject: [issue16851] Hint about correct ismethod and isfunction usage In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1357883663.58.0.498432540565.issue16851@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 07:06:33 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 06:06:33 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357884393.83.0.325076925481.issue16748@psf.upfronthosting.co.za> Ezio Melotti added the comment: > There are tests outside of Lib/test/ hierarchy. See #10572. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 07:18:56 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 06:18:56 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357885136.91.0.316419792507.issue16748@psf.upfronthosting.co.za> Chris Jerdonek added the comment: There are lots of modules to change here. I wonder if some or most of this couldn't be automated. For example, is there any reason we couldn't write a script to check for the type of test duplication fixed documentation-wise in issue 16835? We could use such a script to find the classes that need to be updated when removing test_main (or to double-check existing test modules). I don't know if there are ever times we want such duplication. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 07:21:51 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 06:21:51 +0000 Subject: [issue16874] setup.py upload option repeated in docs In-Reply-To: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za> Message-ID: <1357885311.34.0.236736619849.issue16874@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The attached patch applies to all branches. ---------- Added file: http://bugs.python.org/file28684/issue-16874-1-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 07:44:49 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 06:44:49 +0000 Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches nothing. Ditto B and Z. In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za> Message-ID: <3YjF1W1f7dzS0T@mail.python.org> Roundup Robot added the comment: New changeset 2bc04449fd8c by Ezio Melotti in branch '2.7': #13899: \A, \Z, and \B now correctly match the A, Z, and B literals when used inside character classes (e.g. [A]). Patch by Matthew Barnett. http://hg.python.org/cpython/rev/2bc04449fd8c New changeset 081db241ccda by Ezio Melotti in branch '3.2': #13899: \A, \Z, and \B now correctly match the A, Z, and B literals when used inside character classes (e.g. [A]). Patch by Matthew Barnett. http://hg.python.org/cpython/rev/081db241ccda New changeset 17b1eb4a8144 by Ezio Melotti in branch '3.3': #13899: merge with 3.2. http://hg.python.org/cpython/rev/17b1eb4a8144 New changeset 35ece2465936 by Ezio Melotti in branch 'default': #13899: merge with 3.3. http://hg.python.org/cpython/rev/35ece2465936 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 07:46:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 06:46:43 +0000 Subject: [issue13899] re pattern r"[\A]" should work like "A" but matches nothing. Ditto B and Z. In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za> Message-ID: <1357886803.68.0.907746967665.issue13899@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report John, and for the patch Matthew! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 08:05:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 07:05:23 +0000 Subject: [issue16874] setup.py upload option repeated in docs In-Reply-To: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za> Message-ID: <3YjFTG54syzR7g@mail.python.org> Roundup Robot added the comment: New changeset a30c36fbefcf by Chris Jerdonek in branch '2.7': Issue #16874: fix formatting of setup.py upload options in documentation. http://hg.python.org/cpython/rev/a30c36fbefcf New changeset dcb645b9de4c by Chris Jerdonek in branch '3.2': Issue #16874 (forward-port from 2.7): fix some documentation formatting. http://hg.python.org/cpython/rev/dcb645b9de4c New changeset 63fff55a167f by Chris Jerdonek in branch '3.3': Issue #16874 (merge from 3.2): fix some documentation formatting. http://hg.python.org/cpython/rev/63fff55a167f New changeset 860a2f6282c4 by Chris Jerdonek in branch 'default': Issue #16874 (merge from 3.3): fix some documentation formatting. http://hg.python.org/cpython/rev/860a2f6282c4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 08:07:55 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 07:07:55 +0000 Subject: [issue16874] setup.py upload option repeated in docs In-Reply-To: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za> Message-ID: <1357888075.65.0.843076981184.issue16874@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 08:13:10 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 07:13:10 +0000 Subject: [issue16154] Some minor doc fixes in Doc/library In-Reply-To: <1349562325.82.0.0767622542031.issue16154@psf.upfronthosting.co.za> Message-ID: <3YjFfF3ZfBzQpP@mail.python.org> Roundup Robot added the comment: New changeset 9b3d0bdb9256 by Ezio Melotti in branch '2.7': #16154: fix some doctests in Doc/library. Patch by Ravi Sinha. http://hg.python.org/cpython/rev/9b3d0bdb9256 New changeset 5b405df8518d by Ezio Melotti in branch '3.2': #16154: fix some doctests in Doc/library. Patch by Ravi Sinha. http://hg.python.org/cpython/rev/5b405df8518d New changeset 3e884b3804b3 by Ezio Melotti in branch '3.3': #16154: merge with 3.2. http://hg.python.org/cpython/rev/3e884b3804b3 New changeset 5ec8daab477a by Ezio Melotti in branch 'default': #16154: merge with 3.3. http://hg.python.org/cpython/rev/5ec8daab477a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 08:14:38 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 07:14:38 +0000 Subject: [issue16154] Some minor doc fixes in Doc/library In-Reply-To: <1349562325.82.0.0767622542031.issue16154@psf.upfronthosting.co.za> Message-ID: <1357888478.09.0.106186144185.issue16154@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report and the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 08:37:32 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 07:37:32 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357889852.95.0.387817475438.issue16076@psf.upfronthosting.co.za> Ezio Melotti added the comment: The fix introduced some refleaks: $ ./python -m test -R3:2 test_xml_etree_c test_xml_etree_c leaked [56, 56] references, sum=112 One seems to be in __getstate__: diff --git a/Modules/_elementtree.c b/Modules/_elementtree.c --- a/Modules/_elementtree.c +++ b/Modules/_elementtree.c @@ -859,8 +859,10 @@ PICKLED_ATTRIB, self->extra->attrib, PICKLED_TEXT, self->text, PICKLED_TAIL, self->tail); - if (instancedict) + if (instancedict) { + Py_DECREF(children); return instancedict; + } else { for (i = 0; i < PyList_GET_SIZE(children); i++) Py_DECREF(PyList_GET_ITEM(children, i)); I'm still looking for the other. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 08:45:16 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 07:45:16 +0000 Subject: [issue16928] spurious Cron Daemon e-mails to docs@dinsdale.python.org Message-ID: <1357890316.54.0.914803734426.issue16928@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Some spurious e-mails are sent to python-checkins, e.g. Subject: [Python-checkins] Cron /home/docs/build-devguide From: Cron Daemon root at python.org To: docs at dinsdale.python.org /home/docs/devguide/documenting.rst:766: WARNING: term not in glossary: bytecode (from http://mail.python.org/pipermail/python-checkins/2013-January/118934.html ) The e-mail is spurious in part because "bytecode" links correctly on the actual online version. ---------- assignee: docs at python components: Devguide, Documentation messages: 179643 nosy: chris.jerdonek, docs at python, eric.araujo, ezio.melotti, georg.brandl priority: normal severity: normal status: open title: spurious Cron Daemon e-mails to docs at dinsdale.python.org _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:16:57 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 08:16:57 +0000 Subject: [issue16814] use --directory option of make in describing how to build the docs In-Reply-To: <1356790311.86.0.00498941541992.issue16814@psf.upfronthosting.co.za> Message-ID: <3YjH3q5h6SzS3j@mail.python.org> Roundup Robot added the comment: New changeset 5f24a77e7beb by Chris Jerdonek in branch 'default': Issue #16814: add "make -C Doc html" short-cut to documentation instructions. http://hg.python.org/devguide/rev/5f24a77e7beb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:17:47 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 08:17:47 +0000 Subject: [issue16814] use --directory option of make in describing how to build the docs In-Reply-To: <1356790311.86.0.00498941541992.issue16814@psf.upfronthosting.co.za> Message-ID: <1357892267.93.0.406081042646.issue16814@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I went ahead and committed this if that's okay. I wasn't sensing any strong objection but -0 from some and +1 or +0 from others. To compensate for the extra six words, I went ahead and first made the current language more concise here: http://hg.python.org/devguide/rev/157066a204ab If anyone feels strongly, I would be happy to revert the change though. ---------- resolution: -> fixed stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:24:56 2013 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Jan 2013 08:24:56 +0000 Subject: [issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex In-Reply-To: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za> Message-ID: <1357892696.32.0.314042232745.issue16899@psf.upfronthosting.co.za> Mark Dickinson added the comment: > But I'm unsure is this is expected behavior or luck, and on some > platform this code will not work due to different complex numbers > internal representation. What platform? Isn't the complex number representation standard? E.g., C99 6.2.5p13 says: "Each complex type has the same representation and alignment requirements as an array type containing exactly two elements of the corresponding real type; the first element is equal to the real part, and the second element to the imaginary part, of the complex number." ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:36:44 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 11 Jan 2013 08:36:44 +0000 Subject: [issue16929] poll()/epoll() are not thread-safe Message-ID: <1357893404.57.0.0716117445862.issue16929@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: After optimizing epoll() to use a per-instance buffer like poll() does (http://bugs.python.org/issue16876), I realized that it wasn't thread-safe, and can result in crashes: """ ./python /tmp/test.py *** glibc detected *** ./python: free(): corrupted unsorted chunks: 0x0000000001c8e690 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3041c75676] ./python[0x4fd9ae] ./python(PyThreadState_DeleteCurrent+0x10c)[0x4fdb91] ./python[0x52a444] /lib64/libpthread.so.0[0x30428077e1] /lib64/libc.so.6(clone+0x6d)[0x3041ce153d] ======= Memory map: ======== [...] """ The problem is that poll (and now epoll) array is stored per-instance, and if second call to poll() is made while another thread is currently blocked on poll(), the array is reallocated (through PyMem_Resize()) if the buffer size has changed (if the number of FDs registered has changed). """ static int update_ufd_array(pollObject *self) [...] self->ufd_len = PyDict_Size(self->dict); PyMem_RESIZE(self->ufds, struct pollfd, self->ufd_len); [...] """ can be called while another thread is blocked there: """ /* call poll() */ Py_BEGIN_ALLOW_THREADS poll_result = poll(self->ufds, self->ufd_len, timeout); Py_END_ALLOW_THREADS """ So when the first call to poll() returns, it can end up in SIGSEGV or heap corruption (unless the array was increased an realloc() was able to expand it in-place). Reproducer script attached. ---------- components: Extension Modules files: test.py messages: 179647 nosy: christian.heimes, neologix priority: normal severity: normal stage: needs patch status: open title: poll()/epoll() are not thread-safe type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28685/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:37:17 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2013 08:37:17 +0000 Subject: [issue16928] spurious Cron Daemon e-mails to docs@dinsdale.python.org In-Reply-To: <1357890316.54.0.914803734426.issue16928@psf.upfronthosting.co.za> Message-ID: <1357893437.28.0.435399071353.issue16928@psf.upfronthosting.co.za> Georg Brandl added the comment: This is a known issue in older Sphinx versions. I've updated the version used to build the devguide now; this should fix it. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:37:52 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 08:37:52 +0000 Subject: [issue16928] spurious Cron Daemon e-mails to docs@dinsdale.python.org In-Reply-To: <1357890316.54.0.914803734426.issue16928@psf.upfronthosting.co.za> Message-ID: <1357893472.5.0.438723166192.issue16928@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Great, thank you! :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:38:39 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 08:38:39 +0000 Subject: [issue16930] mention limitations and/or alternatives to hg graft Message-ID: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za> New submission from Chris Jerdonek: In various places, the devguide recommends `hg graft`, but it appears it might not be possible to use on some systems or in certain situations. For example, when I tried grafting a trivial change from 2.7 to 3.2 on Mac OS X, I got the following fatal error: $ hg graft 2.7 grafting revision 81391 abort: case-folding collision between Lib/ConfigParser.py and Lib/configparser.py Here is some related information: http://mercurial.selenic.com/wiki/FixingCaseCollisions At the least, we might want to add a note saying that `hg graft` may not work on certain systems (and name those systems). ---------- components: Devguide messages: 179650 nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan priority: normal severity: normal status: open title: mention limitations and/or alternatives to hg graft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:44:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 08:44:43 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1357893883.51.0.604044509271.issue16076@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is what I found out. I used an easily copy/pastable one-liner that creates 3 variables: e (no children), e2 (3 children), e3 (5 children). Original leaky code (test_xml_etree_c leaked [56, 56] references, sum=112): >>> from xml.etree import ElementTree as ET; e = ET.Element('foo'); SAMPLE_XML = "text
subtext
"; e2 = ET.XML(SAMPLE_XML); SAMPLE_XML = "text
subtext
"; e3 = ET.XML(SAMPLE_XML) [76773 refs] >>> ### e has no children and leaks 1 ref: >>> e.__getstate__() {'tag': 'foo', 'attrib': {}, 'text': None, 'tail': None, '_children': []} [76791 refs] >>> e.__getstate__() {'tag': 'foo', 'attrib': {}, 'text': None, 'tail': None, '_children': []} [76792 refs] >>> e.__getstate__() {'tag': 'foo', 'attrib': {}, 'text': None, 'tail': None, '_children': []} [76793 refs] >>> ### e2 has 3 children and leaks 4 refs: >>> e2.__getstate__() {'tag': 'body', 'attrib': {}, 'text': None, 'tail': None, '_children': [, , ]} [76798 refs] >>> e2.__getstate__() {'tag': 'body', 'attrib': {}, 'text': None, 'tail': None, '_children': [, , ]} [76802 refs] The leaked refs seems to be 1 for the children list + 1 for each children. The diff I pasted in the previous *seems* to fix this (i.e. leaks in __gestate__ are gone, tests pass), but I had it crash once (couldn't reproduce after that, so it might be unrelated*), and I'm not sure it's correct. With that patch applied we go down to test_xml_etree_c leaked [6, 6] references, sum=12. The remaining leaks seem to be in __setstate__. Patched code: >>> from xml.etree import ElementTree as ET; e = ET.Element('foo'); SAMPLE_XML = "text
subtext
"; e2 = ET.XML(SAMPLE_XML); SAMPLE_XML = "text
subtext
"; e3 = ET.XML(SAMPLE_XML) [76773 refs] >>> ### no more leaks for getstate: >>> p = e.__getstate__() [76787 refs] >>> p = e.__getstate__() [76787 refs] >>> ### also no leaks when there are no child: >>> e.__setstate__(p) [76788 refs] >>> e.__setstate__(p) [76788 refs] >>> ### no more leaks for getstate with children: >>> p2 = e2.__getstate__() [76807 refs] >>> p2 = e2.__getstate__() [76807 refs] >>> ### one ref leaked for every child in __setstate__: >>> e2.__setstate__(p2) [76810 refs] >>> e2.__setstate__(p2) [76813 refs] >>> e2.__setstate__(p2) [76816 refs] I'm not working on this anymore now, so someone more familiar with the code can take a look, see if my patch is correct, and fix the remaining leaks. * maybe I'm doing something wrong, but ISTM that ``make -j2`` doesn't always work right away, and sometimes I get different results if I do it again without touching the code. ---------- stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:46:44 2013 From: report at bugs.python.org (gac) Date: Fri, 11 Jan 2013 08:46:44 +0000 Subject: [issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays In-Reply-To: <1357821708.32.0.469925509105.issue16914@psf.upfronthosting.co.za> Message-ID: <1357894004.27.0.740792801868.issue16914@psf.upfronthosting.co.za> gac added the comment: Patch to add the same functionality to Python 2.7, if anyone's interested in that also. ---------- versions: +Python 2.7 Added file: http://bugs.python.org/file28686/smtplib.py.27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:50:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 08:50:48 +0000 Subject: [issue16929] poll()/epoll() are not thread-safe In-Reply-To: <1357893404.57.0.0716117445862.issue16929@psf.upfronthosting.co.za> Message-ID: <1357894248.85.0.0815697424923.issue16929@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For poll() see issue8865. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:52:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 08:52:15 +0000 Subject: [issue16929] poll()/epoll() are not thread-safe In-Reply-To: <1357893404.57.0.0716117445862.issue16929@psf.upfronthosting.co.za> Message-ID: <1357894335.07.0.172945619954.issue16929@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +select.poll is not thread safe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:56:44 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 08:56:44 +0000 Subject: [issue16930] mention limitations and/or alternatives to hg graft In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za> Message-ID: <1357894604.04.0.336490451825.issue16930@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- dependencies: +Update cloning guidelines in devguide stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:56:51 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 08:56:51 +0000 Subject: [issue16931] mention work-around to create diffs in default/non-git mode Message-ID: <1357894611.9.0.235167303817.issue16931@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to mention in the devguide how to create diffs with the changeset number when --git is configured on. Perhaps this can be done via a FAQ like: "How can I get Rietveld to work with a 2.7 patch?" Background: Currently, the devguide recommends configuring Mercurial to use --git when making diffs. However, this causes the changeset ID to be left off of patch files and, for example, prevents Rietveld from working with patches to non-default branches. See also this thread: http://mail.python.org/pipermail/python-dev/2011-March/108765.html This issue describes a couple work-arounds: http://bz.selenic.com/show_bug.cgi?id=3761 ---------- components: Devguide messages: 179654 nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan priority: normal severity: normal status: open title: mention work-around to create diffs in default/non-git mode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 09:58:36 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 11 Jan 2013 08:58:36 +0000 Subject: [issue16929] poll()/epoll() are not thread-safe In-Reply-To: <1357893404.57.0.0716117445862.issue16929@psf.upfronthosting.co.za> Message-ID: <1357894716.19.0.501416779767.issue16929@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: OK, I'll close as duplicate. ---------- dependencies: -select.poll is not thread safe resolution: -> duplicate superseder: -> select.poll is not thread safe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 10:00:32 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 11 Jan 2013 09:00:32 +0000 Subject: [issue8865] select.poll is not thread safe In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za> Message-ID: <1357894832.54.0.668025362945.issue8865@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: This patch should be updated to also fix epoll(). Also, is it right to raise an exception in case of concurrent invocation? Here's a simple script that crashes systematically on my Linux box. ---------- nosy: +neologix Added file: http://bugs.python.org/file28687/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 10:00:48 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 11 Jan 2013 09:00:48 +0000 Subject: [issue16929] poll()/epoll() are not thread-safe In-Reply-To: <1357893404.57.0.0716117445862.issue16929@psf.upfronthosting.co.za> Message-ID: <1357894848.7.0.809121924151.issue16929@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 10:01:35 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 09:01:35 +0000 Subject: [issue13963] dev guide has no mention of mechanics of patch review In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za> Message-ID: <1357894895.32.0.0379999007364.issue13963@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I created issue 16931 to document a way to use Rietveld for 2.7 patches, while still keeping the Mercurial configuration we advise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 10:19:16 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 09:19:16 +0000 Subject: [issue8865] select.poll is not thread safe In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za> Message-ID: <1357895956.34.0.470700704684.issue8865@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Also, is it right to raise an exception in case of concurrent invocation? It is right for poll() because it was not concurrently usable in previous versions in any case. For epoll() it is an another issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 10:31:11 2013 From: report at bugs.python.org (Tim Golden) Date: Fri, 11 Jan 2013 09:31:11 +0000 Subject: [issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong In-Reply-To: <1357839740.51.0.95267360969.issue16921@psf.upfronthosting.co.za> Message-ID: <1357896671.67.0.25662019369.issue16921@psf.upfronthosting.co.za> Tim Golden added the comment: This code is no longer present in subprocess.py now that issue14470 has been applied. ---------- nosy: +brian.curtin, tim.golden resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 10:32:31 2013 From: report at bugs.python.org (Sergey Prokhorov) Date: Fri, 11 Jan 2013 09:32:31 +0000 Subject: [issue11159] Sax parser crashes if given unicode file name In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za> Message-ID: <1357896751.93.0.44686516597.issue11159@psf.upfronthosting.co.za> Changes by Sergey Prokhorov : ---------- nosy: +Sergey.Prokhorov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 10:37:10 2013 From: report at bugs.python.org (Tim Golden) Date: Fri, 11 Jan 2013 09:37:10 +0000 Subject: [issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong In-Reply-To: <1357839740.51.0.95267360969.issue16921@psf.upfronthosting.co.za> Message-ID: <1357897030.37.0.865317221919.issue16921@psf.upfronthosting.co.za> Tim Golden added the comment: Reopening because there is in fact a doc issue reamining. ---------- assignee: -> tim.golden resolution: out of date -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 10:49:19 2013 From: report at bugs.python.org (Tim Golden) Date: Fri, 11 Jan 2013 09:49:19 +0000 Subject: [issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong In-Reply-To: <1357839740.51.0.95267360969.issue16921@psf.upfronthosting.co.za> Message-ID: <1357897759.82.0.538009056519.issue16921@psf.upfronthosting.co.za> Tim Golden added the comment: I can't push from work; the (trivial) doc patch is attached. If no-one gets to it, I'll push from home this evening. ---------- Added file: http://bugs.python.org/file28688/doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 11:26:34 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 10:26:34 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357899994.43.0.202242545804.issue16748@psf.upfronthosting.co.za> Chris Jerdonek added the comment: As suggested in the previous comment, here is simple code to find candidates for test duplication (TestCase subclasses subclassing other TestCase classes): def find_dupes(mod): objects = [getattr(mod, name) for name in sorted(dir(mod))] classes = [obj for obj in objects if isinstance(obj, type) and issubclass(obj, unittest.TestCase)] for c in classes: for d in classes: if c is not d and issubclass(d, c): print("%s: %s < %s" % (mod.__name__, c.__name__, d.__name__)) Out of curiosity, I ran a modified form of this against all test modules to find which ones fit this pattern and *already* rely on unittest discovery (i.e. don't have test_main()). We might want to adjust these as well. There were four: test_asyncore, test_configparser, test_heapq, test_ipaddress ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 11:40:07 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 10:40:07 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <3YjLF14VpczP94@mail.python.org> Roundup Robot added the comment: New changeset f783db4a58ba by Serhiy Storchaka in branch '2.7': Issue #15539: Fix a number of bugs in Tools/scripts/pindent.py. http://hg.python.org/cpython/rev/f783db4a58ba New changeset 9df6b707aef9 by Serhiy Storchaka in branch '3.2': Issue #15539: Fix a number of bugs in Tools/scripts/pindent.py. http://hg.python.org/cpython/rev/9df6b707aef9 New changeset 01df1f7841b2 by Serhiy Storchaka in branch '3.3': Issue #15539: Fix a number of bugs in Tools/scripts/pindent.py. http://hg.python.org/cpython/rev/01df1f7841b2 New changeset 8452c23139c6 by Serhiy Storchaka in branch 'default': Issue #15539: Fix a number of bugs in Tools/scripts/pindent.py. http://hg.python.org/cpython/rev/8452c23139c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 11:42:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 10:42:51 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1357900971.88.0.618956559506.issue15539@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 11:49:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 10:49:04 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357901344.59.0.661319854633.issue16748@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a dirty patch which hacks unittest to search possible test overriding. Just apply the patch and run regression tests. ---------- Added file: http://bugs.python.org/file28689/checkTestOverriding.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 11:59:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 10:59:24 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1357901964.44.0.0565832098748.issue16748@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file28690/test_overriding.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 12:02:19 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2013 11:02:19 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1357902139.83.0.0456842288266.issue16398@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It could be made a bit faster, but it would complicate the code for very little benefit. IMO, this isn't worth it. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 12:04:56 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2013 11:04:56 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357902296.61.0.0903871811158.issue16613@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 12:07:02 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Fri, 11 Jan 2013 11:07:02 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1357893883.51.0.604044509271.issue16076@psf.upfronthosting.co.za> Message-ID: <20130111110655.GG3556@lp-shahaf.local> Daniel Shahaf added the comment: Ezio Melotti wrote on Fri, Jan 11, 2013 at 08:44:43 +0000: > >>> ### one ref leaked for every child in __setstate__: > >>> e2.__setstate__(p2) > [76810 refs] > >>> e2.__setstate__(p2) > [76813 refs] > >>> e2.__setstate__(p2) > [76816 refs] > > I'm not working on this anymore now, so someone more familiar with the > code can take a look, see if my patch is correct, and fix the > remaining leaks. > Thank for narrowing it down so much. Attached patch incorporates your getstate fix and a fix for setstate. It passes the -R 3:2 tests. ---------- Added file: http://bugs.python.org/file28691/memleak-v1.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 6eae84170536 Modules/_elementtree.c --- a/Modules/_elementtree.c Fri Jan 11 10:49:43 2013 +0100 +++ b/Modules/_elementtree.c Fri Jan 11 10:56:05 2013 +0000 @@ -859,8 +859,10 @@ element_getstate(ElementObject *self) PICKLED_ATTRIB, self->extra->attrib, PICKLED_TEXT, self->text, PICKLED_TAIL, self->tail); - if (instancedict) + if (instancedict) { + Py_DECREF(children); return instancedict; + } else { for (i = 0; i < PyList_GET_SIZE(children); i++) Py_DECREF(PyList_GET_ITEM(children, i)); @@ -884,25 +886,17 @@ element_setstate_from_attributes(Element PyErr_SetString(PyExc_TypeError, "tag may not be NULL"); return NULL; } - if (!text) { - Py_INCREF(Py_None); - text = Py_None; - } - if (!tail) { - Py_INCREF(Py_None); - tail = Py_None; - } Py_CLEAR(self->tag); self->tag = tag; Py_INCREF(self->tag); Py_CLEAR(self->text); - self->text = text; + self->text = text ? text : Py_None; Py_INCREF(self->text); Py_CLEAR(self->tail); - self->tail = tail; + self->tail = tail ? tail : Py_None; Py_INCREF(self->tail); /* Handle ATTRIB and CHILDREN. */ From report at bugs.python.org Fri Jan 11 12:09:06 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 11:09:06 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357902546.59.0.911201896701.issue16886@psf.upfronthosting.co.za> Ezio Melotti added the comment: I left a review on Rietveld. Frank, once the comments have been addressed and the patch approved, do you want to commit it on all the 4 branches yourself? If you prefer I can take care of it. ---------- nosy: +ezio.melotti type: -> behavior versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 12:23:38 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Jan 2013 11:23:38 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1357903418.49.0.350996517882.issue15539@psf.upfronthosting.co.za> Ezio Melotti added the comment: Some buildbots are failing: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7/builds/341/steps/test/logs/stdio http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/1263/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 12:29:29 2013 From: report at bugs.python.org (Sandro Tosi) Date: Fri, 11 Jan 2013 11:29:29 +0000 Subject: [issue16932] urlparse fails at parsing "www.python.org:80/" Message-ID: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za> New submission from Sandro Tosi: Hello, as reported at http://mail.python.org/pipermail/docs/2013-January/012375.html urlparse fails to parse URLs without a schema and with a url path, as opposed to what's documented at http://docs.python.org/2/library/urlparse.html?highlight=urlparse#urlparse : ./python -c "from urlparse import urlparse ; print(urlparse('python.org:80/'))" ParseResult(scheme='python.org', netloc='', path='80/', params='', query='', fragment='') (that is for 2.7, but the same happens on all the 3.x active branches). i'm attaching a test to expose this failure. ---------- components: Library (Lib) files: urlparse.diff keywords: patch messages: 179670 nosy: sandro.tosi priority: normal severity: normal stage: needs patch status: open title: urlparse fails at parsing "www.python.org:80/" versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28692/urlparse.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 12:30:50 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2013 11:30:50 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357903850.59.0.277784726538.issue16613@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Can you write-up a patch with tests and a doc change? ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 12:36:47 2013 From: report at bugs.python.org (Sandro Tosi) Date: Fri, 11 Jan 2013 11:36:47 +0000 Subject: [issue16932] urlparse fails at parsing "www.python.org:80/" In-Reply-To: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za> Message-ID: <1357904207.2.0.984713936502.issue16932@psf.upfronthosting.co.za> Sandro Tosi added the comment: Adding Senthil as per expert list ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 13:06:55 2013 From: report at bugs.python.org (Federico Reghenzani) Date: Fri, 11 Jan 2013 12:06:55 +0000 Subject: [issue16915] mode of socket.makefile is more limited than documentation suggests In-Reply-To: <1357825217.2.0.655032840521.issue16915@psf.upfronthosting.co.za> Message-ID: <1357906015.12.0.0312414261994.issue16915@psf.upfronthosting.co.za> Federico Reghenzani added the comment: I think that 't' option can be added to conform with open() built-in function. The other options I don't think it's possible to use with sockets. Adding the 't' doesn't change the makefile() behavior. I added also a clarification in documentation. ---------- keywords: +patch nosy: +federico.reghenzani versions: +Python 3.4 -Python 3.2 Added file: http://bugs.python.org/file28693/t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 13:23:27 2013 From: report at bugs.python.org (Thomas Guettler) Date: Fri, 11 Jan 2013 12:23:27 +0000 Subject: [issue14102] argparse: add ability to create a man page In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za> Message-ID: <1357907007.97.0.718347485066.issue14102@psf.upfronthosting.co.za> Changes by Thomas Guettler : ---------- nosy: +guettli _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 13:31:50 2013 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 11 Jan 2013 12:31:50 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357907510.83.0.0155375734492.issue16613@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- hgrepos: +171 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 13:32:22 2013 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 11 Jan 2013 12:32:22 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357907542.59.0.91837266437.issue16613@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- keywords: +patch Added file: http://bugs.python.org/file28694/951243de359a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 13:36:20 2013 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 11 Jan 2013 12:36:20 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357907780.16.0.941260464171.issue16613@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Can you write-up a patch with tests and a doc change? Done. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 14:03:10 2013 From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=) Date: Fri, 11 Jan 2013 13:03:10 +0000 Subject: [issue16917] Misleading missing parenthesis syntax error In-Reply-To: <1357831779.28.0.575634681694.issue16917@psf.upfronthosting.co.za> Message-ID: Dra?en Lu?anin added the comment: Yes, I see your point. Well, for now I am voting for issue1634034 to get some sort of resolution, as Serhiy mentioned, as it might help this scenario as well. Cheers! On Thu, Jan 10, 2013 at 4:29 PM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > >> This would all be a bit simpler if an indent was obligatory after >> inserting a newline in the middle of a command. > > This is not such a bad idea, but it is not backward-compatible and it would be inconsistent with how parentheses works in other situations. > > Developers usually learn that they should look back at least till the previous line while investigating syntax errors. Even in C (and similar languages) it's common that errors reported on one line are caused by e.g. a missing ';' on the previous line. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 14:09:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 13:09:26 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1357909766.18.0.500742573732.issue15539@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which should fix creating a backup on Windows. Please test it. If test_tools passes on Windows then I'll commit the patch, in contrary case I'll?just skip checking of backup on Windows. ---------- stage: committed/rejected -> patch review status: closed -> open Added file: http://bugs.python.org/file28695/pindent_backup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 14:21:07 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 13:21:07 +0000 Subject: [issue1634034] Show "expected" token on syntax error Message-ID: <1357910467.35.0.905767469463.issue1634034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I?agree, the main problem is in the fact that "expected token" is not always singular. And even "most expected token" is a little subjective. The better solution will be to expect several possible tokens. This requires some parser modification. ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 14:31:29 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 13:31:29 +0000 Subject: [issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong In-Reply-To: <1357839740.51.0.95267360969.issue16921@psf.upfronthosting.co.za> Message-ID: <3YjQ2m3g3lzMCL@mail.python.org> Roundup Robot added the comment: New changeset 1aac333f320a by Tim Golden in branch 'default': #16921 Since Win9x is no longer supported, CREATE_NEW_CONSOLE is http://hg.python.org/cpython/rev/1aac333f320a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 14:33:26 2013 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Jan 2013 13:33:26 +0000 Subject: [issue16445] SEGFAULT when deleting Exception.message In-Reply-To: <1352415910.77.0.640632287013.issue16445@psf.upfronthosting.co.za> Message-ID: <1357911206.13.0.565920919618.issue16445@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 14:44:18 2013 From: report at bugs.python.org (Thomas Guettler) Date: Fri, 11 Jan 2013 13:44:18 +0000 Subject: [issue16933] argparse: remove magic from examples Message-ID: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za> New submission from Thomas Guettler: The current argparse documentation is not easy to read people new to python. http://docs.python.org/dev/library/argparse.html#choices {{{ current: parser.add_argument('foo', choices='abc') }}} Please make this more explicit: {{{ better: parser.add_argument('foo', choices=['one', 'two', 'three']) }}} {{{ current: parser.parse_args('c'.split()) # looks like perl to me }}} {{{ better: parser.parse_args(['c']) }}} Next: Please use a more common type, not "complex" in the choices example. It confuses a lot of people. ---------- messages: 179679 nosy: guettli priority: normal severity: normal status: open title: argparse: remove magic from examples _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:13:56 2013 From: report at bugs.python.org (Stephane Poirier) Date: Fri, 11 Jan 2013 14:13:56 +0000 Subject: [issue16934] qsort doesn't work for double arrays Message-ID: <1357913636.91.0.603686278342.issue16934@psf.upfronthosting.co.za> New submission from Stephane Poirier: qsort doesn't sort arrays that are defined with double elements. You can find attached a script that shows this function working well for int (as described in the ctypes documentation). If int array is replaced by double array qsort doesn't sort any more. Even worse, with python 2.6, the difference between a[0] and b[0] may be nan. The script can be launch by python.exe testQSort33.py ---------- components: ctypes files: testQSort33.py messages: 179680 nosy: stephane.poirier priority: normal severity: normal status: open title: qsort doesn't work for double arrays type: behavior versions: Python 2.6, Python 2.7, Python 3.3 Added file: http://bugs.python.org/file28696/testQSort33.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:24:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 14:24:18 +0000 Subject: [issue16934] qsort doesn't work for double arrays In-Reply-To: <1357913636.91.0.603686278342.issue16934@psf.upfronthosting.co.za> Message-ID: <1357914258.74.0.932088599361.issue16934@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:43:08 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 14:43:08 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery Message-ID: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> New submission from Brett Cannon: For test discovery to work where a dependent module is optional, you end up needing to do something like what is done in http://hg.python.org/cpython/rev/15ddd683c321: -crypt = support.import_module('crypt') +def setUpModule(): + # this import will raise unittest.SkipTest if _crypt doesn't exist, + # so it has to be done in setUpModule for test discovery to work + global crypt + crypt = support.import_module('crypt') That's kind of ugly. It would be better if unittest recognized SkipTest at import time during test discovery ---------- assignee: michael.foord components: Library (Lib) messages: 179681 nosy: brett.cannon, michael.foord priority: normal severity: normal stage: test needed status: open title: unittest should understand SkipTest at import time during test discovery type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:44:05 2013 From: report at bugs.python.org (Michael Foord) Date: Fri, 11 Jan 2013 14:44:05 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1357915445.16.0.70722662684.issue16935@psf.upfronthosting.co.za> Michael Foord added the comment: Agreed and it should be easy to implement. ---------- keywords: +gsoc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:53:53 2013 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Jan 2013 14:53:53 +0000 Subject: [issue16934] qsort doesn't work for double arrays In-Reply-To: <1357913636.91.0.603686278342.issue16934@psf.upfronthosting.co.za> Message-ID: <1357916033.72.0.409623735226.issue16934@psf.upfronthosting.co.za> Mark Dickinson added the comment: What happens if you replace the line: CMPFUNC = CFUNCTYPE(c_double, POINTER(c_double), POINTER(c_double)) in your example code with CMPFUNC = CFUNCTYPE(c_int, POINTER(c_double), POINTER(c_double)) ? ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:54:56 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 11 Jan 2013 14:54:56 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357916096.0.0.944788545979.issue16829@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Going to attach a patch using subprocess in a few minutes... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:57:43 2013 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Jan 2013 14:57:43 +0000 Subject: [issue16934] qsort doesn't work for double arrays In-Reply-To: <1357913636.91.0.603686278342.issue16934@psf.upfronthosting.co.za> Message-ID: <1357916263.15.0.992761984468.issue16934@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing as invalid: the issue is not in Python but with the CMPFUNC line. Your py_cmp_func should return an integer rather than a float to be compatible with libc.qsort. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:57:54 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Jan 2013 14:57:54 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1357916274.87.0.571687568205.issue8145@psf.upfronthosting.co.za> R. David Murray added the comment: I believe this patch is correct in essence, but I think it would be helpful to clarify the explanation of what autocommit mode is. I'll work on an updated patch. It could also be considered a bug that the standard context manager does not support autocommit mode, but I'm going to treat that as a separate bug. Perhaps a fix will come out of fixing issue 10740. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 15:57:59 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 11 Jan 2013 14:57:59 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1357916279.62.0.6044678289.issue16935@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 16:31:22 2013 From: report at bugs.python.org (Jens Lechtenboerger) Date: Fri, 11 Jan 2013 15:31:22 +0000 Subject: [issue16936] Documentation for stat.S_IFMT inconsistent Message-ID: <1357918282.52.0.0217764551769.issue16936@psf.upfronthosting.co.za> New submission from Jens Lechtenboerger: The documentation for the stat module is inconsistent (Doc/library/stat.rst, at least for Python 2.7.2 and 3.3.0): It talks about a function stat.S_IFMT() and a bit mask stat.S_IFMT. Only the former does exist. Besides, it states: "For complete details about the stat(), fstat() and lstat() calls, consult the documentation for your system." I suggest to add some pointers on what systems one might consult what documentation: "(e.g., on GNU/Linux invoke 'man 2 stat')" I don't know about other systems, though. So, doing "man 2 stat", which refers to the POSIX standard and which seems to have served as blueprint for stat's interface, I expected to find the bit mask S_IFMT. However, that does not exist. In contrast, in stat.py that bit mask is hard-coded as 0o170000 in the definition of S_IFMT(). As long-term, backwards-incompatible fix, I suggest to export S_IFMT = 0o170000 and to rename the function S_IFMT(). That way, stat would in fact be aligned with the documentation for my system. As short-term fix, I suggest to correct stat.rst. Replace > Use of the functions above is more portable than use of the first > set of flags: > > stat.S_IFMT > Bit mask for the file type bit fields. with > Use of the functions above may be more portable than use of the > first set of flags. > > Warning: Note that the stat module does not export a bit mask > S_IFMT. (As stated incorrectly in previous versions of the > documentation.) Here, I replaced "is more portable" with "may be more portable" as the constant 0o170000 is hard-coded into S_IFMT() in stat.py. Maybe somebody could add a hint in what sense portability is improved? Alternatively that sentence could be deleted. A diff for stat.rst (Python 3.3.0) is attached. ---------- assignee: docs at python components: Documentation files: stat.rst.diff keywords: patch messages: 179687 nosy: docs at python, lechten priority: normal severity: normal status: open title: Documentation for stat.S_IFMT inconsistent type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file28697/stat.rst.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 16:34:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 15:34:31 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357918471.87.0.0848851025505.issue16829@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is not so easy. The problem is that we have to determine the print command by configuration line. A user may wish to change these settings, and some users already changed them. The patch should not break them. For backward compatibility we also have to run a command with a shell, not directly. A method of quoting of command arguments varies in the different systems and it differs from Python's repr. The new code should work in case if the user has not changed the default settings, and in case he changed them (for example when he replaced %%s to "%%s"). Definitely, this is not an easy issue. ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 16:56:50 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 15:56:50 +0000 Subject: [issue1634034] Show "expected" token on syntax error Message-ID: <1357919810.52.0.101571746066.issue1634034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Hmm, "expected" attribute is set when there is only one possible expected token in PyParser_AddToken(). I don't understand why error messages are so misleading for "def f(*23):" (here not only ')', but a name possible). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 16:57:16 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 11 Jan 2013 15:57:16 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357919836.85.0.821087176686.issue16829@psf.upfronthosting.co.za> Ramchandra Apte added the comment: @Serhiy Storchaka I don't think anybody edits that line anyway. IMHO, a warning about this change should be enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:04:33 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:04:33 +0000 Subject: [issue3170] test_pydoc has no way to regenerate pristine data In-Reply-To: <1214106427.35.0.304484848957.issue3170@psf.upfronthosting.co.za> Message-ID: <1357920273.66.0.590240574774.issue3170@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:06:01 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:06:01 +0000 Subject: [issue9716] The inittab modules cannot be packages In-Reply-To: <1283192897.9.0.714463074092.issue9716@psf.upfronthosting.co.za> Message-ID: <1357920361.17.0.103044989995.issue9716@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:07:15 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:07:15 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1357920435.19.0.00643048452726.issue10544@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:07:32 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:07:32 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1357920452.55.0.495461991338.issue10544@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:09:41 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 16:09:41 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357920581.19.0.777406796344.issue16829@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: At least one who want print filenames on non-default printer must edit that line. In any case we can't break this in a bugfix release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:17:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 16:17:44 +0000 Subject: [issue16624] subprocess.check_output should allow specifying stdin as a string In-Reply-To: <1354748057.02.0.623269532787.issue16624@psf.upfronthosting.co.za> Message-ID: <1357921064.33.0.541586855307.issue16624@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Zack, can you please resend your agreement by email? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:18:00 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 16:18:00 +0000 Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS In-Reply-To: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za> Message-ID: <3YjTkv6ksGzPHs@mail.python.org> Roundup Robot added the comment: New changeset acce13a6e728 by Brett Cannon in branch 'default': Issue #3583: mention that testing whether a bad address not triggering http://hg.python.org/cpython/rev/acce13a6e728 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:18:15 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:18:15 +0000 Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS In-Reply-To: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za> Message-ID: <1357921095.37.0.963560150532.issue3583@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:18:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 16:18:17 +0000 Subject: [issue12004] PyZipFile.writepy gives internal error on syntax errors In-Reply-To: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za> Message-ID: <1357921097.32.0.043283648708.issue12004@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ben, can you please resend your agreement? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:19:08 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:19:08 +0000 Subject: [issue8915] Use locale.nl_langinfo in _strptime In-Reply-To: <1275795309.62.0.41465361185.issue8915@psf.upfronthosting.co.za> Message-ID: <1357921148.28.0.924734503052.issue8915@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:20:51 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:20:51 +0000 Subject: [issue2267] datetime.datetime operator methods are not subclass-friendly In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> Message-ID: <1357921251.42.0.249070584687.issue2267@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:21:01 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Jan 2013 16:21:01 +0000 Subject: [issue16814] use --directory option of make in describing how to build the docs In-Reply-To: <1356790311.86.0.00498941541992.issue16814@psf.upfronthosting.co.za> Message-ID: <1357921261.78.0.596160822399.issue16814@psf.upfronthosting.co.za> ?ric Araujo added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:21:34 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Jan 2013 16:21:34 +0000 Subject: [issue16874] setup.py upload option repeated in docs In-Reply-To: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za> Message-ID: <1357921294.75.0.989631579427.issue16874@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:22:17 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Jan 2013 16:22:17 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1357921337.18.0.286541308676.issue16893@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:22:58 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Jan 2013 16:22:58 +0000 Subject: [issue13934] sqlite3 test typo In-Reply-To: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za> Message-ID: <1357921378.63.0.197875138049.issue13934@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report and patches! ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:23:41 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:23:41 +0000 Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip, genericpath, gettext In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za> Message-ID: <1357921421.33.0.616730056221.issue10895@psf.upfronthosting.co.za> Brett Cannon added the comment: While I appreciate the effort, SilentGhost, I'm going to make a call and say Raymond is right; this isn't worth the code breakage. While all new code should make sure to use the underscore prefix, proactively adding it to pre-existing code just isn't worth the risk. ---------- resolution: -> wont fix status: open -> closed versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:27:35 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:27:35 +0000 Subject: [issue10894] Making stdlib APIs private In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za> Message-ID: <1357921655.62.0.350248274947.issue10894@psf.upfronthosting.co.za> Brett Cannon added the comment: So I just closed the dependency on this issue as I figured the potential code breakage wasn't worth this (plus the referenced TODO item from the devguide is gone and was never turned into a proper task). Now the question becomes do the guidelines SilentGhost wrote out belong somewhere in the docs? ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python stage: -> needs patch versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:29:12 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Jan 2013 16:29:12 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1357921752.22.0.942889747261.issue16935@psf.upfronthosting.co.za> ?ric Araujo added the comment: FTR there is already an alternative to setupmodule: try: import module except ImportError: module = None @unittest.skipUnless(module, 'requires module') class ModuleTests(unittest.TestCase): pass This idiom is more lines than support.import_module, but works for non-stdlib tests too, and is useful when you don?t want the whole file to be skipped if the module is missing (like in distutils? test_sdist where zlib can be missing). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:31:13 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:31:13 +0000 Subject: [issue10541] regrtest.py -T broken In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za> Message-ID: <1357921873.98.0.715378233338.issue10541@psf.upfronthosting.co.za> Brett Cannon added the comment: Alexander's patch LGTM ---------- assignee: -> belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:31:42 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:31:42 +0000 Subject: [issue10991] trace fails when test imported a temporary file In-Reply-To: <1295825472.67.0.685273364418.issue10991@psf.upfronthosting.co.za> Message-ID: <1357921902.26.0.99345871395.issue10991@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:32:15 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:32:15 +0000 Subject: [issue10708] Misc/porting should be folded into the development FAQ or the devguide In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za> Message-ID: <1357921935.08.0.142446667743.issue10708@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:35:11 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 16:35:11 +0000 Subject: [issue969718] BASECFLAGS are not passed to module build line Message-ID: <1357922111.94.0.705492502249.issue969718@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:41:23 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2013 16:41:23 +0000 Subject: [issue16932] urlparse fails at parsing "www.python.org:80/" In-Reply-To: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za> Message-ID: <1357922483.9.0.695384548523.issue16932@psf.upfronthosting.co.za> Georg Brandl added the comment: This is not a bug: urlparse is there to parse URLs, and URLs start with an URL scheme such as "http:". There is no way for a generic URL parser to know that "python.org:80/" is supposed to be "http://python.org:80/". ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 17:59:02 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 11 Jan 2013 16:59:02 +0000 Subject: [issue16933] argparse: remove magic from examples In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za> Message-ID: <1357923542.6.0.117994403459.issue16933@psf.upfronthosting.co.za> Ramchandra Apte added the comment: +1 ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:06:19 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 17:06:19 +0000 Subject: [issue11441] compile() raises SystemError if called from except clause In-Reply-To: <1299601484.28.0.341696706995.issue11441@psf.upfronthosting.co.za> Message-ID: <1357923979.56.0.760952113924.issue11441@psf.upfronthosting.co.za> Brett Cannon added the comment: This no longer seems to be a problem in Python 3.2, 3.3, or 3.4. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:11:37 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 17:11:37 +0000 Subject: [issue10401] Globals / builtins cache In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za> Message-ID: <1357924297.53.0.144251271504.issue10401@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:11:50 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 17:11:50 +0000 Subject: [issue10399] AST Optimization: inlining of function calls In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za> Message-ID: <1357924310.45.0.0875222951815.issue10399@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:13:39 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 17:13:39 +0000 Subject: [issue11844] Update json to upstream simplejson latest release In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za> Message-ID: <1357924419.25.0.666800514328.issue11844@psf.upfronthosting.co.za> Brett Cannon added the comment: What is the status of this, Sandro? Are we still out of sync? If so and it's a licensing issue I can get legal clarification for whatever we need. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:14:31 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 17:14:31 +0000 Subject: [issue11276] 2to3: imports fixer doesn't update references to modules specified without attributes In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za> Message-ID: <1357924471.22.0.810929863453.issue11276@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:14:55 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Jan 2013 17:14:55 +0000 Subject: [issue16879] distutils.command.config uses fragile constant temporary file name In-Reply-To: <1357476277.46.0.0647034504115.issue16879@psf.upfronthosting.co.za> Message-ID: <1357924495.7.0.367516742814.issue16879@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. Did you find this by looking at the code or while using distutils? In other words, if this is just a theoretical issue / code quality problem, it won?t be changed. (distutils is not improved anymore.) ---------- versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:16:55 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Jan 2013 17:16:55 +0000 Subject: [issue16916] The Extended Iterable Unpacking (PEP-3132) for byte strings doesn't match the specification In-Reply-To: <1357826895.67.0.646270991721.issue16916@psf.upfronthosting.co.za> Message-ID: <1357924615.98.0.90237354057.issue16916@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:26:11 2013 From: report at bugs.python.org (Roger Serwy) Date: Fri, 11 Jan 2013 17:26:11 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357925171.82.0.962182831258.issue16829@psf.upfronthosting.co.za> Roger Serwy added the comment: @Serhiy IDLE places its default configuration files within the standard library. Any upgrade of Python can modify the contents of the standard library. Even if we do *nothing* to change Lib/idlelib/config-main.def, the next upgrade would overwrite an end users custom print command anyway. Now, if the end-user changed ~/.idlerc/config-main.cfg instead to include the new "print-command-posix" entry then this patch will not change their custom setting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:32:46 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 11 Jan 2013 17:32:46 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1357925566.35.0.229871190171.issue16893@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I like the proposition in general, but files should be synchronized first. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:35:52 2013 From: report at bugs.python.org (Sandro Tosi) Date: Fri, 11 Jan 2013 17:35:52 +0000 Subject: [issue16932] urlparse fails at parsing "www.python.org:80/" In-Reply-To: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za> Message-ID: <1357925752.81.0.590648602602.issue16932@psf.upfronthosting.co.za> Sandro Tosi added the comment: The documentation reports this example: >>> urlparse('www.cwi.nl:80/%7Eguido/Python.html') ParseResult(scheme='', netloc='', path='www.cwi.nl:80/%7Eguido/Python.html', params='', query='', fragment='') but when executing it returns: $ ./python -V Python 2.7.3+ $ ./python -c "from urlparse import urlparse ; print urlparse('www.cwi.nl:80/%7Eguido/Python.html')" ParseResult(scheme='www.cwi.nl', netloc='', path='80/%7Eguido/Python.html', params='', query='', fragment='') which doesn't match. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:38:00 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2013 17:38:00 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1357925880.98.0.77083428628.issue16893@psf.upfronthosting.co.za> Georg Brandl added the comment: Note that Sphinx' "make text" output already should be suitable. We already update the pydoc topics with that on every release, so we could just as well do the same for the IDLE doc. No need for another separate script. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:43:24 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 11 Jan 2013 17:43:24 +0000 Subject: [issue16715] Get rid of IOError. Use OSError instead In-Reply-To: <3YW0Xs2j15zRkN@mail.python.org> Message-ID: <1357926204.15.0.484646190375.issue16715@psf.upfronthosting.co.za> Andrew Svetlov added the comment: LoadError was IOError descendant, now OSError is directly specified. If somebody want to change base class for LoadError he should to update the code in several places in http/cookiejar.py. The docstring for FileCookieJar.revert directly specifies possible exceptions btw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 18:54:19 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2013 17:54:19 +0000 Subject: [issue16932] urlparse fails at parsing "www.python.org:80/" In-Reply-To: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za> Message-ID: <1357926859.42.0.981504662198.issue16932@psf.upfronthosting.co.za> Georg Brandl added the comment: Hmm, you're right. The behavior has been like this at least since Python 2.5: Python 2.5.4 (r254:67916, Dec 16 2012, 20:33:12) [GCC 4.6.3] on linux3 Type "help", "copyright", "credits" or "license" for more information. >>> from urlparse import urlparse >>> urlparse('www.cwi.nl:80/%7Eguido/Python.html') ('www.cwi.nl', '', '80/%7Eguido/Python.html', '', '', '') The docs refer to RFC 1808. From a quick glance at the BNF in section 2.2, RFC 1808 allows dots in the scheme, but also allows ":" in the path. So there seems to be a parsing ambiguity, but see section 2.4.2: If the parse string contains a colon ":" after the first character and before any characters not allowed as part of a scheme name (i.e., any not an alphanumeric, plus "+", period ".", or hyphen "-"), the of the URL is the substring of characters up to but not including the first colon. These characters and the colon are then removed from the parse string before continuing. That would indicate that the implementation is correct and the documentation should be fixed. Senthil? ---------- keywords: +buildbot -patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:07:32 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 18:07:32 +0000 Subject: [issue16916] The Extended Iterable Unpacking (PEP-3132) for byte strings doesn't match the specification In-Reply-To: <1357826895.67.0.646270991721.issue16916@psf.upfronthosting.co.za> Message-ID: <3YjX9F56bczP5Y@mail.python.org> Roundup Robot added the comment: New changeset a0077c1d201d by Georg Brandl in branch 'default': Closes #16916: clarify "slicing equivalent to extended unpacking" example: the latter always creates a list. http://hg.python.org/peps/rev/a0077c1d201d ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:08:37 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2013 18:08:37 +0000 Subject: [issue16916] The Extended Iterable Unpacking (PEP-3132) for byte strings doesn't match the specification In-Reply-To: <1357826895.67.0.646270991721.issue16916@psf.upfronthosting.co.za> Message-ID: <1357927717.26.0.753311461773.issue16916@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report. This statement was actually false for almost all sequence types, except for those whose slicing returns a list. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:12:44 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2013 18:12:44 +0000 Subject: [issue16924] try: except: ordering error In-Reply-To: <1357869986.79.0.0900594167753.issue16924@psf.upfronthosting.co.za> Message-ID: <1357927964.94.0.286082438304.issue16924@psf.upfronthosting.co.za> Georg Brandl added the comment: If I understand your issue correctly, you are expecting all three exception handlers to be called in innermost-to-outermost order. However, exceptions are not reraised automatically after "except" blocks; you can insert a bare "raise" statement in the handler to get that effect. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:17:42 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2013 18:17:42 +0000 Subject: [issue4350] Remove dead code from Tkinter.py In-Reply-To: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za> Message-ID: <1357928262.1.0.749239076694.issue4350@psf.upfronthosting.co.za> Georg Brandl added the comment: This kind of change is very similar to other "cleanup" changes, so the classification of "not a bug fix" seems valid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:18:58 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 18:18:58 +0000 Subject: [issue16933] argparse: remove magic from examples In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za> Message-ID: <1357928338.91.0.440281616682.issue16933@psf.upfronthosting.co.za> Chris Jerdonek added the comment: +1. By the way, I included a couple fixes similar to these in a patch posted to issue 16878. ---------- nosy: +bethard, chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:20:32 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 18:20:32 +0000 Subject: [issue16933] argparse: remove magic from examples In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za> Message-ID: <1357928432.88.0.0426984409651.issue16933@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:22:02 2013 From: report at bugs.python.org (Martijn Pieters) Date: Fri, 11 Jan 2013 18:22:02 +0000 Subject: [issue16937] -u (unbuffered I/O) command line option documentation mismatch for sys.stdin Message-ID: <1357928522.67.0.838908652159.issue16937@psf.upfronthosting.co.za> New submission from Martijn Pieters: Run `python3.3 -h` and the `-u` option is documented as: > -u : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x > see man page for details on internal buffering relating to '-u' Note that only `stdout` and `stderr` are mentioned. The online documentation at http://docs.python.org/3/using/cmdline.html#cmdoption-u doesn't agree: > ... the binary layer of the stdin, stdout and stderr streams ... nor does `man python3.3`, which claims: > -u Force the binary I/O layers of stdin, stdout and stderr to be unbuffered. The text I/O layer will still > be line-buffered. So, is `stdin` going to be unbuffered, or not, when using `-u`? Running a simple test shows that `stdin` is firmly being buffered regardless of the `-u` switch: $ python3.3 -c 'import sys; print(sys.stdin.buffer, sys.stdout.buffer)' <_io.BufferedReader name=''> <_io.BufferedWriter name=''> $ python3.3 -u -c 'import sys; print(sys.stdin.buffer, sys.stdout.buffer)' <_io.BufferedReader name=''> <_io.FileIO name='' mode='wb'> I'll presume here that `stdin` is deliberately buffered, regardless, and that the documentation and man page are out of date here (in python 2, `-u` does include `stdin`). ---------- assignee: docs at python components: Documentation messages: 179718 nosy: docs at python, mjpieters priority: normal severity: normal status: open title: -u (unbuffered I/O) command line option documentation mismatch for sys.stdin versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:25:11 2013 From: report at bugs.python.org (Bob Ippolito) Date: Fri, 11 Jan 2013 18:25:11 +0000 Subject: [issue11844] Update json to upstream simplejson latest release In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za> Message-ID: <1357928711.85.0.193291585235.issue11844@psf.upfronthosting.co.za> Bob Ippolito added the comment: To try and make this as painless as possible I have done both things. simplejson is now explicitly dual-licensed MIT or AFL v2.1 and there is also an explicit sentence in LICENSE.txt that states "This code is also licensed to the Python Software Foundation (PSF) under a Contributor Agreement." simplejson v3.0.7 (tag v3.0.7 in the repo) is this version. If there's anything more I can do to help, please let me know. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:26:03 2013 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 Jan 2013 18:26:03 +0000 Subject: [issue16930] mention limitations and/or alternatives to hg graft In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za> Message-ID: <1357928763.36.0.802311650075.issue16930@psf.upfronthosting.co.za> Ned Deily added the comment: Keep in mind that the issue isn't which operating system is used; it's whether the file system(s) on which the hg repo resides is (are) case-insensitive or case-sensitive. Most modern operating systems (including OS X) support both file system types and on Unix-y systems, at least, you can even encounter a mixture of case-sensitive and -insensitive file systems within a particular absolute path, i.e. if the path includes mount points to different file systems. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 19:36:05 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 11 Jan 2013 18:36:05 +0000 Subject: [issue16937] -u (unbuffered I/O) command line option documentation mismatch for sys.stdin In-Reply-To: <1357928522.67.0.838908652159.issue16937@psf.upfronthosting.co.za> Message-ID: <1357929365.09.0.266899930883.issue16937@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 20:24:36 2013 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Fri, 11 Jan 2013 19:24:36 +0000 Subject: [issue16879] distutils.command.config uses fragile constant temporary file name In-Reply-To: <1357476277.46.0.0647034504115.issue16879@psf.upfronthosting.co.za> Message-ID: <1357932276.62.0.87267819571.issue16879@psf.upfronthosting.co.za> Micha? G?rny added the comment: While using. We run parallel merges with out-of-source builds in Gentoo, and I found this to result in a failure when building the 'egenix-mx-base' package [1] which uses the 'config' command. [1]:http://pypi.python.org/pypi/egenix-mx-base ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 20:26:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 19:26:01 +0000 Subject: [issue16936] Documentation for stat.S_IFMT inconsistent In-Reply-To: <1357918282.52.0.0217764551769.issue16936@psf.upfronthosting.co.za> Message-ID: <3YjYvr0sFXzS9y@mail.python.org> Roundup Robot added the comment: New changeset 0d7a8a4d6f30 by Georg Brandl in branch '2.7': Closes #16936: fix duplicate/ambiguous description of stat.S_IFMT in the docs. http://hg.python.org/cpython/rev/0d7a8a4d6f30 New changeset 3555391a9909 by Georg Brandl in branch '3.3': Closes #16936: fix duplicate/ambiguous description of stat.S_IFMT in the docs. http://hg.python.org/cpython/rev/3555391a9909 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 20:57:16 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Fri, 11 Jan 2013 19:57:16 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357934236.9.0.261854136233.issue16886@psf.upfronthosting.co.za> Frank Wierzbicki added the comment: I'd love to work through the commit process myself once I get through all of the comments. My intention is to become much more active here as Jython3 starts to ramp up over the next year. It would be great if I could eventually get all of Jython's .py files into CPython's Lib (as has been discussed at previous PyCons). Getting all of the tests here would be a solid step in that direction. My plan is to go through this review process for the near future but do the commits myself. Just to be sure the 4 branches are 2.7, 3.3, 3.4 and default? And can I merge safely from 2.7 to 3.3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:23:43 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 20:23:43 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <3YjbBP3yQjzS4V@mail.python.org> Roundup Robot added the comment: New changeset 2d0c5f97af48 by Serhiy Storchaka in branch '2.7': Issue #15539: Fix backup file creation in pindent.py on Windows http://hg.python.org/cpython/rev/2d0c5f97af48 New changeset a9990104f728 by Serhiy Storchaka in branch '3.2': Issue #15539: Fix a backup file creation in pindent.py on Windows. http://hg.python.org/cpython/rev/a9990104f728 New changeset 735361e8709e by Serhiy Storchaka in branch '3.3': Issue #15539: Fix a backup file creation in pindent.py on Windows. http://hg.python.org/cpython/rev/735361e8709e New changeset c46dec051819 by Serhiy Storchaka in branch 'default': Issue #15539: Fix a backup file creation in pindent.py on Windows. http://hg.python.org/cpython/rev/c46dec051819 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:27:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 20:27:35 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1357936055.27.0.722679666594.issue15539@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I?hope it will help buidbots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:33:33 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 11 Jan 2013 20:33:33 +0000 Subject: [issue16933] argparse: remove magic from examples In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za> Message-ID: <1357936413.73.0.81745563466.issue16933@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Patch attached. ---------- assignee: -> docs at python components: +Documentation keywords: +easy, patch nosy: +docs at python stage: needs patch -> patch review Added file: http://bugs.python.org/file28698/issue-16933-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:34:25 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2013 20:34:25 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357936465.33.0.392062512223.issue16613@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Put a *versionchanged* tag in the doc entry and this is ready to apply. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:35:12 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2013 20:35:12 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357936512.06.0.142349081576.issue16613@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:45:12 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 20:45:12 +0000 Subject: [issue16730] _fill_cache in _bootstrap.py crashes without directory execute permissions In-Reply-To: <1355928901.47.0.243119596238.issue16730@psf.upfronthosting.co.za> Message-ID: <3YjbgC4LSBzS8m@mail.python.org> Roundup Robot added the comment: New changeset 159967aa24a5 by Brett Cannon in branch '3.3': Issue #16730: Don't raise an exception in http://hg.python.org/cpython/rev/159967aa24a5 New changeset b94f308e9b47 by Brett Cannon in branch 'default': Merge from 3.3 for fix for issue #16730 http://hg.python.org/cpython/rev/b94f308e9b47 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:45:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 20:45:19 +0000 Subject: [issue4350] Remove dead code from Tkinter.py In-Reply-To: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za> Message-ID: <1357937119.58.0.128286097658.issue4350@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> commit review type: behavior -> enhancement versions: -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:46:09 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 20:46:09 +0000 Subject: [issue16730] _fill_cache in _bootstrap.py crashes without directory execute permissions In-Reply-To: <1355928901.47.0.243119596238.issue16730@psf.upfronthosting.co.za> Message-ID: <1357937169.05.0.216756746946.issue16730@psf.upfronthosting.co.za> Brett Cannon added the comment: Tests added for both the file and unreadable cases and the appropriate exceptions now caught. Thanks to everyone for helping with this! ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:46:37 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 20:46:37 +0000 Subject: [issue10965] dev task of documenting undocumented APIs In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za> Message-ID: <1357937197.87.0.980964748322.issue10965@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: brett.cannon -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:48:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 20:48:43 +0000 Subject: [issue11844] Update json to upstream simplejson latest release In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za> Message-ID: <1357937323.6.0.367108849546.issue11844@psf.upfronthosting.co.za> Brett Cannon added the comment: Short of doing an actual merge I don't think so, Bob. Thanks for the changes! Sandro, feel free to do any merge you were planning to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:49:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Jan 2013 20:49:18 +0000 Subject: [issue4350] Remove dead code from Tkinter.py In-Reply-To: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za> Message-ID: <1357937358.63.0.555689414674.issue4350@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Tkinter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:51:43 2013 From: report at bugs.python.org (Jason Huntley) Date: Fri, 11 Jan 2013 20:51:43 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1357937503.26.0.290031360909.issue3871@psf.upfronthosting.co.za> Jason Huntley added the comment: Finally! I was able to get all building on mingw64, gcc 4.7.2, and python 3.3. I had to take everybody's work here a little further, and I have produced a new patch which will build python33 using the latest minw64 compiler in an msys environment. I cloned the 3.3 branch and applied the latest patch available here, py3k-20121004-MINGW.patch. I had to make quite a few more updates to get all the modules compiling with 4.7.2 and python find all the modules in the correct paths in an msys/mingw64 environment. I've compiled another patch, which addresses all the latest issues. For all interested, run my setup script from the following location: https://github.com/onepremise/MinGW-AD64S/ Just open dos in admin mode and run setup.bat. This will build all the required dependencies and finally python 3.3. ---------- Added file: http://bugs.python.org/file28699/py3k-20121227-MINGW.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:52:54 2013 From: report at bugs.python.org (Jason Huntley) Date: Fri, 11 Jan 2013 20:52:54 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1357937574.25.0.905136009957.issue3871@psf.upfronthosting.co.za> Jason Huntley added the comment: Hey Guys, I've furthered the progress of the patch I've been working on. THis patch builds Python3.3 in mingw64 & msys using gcc 4.7.2 compiler. This patch can also enable and build the following modules: ctypes bz2 multiprocessing sqlite3 ssl pyexpat zlib Of course, there are many others, but these were some of the problem modules I encounted previously. Partial success running the python tests. Many of the basic tests pass, I still have many to resolve. I have one thread test failing I need to resolve as it's preventing from all the tests running. Regardless, seems like some progress. >>I think it would be great if everyone could collaborate better with this stuff; I agree; I would really like for us to make this a joint effort. However, I'm noticing a ton of descrepancies with these patches. Some are removing pthreads, others are adding them back. Some patches are ignoring the PC/pyconfig while others are trying to generate a custom mingw version. It seems some are also compiling and using the mingw version outside of the msys shell, which I'm not certain of the advantages there when u can just use the mscv version. I think we need to take a minute to agree on some specific goals and criteria this mingw port should be used for. Just to kick things off, here are some of the requirements which I think we should aim for. * The build must be reproducible in the mingw msys shell, in the default environment described on the mingw64 site, also included some other good doc references: * https://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS * https://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler * http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html#env * These documented steps have also been automated by the sripts here https://github.com/onepremise/MinGW-AD64S * Currently, I have the mingw build using the PC platform specified config headers and source. * too many issues reside around enabling posix threads as the pthread_t identifier in mingw doesn't match existing py thread framework returning longs. * As a result, the patch I provided builds with the ntthread implementation. * In addition, PC/pyconfig.h and PC/getpath.c are being used with slight modifications for __MINGW32__ * Initial python mingw64 deployment layout, version identifiers should follow existing scheme, "3.3" not 33: * should deploy libraries to /mingw/lib, libpython3.3.a, Format: libpython3.3.dll, libpython3.3.dll.a. * executable binaries should exist in /mingw/bin. Format: python.exe, python3.3.exe. * The python script library deploys to /mingw/lib/Python3.3. * /mingw/lib/Python3.3/lib-dynload * /mingw/lib/Python3.3/site-packates * Headers located /mingw/include/Python3.3 * Having Python build isn't satisfactory enough to promote a patch, patches should not cause new test failures or regressions. Preferably they should resolve core compilation issues and module compilation issues, while not creating new test failures and preferrably address/fix failing tests. (python -m test) * covered on the dev-guilde, http://docs.python.org/devguide/ Please feel free to contriube, update, remove, discuss etc... >>https://github.com/mingwandroid/crucifixion-freedom/tree/master/patches/python/3.3.0 [Python cross and MinGW compilation] >>https://github.com/niXman/mingw-builds/tree/master/patches/Python-3.3.0 [MinGW toolchains including Python pretty-printing GDB] I tried some of these patches, but they aren't very organinzed. I really need some docemntaiton to better understand what each patch does and which pairs go together and which don't. Wiki over there is blank. >>in fact, just after Roumen's huge patch we apply some patches to remove large parts >>of it so we can re-introduce those independent fixes via separate patches). I had to do the same as well. There were regressions in some of these patches causing the python tests to fail and prevent the python setup.py script from running. >>Our patching strategies are more sane (many patches as opposed to a monolithic patch - >>Given how intrusive these patches are, getting them merged into CPython is a bit of a >>pipe dream (I'd love to be wrong about that), so making it as easy as possible >>for the interested parties to maintain (forward port), build, test and package >>Python releases is probably the best we can hope for. If we can make the >>patchessmall and independently reviewable then maybe some parts could be >>merged. I prefer this as well. It will make code reviewing easier. Otherwise, some kind of staging location would be useful. I'm fine using rietveld, the tracker. We just need to name the patches better, including prefix/dates or provide descriptions in the comments below. Right now it's hard to tell which patches to apply just from reading through the comments >>I would like to disagree with 'hard codded' compiler flags into python >>code. For instance -mms-bitfields is default for GCC 4.7+ . They have been removed in this patch >>Please provide more details for change in Lib/ntpath.py . Mingw msys was having issues processing the paths provided by ntpath.py. The paths being passed around have a seldom used format, which works in windows but not mingw, which is providing a drive without a path separator: C:my/path. This should be provided as C:/my/path. Either backslash or forward slash can be used, mingw doesn't care. Mingw just needs the path separator after the drive letter to make sense of the path. >>What is reasons to add more build-in modules (time, math, ...) ? python.exe setup.py build --compiler=mingw32 fails without the time and math modules enabled. Somewhere in the python script, they were being imported. >> Why is updated PC/pyconfig.h ? This is so called by python community Because mingw uses much of the same existing framworks provided by system32. >>"posix-build" and pyconfig.h is generated by configure script. Yes i noticed this too, but as I started working with configure.ac, Makefile.pre.in, and pyconfig.h, I noticed I was basically recreating the pyconfig.h file used under PC. I also noticed others using this as well in their own ports. I imagine it would be better to get the configure scripts detecting and setting evironment varialbles correctly. However, as of right now, it's far from doing so. It was quicker to just use the existing PC file and add a few defines for MINGW32. >>File configure.ac contain so many unrelated changes - replace tabs with >>spaces. Please post as separate diff you changes. I don't know what to say about the configure.ac. The file provided by the release, has both tabs in spaces as well. Whatever the standard is, it's easy to fix. >>Why is updated Lib/plat-generic/regen ? Because "/usr/include/netinet/in.h" doesn't exist in the mingw64 msys environment. This script fails in mingw. You didn't notice? >>Currently my private repository reintroduce support _sysconfigdata.py >>but this require some changes in PC/getpathp.c . I left current >>installation from makefile as is and after this with an extra script i >>move file for location same as primary build. python won't run in mys without the proper search paths being referenced in getpathp.c. The posixs getpathp.c seem to have issues well, I might have been able to get it to work if I tested more, but It was easier to just modify the PC getpathp and get everyting working. ---------- Added file: http://bugs.python.org/file28700/py3k-20130110-MINGW.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:54:28 2013 From: report at bugs.python.org (Jason Huntley) Date: Fri, 11 Jan 2013 20:54:28 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1357937668.02.0.648942384057.issue3871@psf.upfronthosting.co.za> Changes by Jason Huntley : Removed file: http://bugs.python.org/file28699/py3k-20121227-MINGW.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 21:55:23 2013 From: report at bugs.python.org (Jason Huntley) Date: Fri, 11 Jan 2013 20:55:23 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1357937723.44.0.0670920729491.issue3871@psf.upfronthosting.co.za> Jason Huntley added the comment: Hey Guys, I've furthered the progress of the patch I've been working on. THis patch builds Python3.3 in mingw64 & msys using gcc 4.7.2 compiler. This patch can also enable and build the following modules: ctypes bz2 multiprocessing sqlite3 ssl pyexpat zlib Of course, there are many others, but these were some of the problem modules I encounted previously. Partial success running the python tests. Many of the basic tests pass, I still have many to resolve. I have one thread test failing I need to resolve as it's preventing from all the tests running. Regardless, seems like some progress. >>I think it would be great if everyone could collaborate better with this stuff; I agree; I would really like for us to make this a joint effort. However, I'm noticing a ton of descrepancies with these patches. Some are removing pthreads, others are adding them back. Some patches are ignoring the PC/pyconfig while others are trying to generate a custom mingw version. It seems some are also compiling and using the mingw version outside of the msys shell, which I'm not certain of the advantages there when u can just use the mscv version. I think we need to take a minute to agree on some specific goals and criteria this mingw port should be used for. Just to kick things off, here are some of the requirements which I think we should aim for. * The build must be reproducible in the mingw msys shell, in the default environment described on the mingw64 site, also included some other good doc references: * https://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS * https://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler * http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html#env * These documented steps have also been automated by the sripts here https://github.com/onepremise/MinGW-AD64S * Currently, I have the mingw build using the PC platform specified config headers and source. * too many issues reside around enabling posix threads as the pthread_t identifier in mingw doesn't match existing py thread framework returning longs. * As a result, the patch I provided builds with the ntthread implementation. * In addition, PC/pyconfig.h and PC/getpath.c are being used with slight modifications for __MINGW32__ * Initial python mingw64 deployment layout, version identifiers should follow existing scheme, "3.3" not 33: * should deploy libraries to /mingw/lib, libpython3.3.a, Format: libpython3.3.dll, libpython3.3.dll.a. * executable binaries should exist in /mingw/bin. Format: python.exe, python3.3.exe. * The python script library deploys to /mingw/lib/Python3.3. * /mingw/lib/Python3.3/lib-dynload * /mingw/lib/Python3.3/site-packates * Headers located /mingw/include/Python3.3 * Having Python build isn't satisfactory enough to promote a patch, patches should not cause new test failures or regressions. Preferably they should resolve core compilation issues and module compilation issues, while not creating new test failures and preferrably address/fix failing tests. (python -m test) * covered on the dev-guilde, http://docs.python.org/devguide/ Please feel free to contriube, update, remove, discuss etc... >>https://github.com/mingwandroid/crucifixion-freedom/tree/master/patches/python/3.3.0 [Python cross and MinGW compilation] >>https://github.com/niXman/mingw-builds/tree/master/patches/Python-3.3.0 [MinGW toolchains including Python pretty-printing GDB] I tried some of these patches, but they aren't very organinzed. I really need some docemntaiton to better understand what each patch does and which pairs go together and which don't. Wiki over there is blank. >>in fact, just after Roumen's huge patch we apply some patches to remove large parts >>of it so we can re-introduce those independent fixes via separate patches). I had to do the same as well. There were regressions in some of these patches causing the python tests to fail and prevent the python setup.py script from running. >>Our patching strategies are more sane (many patches as opposed to a monolithic patch - >>Given how intrusive these patches are, getting them merged into CPython is a bit of a >>pipe dream (I'd love to be wrong about that), so making it as easy as possible >>for the interested parties to maintain (forward port), build, test and package >>Python releases is probably the best we can hope for. If we can make the >>patchessmall and independently reviewable then maybe some parts could be >>merged. I prefer this as well. It will make code reviewing easier. Otherwise, some kind of staging location would be useful. I'm fine using rietveld, the tracker. We just need to name the patches better, including prefix/dates or provide descriptions in the comments below. Right now it's hard to tell which patches to apply just from reading through the comments >>I would like to disagree with 'hard codded' compiler flags into python >>code. For instance -mms-bitfields is default for GCC 4.7+ . They have been removed in this patch >>Please provide more details for change in Lib/ntpath.py . Mingw msys was having issues processing the paths provided by ntpath.py. The paths being passed around have a seldom used format, which works in windows but not mingw, which is providing a drive without a path separator: C:my/path. This should be provided as C:/my/path. Either backslash or forward slash can be used, mingw doesn't care. Mingw just needs the path separator after the drive letter to make sense of the path. >>What is reasons to add more build-in modules (time, math, ...) ? python.exe setup.py build --compiler=mingw32 fails without the time and math modules enabled. Somewhere in the python script, they were being imported. >> Why is updated PC/pyconfig.h ? This is so called by python community Because mingw uses much of the same existing framworks provided by system32. >>"posix-build" and pyconfig.h is generated by configure script. Yes i noticed this too, but as I started working with configure.ac, Makefile.pre.in, and pyconfig.h, I noticed I was basically recreating the pyconfig.h file used under PC. I also noticed others using this as well in their own ports. I imagine it would be better to get the configure scripts detecting and setting evironment varialbles correctly. However, as of right now, it's far from doing so. It was quicker to just use the existing PC file and add a few defines for MINGW32. >>File configure.ac contain so many unrelated changes - replace tabs with >>spaces. Please post as separate diff you changes. I don't know what to say about the configure.ac. The file provided by the release, has both tabs in spaces as well. Whatever the standard is, it's easy to fix. >>Why is updated Lib/plat-generic/regen ? Because "/usr/include/netinet/in.h" doesn't exist in the mingw64 msys environment. This script fails in mingw. You didn't notice? >>Currently my private repository reintroduce support _sysconfigdata.py >>but this require some changes in PC/getpathp.c . I left current >>installation from makefile as is and after this with an extra script i >>move file for location same as primary build. python won't run in mys without the proper search paths being referenced in getpathp.c. The posixs getpathp.c seem to have issues well, I might have been able to get it to work if I tested more, but It was easier to just modify the PC getpathp and get everyting working. ---------- Added file: http://bugs.python.org/file28701/py3k-20130110-MINGW.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 22:00:25 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 11 Jan 2013 21:00:25 +0000 Subject: [issue16931] mention work-around to create diffs in default/non-git mode In-Reply-To: <1357894611.9.0.235167303817.issue16931@psf.upfronthosting.co.za> Message-ID: <1357938025.86.0.797520232365.issue16931@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 23:05:47 2013 From: report at bugs.python.org (Ben Morgan) Date: Fri, 11 Jan 2013 22:05:47 +0000 Subject: [issue12004] PyZipFile.writepy gives internal error on syntax errors In-Reply-To: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za> Message-ID: <1357941947.45.0.234085180004.issue12004@psf.upfronthosting.co.za> Ben Morgan added the comment: I've sent it again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 23:14:18 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2013 22:14:18 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <1357942458.1.0.557296262553.issue16613@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Also, please change the variable name from *amap* to either *m* or *mapping*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 23:26:11 2013 From: report at bugs.python.org (Sven Brauch) Date: Fri, 11 Jan 2013 22:26:11 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357943171.06.0.508468568889.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Not an issue, having this thing resolved upstream would save a huge lot of pain elsewhere. ;) So, to make sure... I'll go to the asdl file, make arguments have two arg attributes which store the data for the var and kwarg which they can contain, then I adjust ast.c to reflect that new structure. Then I go to asdl.py and hack it so we can have attributes ( ... ) on arguments. Does that sound correct? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 23:42:10 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 11 Jan 2013 22:42:10 +0000 Subject: [issue16938] pydoc confused by __dir__ Message-ID: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za> New submission from Ronald Oussoren: If a class implements __dir__ to also return a number of attributes that aren't present in the class __dict__ inspect.classify_class_attrs gets confused and assumes the home class is None. This in turn confused pydoc, docclass in pydoc assumes that the 'class' slot in the sequence returned by classify_class_attrs is actually a class and fails when it None (because None doesn't have a __name__ attribute). I've classified this as "low" because I've found a useable workaround: I have implemented a "__objclass__" property for my custom descriptor and with that pydoc works. It would be nice if pydoc wouldn't crash on this. One possible workaround: assume that the class is the inspected class when a name returned by dir(cls) cannot be found in one of the classes on the mro. I'll provide a patch if this would be acceptable behavior. ---------- components: Library (Lib) messages: 179738 nosy: ronaldoussoren priority: low severity: normal stage: test needed status: open title: pydoc confused by __dir__ type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 23:43:46 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2013 22:43:46 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1357944226.67.0.134966521839.issue16398@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The easiest change would essentially involve inlining the code for append/appendleft and then removing unneeded steps (the state update, the INCREF/DECREF of item, and the TRIM() test). Of these, the INCREF/DECREF is likely to be a nice win because we can rotate without visiting all the underlying objects (each of which would likely be a cache-line miss). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 23:44:03 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Jan 2013 22:44:03 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1357944243.42.0.0937499815002.issue16398@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg179666 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 23:46:07 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Fri, 11 Jan 2013 22:46:07 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357944367.77.0.849350893503.issue16886@psf.upfronthosting.co.za> Frank Wierzbicki added the comment: > Well, we generally prefer to go through the review process always, except for relatively small commits (which some of yours may be). Good to know, in that case I'll plan to go through the review process always. > 2.7 is separate from 3.x. So to commit to all four branches you commit to 3.2, merge to 3.3, merge to default, and the graft to 2.7. (Myself, I'm still using patch to do the 2.7 updates, I haven't tried graft yet.) When you say "use patch" to do the 2.7 update - do you mean a manual patch? I'm not ready to look into graft and would prefer to just do the regular thing for now. > (In theory this should all be in the devguide...) I'll definitely be reading the devguide as I prepare to push my changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 11 23:47:46 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 Jan 2013 22:47:46 +0000 Subject: [issue16937] -u (unbuffered I/O) command line option documentation mismatch for sys.stdin In-Reply-To: <1357928522.67.0.838908652159.issue16937@psf.upfronthosting.co.za> Message-ID: <1357944466.59.0.778719352347.issue16937@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, stdin is always buffered, simply because it doesn't make a difference (except if you're trying to read raw data from fd 0). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 00:09:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 23:09:34 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <3Yjfsn0zX4zSB8@mail.python.org> Roundup Robot added the comment: New changeset a4292889e942 by Brett Cannon in branch 'default': Issue #15031: Refactor some code in importlib pertaining to validating http://hg.python.org/cpython/rev/a4292889e942 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 00:14:15 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jan 2013 23:14:15 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1357946055.54.0.320462026595.issue15031@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, so I took Nick's suggestion of doing header verification separately from the actual compilation, but I ended up just writing the patch from scratch to see how a possible API might play out. ATM the API is as functions and private, but if I find the need/desire to make it public (or enough ask for it) I will before 3.4 comes out. Probably will know better once I rewrite py_compile/compileall to use this code. Thanks to everyone for spending so much time talking this issue out with me. ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 00:14:44 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 11 Jan 2013 23:14:44 +0000 Subject: [issue16473] Minor difference in decoding quoted-printable text In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <1357946084.86.0.333104548013.issue16473@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 00:40:07 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Jan 2013 23:40:07 +0000 Subject: [issue16613] ChainMap.new_child could use improvement In-Reply-To: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za> Message-ID: <3YjgY170tvzS9N@mail.python.org> Roundup Robot added the comment: New changeset c0ddae67f4df by Vinay Sajip in branch 'default': Closes #16613: Added optional mapping argument to ChainMap.new_child. http://hg.python.org/cpython/rev/c0ddae67f4df ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 00:41:52 2013 From: report at bugs.python.org (John O'Connor) Date: Fri, 11 Jan 2013 23:41:52 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1357947712.68.0.579803256071.issue16398@psf.upfronthosting.co.za> John O'Connor added the comment: Looking at the implementation (rather quickly)[1]. I'm wondering if there is a reason why the appendleft(pop()) loop is required. It would seem the best way would be to determine the new head link, make the previous link the new end link and concatenate the two chains (by just swapping some pointers). [1]. http://hg.python.org/cpython/file/a4292889e942/Modules/_collectionsmodule.c#l429 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 01:01:30 2013 From: report at bugs.python.org (py.user) Date: Sat, 12 Jan 2013 00:01:30 +0000 Subject: [issue16715] Get rid of IOError. Use OSError instead In-Reply-To: <3YW0Xs2j15zRkN@mail.python.org> Message-ID: <1357948890.23.0.570168571367.issue16715@psf.upfronthosting.co.za> py.user added the comment: Zen: Explicit is better than implicit. In the face of ambiguity, refuse the temptation to guess. I assume that someone changes the LoadError class and goes into the revert function. How he can figure out that the cookies should return to the previous state if LoadError was raised ? Before the change it was explicit and after the change it became implicit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 01:24:48 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 12 Jan 2013 00:24:48 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1357950288.48.0.840212588763.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yes. Feel free to do that in separate patches as needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 01:35:42 2013 From: report at bugs.python.org (Ed Campbell) Date: Sat, 12 Jan 2013 00:35:42 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1357950942.02.0.41759733627.issue10544@psf.upfronthosting.co.za> Changes by Ed Campbell : ---------- nosy: +esc24 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 02:02:22 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 01:02:22 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357952542.38.0.551948050161.issue16880@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Given the current (3.3) imp.py docstring """This module provides the components needed to build your own __import__ function. Undocumented functions are obsolete. In most cases it is preferred you consider using the importlib module's functionality over this module. """ I wonder why it is being imported on startup. Is this an obsolete holdover. --- The patch solves the problem of importing a non-existing load_dynamic, but - elif type_ == C_EXTENSION: + elif type_ == C_EXTENSION and load_dynamic is not None: return load_dynamic(name, filename, file) With this change, an attempt to import a C_EXTENSION file will fall through to else: msg = "Don't know how to import {} (type code {})".format(name, type_) raise ImportError(msg, name=name) Jeffery: does your m68k-atari-mint have no C_EXTENSION files, so that this will never be a problem? On my Windows system, _tkinter is one such, with the following outcome. import imp imp.load_dynamic >>> imp.load_module('tk2', *imp.find_module('_tkinter')) Traceback (most recent call last): File "", line 1, in imp.load_module('tk2', *imp.find_module('_tkinter')) File "C:\Programs\Python33\lib\imp.py", line 164, in load_module return load_dynamic(name, filename, file) TypeError: 'NoneType' object is not callable Or is this not a problem because deprecated imp.load_module is never actually used? ___ Brett: by 'expected exception', do you mean the one above? or the one that is caught by the patch? Another question: load_dynamic has a public name but is un-documented. Does that make it private enough that we can freely rebind it to None? Perhaps it does not matter since we are only doing this on machines where Python does not even start, so we won't disable a working imp.load_dynamic call if there is one somewhere (including the stdlib). ___ If imp.load_dynamic is private, then its import into imp can be removed once deprecated load_module is removed, making this issue moot. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 02:15:55 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 01:15:55 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357953354.67.0.801164834669.issue16886@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, export patch from 3.2 or 3.3 (which you need to do anyway to upload here), import patch into 2.7. Feel free to ask questions on the Core-mentorship list. The devguide is still a work-in-progress, but has had several recent patches. Great to hear that Jython3 is on the horizon. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 02:18:50 2013 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sat, 12 Jan 2013 01:18:50 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1357953530.55.0.0222234231224.issue16880@psf.upfronthosting.co.za> Jeffrey Armstrong added the comment: Terry: If I'm understanding this correctly, C_EXTENSION implies a dynamically loaded module authored in C. The issue on FreeMiNT, the operating system in question, is that there is no support for true shared objects. Any C modules must be statically linked with the Python executable. I'm thinking the answer is "No, it won't be a problem on m68k-atari-mint," if I'm understanding the meaning of "C_EXTENSION" correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 02:44:58 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 01:44:58 +0000 Subject: [issue16887] IDLE - tabify/untabify applied when clicking Cancel In-Reply-To: <1357592262.2.0.644397432764.issue16887@psf.upfronthosting.co.za> Message-ID: <1357955097.85.0.740187281613.issue16887@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 02:47:12 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 01:47:12 +0000 Subject: [issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex In-Reply-To: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za> Message-ID: <1357955232.5.0.850001062509.issue16899@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 02:49:35 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Jan 2013 01:49:35 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357955375.7.0.54203410124.issue16886@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not positive what Terry means by export patch and import patch...I think hg actually has commands like that, but I don't use them myself. I just use hg diff to generate the diff/patch file, and then use the regular patch command to apply it to 2.7. (I'm sure there are those who will laugh at me for being old school and not taking advantage of our nice shiny dvcs :) I hear that graft is better at resolving conflicts, but as I say I haven't tried it yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 03:17:59 2013 From: report at bugs.python.org (Leon Maurer) Date: Sat, 12 Jan 2013 02:17:59 +0000 Subject: [issue15574] IDLE crashes using clipboard copy command on OS X with ActiveTcl 8.5.12 In-Reply-To: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za> Message-ID: <1357957079.83.0.564339038695.issue15574@psf.upfronthosting.co.za> Leon Maurer added the comment: Thanks for the update. IDLE does indeed work for me now. Unfortunately, the program I was trying to get working under OS X still has lots of problems. At least it doesn't crash due to copy and paste anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 03:34:09 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Sat, 12 Jan 2013 02:34:09 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357958049.96.0.111780978512.issue16886@psf.upfronthosting.co.za> Frank Wierzbicki added the comment: I'm getting an error when I try to upload patches via Reitveld: TypeError at /review/16886/add int() argument must be a string or a number, not 'AddForm' so I'm attaching my updated patch here. Is this a known issue? If not, where should I report it? ---------- Added file: http://bugs.python.org/file28702/dictcomps_updated.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 03:37:05 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 02:37:05 +0000 Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za> Message-ID: <1357958225.11.0.589089896723.issue16901@psf.upfronthosting.co.za> Terry J. Reedy added the comment: First, a minor issue about class signatures: doc: FileCookieJar(filename, delayload=None, policy=None) code: def __init__(self, filename=None, delayload=False, policy=None) Pretty clearly, doc should be changed to match code, as later code allow for possibility of filename = None (meaning that that is intentional). Ditto for doc for FileCookieJar subclasses (which inherit __init__): MozillaCookieJar(filename, delayload=None, policy=None) LWPCookieJar(filename, delayload=None, policy=None) --- FileCookieJar has .load which in inherited by the subclasses. It checks for a filename and opens it and then calls ._really_load. The two subclasses have customized ._really_load methods that correspond to their customized .save methods. FileCookieJar itself does not. If it did, it would have to somehow be 'generic'. This suggests to me that FileCookieJar was not intended to be directly used. This impression is reinforced by the definition of .save(). def save(self, filename=None, ignore_discard=False, ignore_expires=False): """Save cookies to a file.""" raise NotImplementedError() In other words, there is no generic format to save to *or* load from. There should be a corresponding ._really_load to raise the same exception. Bottom line: as best I understand, your code is not intended to work, but both the doc and implementation are deficient in not saying so, and both should be improved. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, terry.reedy stage: -> test needed versions: +Python 2.7, Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 03:45:05 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Sat, 12 Jan 2013 02:45:05 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357958049.96.0.111780978512.issue16886@psf.upfronthosting.co.za> Message-ID: Frank Wierzbicki added the comment: On Fri, Jan 11, 2013 at 6:34 PM, Frank Wierzbicki wrote: > Reitveld *Rietveld I see just uploading a new patch to bugs.python does the right thing so I'll just move along :) ---------- nosy: +Frank.Wierzbicki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 03:57:26 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 02:57:26 +0000 Subject: [issue16930] mention limitations and/or alternatives to hg graft In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za> Message-ID: <1357959446.06.0.288224370714.issue16930@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Windows preserves case when writing a filename but ignores it when searching and opening filenames. IE, if I have tem.py and try to save TEM.py (from IDLE), it says 'tem.py exists, overwrite?'. So will or will not that be a problem for graft with 2.7/3.x module name case changes? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 03:59:12 2013 From: report at bugs.python.org (Jason Alvarado) Date: Sat, 12 Jan 2013 02:59:12 +0000 Subject: [issue16939] Broken link in 14. Cryptographic Service Message-ID: <1357959551.72.0.678573558111.issue16939@psf.upfronthosting.co.za> New submission from Jason Alvarado: http://docs.python.org/3.1/library/crypto.html The link to A.M, Kuchling URL is broken http://www.amk.ca/python/code/crypto.html ---------- assignee: docs at python components: Documentation messages: 179758 nosy: Jason.Alvarado, docs at python priority: normal severity: normal status: open title: Broken link in 14. Cryptographic Service versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 04:04:45 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 12 Jan 2013 03:04:45 +0000 Subject: [issue16930] mention limitations and/or alternatives to hg graft In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za> Message-ID: <1357959885.67.0.748093763837.issue16930@psf.upfronthosting.co.za> Chris Jerdonek added the comment: To clarify my original comment, I got an error about ConfigParser.py/configparser.py even when that file was not part of the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 04:06:29 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Jan 2013 03:06:29 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1357959989.98.0.556644520471.issue16398@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file28703/rotate.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 04:10:18 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 03:10:18 +0000 Subject: [issue16933] argparse: remove magic from examples In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za> Message-ID: <1357960218.79.0.779955610312.issue16933@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The new examples are much better and to me the patch looks ready to apply. ---------- nosy: +terry.reedy stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 04:31:12 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 03:31:12 +0000 Subject: [issue16933] argparse: remove magic from examples In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za> Message-ID: <3Yjmgg4qnTzP5k@mail.python.org> Roundup Robot added the comment: New changeset b2bb3219d36d by Chris Jerdonek in branch '2.7': Issue #16933: Improve choices examples in argparse documentation. http://hg.python.org/cpython/rev/b2bb3219d36d New changeset eaa2a6074741 by Chris Jerdonek in branch '3.2': Issue #16933 (2.7 forward-port): Improve choices examples in argparse docs. http://hg.python.org/cpython/rev/eaa2a6074741 New changeset de9eb3031f5a by Chris Jerdonek in branch '3.3': Issue #16933 (merge from 3.2): Improve choices examples in argparse docs. http://hg.python.org/cpython/rev/de9eb3031f5a New changeset bddbaaf332d7 by Chris Jerdonek in branch 'default': Issue #16933 (merge from 3.3): Improve choices examples in argparse docs. http://hg.python.org/cpython/rev/bddbaaf332d7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 04:32:02 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 03:32:02 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1357961522.36.0.546885628429.issue16927@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I like this idea, including the function subdivisions. I once suggested moving the classes into the later builtins chapter, but it was pointed out to me that a) they once *were* functions (no longer relevant); b) they are callables (very relevant); and hence people who see "bytearray(b'abc')" might not know that bytearray *is* a class. A separate section could have a few lines of introduction explaining "Keyword 'class' and built-in name 'type' serve different roles in code. But when referring to a Python object, they are more or less synonyms. Classes are callable. The operators and methods of the instances returned by the following built-classes are explained in the Built-in Types section." The index is another discovery method, one I use routinely, especially with the offline Windows help version of the docs, where one just types the first few letters of the name being sought in the index tab (much easier than the online click and search version). (Though the index entries might be improved a bit, that is another issue.) code related: compile comes before eval and exec, both of which use compile on string input. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 04:33:15 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 12 Jan 2013 03:33:15 +0000 Subject: [issue16933] argparse: remove magic from examples In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za> Message-ID: <1357961595.44.0.549851053842.issue16933@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for reporting the suggestion, Thomas. And thanks for looking over the patch, Terry. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 04:36:48 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 12 Jan 2013 03:36:48 +0000 Subject: [issue11176] give more meaningful argument names in argparse documentation In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za> Message-ID: <1357961808.29.0.309219063445.issue11176@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Issue 16933 improved the "choices" examples. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 04:49:06 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 12 Jan 2013 03:49:06 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1357962546.75.0.213319951329.issue16927@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I admit that I'm used to the alphabetical listing, but I like the idea for this organization. In fact, it's similar to how the Built-in Types page is organized: grouped by similarity rather than listed alphabetically. Also just a note: strictly speaking there are built-in types not in the built-in types section (e.g. staticmethod and classmethod), but I think that's okay. (There can be a disclaimer to this effect in the intro sentences of the first grouping.) Lastly, it might also be worth grouping the built-in types into subgroups (similar to how they're done for Built-in Types). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 05:00:57 2013 From: report at bugs.python.org (paul j3) Date: Sat, 12 Jan 2013 04:00:57 +0000 Subject: [issue16940] argparse 15.4.5.1. Sub-commands documentation missing indentation Message-ID: <1357963257.08.0.262737985676.issue16940@psf.upfronthosting.co.za> New submission from paul j3: Argparse 15.4.5.1. Sub-commands In the example: >>> parser.parse_args(['--help']) usage: PROG [-h] [--foo] {a,b} ... positional arguments: {a,b} sub-command help a a help b b help optional arguments: -h, --help show this help message and exit --foo foo help The 'a help', 'b help' lines should be indented ---------- assignee: docs at python components: Documentation messages: 179766 nosy: docs at python, paul.j3 priority: normal severity: normal status: open title: argparse 15.4.5.1. Sub-commands documentation missing indentation versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 06:02:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 12 Jan 2013 05:02:36 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357966956.83.0.930681980781.issue16886@psf.upfronthosting.co.za> Ezio Melotti added the comment: > The devguide is still a work-in-progress I would say it's already quite mature, however I'm rewriting the part about commiting: see #14468 and https://bitbucket.org/ezio_melotti/devguide/src/default/committing.rst?at=default (in particular the "working with mercurial" part and the "multiple clones approach"). > I'm getting an error when I try to upload patches via Reitveld: Just upload them here :) If you have other questions you can also come on IRC (#python-dev on Freenode). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 06:19:34 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 12 Jan 2013 05:19:34 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1357967974.25.0.302153565547.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: FTR I created a bitbucket clone of the devguide to make reviews easier: Here you can find the rendered output: https://bitbucket.org/ezio_melotti/devguide/src/default/committing.rst?at=default Here you can find the patches I applied and comment on them: https://bitbucket.org/ezio_melotti/devguide/commits/all ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 06:24:42 2013 From: report at bugs.python.org (Leon Maurer) Date: Sat, 12 Jan 2013 05:24:42 +0000 Subject: [issue16941] TkInter won't update display on OS X if delay is too small Message-ID: <1357968281.99.0.183131083594.issue16941@psf.upfronthosting.co.za> New submission from Leon Maurer: I'm running in to a problem where TkInter won't update the display on OS X. I've attached a simple piece of code that has this problem, and I've also made a short screen-cast of the problem: https://mywebspace.wisc.edu/lnmaurer/web/updatebug/updatebug.mov The program is simple -- basically a big canvas with a some text in the middle that counts up. The screen-cast has three parts. First, it shows the program working as it should. Then, I add a simple background image to the canvas (a black rectangle), and the interface refuses to refresh at all; I get a spinning beach ball wheel (although that doesn't show up in the screen-cast). Then, I increase the delay between updates, and the interface refreshes as it should. The middle case, where the interface becomes totally unresponsive, is a bug. I haven't been able to reproduce this problem under Linux or Windows; I've only run in to it on OS X. Also, the size of the canvas and image matters; if I make them small enough, the interface won't freeze up. Computer and software information: OS X 10.6.8 Python 2.7.3 ActiveTcl 8.5.13 PIL 1.1.7 MacBookPro5,5 w/ 2.26GHz Core 2 Duo (so a machine that's kind of slow by today's standards -- maybe faster machines won't run in to this problem, but this machine doesn't have the problem when running Windows or Linux) ---------- components: Tkinter files: bugtest.py messages: 179769 nosy: Leon.Maurer priority: normal severity: normal status: open title: TkInter won't update display on OS X if delay is too small versions: Python 2.7 Added file: http://bugs.python.org/file28704/bugtest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 06:34:59 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 12 Jan 2013 05:34:59 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1357968899.48.0.34208952895.issue16935@psf.upfronthosting.co.za> Ezio Melotti added the comment: FWIW the difference between support.import_module and the try/except/skip is that usually the former is used when *all* the tests require the imported module, whereas the latter is used when only some of the tests requires it. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 06:46:35 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 12 Jan 2013 05:46:35 +0000 Subject: [issue16885] SQLite3 iterdump ordering In-Reply-To: <1357569830.11.0.727312766793.issue16885@psf.upfronthosting.co.za> Message-ID: <1357969595.96.0.564729613572.issue16885@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can you provide a minimal script to reproduce the issue? If you can then turn the script in a unittest, you can try to patch the code and order the sqlite_master table and see if that fixes the problem. ---------- nosy: +ezio.melotti, ghaering, r.david.murray stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 07:13:49 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 12 Jan 2013 06:13:49 +0000 Subject: [issue16941] TkInter won't update display on OS X if delay is too small In-Reply-To: <1357968281.99.0.183131083594.issue16941@psf.upfronthosting.co.za> Message-ID: <1357971229.44.0.442143976867.issue16941@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the thorough documentation. If you haven't already, I would ask about the problem over on the Tkinter mailing list where people with heavy-duty Tkinter experience hang out. http://mail.python.org/mailman/listinfo/tkinter-discuss ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 07:30:13 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 06:30:13 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <3YjrfB3z48zSCk@mail.python.org> Roundup Robot added the comment: New changeset 9fb793b60e79 by Raymond Hettinger in branch 'default': Issue #16398: Optimize deque.rotate() http://hg.python.org/cpython/rev/9fb793b60e79 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 07:32:28 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Jan 2013 06:32:28 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1357972348.14.0.691536771986.issue16398@psf.upfronthosting.co.za> Raymond Hettinger added the comment: John, that wouldn't work because the blocks are fixed length and the endmost blocks are typically only partially filled, so all the data elements have to shift positions within their blocks. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 08:50:26 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 07:50:26 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1357977026.56.0.0789700355267.issue16886@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The hg workbench gui of tortoisehg, which I use, has make/apply patch selections that get translated to hg commands. So same thing ;-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:05:16 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 08:05:16 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <3Yjtlv17zXzSBy@mail.python.org> Roundup Robot added the comment: New changeset 0d81333bde78 by Raymond Hettinger in branch '2.7': Issue #16398: Optimize deque.rotate() http://hg.python.org/cpython/rev/0d81333bde78 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:12:56 2013 From: report at bugs.python.org (C19) Date: Sat, 12 Jan 2013 08:12:56 +0000 Subject: [issue16942] seriously? http.cookiejar.FileCookieJar().save method NOTImplemented? Message-ID: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za> New submission from C19: Is it means that we should use MozillaCookieJar LWPCookieJar or MSIECookieJar? But the document says "perhaps save cookies to, a file on disk. " http://docs.python.org/2/library/cookielib.html?highlight=filecookiejar#cookielib.FileCookieJar it looks like FileCookieJar is just a base class.it shouldn't be used on normal purpose(like save your cookie).then the document should be modified. but I think it's better to make the FileCookieJar works as expected. ---------- messages: 179777 nosy: C19 priority: normal severity: normal status: open title: seriously? http.cookiejar.FileCookieJar().save method NOTImplemented? type: enhancement versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:22:58 2013 From: report at bugs.python.org (C19) Date: Sat, 12 Jan 2013 08:22:58 +0000 Subject: [issue16942] seriously? urllib still doesn't support persistent connections? In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za> Message-ID: <1357978978.63.0.0191382102505.issue16942@psf.upfronthosting.co.za> C19 added the comment: # TODO(jhylton): Should this be redesigned to handle # persistent connections? # We want to make an HTTP/1.1 request, but the addinfourl # class isn't prepared to deal with a persistent connection. # It will try to read all remaining data from the socket, # which will block while the server waits for the next request. # So make sure the connection gets closed after the (only) # request. headers["Connection"] = "close" http://bugs.python.org/issue9740 this has been a long time..how many is annoyed by this..Count me in.. persistent connections may not be easy on various OS and act the same. I'm just satisfied if it works on linux. ---------- title: seriously? http.cookiejar.FileCookieJar().save method NOTImplemented? -> seriously? urllib still doesn't support persistent connections? versions: +Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:29:18 2013 From: report at bugs.python.org (C19) Date: Sat, 12 Jan 2013 08:29:18 +0000 Subject: [issue16943] seriously? FileCookieJar can't really save ? save method is NotImplemented Message-ID: <1357979358.05.0.978193495603.issue16943@psf.upfronthosting.co.za> New submission from C19: Is it means that we should use MozillaCookieJar LWPCookieJar or MSIECookieJar? But the document says "perhaps save cookies to, a file on disk. " http://docs.python.org/2/library/cookielib.html?highlight=filecookiejar#cookielib.FileCookieJar it looks like FileCookieJar is just a base class.it shouldn't be used on normal purpose(like save your cookie).then the document should be modified. but I think it's better to make the FileCookieJar works as expected. ---------- messages: 179779 nosy: C19 priority: normal severity: normal status: open title: seriously? FileCookieJar can't really save ? save method is NotImplemented _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:29:50 2013 From: report at bugs.python.org (C19) Date: Sat, 12 Jan 2013 08:29:50 +0000 Subject: [issue16943] seriously? FileCookieJar can't really save ? save method is NotImplemented In-Reply-To: <1357979358.05.0.978193495603.issue16943@psf.upfronthosting.co.za> Message-ID: <1357979390.18.0.00885438992357.issue16943@psf.upfronthosting.co.za> Changes by C19 : ---------- components: +Library (Lib) type: -> enhancement versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:36:32 2013 From: report at bugs.python.org (C19) Date: Sat, 12 Jan 2013 08:36:32 +0000 Subject: [issue16942] seriously? urllib still doesn't support persistent connections? In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za> Message-ID: <1357979792.35.0.224916796154.issue16942@psf.upfronthosting.co.za> C19 added the comment: https://github.com/shazow/urllib3 do we really have to use a 3rd party module for this ?.. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:41:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 08:41:04 +0000 Subject: [issue16940] argparse 15.4.5.1. Sub-commands documentation missing indentation In-Reply-To: <1357963257.08.0.262737985676.issue16940@psf.upfronthosting.co.za> Message-ID: <3YjvY91bb4zSDB@mail.python.org> Roundup Robot added the comment: New changeset eae31f2b6f60 by Ezio Melotti in branch '2.7': #16940: fix indentation in example. http://hg.python.org/cpython/rev/eae31f2b6f60 New changeset 3d54723c9be6 by Ezio Melotti in branch '3.2': #16940: fix indentation in example. http://hg.python.org/cpython/rev/3d54723c9be6 New changeset b468f6c8eae5 by Ezio Melotti in branch '3.3': #16940: merge with 3.2. http://hg.python.org/cpython/rev/b468f6c8eae5 New changeset 6fe28afa6611 by Ezio Melotti in branch 'default': #16940: merge with 3.3. http://hg.python.org/cpython/rev/6fe28afa6611 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:41:47 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 12 Jan 2013 08:41:47 +0000 Subject: [issue16940] argparse 15.4.5.1. Sub-commands documentation missing indentation In-Reply-To: <1357963257.08.0.262737985676.issue16940@psf.upfronthosting.co.za> Message-ID: <1357980107.48.0.105614478256.issue16940@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 09:58:22 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Sat, 12 Jan 2013 08:58:22 +0000 Subject: [issue16943] seriously? FileCookieJar can't really save ? save method is NotImplemented In-Reply-To: <1357979358.05.0.978193495603.issue16943@psf.upfronthosting.co.za> Message-ID: <1357981102.42.0.605839284395.issue16943@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> seriously? urllib still doesn't support persistent connections? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 10:46:22 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 12 Jan 2013 09:46:22 +0000 Subject: [issue16942] urllib still doesn't support persistent connections In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za> Message-ID: <1357983982.63.0.296919213554.issue16942@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- title: seriously? urllib still doesn't support persistent connections? -> urllib still doesn't support persistent connections _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 11:15:33 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Jan 2013 10:15:33 +0000 Subject: [issue2267] datetime.datetime operator methods are not subclass-friendly In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> Message-ID: <1357985733.57.0.763105722787.issue2267@psf.upfronthosting.co.za> Mark Dickinson added the comment: Alexander: can this be closed as "wont fix"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 11:26:55 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 12 Jan 2013 10:26:55 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1357986415.32.0.304705601931.issue16829@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Attached is a patch which uses subprocess. Haven't tested it much. ---------- Added file: http://bugs.python.org/file28705/issue16829.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 12:26:56 2013 From: report at bugs.python.org (Peter Stahl) Date: Sat, 12 Jan 2013 11:26:56 +0000 Subject: [issue16944] German number separators not working using format language and locale "de_DE" Message-ID: <1357990016.64.0.159100060877.issue16944@psf.upfronthosting.co.za> New submission from Peter Stahl: Yesterday, I opened a question on Stackoverflow that explains my problem in detail. Please read this page first: http://stackoverflow.com/questions/14287051/german-number-separators-using-format-language-on-osx A short summary: I'm on OSX 10.8.2. I wanted to format numbers according to the German numbering convention using Python's format language and the locale setting "de_DE". Actually, the following should work to achieve that: >>> import locale >>> locale.setlocale(locale.LC_ALL, 'de_DE') >>> '{0:n}'.format(1234.56) The result of the last expressions should be 1.234,56. However, my result is 1234,56. More examples are on Stackoverflow. According to what other SO members have found out, this is a problem with the locale settings of OSX because the grouping of numbers is not fully part of the locale "de_DE". On Windows, however, grouping works fine using the locale "deu_deu" which is not available on OSX. Is this a bug? At least, it doesn't seem to be documented anywhere and is probably not the correct behavior even on OSX. Others have reported similar problems on OSX as well. Do you have a quick solution for this issue? Thanks in advance. ---------- components: Library (Lib) messages: 179785 nosy: Peter.Stahl priority: normal severity: normal status: open title: German number separators not working using format language and locale "de_DE" type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 12:32:53 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 11:32:53 +0000 Subject: [issue16876] epoll: reuse epoll_event buffer instead of allocating a new one at each poll() In-Reply-To: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za> Message-ID: <3YjzMQ587czSDG@mail.python.org> Roundup Robot added the comment: New changeset 30eb98c8afef by Charles-Fran?ois Natali in branch 'default': Issue #16876: Revert be8e6b81284e, which wasn't thread-safe: wait until a http://hg.python.org/cpython/rev/30eb98c8afef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 12:38:19 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 12 Jan 2013 11:38:19 +0000 Subject: [issue2267] datetime.datetime operator methods are not subclass-friendly In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> Message-ID: <1357990699.02.0.522377216027.issue2267@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 12:39:14 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 12 Jan 2013 11:39:14 +0000 Subject: [issue16944] German number separators not working using format language and locale "de_DE" In-Reply-To: <1357990016.64.0.159100060877.issue16944@psf.upfronthosting.co.za> Message-ID: <1357990754.57.0.579907315955.issue16944@psf.upfronthosting.co.za> Stefan Krah added the comment: What is the output of this? >>> locale.localeconv() {'mon_decimal_point': ',', 'frac_digits': 2, 'p_sign_posn': 1, 'thousands_sep': '.', 'p_sep_by_space': 1, 'int_curr_symbol': 'EUR ', 'decimal_point': ',', 'mon_thousands_sep': '.', 'n_sep_by_space': 1, 'int_frac_digits': 2, 'currency_symbol': 'EUR', 'negative_sign': '-', 'mon_grouping': [3, 3, 0], 'positive_sign': '', 'n_cs_precedes': 0, 'grouping': [3, 3, 0], 'n_sign_posn': 1, 'p_cs_precedes': 0} If 'grouping' is [], then this looks like a bug in OSX. Python gets the values directly from the operating system. ---------- nosy: +skrah status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 12:52:17 2013 From: report at bugs.python.org (Peter Stahl) Date: Sat, 12 Jan 2013 11:52:17 +0000 Subject: [issue16944] German number separators not working using format language and locale "de_DE" In-Reply-To: <1357990754.57.0.579907315955.issue16944@psf.upfronthosting.co.za> Message-ID: Peter Stahl added the comment: Using the locale 'de_DE', the output is: {'mon_decimal_point': ',', 'int_frac_digits': 2, 'p_sep_by_space': 0, 'frac_digits': 2, 'thousands_sep': '', 'n_sign_posn': 1, 'decimal_point': ',', 'int_curr_symbol': 'EUR ', 'n_cs_precedes': 1, 'p_sign_posn': 1, 'mon_thousands_sep': '.', 'negative_sign': '-', 'currency_symbol': 'Eu', 'n_sep_by_space': 0, 'mon_grouping': [3, 3, 0], 'p_cs_precedes': 1, 'positive_sign': '', 'grouping': [127]} What does the number 127 mean? Am 12.01.2013 um 12:39 schrieb Stefan Krah : > > Stefan Krah added the comment: > > What is the output of this? > >>>> locale.localeconv() > {'mon_decimal_point': ',', 'frac_digits': 2, 'p_sign_posn': 1, 'thousands_sep': '.', 'p_sep_by_space': 1, 'int_curr_symbol': 'EUR ', 'decimal_point': ',', 'mon_thousands_sep': '.', 'n_sep_by_space': 1, 'int_frac_digits': 2, 'currency_symbol': 'EUR', 'negative_sign': '-', 'mon_grouping': [3, 3, 0], 'positive_sign': '', 'n_cs_precedes': 0, 'grouping': [3, 3, 0], 'n_sign_posn': 1, 'p_cs_precedes': 0} > > > If 'grouping' is [], then this looks like a bug in OSX. Python gets > the values directly from the operating system. > > ---------- > nosy: +skrah > status: open -> pending > > _______________________________________ > Python tracker > > _______________________________________ ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 13:24:31 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 12 Jan 2013 12:24:31 +0000 Subject: [issue16944] German number separators not working using format language and locale "de_DE" In-Reply-To: <1357990016.64.0.159100060877.issue16944@psf.upfronthosting.co.za> Message-ID: <1357993471.04.0.389071828427.issue16944@psf.upfronthosting.co.za> Stefan Krah added the comment: 127 means "no-more-grouping", so Python behaves as instructed by the OS. As you see, the OS prescribes 1.345.677,222 for *monetary* quantities and 1345677,222 otherwise. According to http://de.wikipedia.org/wiki/DIN_1333 , for non monetary quantities DIN-1333 says *empty spaces* *may* be used as separators. DIN-5008 says they *should* be used. :) Most operating systems use [3, 3, 0] also for de_DE 'grouping', but given the unclear situation it's hard to claim a bug in OSX. The only way out of this would be to introduce a new 'm' locale specifier that uses mon_grouping. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 13:49:35 2013 From: report at bugs.python.org (=?utf-8?q?M=C3=A1rcio_Faustino?=) Date: Sat, 12 Jan 2013 12:49:35 +0000 Subject: [issue5380] pty.read raises IOError when slave pty device is closed In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za> Message-ID: <1357994975.35.0.7364587191.issue5380@psf.upfronthosting.co.za> Changes by M?rcio Faustino : ---------- nosy: +marciof _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 14:21:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 13:21:35 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <3Yk1mp4hDbzS8w@mail.python.org> Roundup Robot added the comment: New changeset 5b36768b9a11 by Eli Bendersky in branch '3.3': Issue #16076: fix refleak in pickling of Element. http://hg.python.org/cpython/rev/5b36768b9a11 New changeset 848738d3c40f by Eli Bendersky in branch 'default': Close #16076: fix refleak in pickling of Element. http://hg.python.org/cpython/rev/848738d3c40f ---------- stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 14:38:42 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Jan 2013 13:38:42 +0000 Subject: [issue16885] SQLite3 iterdump ordering In-Reply-To: <1357569830.11.0.727312766793.issue16885@psf.upfronthosting.co.za> Message-ID: <1357997922.18.0.825470797223.issue16885@psf.upfronthosting.co.za> R. David Murray added the comment: When you say sometimes, do you mean randomly on the same schema, or do you mean depending on the specific schema sometimes it doesn't work? The code is the same in the other python versions, so I'm adding them as the bug doubtless exists there as well. ---------- versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 14:43:32 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 13:43:32 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <3Yk2GC1RdKzS85@mail.python.org> Roundup Robot added the comment: New changeset 4501813ea676 by Eli Bendersky in branch '3.3': Issue #16076: check for return value of PyTuple_New for args (following http://hg.python.org/cpython/rev/4501813ea676 New changeset 7313096e0bad by Eli Bendersky in branch 'default': Issue #16076: check for return value of PyTuple_New for args (following http://hg.python.org/cpython/rev/7313096e0bad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 14:52:23 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Jan 2013 13:52:23 +0000 Subject: [issue16942] urllib still doesn't support persistent connections In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za> Message-ID: <1357998743.34.0.187601147211.issue16942@psf.upfronthosting.co.za> R. David Murray added the comment: Please open a separate issue for your enhancement request in your second message (assuming there isn't already one open). I'm not sure what your third message is about, but it also sounds off topic for your original bug report. For the FileCookieJar issue, I agree that the documentation is unclear. However, it is perfectly reasonable to have a documented base class that is an Abstract Base Class, and there is no reason for us to invent our own unique cookie file format just to make FileCookieJar work by itself. ABCs didn't exist when FileCookieJar was implemented, so it should be turned in to one for 3.4 (it might break working code, so we shouldn't do that for bug fix releases). That way you would get a useful error when you try to instantiate it, rather than when you try to use it. And the docs should document it as being a base-class-only for all active releases. ---------- assignee: -> docs at python components: +Documentation, Library (Lib) nosy: +docs at python, r.david.murray stage: -> needs patch type: enhancement -> behavior versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 14:58:49 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 12 Jan 2013 13:58:49 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1357999129.9.0.386411421829.issue16922@psf.upfronthosting.co.za> Eli Bendersky added the comment: The fix looks good, but please don't add tests to the doctests - they are deprecated (from 3.3) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:12:57 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 12 Jan 2013 14:12:57 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1357999977.68.0.016210408107.issue15031@psf.upfronthosting.co.za> Brett Cannon added the comment: Nick had some good suggestions on improvements: http://mail.python.org/pipermail/python-dev/2013-January/123602.html Re-opening to remind me to do them. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:13:56 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 14:13:56 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <3Yk2xH0SVwzPBt@mail.python.org> Roundup Robot added the comment: New changeset a1efab48d8f8 by Eli Bendersky in branch 'default': Close #15442: Expand the list of default directories ignored by filecmp.dircmp and expose it as a module attribute http://hg.python.org/cpython/rev/a1efab48d8f8 ---------- nosy: +python-dev resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:14:44 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 12 Jan 2013 14:14:44 +0000 Subject: [issue16945] rewrite CGIHTTPRequestHandler to always use subprocess Message-ID: <1358000083.64.0.0773347996342.issue16945@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: On Unix, CGIHTTPRequestHandler.run_cgi() uses the following code to run a CGI script: """ pid = os.fork() [...] # Child try: try: os.setuid(nobody) except OSError: pass os.dup2(self.rfile.fileno(), 0) os.dup2(self.wfile.fileno(), 1) os.execve(scriptfile, args, env) """ It's basically reimplementing subprocess.Popen, with a potential securiy issue: open file descriptors are not closed before exec, which means that the CGI script - which is run as 'nobody' on Unix to reduce its priviledges - can inherit open sockets or files (unless they're close-on-exec)... The attached patch rewrites run_cgi() to use subprocess on all platorms. I'm not at all familiar with CGI, so I don't guarantee it's correct, but the regression test test_httpservers passes on Linux. It leads to cleaner and safer code, so if someone with some httpsever/CGI background could review it, it would be great. ---------- files: cgi_subprocess.diff keywords: needs review, patch messages: 179797 nosy: neologix priority: normal severity: normal stage: patch review status: open title: rewrite CGIHTTPRequestHandler to always use subprocess type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file28706/cgi_subprocess.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:17:33 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 12 Jan 2013 14:17:33 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1358000253.07.0.250792667756.issue16880@psf.upfronthosting.co.za> Brett Cannon added the comment: load_dynamic should probably be documented since it does something you can't do on your own and importlib itself uses it. As for the exception test, it should be to make sure ImportError is raised (i.e. the 'else' clause is hit). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:26:26 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Sat, 12 Jan 2013 14:26:26 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1358000786.79.0.291297000406.issue10544@psf.upfronthosting.co.za> Changes by Daniel Shahaf : ---------- nosy: +danielsh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:27:47 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 12 Jan 2013 14:27:47 +0000 Subject: [issue10541] regrtest.py -T broken In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za> Message-ID: <1358000867.57.0.0817566501256.issue10541@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: -eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:28:50 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Jan 2013 14:28:50 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1358000930.78.0.381029032799.issue16922@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But all findtext tests are doctests and I want to keep the tests together. I think there should be separated issue for converting ElementTree doctests to unittests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:38:11 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 12 Jan 2013 14:38:11 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1358001491.97.0.0180021549575.issue16922@psf.upfronthosting.co.za> Eli Bendersky added the comment: Serhiy, indeed - that's issue #15083. But since rewriting all tests is a large task no one is willing to take at this point, my strategy has been incremental: rewrite a chunk at a time when tests are being touched. Just adding new doctests goes against the desired direction. I'll convert the findtext tests to unittest in 3.3 and default and then you can add your new tests in the proper place. Stay tuned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:39:23 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 12 Jan 2013 14:39:23 +0000 Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za> Message-ID: <1358001563.97.0.568175424696.issue15083@psf.upfronthosting.co.za> Eli Bendersky added the comment: It should be noted that the doctests complicate things considerably, and should be rewritten to be unittest, which are easier to manipulate in terms of modules used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:39:55 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 12 Jan 2013 14:39:55 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1358001595.52.0.676389625138.issue16398@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I am OK with this patch being applied to 2.7, but I wonder why. This is not a bugfix... :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:54:13 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Jan 2013 14:54:13 +0000 Subject: [issue16946] subprocess: _close_open_fd_range_safe() does not set close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined Message-ID: <1358002453.56.0.227593845503.issue16946@psf.upfronthosting.co.za> New submission from STINNER Victor: The following extract of _close_open_fd_range_safe() is not correct: #ifdef O_CLOEXEC fd_dir_fd = open(FD_DIR, O_RDONLY | O_CLOEXEC, 0); #else fd_dir_fd = open(FD_DIR, O_RDONLY, 0); #ifdef FD_CLOEXEC { int old = fcntl(fd_dir_fd, F_GETFD); if (old != -1) fcntl(fd_dir_fd, F_SETFD, old | FD_CLOEXEC); } #endif #endif On Linux older than 2.6.23, O_CLOEXEC may be defined by the glibc whereas the kernel does not support it. In this case, the flag is simply ignored and close-on-exec flag is not set on the file descriptor. ---------- messages: 179803 nosy: haypo, neologix priority: normal severity: normal status: open title: subprocess: _close_open_fd_range_safe() does not set close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 15:56:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Jan 2013 14:56:40 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1358002600.2.0.359024299536.issue16829@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No surrounding %%s with quotes, nor changing to %%r doesn't work in all cases, because Python and shell use different quoting schemas. The only solution is using shlex.quote (which available only since 3.3). But even in this case we should be careful, this can break user code if user has "fixed" the issue by surrounding %%s with quotes (singular or double) or changing to %%r. Perhaps we should substitute not only bare %%s, but also "%%s", '%%s' and %%r. Ramchandra's patch doesn't help. First, shlex.split will fail in the same way as a shell. Second, we must run the command via shell, because user can use pipe or redirection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:01:55 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 12 Jan 2013 15:01:55 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1358002915.96.0.380093342651.issue16880@psf.upfronthosting.co.za> Nick Coghlan added the comment: The misleading docs Terry pointed out should also be fixed to note that "imp" is still used to expose some functionality where importlib really does need help from the underlying platform (such as loading dynamic modules). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:09:47 2013 From: report at bugs.python.org (Nurhusien Hasen) Date: Sat, 12 Jan 2013 15:09:47 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1358002915.96.0.380093342651.issue16880@psf.upfronthosting.co.za> Message-ID: Nurhusien Hasen added the comment: Pleas stop your from me all isuss masege On 1/13/13, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > The misleading docs Terry pointed out should also be fixed to note that > "imp" is still used to expose some functionality where importlib really does > need help from the underlying platform (such as loading dynamic modules). > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/nurhusien.hasen27%40gmail.com > > ---------- nosy: +Nurhusien2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:10:33 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Jan 2013 15:10:33 +0000 Subject: [issue16946] subprocess: _close_open_fd_range_safe() does not set close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined In-Reply-To: <1358002453.56.0.227593845503.issue16946@psf.upfronthosting.co.za> Message-ID: <1358003433.08.0.441282545431.issue16946@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +gps _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:11:57 2013 From: report at bugs.python.org (Nurhusien Hasen) Date: Sat, 12 Jan 2013 15:11:57 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: Message-ID: Nurhusien Hasen added the comment: Pleas stop your from me all isuss masege On 1/13/13, Nurhusien Hasen wrote: > Pleas stop your from me all isuss masege > > On 1/13/13, Nick Coghlan wrote: >> >> Nick Coghlan added the comment: >> >> The misleading docs Terry pointed out should also be fixed to note that >> "imp" is still used to expose some functionality where importlib really >> does >> need help from the underlying platform (such as loading dynamic modules). >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ >> _______________________________________________ >> Python-bugs-list mailing list >> Unsubscribe: >> http://mail.python.org/mailman/options/python-bugs-list/nurhusien.hasen27%40gmail.com >> >> > > > -- > find signatures serves > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:13:13 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 12 Jan 2013 15:13:13 +0000 Subject: [issue16259] Replace exec() in test.regrtest with __import__ In-Reply-To: <1350444394.63.0.4278126209.issue16259@psf.upfronthosting.co.za> Message-ID: <1358003593.0.0.912152517703.issue16259@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Boiiummp. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:13:31 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 12 Jan 2013 15:13:31 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358003611.6.0.311089904397.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Attached is a new patch which is implemented completely in C. It adds a WinFileIO class to the io module, which has the same API as FileIO except that: * It has a handle attribute instead of a fileno() method. * It has staticmethods openhandle() and closehandle() which are analogues of os.open() and os.close(). The patch also adds a keyword-only "rawfiletype" argument to io.open() so that you can write f = open("somefile", "w", rawfiletype=WinFileIO) ---------- Added file: http://bugs.python.org/file28707/winfileio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:13:44 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 12 Jan 2013 15:13:44 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358003624.63.0.706467929696.issue12939@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file28544/winfileio.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:13:50 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 12 Jan 2013 15:13:50 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358003630.06.0.428991818695.issue12939@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file28545/test_winfileio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:13:59 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 12 Jan 2013 15:13:59 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358003639.66.0.669050452056.issue12939@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file28590/winfileio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:15:43 2013 From: report at bugs.python.org (Nurhusien Hasen) Date: Sat, 12 Jan 2013 15:15:43 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: Message-ID: Nurhusien Hasen added the comment: Pleas stop your from me all isuss maseges On 1/13/13, Nurhusien Hasen wrote: > > Nurhusien Hasen added the comment: > > Pleas stop your from me all isuss masege > > On 1/13/13, Nurhusien Hasen wrote: >> Pleas stop your from me all isuss masege >> >> On 1/13/13, Nick Coghlan wrote: >>> >>> Nick Coghlan added the comment: >>> >>> The misleading docs Terry pointed out should also be fixed to note that >>> "imp" is still used to expose some functionality where importlib really >>> does >>> need help from the underlying platform (such as loading dynamic >>> modules). >>> >>> ---------- >>> >>> _______________________________________ >>> Python tracker >>> >>> _______________________________________ >>> _______________________________________________ >>> Python-bugs-list mailing list >>> Unsubscribe: >>> http://mail.python.org/mailman/options/python-bugs-list/nurhusien.hasen27%40gmail.com >>> >>> >> >> >> -- >> find signatures serves >> > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:19:58 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 12 Jan 2013 15:19:58 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358003998.4.0.124544524057.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Forgot to mention, the handles are non-inheritable. You can use _winapi.DuplicateHandle() to create an inheritable duplicate handle if you really need to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:28:57 2013 From: report at bugs.python.org (Leon Maurer) Date: Sat, 12 Jan 2013 15:28:57 +0000 Subject: [issue16941] TkInter won't update display on OS X if delay is too small In-Reply-To: <1357968281.99.0.183131083594.issue16941@psf.upfronthosting.co.za> Message-ID: <1358004537.79.0.446074839554.issue16941@psf.upfronthosting.co.za> Leon Maurer added the comment: That's a good idea; I'll shoot them a message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:34:16 2013 From: report at bugs.python.org (Christoph Deil) Date: Sat, 12 Jan 2013 15:34:16 +0000 Subject: [issue16947] Search for "sherpa" on pypi leads to gitflow Message-ID: <1358004856.63.0.647695123889.issue16947@psf.upfronthosting.co.za> New submission from Christoph Deil: If you enter "sherpa" on http://pypi.python.org you currently get http://pypi.python.org/pypi/gitflow/0.5.0 Why? It doesn't make much sense as the term "sherpa" doesn't appear on that pypi page. Instead pypi should say "not found", as the sherpa Python package is not registered on pypi: http://cxc.cfa.harvard.edu/contrib/sherpa/ ---------- components: None messages: 179813 nosy: Christoph.Deil priority: normal severity: normal status: open title: Search for "sherpa" on pypi leads to gitflow type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:42:57 2013 From: report at bugs.python.org (Nurhusien Hasen) Date: Sat, 12 Jan 2013 15:42:57 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: Message-ID: Nurhusien Hasen added the comment: On 1/13/13, Nurhusien Hasen wrote: > > Nurhusien Hasen added the comment: > > Pleas stop your from me all isuss maseges > > On 1/13/13, Nurhusien Hasen wrote: >> >> Nurhusien Hasen added the comment: >> >> Pleas stop your from me all isuss masege >> >> On 1/13/13, Nurhusien Hasen wrote: >>> Pleas stop your from me all isuss masege >>> >>> On 1/13/13, Nick Coghlan wrote: >>>> >>>> Nick Coghlan added the comment: >>>> >>>> The misleading docs Terry pointed out should also be fixed to note that >>>> "imp" is still used to expose some functionality where importlib really >>>> does >>>> need help from the underlying platform (such as loading dynamic >>>> modules). >>>> >>>> ---------- >>>> >>>> _______________________________________ >>>> Python tracker >>>> >>>> _______________________________________ >>>> _______________________________________________ >>>> Python-bugs-list mailing list >>>> Unsubscribe: >>>> http://mail.python.org/mailman/options/python-bugs-list/nurhusien.hasen27%40gmail.com >>>> >>>> >>> >>> >>> -- >>> find signatures serves >>> >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ >> > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > -- find signatures serves ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:45:10 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 15:45:10 +0000 Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za> Message-ID: <3Yk4yZ07ZwzR8Q@mail.python.org> Roundup Robot added the comment: New changeset f9d1d120c19e by Eli Bendersky in branch '3.3': Issues #15083 and #16992: port find.* method tests to unittest http://hg.python.org/cpython/rev/f9d1d120c19e New changeset 18b16104166c by Eli Bendersky in branch 'default': Issues #15083 and #16992: port find.* method tests to unittest http://hg.python.org/cpython/rev/18b16104166c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:45:23 2013 From: report at bugs.python.org (Nurhusien Hasen) Date: Sat, 12 Jan 2013 15:45:23 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: Message-ID: Nurhusien Hasen added the comment: Pleas stop your from me all isuss maseges pleas stop On 1/13/13, Nurhusien Hasen wrote: > On 1/13/13, Nurhusien Hasen wrote: >> >> Nurhusien Hasen added the comment: >> >> Pleas stop your from me all isuss maseges >> >> On 1/13/13, Nurhusien Hasen wrote: >>> >>> Nurhusien Hasen added the comment: >>> >>> Pleas stop your from me all isuss masege >>> >>> On 1/13/13, Nurhusien Hasen wrote: >>>> Pleas stop your from me all isuss masege >>>> >>>> On 1/13/13, Nick Coghlan wrote: >>>>> >>>>> Nick Coghlan added the comment: >>>>> >>>>> The misleading docs Terry pointed out should also be fixed to note >>>>> that >>>>> "imp" is still used to expose some functionality where importlib >>>>> really >>>>> does >>>>> need help from the underlying platform (such as loading dynamic >>>>> modules). >>>>> >>>>> ---------- >>>>> >>>>> _______________________________________ >>>>> Python tracker >>>>> >>>>> _______________________________________ >>>>> _______________________________________________ >>>>> Python-bugs-list mailing list >>>>> Unsubscribe: >>>>> http://mail.python.org/mailman/options/python-bugs-list/nurhusien.hasen27%40gmail.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> find signatures serves >>>> >>> >>> ---------- >>> >>> _______________________________________ >>> Python tracker >>> >>> _______________________________________ >>> >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ >> > > > -- > find signatures serves > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:46:49 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 12 Jan 2013 15:46:49 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1358005609.24.0.647127790132.issue16922@psf.upfronthosting.co.za> Eli Bendersky added the comment: Tests ported in 3.3 and 3.4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:56:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 15:56:23 +0000 Subject: [issue16762] test_subprocess failure on OpenBSD/NetBSD buildbots In-Reply-To: <1356344635.01.0.0408386674119.issue16762@psf.upfronthosting.co.za> Message-ID: <3Yk5CV53b4zS65@mail.python.org> Roundup Robot added the comment: New changeset 61d6b34af419 by Charles-Fran?ois Natali in branch '2.7': Issue #16762: Fix some test_subprocess failures on NetBSD and OpenBSD: kill() http://hg.python.org/cpython/rev/61d6b34af419 New changeset 58ce6ac61ada by Charles-Fran?ois Natali in branch '3.2': Issue #16762: Fix some test_subprocess failures on NetBSD and OpenBSD: kill() http://hg.python.org/cpython/rev/58ce6ac61ada New changeset a3f0414af55b by Charles-Fran?ois Natali in branch '3.3': Issue #16762: Fix some test_subprocess failures on NetBSD and OpenBSD: kill() http://hg.python.org/cpython/rev/a3f0414af55b New changeset 487ed428f0ba by Charles-Fran?ois Natali in branch 'default': Issue #16762: Fix some test_subprocess failures on NetBSD and OpenBSD: kill() http://hg.python.org/cpython/rev/487ed428f0ba ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 16:57:31 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 12 Jan 2013 15:57:31 +0000 Subject: [issue16762] test_subprocess failure on OpenBSD/NetBSD buildbots In-Reply-To: <1356344635.01.0.0408386674119.issue16762@psf.upfronthosting.co.za> Message-ID: <1358006251.54.0.3498530794.issue16762@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:08:45 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 16:08:45 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1358006925.1.0.253104927827.issue16880@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg179807 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:08:58 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 16:08:58 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1358006938.19.0.123260106927.issue16880@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg179806 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:09:17 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 16:09:17 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1358006957.69.0.622398669298.issue16880@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg179810 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:09:39 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 16:09:39 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1358006979.66.0.275025357764.issue16880@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg179814 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:10:04 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 16:10:04 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1358007004.15.0.288506224923.issue16880@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg179816 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:11:07 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Jan 2013 16:11:07 +0000 Subject: [issue16880] Importing "imp" will fail if dynamic loading not supported In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za> Message-ID: <1358007067.8.0.676079371278.issue16880@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: -Nurhusien2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:20:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 16:20:25 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <3Yk5lD4pbZzS2D@mail.python.org> Roundup Robot added the comment: New changeset e651d96e6b07 by Serhiy Storchaka in branch '2.7': Issue #16829: IDLE printing no longer fails if there are spaces or other http://hg.python.org/cpython/rev/e651d96e6b07 New changeset 20065626c0b5 by Serhiy Storchaka in branch '3.2': Issue #16829: IDLE printing no longer fails if there are spaces or other http://hg.python.org/cpython/rev/20065626c0b5 New changeset 778bead39825 by Serhiy Storchaka in branch '3.3': Issue #16829: IDLE printing no longer fails if there are spaces or other http://hg.python.org/cpython/rev/778bead39825 New changeset 529b5ced59e0 by Serhiy Storchaka in branch 'default': Issue #16829: IDLE printing no longer fails if there are spaces or other http://hg.python.org/cpython/rev/529b5ced59e0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:26:48 2013 From: report at bugs.python.org (Leon Maurer) Date: Sat, 12 Jan 2013 16:26:48 +0000 Subject: [issue16941] TkInter won't update display on OS X if delay is too small In-Reply-To: <1357968281.99.0.183131083594.issue16941@psf.upfronthosting.co.za> Message-ID: <1358008008.77.0.786156550678.issue16941@psf.upfronthosting.co.za> Leon Maurer added the comment: Well, it looks like the problem is known and can't be fixed: http://mail.python.org/pipermail/tkinter-discuss/2013-January/003343.html Oh well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:28:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Jan 2013 16:28:33 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1358008113.63.0.745047652948.issue16829@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I?have committed a very simple fix with shlex.quote (pipes.quote before 3.3). This is not fully backward compatible, it can break user configuration if the user had "fixed" this issue himself (and this "fix" is not perfect). But I think it's quite unlikely. Otherwise, we would get a bug report much earlier. An attempt to consider such hypothetical situation requires tedious code. Thank you for report, Rod. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:34:55 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 16:34:55 +0000 Subject: [issue16259] Replace exec() in test.regrtest with __import__ In-Reply-To: <1350444394.63.0.4278126209.issue16259@psf.upfronthosting.co.za> Message-ID: <3Yk63y245dzS5j@mail.python.org> Roundup Robot added the comment: New changeset e22c09f636d4 by R David Murray in branch 'default': #16259: delete some no-longer-used code from regrtest. http://hg.python.org/cpython/rev/e22c09f636d4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:35:28 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Jan 2013 16:35:28 +0000 Subject: [issue16259] Replace exec() in test.regrtest with __import__ In-Reply-To: <1350444394.63.0.4278126209.issue16259@psf.upfronthosting.co.za> Message-ID: <1358008528.36.0.695155151846.issue16259@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:39:18 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Jan 2013 16:39:18 +0000 Subject: [issue16947] Search for "sherpa" on pypi leads to gitflow In-Reply-To: <1358004856.63.0.647695123889.issue16947@psf.upfronthosting.co.za> Message-ID: <1358008758.15.0.535926699575.issue16947@psf.upfronthosting.co.za> R. David Murray added the comment: Please report pypi issues to the pypi bug tracker: http://sourceforge.net/tracker/?group_id=66150&atid=513503 ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 17:43:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Jan 2013 16:43:02 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1358008982.33.0.517551878242.issue16922@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch for 3.3+. ---------- Added file: http://bugs.python.org/file28708/etree_finditer_empty-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 18:59:43 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 12 Jan 2013 17:59:43 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1358013583.26.0.686719131306.issue15442@psf.upfronthosting.co.za> ?ric Araujo added the comment: + .. versionadded:: 3.3 3.4* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 19:52:55 2013 From: report at bugs.python.org (Jakub Wilk) Date: Sat, 12 Jan 2013 18:52:55 +0000 Subject: [issue16948] email.mime.text.MIMEText: QP encoding broken with charset!=ISO-8859-1 Message-ID: <1358016775.26.0.412297588527.issue16948@psf.upfronthosting.co.za> New submission from Jakub Wilk: If you try to create MIMEText object with text containing characters outside the ISO-8859-1 range, the quoted-printable encoder fails with KeyError: Python 3.2.3 (default, Sep 10 2012, 12:58:42) [GCC 4.7.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import email.mime.text >>> email.mime.text.MIMEText('\u017c', 'plain', 'ISO-8859-2') Traceback (most recent call last): File "/usr/lib/python3.2/email/message.py", line 331, in set_charset cte(self) TypeError: 'str' object is not callable During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.2/email/mime/text.py", line 30, in __init__ self.set_payload(_text, _charset) File "/usr/lib/python3.2/email/message.py", line 296, in set_payload self.set_charset(charset) File "/usr/lib/python3.2/email/message.py", line 333, in set_charset self._payload = charset.body_encode(self._payload) File "/usr/lib/python3.2/email/charset.py", line 395, in body_encode return email.quoprimime.body_encode(string) File "/usr/lib/python3.2/email/quoprimime.py", line 240, in body_encode if body_check(ord(c)): File "/usr/lib/python3.2/email/quoprimime.py", line 81, in body_check return chr(octet) != _QUOPRI_BODY_MAP[octet] KeyError: 380 ---------- components: Library (Lib) messages: 179826 nosy: jwilk priority: normal severity: normal status: open title: email.mime.text.MIMEText: QP encoding broken with charset!=ISO-8859-1 versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 19:57:06 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Jan 2013 18:57:06 +0000 Subject: [issue16948] email.mime.text.MIMEText: QP encoding broken with charset!=ISO-8859-1 In-Reply-To: <1358016775.26.0.412297588527.issue16948@psf.upfronthosting.co.za> Message-ID: <1358017026.79.0.845176954929.issue16948@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry, r.david.murray versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 20:22:36 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Sat, 12 Jan 2013 19:22:36 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1358018556.83.0.199965448477.issue16886@psf.upfronthosting.co.za> Changes by Frank Wierzbicki : Added file: http://bugs.python.org/file28709/dictcomps_updated2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 21:09:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Jan 2013 20:09:35 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1358021375.31.0.0566004054504.issue15539@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 21:59:28 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Jan 2013 20:59:28 +0000 Subject: [issue16923] test_ssl kicks up a lot of ResourceWarnings In-Reply-To: <1357849095.58.0.0656533205618.issue16923@psf.upfronthosting.co.za> Message-ID: <3YkCxB5HDTzS3g@mail.python.org> Roundup Robot added the comment: New changeset 2c3f5ed7a5c9 by Antoine Pitrou in branch '3.3': Issue #16923: Fix ResourceWarnings in test_ssl. http://hg.python.org/cpython/rev/2c3f5ed7a5c9 New changeset f79d282c8147 by Antoine Pitrou in branch 'default': Issue #16923: Fix ResourceWarnings in test_ssl. http://hg.python.org/cpython/rev/f79d282c8147 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 22:01:41 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 Jan 2013 21:01:41 +0000 Subject: [issue16923] test_ssl kicks up a lot of ResourceWarnings In-Reply-To: <1357849095.58.0.0656533205618.issue16923@psf.upfronthosting.co.za> Message-ID: <1358024501.22.0.590860880023.issue16923@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Done! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 22:03:16 2013 From: report at bugs.python.org (Christoph Deil) Date: Sat, 12 Jan 2013 21:03:16 +0000 Subject: [issue16947] Search for "sherpa" on pypi leads to gitflow In-Reply-To: <1358004856.63.0.647695123889.issue16947@psf.upfronthosting.co.za> Message-ID: <1358024596.07.0.381243681436.issue16947@psf.upfronthosting.co.za> Christoph Deil added the comment: Sorry about that. Ticket in PyPI tracer is now here: http://sourceforge.net/tracker/?func=detail&aid=3600625&group_id=66150&atid=513503 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 22:09:37 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 12 Jan 2013 21:09:37 +0000 Subject: [issue1602133] non-framework python fails to define os.environ properly Message-ID: <1358024977.81.0.413797492247.issue1602133@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I appear to be running into this as well in py2app, with the current 2.7 tree and a --enable-shared build py2app's updates to the environment (with setenv from C code) won't be seen by Python, even though Python is initialized after the call to setenv. The patch doesn't work for me though: with the patch the build fails because os.environ no longer contains 'PATH'. I'm looking into this issue. The basic idea of the patch seems sane, both posixmodule.c and crt_externs.h mention that the call is needed for shared libraries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 22:16:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Jan 2013 21:16:48 +0000 Subject: [issue16601] Restarting iteration over tarfile continues from where it left off. In-Reply-To: <1354564872.87.0.0661195327337.issue16601@psf.upfronthosting.co.za> Message-ID: <1358025408.49.0.847343867054.issue16601@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Michael Birtwell, can you please submit a contributor form? http://python.org/psf/contrib/contrib-form/ http://python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 22:24:31 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 12 Jan 2013 21:24:31 +0000 Subject: [issue16941] TkInter won't update display on OS X if delay is too small In-Reply-To: <1357968281.99.0.183131083594.issue16941@psf.upfronthosting.co.za> Message-ID: <1358025871.1.0.929233494489.issue16941@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Would it be possible, and sane, to enforce a minimal delay on OSX? That is, code that automaticly ensures that the delay has some minimal value. Or does the required delay depend on what you are doing? ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 22:44:43 2013 From: report at bugs.python.org (Leon Maurer) Date: Sat, 12 Jan 2013 21:44:43 +0000 Subject: [issue16941] TkInter won't update display on OS X if delay is too small In-Reply-To: <1357968281.99.0.183131083594.issue16941@psf.upfronthosting.co.za> Message-ID: <1358027083.15.0.486605559925.issue16941@psf.upfronthosting.co.za> Leon Maurer added the comment: It seems to depend on what you're doing. Plus, the delay I needed turned an already slow animation in to a slide show. In this case, a better fix seems to be sticking a "root.update()" right before the "root.after". Then it works with no delay. However, apparently it's a little dangerous to use: http://mail.python.org/pipermail/tkinter-discuss/2013-January/003346.html In my case, the only side effect seems to be that using the menu effectively pauses the simualtion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 23:03:48 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 12 Jan 2013 22:03:48 +0000 Subject: [issue15442] Expand the list of default dirs filecmp.dircmp ignores In-Reply-To: <1343147532.2.0.187379599839.issue15442@psf.upfronthosting.co.za> Message-ID: <1358028228.25.0.645875880819.issue15442@psf.upfronthosting.co.za> Eli Bendersky added the comment: What? Where did you see 3.3? It says 3.4 ;-) Thanks, fixed in 72ddb250f058 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 23:12:11 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 12 Jan 2013 22:12:11 +0000 Subject: [issue16941] TkInter won't update display on OS X if delay is too small In-Reply-To: <1357968281.99.0.183131083594.issue16941@psf.upfronthosting.co.za> Message-ID: <1358028731.89.0.122121204028.issue16941@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, on my newer 2.2Ghz i7-based MacBookPro, I can reproduce the problem but I see satisfactory results by setting the delay to just 10 rather than 100. So, it is likely that the minimum delay is system- and application- dependent. Since there's not likely anything to be done here in Tkinter, I am going to close this issue. Perhaps some day down the road, work being down now by Guido in PEP 3156 may provide a better way to integrate Python event loops with Tk's and Cocoa's. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 12 23:23:14 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 12 Jan 2013 22:23:14 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1358029394.85.0.377837169447.issue16922@psf.upfronthosting.co.za> Eli Bendersky added the comment: PyUnicode_New has been added in 3.3, so the 3.2 patch doesn't compile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 00:30:16 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Jan 2013 23:30:16 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module In-Reply-To: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za> Message-ID: <1358033414.64.0.00116196176988.issue16860@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'll wait a little before removing O_NOFOLLOW I don't know this flag. What is its effect of the directory part of the path? Does it change anything if the directory is a symbolic link? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 00:37:35 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Jan 2013 23:37:35 +0000 Subject: [issue16500] Add an 'atfork' module In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za> Message-ID: <1358033855.49.0.878450514405.issue16500@psf.upfronthosting.co.za> STINNER Victor added the comment: "The tempfile module has a specialized RNG that re-initialized the RNG after fork() by comparing os.getpid() to an instance variable every time the RNG is accessed. The check can be replaced with an afterfork callback." By the way, OpenSSL expects that its PRNG is reseed somehow (call RNG_add) after a fork. I wrote a patch for OpenSSL, but I don't remember if I sent it to OpenSSL. https://bitbucket.org/haypo/hasard/src/4a1be69a47eb1b2ec7ca95a341d4ca953a77f8c6/patches/openssl_rand_fork.patch?at=default Reseeding tempfile PRNG is useless (but spend CPU/memory/hang until we have enough entropy?) if the tempfile is not used after fork. I like the current approach. -- I'm not saying that a new atfork module would not help, just that the specific case of tempfile should be discussed :-) I like the idea of a generic module to call code after fork. ---------- nosy: +haypo title: Add an 'afterfork' module -> Add an 'atfork' module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 00:45:06 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Jan 2013 23:45:06 +0000 Subject: [issue10115] Support accept4() for atomic setting of flags at socket creation In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za> Message-ID: <1358034306.8.0.168712686126.issue10115@psf.upfronthosting.co.za> STINNER Victor added the comment: See the PEP 433 which proposes an unified API to set/unset close-on-exec flag on any function creating a file descriptor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 00:46:16 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 12 Jan 2013 23:46:16 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module In-Reply-To: <1358033414.64.0.00116196176988.issue16860@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: >> I'll wait a little before removing O_NOFOLLOW > > I don't know this flag. What is its effect of the directory part of the path? Does it change anything if the directory is a symbolic link? No, it only has an effect if the target file is a symlink. FWIW, glibc's mkstemp() implementation doesn't use it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 00:48:11 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Jan 2013 23:48:11 +0000 Subject: [issue16860] Use O_CLOEXEC in the tempfile module In-Reply-To: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za> Message-ID: <1358034491.77.0.717850472364.issue16860@psf.upfronthosting.co.za> STINNER Victor added the comment: > No, it only has an effect if the target file is a symlink. Oh ok, so O_NOFOLLOW is useless when O_EXCL is used. It is safe to remove it, but please only modify Python 3.4 (just in case...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 01:04:11 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Sun, 13 Jan 2013 00:04:11 +0000 Subject: [issue14208] No way to recover original argv with python -m In-Reply-To: <1331016803.5.0.715499259579.issue14208@psf.upfronthosting.co.za> Message-ID: <1358035451.79.0.725927645615.issue14208@psf.upfronthosting.co.za> Changes by Daniel Shahaf : ---------- nosy: +danielsh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 01:06:25 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 13 Jan 2013 00:06:25 +0000 Subject: [issue16850] Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1358035585.31.0.590633478612.issue16850@psf.upfronthosting.co.za> STINNER Victor added the comment: I created the PEP 433 which proposes a more global change to set the close-on-exec flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 01:28:26 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Sun, 13 Jan 2013 00:28:26 +0000 Subject: [issue2209] mailbox module doesn't support compressed mbox In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za> Message-ID: <1358036906.98.0.590053913286.issue2209@psf.upfronthosting.co.za> Changes by Daniel Shahaf : ---------- nosy: +danielsh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 02:05:54 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 13 Jan 2013 01:05:54 +0000 Subject: [issue16829] IDLE on POSIX can't print filenames with spaces In-Reply-To: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za> Message-ID: <1358039154.27.0.256277695613.issue16829@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Given the system-dependent nature of the problem, starting with the simplest thing that really ought to work seems reasonable to me. I verified that the 3.3 patch has no effect on Windows. IE, files with and without spaces printed without .py in the printed title. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 03:09:42 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 13 Jan 2013 02:09:42 +0000 Subject: [issue16406] move the "Uploading Packages" section to distutils/packageindex.rst In-Reply-To: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za> Message-ID: <1358042982.07.0.985460660462.issue16406@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updated the last patch by moving the "PyPI package display" to beneath the "Registering Packages" section (since only the register command affects the package display). ?ric, does this look okay to you? I didn't change the text of any of the sections -- only moved them (and added introductory page text and index entries). ---------- Added file: http://bugs.python.org/file28710/issue-16406-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 03:54:29 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 13 Jan 2013 02:54:29 +0000 Subject: [issue14208] No way to recover original argv with python -m In-Reply-To: <1331016803.5.0.715499259579.issue14208@psf.upfronthosting.co.za> Message-ID: <1358045669.67.0.1420367491.issue14208@psf.upfronthosting.co.za> Nick Coghlan added the comment: For PEP 432, I'm proposing to expose this as sys._configuration.raw_argv ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 05:06:17 2013 From: report at bugs.python.org (Todd Rovito) Date: Sun, 13 Jan 2013 04:06:17 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358049977.8.0.630367394594.issue16893@psf.upfronthosting.co.za> Todd Rovito added the comment: Andrew, Zachary and I worked on another issue together to sync idle.rst with help.txt here: http://bugs.python.org/issue5066 Issue 5066 is ready for commit if you have time by the way. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 08:07:07 2013 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 13 Jan 2013 07:07:07 +0000 Subject: [issue16946] subprocess: _close_open_fd_range_safe() does not set close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined In-Reply-To: <1358002453.56.0.227593845503.issue16946@psf.upfronthosting.co.za> Message-ID: <1358060827.35.0.685251465451.issue16946@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith -gps _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 09:12:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 08:12:33 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1358064753.92.0.358763020084.issue16398@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why only 2.7 and 3.4? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 09:18:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 08:18:27 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1358065107.63.0.738815760149.issue16922@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28675/etree_finditer_empty-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 09:19:06 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 08:19:06 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1358065146.55.0.506870029053.issue16922@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed. Patch updated. ---------- Added file: http://bugs.python.org/file28711/etree_finditer_empty-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 09:22:24 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Jan 2013 08:22:24 +0000 Subject: [issue16850] Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT In-Reply-To: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za> Message-ID: <1358065344.56.0.356529615894.issue16850@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 09:32:53 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Jan 2013 08:32:53 +0000 Subject: [issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex In-Reply-To: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za> Message-ID: <1358065973.17.0.534377179073.issue16899@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 09:36:23 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Jan 2013 08:36:23 +0000 Subject: [issue11844] Update json to upstream simplejson latest release In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za> Message-ID: <1358066183.09.0.668201347606.issue11844@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 09:36:51 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Jan 2013 08:36:51 +0000 Subject: [issue16879] distutils.command.config uses fragile constant temporary file name In-Reply-To: <1357476277.46.0.0647034504115.issue16879@psf.upfronthosting.co.za> Message-ID: <1358066211.87.0.390305804377.issue16879@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 09:59:27 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 13 Jan 2013 08:59:27 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1358067567.49.0.498722292492.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I just talked to Ezio on IRC about this. I think it will be a lot easier to review and see what's going on with these changes if they are put forth in smaller, bite-sized pieces and committed incrementally. It's harder to understand and have a dialogue about a large set of changes all at once. I gave him some suggestions for first commits in this direction and offered to help more with breaking things up into smaller pieces if he needs it. I also have an interest in simplifying our presentation/organization and in adding more information about using Mercurial more effectively (e.g. issue 16930 and issue 16931). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 10:11:14 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 13 Jan 2013 09:11:14 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1358068274.79.0.672014819712.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: I added more comments on bitbucket to indicate the new parts, the ones that have been moved, and the ones that have been removed. That should make reviews easier. I still haven't looked at the original FAQs (in faqs.rst), and still have to decide what should go where. The general idea is that committers-specific FAQs should go in committing.rst, and the rest should go in faqs.rst. Another option is to keep in committing.rst only the "4 fundamental FAQs" (i.e. "In what branches should I commit?", "In what order should I merge my commits?", "How do I merge between different branches (within the same major version)?", "How do I port a changeset between the two major Python versions (2.x and 3.x)?"), and move all the other stubs (including the one about null merges) on faqs.rst, possibly grouping them in two different sections: committers and contributors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 10:35:57 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 13 Jan 2013 09:35:57 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1358069757.88.0.0100798210217.issue14468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I think it could cause confusion to have FAQs spread across two different files because then we'll have to distinguish between two FAQs in our hyperlinks, and it won't be obvious which FAQ page contains which questions. I would recommend creating a new section in our existing FAQ called something like "Using Mercurial with CPython," optionally subdividing that into a committer section and an "everyone" section. The original section can be morphed into a section answering generic questions about Mercurial (not necessarily specific to CPython or the patch workflow). If a question is important enough to be on the same page as the rest of committing.rst, it can be added as a normal section of that page (what is the need to give all of those sections FAQ-style titles?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 10:41:15 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Jan 2013 09:41:15 +0000 Subject: [issue14208] No way to recover original argv with python -m In-Reply-To: <1358045669.67.0.1420367491.issue14208@psf.upfronthosting.co.za> Message-ID: <1358069933.3343.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > For PEP 432, I'm proposing to expose this as sys._configuration.raw_argv I think sys.raw_argv would be as good. It's not really (not only) a configuration item. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 10:46:24 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 13 Jan 2013 09:46:24 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1358070384.97.0.264440993342.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: I used FAQ-style titles to make easier to find the solution starting from a problem ("how do I do X?") and because I was planning to add more, but I can revert them to normal titles. So that would result in 4 sections: * Active branches (was "In what branches should I commit?"); * Merging order (was "In what order should I merge my commits?"); * Merging between different branches (within the same major version) (was "How do I merge between different branches (within the same major version)?"); * Porting changesets between the two major Python versions (2.x and 3.x) (was "How do I port a changeset between the two major Python versions (2.x and 3.x)?"); At the end of committing.rst I can add a link to the "committers faqs" in faqs.rst, and add more FAQs there. Everything about null merges, head merges, merge conflicts, long-term development branches etc. will go to faqs.rst. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 10:56:42 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 13 Jan 2013 09:56:42 +0000 Subject: [issue16949] removal of string exceptions is already done Message-ID: <1358071002.08.0.359993938626.issue16949@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe: This part of the PEP is written as if string exceptions are currently being removed, which is not the case. Also, it is probably more accurate to say "they are forbidden *and* are removed", instead of "they are forbidden *because* they are are removed. ---------- assignee: docs at python components: Documentation files: string-exceptions.diff keywords: patch messages: 179854 nosy: docs at python, tshepang priority: normal severity: normal status: open title: removal of string exceptions is already done Added file: http://bugs.python.org/file28712/string-exceptions.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:07:42 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Jan 2013 10:07:42 +0000 Subject: [issue16949] removal of string exceptions is already done In-Reply-To: <1358071002.08.0.359993938626.issue16949@psf.upfronthosting.co.za> Message-ID: <1358071662.11.0.372327658553.issue16949@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:16:29 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 13 Jan 2013 10:16:29 +0000 Subject: [issue14208] No way to recover original argv with python -m In-Reply-To: <1331016803.5.0.715499259579.issue14208@psf.upfronthosting.co.za> Message-ID: <1358072189.06.0.44115031601.issue14208@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm not seeing a good justification for doing anything more, though: - needing to access this information is an exceedingly niche use case - I don't see any way for raw_argv to be useful in a cross-implementation manner. - the exposure as sys._configuration.raw_argv is a natural consequence of the PEP 432 implementation (it's there to allow an embedding application to override the command line arguments seen by CPython) Elevating it to part of the language standard doesn't make sense, while exposing it as an implementation feature of the CPython initialisation process seems more reasonable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:19:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Jan 2013 10:19:20 +0000 Subject: [issue14208] No way to recover original argv with python -m In-Reply-To: <1358072189.06.0.44115031601.issue14208@psf.upfronthosting.co.za> Message-ID: <1358072218.3343.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > I'm not seeing a good justification for doing anything more, though: > > - needing to access this information is an exceedingly niche use case > - I don't see any way for raw_argv to be useful in a cross-implementation manner. I expect it to be useful in the "launch (almost) the same command in the same way" situation. Not that it happens often :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:20:38 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 13 Jan 2013 10:20:38 +0000 Subject: [issue16950] the old raise syntax is not legal in Python 3 Message-ID: <1358072438.43.0.0984946065161.issue16950@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe: There is an outdated statement that "the old form of raising exceptions *will* be removed in Python 3". It's ambiguous in that you don't know if such was ever in Python 3, and it is also time-sensitive (and now outdated). ---------- assignee: docs at python components: Documentation messages: 179857 nosy: docs at python, tshepang priority: normal severity: normal status: open title: the old raise syntax is not legal in Python 3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:20:58 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 13 Jan 2013 10:20:58 +0000 Subject: [issue16950] the old raise syntax is not legal in Python 3 In-Reply-To: <1358072438.43.0.0984946065161.issue16950@psf.upfronthosting.co.za> Message-ID: <1358072458.02.0.44409382388.issue16950@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- keywords: +patch Added file: http://bugs.python.org/file28713/raise-exception.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:26:31 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Jan 2013 10:26:31 +0000 Subject: [issue16949] removal of string exceptions is already done In-Reply-To: <1358071002.08.0.359993938626.issue16949@psf.upfronthosting.co.za> Message-ID: <3YkYrQ1YzMzR3j@mail.python.org> Roundup Robot added the comment: New changeset bf68a42a43bf by Georg Brandl in branch 'default': Closes #16949: update wording about string exceptions. http://hg.python.org/peps/rev/bf68a42a43bf ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:27:09 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Jan 2013 10:27:09 +0000 Subject: [issue16950] the old raise syntax is not legal in Python 3 In-Reply-To: <1358072438.43.0.0984946065161.issue16950@psf.upfronthosting.co.za> Message-ID: <3YkYs86mCnzRws@mail.python.org> Roundup Robot added the comment: New changeset 89db18c77152 by Georg Brandl in branch 'default': Closes #16950: update wording about raise syntax. http://hg.python.org/peps/rev/89db18c77152 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:33:40 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 13 Jan 2013 10:33:40 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1358070384.97.0.264440993342.issue14468@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: The combination of the last two suggestions sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:43:21 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 13 Jan 2013 10:43:21 +0000 Subject: [issue16951] expand on meaning of 'string literals that rely on significant trailing whitespace' Message-ID: <1358073801.18.0.127692907122.issue16951@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe: In PEP 8, there is: > Don't write string literals that rely on significant trailing whitespace It's not clear to me what this means, and therefore likely needs further explanation, or maybe an example. ---------- assignee: docs at python components: Documentation messages: 179861 nosy: docs at python, tshepang priority: normal severity: normal status: open title: expand on meaning of 'string literals that rely on significant trailing whitespace' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 11:47:36 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 13 Jan 2013 10:47:36 +0000 Subject: [issue16951] expand on meaning of 'string literals that rely on significant trailing whitespace' In-Reply-To: <1358073801.18.0.127692907122.issue16951@psf.upfronthosting.co.za> Message-ID: <1358074056.38.0.844333692594.issue16951@psf.upfronthosting.co.za> Georg Brandl added the comment: It means not write a = "abc " as a = """abc """ with the four spaces trailing at the end of the line. I don't think there is a more concise way of putting it in the PEP. ---------- nosy: +georg.brandl resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 12:04:07 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 13 Jan 2013 11:04:07 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1358075047.04.0.674036036428.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: I made a separate repo to implement this and divided the previous commits in smaller ones: https://bitbucket.org/ezio_melotti/devguide-14468 If this is OK, I'll start regrouping the FAQs in faqs.rst and then move there the section about long-term development of features. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 12:22:01 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Jan 2013 11:22:01 +0000 Subject: [issue11844] Update json to upstream simplejson latest release In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za> Message-ID: <1358076121.43.0.902040470076.issue11844@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Which simplejson features or fixes exactly are missing from the json module? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 12:39:29 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 11:39:29 +0000 Subject: [issue11159] Sax parser crashes if given unicode file name In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za> Message-ID: <1358077169.01.0.697580048088.issue11159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28268/sax_unicode_fn-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 12:42:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 11:42:37 +0000 Subject: [issue11159] Sax parser crashes if given unicode file name In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za> Message-ID: <1358077357.58.0.0320869316715.issue11159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file28268/sax_unicode_fn-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 12:44:33 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 13 Jan 2013 11:44:33 +0000 Subject: [issue11844] Update json to upstream simplejson latest release In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za> Message-ID: <1358077473.81.0.685804702487.issue11844@psf.upfronthosting.co.za> Ezio Melotti added the comment: Is there any reason why the two codebases are maintained separately instead of being kept in sync? (and what's the reason for simplejson to be still maintained? faster release cycles? compatibility with older Python versions?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 12:48:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 11:48:30 +0000 Subject: [issue11159] Sax parser crashes if given unicode file name In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za> Message-ID: <1358077710.4.0.307089613195.issue11159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ported tests for nonascii System-Id on 3.x. If no one objects I'll commit this next week. ---------- Added file: http://bugs.python.org/file28714/sax_unicode_fn-3.x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 13:17:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 12:17:57 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1358079477.23.0.29237583324.issue14377@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated (tostring() and tostringlist() refet to write()?about short_empty_elements parameter). Perhaps descriptions of encoding and method parameters should not be repeated too? > Why do you force short_empty_elements to be keyword only? Because sequences of parameters in XMLGenerator(), ElementTree.write(), ElementTree.tostring() are different and this can confuse. Also it will be easer to deprecate or rename keyword-only parameter in future (in favor of general fabric for example). I think that all optional, non-basic and very rarely used parameters should by keyword-only. ---------- Added file: http://bugs.python.org/file28715/etree_short_empty_elements_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 13:27:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 12:27:30 +0000 Subject: [issue11844] Update json to upstream simplejson latest release In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za> Message-ID: <1358080050.04.0.381052329177.issue11844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue16535. I doubt that json should support decimals in this manner, with special boolean parameter instead of general fabric function. Current simlejson has too many special parameters. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 13:29:42 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Jan 2013 12:29:42 +0000 Subject: [issue16535] json encoder unable to handle decimal In-Reply-To: <1353624338.46.0.574343718645.issue16535@psf.upfronthosting.co.za> Message-ID: <1358080182.6.0.610404859632.issue16535@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Decimal numbers should simply be serializable by default. It doesn't make sense to add a specialized option. ---------- components: +Library (Lib) type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 14:04:26 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 13 Jan 2013 13:04:26 +0000 Subject: [issue13659] Add a help() viewer for IDLE's Shell. In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za> Message-ID: <1358082266.06.0.298260925991.issue13659@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 14:16:11 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 13 Jan 2013 13:16:11 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1358082971.26.0.495876535961.issue2226@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Bump. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 14:26:58 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Jan 2013 13:26:58 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <3Ykdrf0LyQzSHW@mail.python.org> Roundup Robot added the comment: New changeset 849eb27baf1c by Eli Bendersky in branch '3.2': Issue #16922: fixed findtext() to return empty Unicode string instead of empty bytes object when there's no text. http://hg.python.org/cpython/rev/849eb27baf1c New changeset 6323e5f1ed81 by Eli Bendersky in branch '3.3': Issue #16922: fixed findtext() to return empty Unicode string instead of empty bytes object when there's no text. http://hg.python.org/cpython/rev/6323e5f1ed81 New changeset c38423931724 by Eli Bendersky in branch 'default': Issue #16922: fixed findtext() to return empty Unicode string instead of empty bytes object when there's no text. http://hg.python.org/cpython/rev/c38423931724 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 14:27:38 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 13 Jan 2013 13:27:38 +0000 Subject: [issue16922] ElementTree.findtext() returns empty bytes object instead of empty string In-Reply-To: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za> Message-ID: <1358083658.76.0.376730826688.issue16922@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 15:02:18 2013 From: report at bugs.python.org (Antoon Pardon) Date: Sun, 13 Jan 2013 14:02:18 +0000 Subject: [issue16915] mode of socket.makefile is more limited than documentation suggests In-Reply-To: <1357825217.2.0.655032840521.issue16915@psf.upfronthosting.co.za> Message-ID: <1358085738.03.0.174107240204.issue16915@psf.upfronthosting.co.za> Antoon Pardon added the comment: I think one could argue for allowing mode "r+" instead of "wb". Because "w" suggest truncation, which doesn't make sense on sockets either. But in the end I agree that allowing 'r', 'w', 'b' and 't' is probably the best compromise available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 15:05:09 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Jan 2013 14:05:09 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <3Ykfhj0XsFzPGT@mail.python.org> Roundup Robot added the comment: New changeset 58168d69b496 by Eli Bendersky in branch 'default': Close #14377: Add a new parameter to ElementTree.write and some module-level http://hg.python.org/cpython/rev/58168d69b496 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 15:09:41 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 13 Jan 2013 14:09:41 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1358086181.95.0.470252172368.issue14377@psf.upfronthosting.co.za> ?ric Araujo added the comment: I don?t think a space before the slash should be added. (It was common in the days of XHTML 1 because of an SGML parsing hack.) ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 15:21:34 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 13 Jan 2013 14:21:34 +0000 Subject: [issue16951] expand on meaning of 'string literals that rely on significant trailing whitespace' In-Reply-To: <1358074056.38.0.844333692594.issue16951@psf.upfronthosting.co.za> Message-ID: Tshepang Lekhonkhobe added the comment: > I don't think there is a more concise way of putting it in the PEP. Is it not more important to be clear than to be concise? Can't you put this info that PEP, or at least a link to this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 15:24:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 13 Jan 2013 14:24:57 +0000 Subject: [issue16952] test_kqueue failure on NetBSD/OpenBSD Message-ID: <1358087097.62.0.636962955587.issue16952@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: test_kqueue fails on both NetBSD and OpenBSD: http://buildbot.python.org/all/builders/AMD64 NetBSD 5.1.2 [SB] 2.7/builds/206/steps/test/logs/stdio http://buildbot.python.org/all/builders/x86 OpenBSD 5.1 [SB] 2.7/builds/153/steps/test/logs/stdio """ ====================================================================== FAIL: test_queue_event (test.test_kqueue.TestKQueue) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/test/test_kqueue.py", line 129, in test_queue_event (server.fileno(), select.KQ_FILTER_WRITE, flags)]) AssertionError: Lists differ: [(10L, 1, 5L), (11L, 1, 5L)] != [(10, 1, 0), (11, 1, 0)] First differing element 0: (10L, 1, 5L) (10, 1, 0) - [(10L, 1, 5L), (11L, 1, 5L)] ? - ^^ - ^^ + [(10, 1, 0), (11, 1, 0)] ? ^ """ The test assumes that the input flags (EV_ADD, EV_ENABLE...) will be returned in the output events. It's apparently not the case on OpenBSD and NetBSD (and probably on OS-X neither, because this check is disabled on this platform), and I can't see anything in the kqueue man pages hinting to this behavior (only specific flags will be set on output, like EV_ERROR). Knowing which flag was specified is not really useful actually. The patch attached just removes this check (we keep checking the file descriptors and filter, of course). ---------- components: Tests files: kqueue_flags.diff keywords: needs review, patch messages: 179877 nosy: neologix priority: normal severity: normal stage: patch review status: open title: test_kqueue failure on NetBSD/OpenBSD type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28716/kqueue_flags.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 15:27:21 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 13 Jan 2013 14:27:21 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1358086181.95.0.470252172368.issue14377@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: On Sun, Jan 13, 2013 at 6:09 AM, ?ric Araujo wrote: > > ?ric Araujo added the comment: > > I don?t think a space before the slash should be added. (It was common in > the days of XHTML 1 because of an SGML parsing hack.) > Ok, will fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 15:38:20 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 13 Jan 2013 14:38:20 +0000 Subject: [issue16951] expand on meaning of 'string literals that rely on significant trailing whitespace' In-Reply-To: <1358073801.18.0.127692907122.issue16951@psf.upfronthosting.co.za> Message-ID: <1358087900.71.0.765776201944.issue16951@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think the sentence is already clear enough --- editors often remove trailing spaces, so if they are significant (e.g. if they are in a string literal) they are at risk. This is actually more a general advice than a styling guideline, so I'm not even sure it belongs to the PEP 8. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 15:47:07 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 13 Jan 2013 14:47:07 +0000 Subject: [issue16945] rewrite CGIHTTPRequestHandler to always use subprocess In-Reply-To: <1358000083.64.0.0773347996342.issue16945@psf.upfronthosting.co.za> Message-ID: <1358088427.83.0.0614328273797.issue16945@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 16:16:47 2013 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 13 Jan 2013 15:16:47 +0000 Subject: [issue16953] select module compile errors with broken poll() Message-ID: <1358090207.46.0.168893562031.issue16953@psf.upfronthosting.co.za> New submission from Jeffrey Armstrong: On a platform with a broken poll() function (as detected during configure), Modules/selectmodule.c fails to compile. The error occurs at two points: ./Modules/selectmodule.c:2100: `select_poll' undeclared here (not in a function) ./Modules/selectmodule.c:2100: initializer element is not constant ./Modules/selectmodule.c:2100: (near initialization for `select_methods[1].ml_meth') ./Modules/selectmodule.c:2100: `poll_doc' undeclared here (not in a function) ./Modules/selectmodule.c:2100: initializer element is not constant ./Modules/selectmodule.c:2100: (near initialization for `select_methods[1].ml_doc') ./Modules/selectmodule.c: In function `PyInit_select': ./Modules/selectmodule.c:2159: `poll_Type' undeclared (first use in this function) ./Modules/selectmodule.c:2159: (Each undeclared identifier is reported only once ./Modules/selectmodule.c:2159: for each function it appears in.) The problem is occurring because both "select_poll" and "poll_Type" are undeclared if HAVE_BROKEN_POLL is declared. The fix would be on two lines: selectmodule.c:2099 #ifdef(HAVE_POLL) should be: #if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL) selectmodule.c:2149 #if defined(HAVE_POLL) should be: #if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL) Making these two minor changes allows selectmodule.c to compile fine in the case where the platform has a "broken" poll(). This bug was found on m68k-atari-mint compiling using gcc 2.95.3 ---------- components: Build messages: 179880 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: select module compile errors with broken poll() versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 16:26:53 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 15:26:53 +0000 Subject: [issue16954] Add docstrings for ElementTree module Message-ID: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Perhaps almost all Doxygen comments in ElementTree module should be converted to docstrings. ---------- assignee: docs at python components: Documentation, XML messages: 179881 nosy: docs at python, eli.bendersky, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Add docstrings for ElementTree module type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 16:33:08 2013 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 13 Jan 2013 15:33:08 +0000 Subject: [issue16953] select module compile errors with broken poll() In-Reply-To: <1358090207.46.0.168893562031.issue16953@psf.upfronthosting.co.za> Message-ID: <1358091188.78.0.486394182293.issue16953@psf.upfronthosting.co.za> Changes by Jeffrey Armstrong : ---------- type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 16:38:07 2013 From: report at bugs.python.org (Jaroslav Henner) Date: Sun, 13 Jan 2013 15:38:07 +0000 Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first time Message-ID: <1358091487.0.0.948421236656.issue1633941@psf.upfronthosting.co.za> Changes by Jaroslav Henner : ---------- nosy: +jary _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 16:42:34 2013 From: report at bugs.python.org (Daniel Shahaf) Date: Sun, 13 Jan 2013 15:42:34 +0000 Subject: [issue14208] No way to recover original argv with python -m In-Reply-To: <1358072218.3343.2.camel@localhost.localdomain> Message-ID: <20130113154210.GA2946@lp-shahaf.local> Daniel Shahaf added the comment: Antoine Pitrou wrote on Sun, Jan 13, 2013 at 10:19:20 +0000: > > Antoine Pitrou added the comment: > > > I'm not seeing a good justification for doing anything more, though: > > > > - needing to access this information is an exceedingly niche use case > > - I don't see any way for raw_argv to be useful in a cross-implementation manner. > > I expect it to be useful in the "launch (almost) the same command in the > same way" situation. > Not that it happens often :-) What about the "launch a different command with the same interpreter flags" use-case? For example, having 'python -E foo.py --foooptions' want to execute 'python -E bar.py'. Perhaps it'll be cleaner to expose in state_argv ['python', '-E']; in sys.argv ['foo.py', '--foooptions']; and have scripts that want to exec themselves use an idiomatic os.execv(sys.executable, sys.state_argv + sys.argv). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 17:10:59 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 13 Jan 2013 16:10:59 +0000 Subject: [issue16580] Add examples to int.to_bytes and int.from_bytes In-Reply-To: <1354217109.61.0.534443148437.issue16580@psf.upfronthosting.co.za> Message-ID: <1358093459.84.0.981727850144.issue16580@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- title: Add examples to int.to_bytres and int.from_bytes -> Add examples to int.to_bytes and int.from_bytes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 18:17:03 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 13 Jan 2013 17:17:03 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1358097423.73.0.827340278787.issue16954@psf.upfronthosting.co.za> Eli Bendersky added the comment: Definitely. And this is one of those issues where I can wholeheartedly say that patches are welcome :-) Even incremental patching will be OK (i.e. patches documenting single methods or groups of methods). Incidentally, while replacing the comment by docstring for issue #14377, I noticed an argument (default_namespace) that wasn't documented anywhere, including the ReST docs. So such a transition can have more benefits than seems on the surface. ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 18:27:13 2013 From: report at bugs.python.org (John Brearley) Date: Sun, 13 Jan 2013 17:27:13 +0000 Subject: [issue16920] multiprocessing.connection listener gets MemoryError onrecv In-Reply-To: <1357866356.83.0.954557409074.issue16920@psf.upfronthosting.co.za> Message-ID: John Brearley added the comment: Hi Richard: Thanks for the update. Yes, the multiprocessing.communication.Client works much better. The residual issue left here is wether Python is vulnerable to a DOS attack. If someone used regular sockets deliberately, they could crash multiprocessing server code deliberately. Any chance of doing a real message length check against the embedded message length check? Might not hurt for documentation to state that raw sockets are not supported, that you must use the client. Regards, John Brearley 613-259-5622 (H) ---------- title: multiprocessing.connection listener gets MemoryError on recv -> multiprocessing.connection listener gets MemoryError onrecv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 18:37:15 2013 From: report at bugs.python.org (John Brearley) Date: Sun, 13 Jan 2013 17:37:15 +0000 Subject: [issue16955] multiprocessing.connection poll() always returns false Message-ID: <1358098635.68.0.0505000601155.issue16955@psf.upfronthosting.co.za> New submission from John Brearley: In the attached multiprocessing.connection simple client script, the poll() method is always returning false. If I force the temp variable to 1, the recv()method happily gets the incoming data. I had hoped to use the poll() method to implement a timeout error, to avoid the blocking nature of the client. ---------- files: socket_client_mp.py messages: 179885 nosy: jbrearley priority: normal severity: normal status: open title: multiprocessing.connection poll() always returns false versions: Python 3.3 Added file: http://bugs.python.org/file28717/socket_client_mp.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 18:51:28 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Jan 2013 17:51:28 +0000 Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1358099488.2.0.233207786239.issue6975@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't really understand your algorithm. Why do you need a stack? It should be simply iterative: - if the symlink is relative, prepend the symlink target to the rest - if the symlink is absolute, discard the current path and prepend the symlink target to the rest Here is how pathlib does it: https://bitbucket.org/pitrou/pathlib/src/67a2524b057f1af5b3cba26370b1353e73cdda16/pathlib.py?at=default#cl-227 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 18:56:59 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Jan 2013 17:56:59 +0000 Subject: [issue16535] json encoder unable to handle decimal In-Reply-To: <1353624338.46.0.574343718645.issue16535@psf.upfronthosting.co.za> Message-ID: <1358099819.91.0.289852003221.issue16535@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 19:42:34 2013 From: report at bugs.python.org (Mark Shannon) Date: Sun, 13 Jan 2013 18:42:34 +0000 Subject: [issue16956] Allow signed line number deltas in the code object's line number table Message-ID: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za> New submission from Mark Shannon: The restriction that line numbers must be monotonically increasing w.r.t bytecode offset in the co_lnotab array prevents a number of beneficial transformations in the bytecode compiler. This patch allows negative line number deltas and uses this capability to generate code for 'while' loops in standard text book fashion, putting the test *after* the body. ---------- hgrepos: 172 messages: 179887 nosy: Mark.Shannon priority: normal severity: normal status: open title: Allow signed line number deltas in the code object's line number table _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 19:44:06 2013 From: report at bugs.python.org (Mark Shannon) Date: Sun, 13 Jan 2013 18:44:06 +0000 Subject: [issue16956] Allow signed line number deltas in the code object's line number table In-Reply-To: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za> Message-ID: <1358102646.94.0.635013738333.issue16956@psf.upfronthosting.co.za> Changes by Mark Shannon : ---------- keywords: +patch Added file: http://bugs.python.org/file28718/dd04caae6647.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 20:21:22 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 13 Jan 2013 19:21:22 +0000 Subject: [issue16500] Add an 'atfork' module In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za> Message-ID: <1358104882.45.0.0467142893481.issue16500@psf.upfronthosting.co.za> Georg Brandl added the comment: Might make sense to put this in atexit.atfork() to avoid small-module inflation? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 20:46:59 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 13 Jan 2013 19:46:59 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1358106419.46.0.137279156902.issue444582@psf.upfronthosting.co.za> Thomas Kluyver added the comment: The 'short circuit' appears to do what I'd consider the wrong thing when an executable file of the same name exists in the working directory. i.e. which('setup.py') can return 'setup.py', even though running 'setup.py' in a shell doesn't work (you need ./setup.py). This is on UNIX-y systems, I see from the comments that the cwd is implicitly on the path in Windows. Is this in scope for which() to deal with? Should I open a bug for it? Apologies if it's been discussed already. ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 20:56:35 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 13 Jan 2013 19:56:35 +0000 Subject: [issue16920] multiprocessing.connection listener gets MemoryError onrecv In-Reply-To: <1357838372.36.0.779855402088.issue16920@psf.upfronthosting.co.za> Message-ID: <1358106995.42.0.980699350211.issue16920@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > If someone used regular sockets deliberately, they could crash > multiprocessing server code deliberately. Any chance of doing a real message > length check against the embedded message length check? You can do message = conn.recv_bytes(maxlength) if you want a length check -- OSError will be raised if the message is too long. But Listener() and Client() are *not* replacements for the normal socket API and I would not really advise using them for communication over a network. They are mostly used internally by multiprocessing -- and then only with digest authentication. All processes in the same program inherit the same randomly generated authentication key -- current_process().authkey. If you create a listener by doing listener = Listener(address, authenticate=True) then other processes from the same program can connect by doing conn = Client(address, authenticate=True) Without knowing the correct authentication key it is not possible to connect and do a DOS like you describe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 21:22:38 2013 From: report at bugs.python.org (Brian Curtin) Date: Sun, 13 Jan 2013 20:22:38 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1358108558.26.0.994000297255.issue444582@psf.upfronthosting.co.za> Brian Curtin added the comment: Please open a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 21:23:17 2013 From: report at bugs.python.org (Michael Herrmann) Date: Sun, 13 Jan 2013 20:23:17 +0000 Subject: [issue2128] sys.argv is wrong for unicode strings In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za> Message-ID: <1358108597.28.0.211074273667.issue2128@psf.upfronthosting.co.za> Michael Herrmann added the comment: Hi, is it correct that this bug no longer appears in Python 2.7.3? I checked the changelogs of 2.7, but couldn't find anything. Thanks! Michael ---------- nosy: +mherrmann.at _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 21:31:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 20:31:38 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1358109098.39.0.183683081837.issue1159051@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 21:43:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Jan 2013 20:43:54 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1358109834.12.0.680326810221.issue14377@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I?think ?ric means different spaces, spaces in empty tags ( vs ). I don't know what the standard says about this. It should a separated issue. As for line continuations in docs, in all cases where they are occurred, a space used before a backslash for readability. I have reverted this change in 50606131a987. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 21:58:39 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 13 Jan 2013 20:58:39 +0000 Subject: [issue16955] multiprocessing.connection poll() always returns false In-Reply-To: <1358098635.68.0.0505000601155.issue16955@psf.upfronthosting.co.za> Message-ID: <1358110719.21.0.62997322184.issue16955@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Thanks for the report. It seems to only affect Windows, and only when using sockets rather than pipes. Till this is fixed you could use temp = bool(multiprocessing.connection.wait([cl], 1)) instead of temp = cl.poll(1) As I mentioned on the other issue, I would not advise use of Listener() and Client() without using authentication -- you are probably better off using raw sockets and select(). ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 22:06:22 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 13 Jan 2013 21:06:22 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <1358111182.48.0.0619970084682.issue10527@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The commits did not have the intended effect. They just define a _poll() function (and only on Windows) and it is not referenced anywhere else. I will look in to fixing this -- on 2.7 and 3.2 this will need to be done in the C code. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 22:35:24 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 13 Jan 2013 21:35:24 +0000 Subject: [issue16398] deque.rotate() could be much faster In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za> Message-ID: <1358112924.24.0.40028991246.issue16398@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Jes?s, I backported this to 2.7 because it was affecting intended usability of multiple parts of the API. The current code had the egregious and unintended side-effect of touching every data element during a rotate -- this resulted in a huge number of unnecessary cache line misses and was blowing useful data out of cache. IMO, a performance bug is different from a micro-optimization, especially if it is affecting the intended uses for part of an API. Serhiy, you're welcome to backport to 3.3 if you desire. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 22:43:00 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Jan 2013 21:43:00 +0000 Subject: [issue16500] Add an 'atfork' module In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za> Message-ID: <1358113380.27.0.673724312539.issue16500@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 22:43:08 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Jan 2013 21:43:08 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1358113388.5.0.959841632516.issue16935@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 23:13:51 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 13 Jan 2013 22:13:51 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems Message-ID: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> New submission from Thomas Kluyver: There's a 'short circuit' in shutil.which(), described as 'If we're given a full path which matches the mode and it exists, we're done here.' It also matches if an executable file of the same name is present in the working directory, although on most Unix-y systems you need ./ to execute such files in a shell (i.e. ./foo, not just foo). This could fool code calling which() into thinking that a program is installed, when it is not. If we consider this a bug, one simple fix would be to only allow the short circuit with an absolute path, so the line if _access_check(cmd, mode): would become if os.path.isabs(cmd) and _access_check(cmd, mode): ---------- components: Library (Lib) messages: 179897 nosy: takluyver priority: normal severity: normal status: open title: shutil.which() shouldn't look in working directory on unix-y systems type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 23:31:44 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 13 Jan 2013 22:31:44 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1358116304.16.0.281338736601.issue14377@psf.upfronthosting.co.za> Eli Bendersky added the comment: OK, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 23:52:36 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 13 Jan 2013 22:52:36 +0000 Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za> Message-ID: <1358117556.65.0.0169954753285.issue15651@psf.upfronthosting.co.za> Eli Bendersky added the comment: I looked at the patch a bit more in depth and must admit that I'm reluctant to apply it. It's a very large patch with very little documentation about what steps are taken and why, and I just don't see the motivation. The way I see it, PEP 384 is great for compatibility of third-party extensions and embeddings of Python, but much less critical for a module that's always distributed as part of stdlib and thus is kept in exact sync with the ABI of the Python version it comes with. Correct me if I'm wrong. That said, I won't object to some refactoring if it improves the code. But when such large changes are proposed, I really prefer to see small, incremental patches that replace just a part of the code. Such patches should come with an explanation of why the change is made (i.e. which part of PEP 384 does it adhere to). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 23:54:28 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Jan 2013 22:54:28 +0000 Subject: [issue16955] multiprocessing.connection poll() always returns false In-Reply-To: <1358098635.68.0.0505000601155.issue16955@psf.upfronthosting.co.za> Message-ID: <3YktRQ61nWzSH7@mail.python.org> Roundup Robot added the comment: New changeset e1c81ab5ad97 by Richard Oudkerk in branch '3.3': Issue #16955: Fix the poll() method for multiprocessing's socket http://hg.python.org/cpython/rev/e1c81ab5ad97 New changeset d904a741afde by Richard Oudkerk in branch 'default': Issue #16955: Fix the poll() method for multiprocessing's socket http://hg.python.org/cpython/rev/d904a741afde ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 13 23:56:11 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 13 Jan 2013 22:56:11 +0000 Subject: [issue16955] multiprocessing.connection poll() always returns false In-Reply-To: <1358098635.68.0.0505000601155.issue16955@psf.upfronthosting.co.za> Message-ID: <1358117771.29.0.204200910709.issue16955@psf.upfronthosting.co.za> Richard Oudkerk added the comment: This should be fixed now. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 00:30:07 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 13 Jan 2013 23:30:07 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <1358119807.06.0.258812294484.issue10527@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: What do you mean? The intent was to use poll() instead of select() anywhere available in order to avoid running out of fds. The change didn't affect Windows because as of right now select() is the only thing available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:06:27 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 14 Jan 2013 00:06:27 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1358121987.89.0.109308121743.issue16935@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Without the proposed enhancement, you could also combine ?ric's approach with the original patch by doing something like: try: support.import_module(module) except SkipTest: module = None def setUpModule(): if module is None: raise SkipTest() ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:08:42 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 14 Jan 2013 00:08:42 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1358122122.33.0.099940454913.issue16935@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Should be: "module = support.import_module('module')" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:13:56 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 00:13:56 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1358122436.97.0.767148288235.issue8145@psf.upfronthosting.co.za> R. David Murray added the comment: Here is a revised patch. I am leaving out the changes relating to the transaction manager. It turns out that the transaction manager doesn't do anything useful even if isolation_level is not None. I'm going to open a new issue to discuss the best way to fix it, and any documentation changes relating to any leftover brokenness will be part of that issue. ---------- Added file: http://bugs.python.org/file28719/sqlite_transaction_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:18:51 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 00:18:51 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1358122731.54.0.356700653301.issue8145@psf.upfronthosting.co.za> R. David Murray added the comment: I misspoke, the transaction manager does do something useful in non-None isolation level. I'm still going to open a bug about isolation_level None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:24:06 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 14 Jan 2013 00:24:06 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <1358123046.25.0.980709637277.issue10527@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > What do you mean? The intent was to use poll() instead of select() > anywhere available in order to avoid running out of fds. > The change didn't affect Windows because as of right now select() is > the only thing available. The change *only* effects Windows. Currently the code goes if sys.platform != 'win32': ... else: if hasattr(select, 'poll'): def _poll(fds, timeout): ... else: def _poll(fds, timeout): ... So _poll() is only defined when sys.platform == 'win32'. Furthermore, the _poll() function is never used anywhere: ConnectionBase.poll() uses Connection._poll(), which uses wait(), which uses select(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:32:43 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 14 Jan 2013 00:32:43 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <1358123563.59.0.895344659558.issue10527@psf.upfronthosting.co.za> Richard Oudkerk added the comment: It looks like the change to multiprocessing/connection.py committed does not match the one uploaded as issue10527-3.patch changeset 81174:e971a70984b8 1.1 --- a/Lib/multiprocessing/connection.py 1.2 +++ b/Lib/multiprocessing/connection.py 1.3 @@ -509,6 +509,27 @@ if sys.platform != 'win32': 1.4 return c1, c2 1.5 1.6 else: 1.7 + if hasattr(select, 'poll'): 1.8 + def _poll(fds, timeout): 1.9 + if timeout is not None: 1.10 + timeout = int(timeout) * 1000 # timeout is in milliseconds 1.11 + fd_map = {} 1.12 + pollster = select.poll() 1.13 + for fd in fds: 1.14 + pollster.register(fd, select.POLLIN) 1.15 + if hasattr(fd, 'fileno'): 1.16 + fd_map[fd.fileno()] = fd 1.17 + else: 1.18 + fd_map[fd] = fd 1.19 + ls = [] 1.20 + for fd, event in pollster.poll(timeout): 1.21 + if event & select.POLLNVAL: 1.22 + raise ValueError('invalid file descriptor %i' % fd) 1.23 + ls.append(fd_map[fd]) 1.24 + return ls 1.25 + else: 1.26 + def _poll(fds, timeout): 1.27 + return select.select(fds, [], [], timeout)[0] 1.28 1.29 def Pipe(duplex=True): 1.30 ''' issue10527-3.patch: diff --git a/Lib/multiprocessing/connection.py b/Lib/multiprocessing/connection.py --- a/Lib/multiprocessing/connection.py +++ b/Lib/multiprocessing/connection.py @@ -861,6 +861,27 @@ return [o for o in object_list if o in ready_objects] else: + if hasattr(select, 'poll'): + def _poll(fds, timeout): + if timeout is not None: + timeout = int(timeout) * 1000 # timeout is in milliseconds + fd_map = {} + pollster = select.poll() + for fd in fds: + pollster.register(fd, select.POLLIN) + if hasattr(fd, 'fileno'): + fd_map[fd.fileno()] = fd + else: + fd_map[fd] = fd + ls = [] + for fd, event in pollster.poll(timeout): + if event & select.POLLNVAL: + raise ValueError('invalid file descriptor %i' % fd) + ls.append(fd_map[fd]) + return ls + else: + def _poll(fds, timeout): + return select.select(fds, [], [], timeout)[0] def wait(object_list, timeout=None): ''' @@ -870,12 +891,12 @@ ''' if timeout is not None: if timeout <= 0: - return select.select(object_list, [], [], 0)[0] + return _poll(object_list, 0) else: deadline = time.time() + timeout while True: try: - return select.select(object_list, [], [], timeout)[0] + return _poll(object_list, timeout) except OSError as e: if e.errno != errno.EINTR: raise ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:46:45 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 00:46:45 +0000 Subject: [issue16958] The sqlite3 context manager does not work with isolation_level=None Message-ID: <1358124405.04.0.0310758361359.issue16958@psf.upfronthosting.co.za> New submission from R. David Murray: Its operation is also not particularly intuitive if isolation_level is not None, so its documentation needs some clarification. Currently the transaction manager does nothing on enter, and does a commit or rollback on exit, depending on whether or not there was an exception inside the with block. With isolation_level set to None, the sqlite3 library is in autocommit mode, so changes will get committed immediately inside the with, which is simply broken. If isolation_level is not None, then the behavior of the transaction manager depends heavily on what happens inside the with block. If the with block contains only the defined DQL statements (insert, update, delete, replace) and select statements, then things will work as expected. However, if another statement (such as a CREATE TABLE or a PRAGMA) is included in the with block, an intermediate commit will be done and a new transaction started. I propose to do two things to fix this issue: explain the above in the transactions manager docs, and have the context manager check to see if we are in isolation_level None, and if so, issue a begin (and then document that as well). One question is, can the fix be backported? It will change the behavior of code that doesn't throw an error, but most such code won't be doing what the author expected (run the with block inside a transaction...in pure autocommit mode the transaction manager is a no-op). One place code could break is if someone figured out this issue and worked around it by explicitly starting a transaction before (or after) entering the with block. In this case they would now get an error that a transaction cannot be started inside another. I would think this is unlikely...the more obvious workaround would be to write a custom transaction manager, so I suspect that that is what is actually in the field. But that's a (hopeful :) guess. A fix for this problem would be to use 'savepoint' instead of 'begin' if the sqlite3 version supports it (it is apparently supported as of 3.6.8). So, I'd like to see the fix, conditionally using SAVEPOINT, (once it written and tested) applied to all active python versions, but am open to the argument that it shouldn't be. ---------- components: Extension Modules, Library (Lib) keywords: easy messages: 179909 nosy: ghaering, r.david.murray priority: normal severity: normal stage: needs patch status: open title: The sqlite3 context manager does not work with isolation_level=None type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:47:22 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 00:47:22 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1358124442.55.0.794342511516.issue8145@psf.upfronthosting.co.za> R. David Murray added the comment: Opened issue 16958 for the transaction manager problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:47:59 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 00:47:59 +0000 Subject: [issue16958] The sqlite3 context manager does not work with isolation_level=None In-Reply-To: <1358124405.04.0.0310758361359.issue16958@psf.upfronthosting.co.za> Message-ID: <1358124479.68.0.630368425254.issue16958@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +nagylzs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 01:49:21 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 14 Jan 2013 00:49:21 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <1358124561.66.0.953628797492.issue10527@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Damn, you're right. I must have messed up something while porting the patch from 3.2 all the way up to 3.4 as the merge produced some conflicts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 02:04:22 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 14 Jan 2013 01:04:22 +0000 Subject: [issue16958] The sqlite3 context manager does not work with isolation_level=None In-Reply-To: <1358124405.04.0.0310758361359.issue16958@psf.upfronthosting.co.za> Message-ID: <1358125462.07.0.803043022036.issue16958@psf.upfronthosting.co.za> Martin v. L?wis added the comment: "changes will get committed immediately inside the with, which is simply broken" What do you mean by that? A. Changes ought to be committed immediately, but are not; it is broken, and changes must be committed immediately. - or - B. What actually happens is that changes are committed immediately, and sqlite is incorrect in doing so. Your discussion suggests B; in this case, I disagree that there is a bug. In auto-commit mode, it should really auto-commit, regardless of context managers. The context manager documentation doesn't claim otherwise. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 02:15:58 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 01:15:58 +0000 Subject: [issue16958] The sqlite3 context manager does not work with isolation_level=None In-Reply-To: <1358124405.04.0.0310758361359.issue16958@psf.upfronthosting.co.za> Message-ID: <1358126158.22.0.0656660966786.issue16958@psf.upfronthosting.co.za> R. David Murray added the comment: B, yes. So you would view the connection context manager acting as an actual transaction manager as a new feature? Would you be OK with adding that feature to the existing context manager in 3.4 (since currently the context manager is a noop in autocommit mode), or do you think we need to create a new context manager for this? Or do we do as the issue that sparked this (issue 8145) suggested, and just document how to create your own? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 02:24:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Jan 2013 01:24:27 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <3YkxmK3VnzzSJb@mail.python.org> Roundup Robot added the comment: New changeset 831f49cc00fc by Giampaolo Rodola' in branch 'default': fix for previous commit related to issue 10527 which didn't have the intended effect as per http://bugs.python.org/issue10527#msg179895 http://hg.python.org/cpython/rev/831f49cc00fc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 02:28:55 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 14 Jan 2013 01:28:55 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <1358126935.49.0.976063468612.issue10527@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: 3.3 and 3.4 branches should now be fixed. 2.7 and 3.2 still need to be fixed and the code from connections.py removed. Sorry for the mess up. ---------- assignee: giampaolo.rodola -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 03:17:44 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 Jan 2013 02:17:44 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1358129864.49.0.402460088381.issue16954@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 03:17:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 Jan 2013 02:17:58 +0000 Subject: [issue11159] Sax parser crashes if given unicode file name In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za> Message-ID: <1358129878.03.0.370835297602.issue11159@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 04:59:03 2013 From: report at bugs.python.org (Aaron Meurer) Date: Mon, 14 Jan 2013 03:59:03 +0000 Subject: [issue16959] rlcompleter doesn't work if __main__ can't be imported Message-ID: <1358135943.75.0.97619198268.issue16959@psf.upfronthosting.co.za> New submission from Aaron Meurer: The rlcompleter module does not work if __main__ cannot be imported, even though it can be used without it. For example, on the App Engine, __main__ is not usable. If one creates the example app described at https://developers.google.com/appengine/docs/python/gettingstartedpython27/helloworld, and adds "import rlcompleter" to the top of helloworld.py, you get the following error in the AppEngine Traceback (most recent call last): File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/runtime/wsgi.py", line 196, in Handle handler = _config_handle.add_wsgi_middleware(self._LoadHandler()) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/runtime/wsgi.py", line 255, in _LoadHandler handler = __import__(path[0]) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1766, in load_module return self.FindAndLoadModule(submodule, fullname, search_path) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1630, in FindAndLoadModule description) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1577, in LoadModuleRestricted description) File "/Users/aaronmeurer/Desktop/helloworld/helloworld.py", line 2, in import rlcompleter File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1766, in load_module return self.FindAndLoadModule(submodule, fullname, search_path) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1630, in FindAndLoadModule description) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1577, in LoadModuleRestricted description) File "/sw/lib/python2.7/rlcompleter.py", line 43, in import __main__ File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1766, in load_module return self.FindAndLoadModule(submodule, fullname, search_path) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1630, in FindAndLoadModule description) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate return func(self, *args, **kwargs) File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1577, in LoadModuleRestricted description) ImportError: Cannot re-init internal module __main__ Now, I don't really understand what the issue is here. I don't really get how __main__ is supposed to work, whether this is something that might be expected to happen in an environment that isn't highly modded like the App Engine's. Probably this should at least be considered an App Engine bug. My point is that it's possible to use the rlcompleter module completely without __main__, if one passes the optional argument to Completer. My suggestion is to catch ImportError when importing __main__, and if it isn't importable, make the argument to Completer required. It should be a minimal code change. ---------- components: Library (Lib) messages: 179917 nosy: Aaron.Meurer priority: normal severity: normal status: open title: rlcompleter doesn't work if __main__ can't be imported type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 05:07:14 2013 From: report at bugs.python.org (Aaron Meurer) Date: Mon, 14 Jan 2013 04:07:14 +0000 Subject: [issue16959] rlcompleter doesn't work if __main__ can't be imported In-Reply-To: <1358135943.75.0.97619198268.issue16959@psf.upfronthosting.co.za> Message-ID: <1358136434.26.0.691241593417.issue16959@psf.upfronthosting.co.za> Aaron Meurer added the comment: For completion, here's the corresponding App Engine issue I opened: http://code.google.com/p/googleappengine/issues/detail?id=8665. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 08:58:17 2013 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Jan 2013 07:58:17 +0000 Subject: [issue11159] Sax parser crashes if given unicode file name In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za> Message-ID: <1358150297.88.0.771150741415.issue11159@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't think that the file system encoding is the correct answer here. AFAIR expat uses UTF-8 encoded strings. Python 3.x uses PyArg_ParseTupleAndKeywords() with "s" which converts PyUnicode to PyBytes with the utf-8 codec. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 09:11:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 08:11:18 +0000 Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1358151077.98.0.474680451411.issue6975@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I don't really understand your algorithm. Why do you need a stack? Before resolving the symlink we mark the path as unresolved symlink for detecting infinite symlink loops. Before resolving the symlink we mark the path as resolved symlink (and cache the resolved value for speed) for allowing finite symlink recursion. Here is a test which pathlib fails. ---------- Added file: http://bugs.python.org/file28720/pathlib_resolve_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 09:59:39 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 14 Jan 2013 08:59:39 +0000 Subject: [issue16960] Fix PEP8 errors in stdlib. Message-ID: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za> New submission from Ramchandra Apte: This bug is intended to contain all the patches for fixing PEP8 errors in stdlib. I am thinking of using a tool such as autopep8 to help fix the errors. ---------- messages: 179921 nosy: ramchandra.apte priority: normal severity: normal status: open title: Fix PEP8 errors in stdlib. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:00:05 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 14 Jan 2013 09:00:05 +0000 Subject: [issue16960] Fix PEP8 errors everywhere In-Reply-To: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za> Message-ID: <1358154005.9.0.210748873583.issue16960@psf.upfronthosting.co.za> Ramchandra Apte added the comment: s/stdlib/everywhere ---------- components: +None title: Fix PEP8 errors in stdlib. -> Fix PEP8 errors everywhere _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:04:34 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 Jan 2013 09:04:34 +0000 Subject: [issue16960] Fix PEP8 errors everywhere In-Reply-To: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za> Message-ID: <1358154274.58.0.372345150737.issue16960@psf.upfronthosting.co.za> Ezio Melotti added the comment: Sorry, but we don't fix style issue unless we are already working on that code for some other reasons. ---------- nosy: +ezio.melotti resolution: -> rejected stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:05:43 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 14 Jan 2013 09:05:43 +0000 Subject: [issue16960] Fix PEP8 errors everywhere In-Reply-To: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za> Message-ID: <1358154343.22.0.29347672592.issue16960@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Why? This may be low priority. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:09:13 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 Jan 2013 09:09:13 +0000 Subject: [issue16960] Fix PEP8 errors everywhere In-Reply-To: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za> Message-ID: <1358154553.79.0.348742037096.issue16960@psf.upfronthosting.co.za> Ezio Melotti added the comment: Several reasons, e.g.: * there's the risk of introducing new bugs; * it makes merging more difficult; * it takes time to produce and review the patches; * it makes hg annotate harder to use; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:12:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 09:12:02 +0000 Subject: [issue11159] Sax parser crashes if given unicode file name In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za> Message-ID: <1358154722.35.0.22152700111.issue11159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, this thing was doubted me too. I proceeded from the following considerations. 1. Often system id is used for file operations and in this case you need to use the file system encoding. Unfortunately Python 2 does not have 'surrogateescape' handler which would allow to encode arbitrary name and then restore and re-encode it for file operations. 2. Python 2 in contrary to Python 3 accepts bytes and they may not be valid UTF-8. We have to choose between compatibility with Python 2 and Python 3. I chose the first, because it is more important for bugfix. May be I am wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:13:28 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Jan 2013 09:13:28 +0000 Subject: [issue16500] Add an 'atfork' module In-Reply-To: <1358113380.32.0.00441020823972.issue16500@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Might make sense to put this in atexit.atfork() to avoid small-module inflation? It sounds strange to mix "at exit" and "at fork" in the same module. Both are very different. 2013/1/13 Arfrever Frehtes Taifersar Arahesis : > > Changes by Arfrever Frehtes Taifersar Arahesis : > > > ---------- > nosy: +Arfrever > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:15:31 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Jan 2013 09:15:31 +0000 Subject: [issue2128] sys.argv is wrong for unicode strings In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za> Message-ID: <1358154931.94.0.939043823008.issue2128@psf.upfronthosting.co.za> STINNER Victor added the comment: > is it correct that this bug no longer appears in Python 2.7.3? Martin wrote that it cannot be fixed in Python 2: "For 2.6, I don't think fixing it is feasible." The "fix" is to upgrade your application to Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:35:14 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Jan 2013 09:35:14 +0000 Subject: [issue16960] Fix PEP8 errors everywhere In-Reply-To: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za> Message-ID: <1358156114.72.0.912164170968.issue16960@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I concur with Ezio's reasons for rejecting this. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 10:58:26 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 14 Jan 2013 09:58:26 +0000 Subject: [issue16960] Fix PEP8 errors everywhere In-Reply-To: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za> Message-ID: <1358157506.32.0.542229244426.issue16960@psf.upfronthosting.co.za> Ramchandra Apte added the comment: It's a valid bug report however difficult or low priority it is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 11:46:58 2013 From: report at bugs.python.org (lekma) Date: Mon, 14 Jan 2013 10:46:58 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1358160418.37.0.0507342646726.issue15870@psf.upfronthosting.co.za> Changes by lekma : ---------- nosy: +lekma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 11:57:01 2013 From: report at bugs.python.org (gac) Date: Mon, 14 Jan 2013 10:57:01 +0000 Subject: [issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays In-Reply-To: <1357821708.32.0.469925509105.issue16914@psf.upfronthosting.co.za> Message-ID: <1358161021.55.0.14673184928.issue16914@psf.upfronthosting.co.za> gac added the comment: Here's a second path I've done for the current/default branch, using a separate print function for output, as recommended by Berker Peksag. I tried to add it as a separate patch set using the code review tool but every time I did, I just got a screen full of debug output from Django so I'm going to attach it here instead. The for loop on args inside _print_debug probably isn't ideal, but I've done this to try and make sure that debuglevel 1 output is identical to what it was before my patches. Because args is passed into _print_debug as a tuple, I found that when doing "print(message, args, file=stderr)" it introduced the extra parentheses and quotes inherent with a tuple into the output. By concatenating string representations of this tuple onto the existing string it means the original output format is duplicated exactly. There may be a speed penalty for this, but realistically it seems that a minor speed penalty would be expected when using debugging options and the output consistency trumps raw speed for debugging. Once I've found a way of achieving the same in 2.7 (i.e. maintaining the original output format when being passed a tuple, the approach I've used for Python 3 doesn't seem to have the desired affect in 2.7) then I'll hopefully submit a patch for that as well. ---------- Added file: http://bugs.python.org/file28721/smtplib.34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 12:00:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 11:00:23 +0000 Subject: [issue11159] Sax parser crashes if given unicode file name In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za> Message-ID: <1358161223.33.0.241230317065.issue11159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is an alternative patch. It doesn't encode system id when it settled, instead system id attribute can be bytes or an unicode and encoding/decoding happened only a file opened. ---------- Added file: http://bugs.python.org/file28722/sax_unicode_fn_alt-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 12:09:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 11:09:17 +0000 Subject: [issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za> Message-ID: <1358161757.29.0.25580277384.issue16903@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 12:09:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 11:09:56 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1358161796.83.0.545873079439.issue16954@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 12:52:31 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 11:52:31 +0000 Subject: [issue16960] Fix PEP8 errors everywhere In-Reply-To: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za> Message-ID: <1358164351.74.0.0754180223378.issue16960@psf.upfronthosting.co.za> R. David Murray added the comment: It is valid, but it is not *useful* to have it in the bug tracker as an open bug. All developers are aware that when they touch code for some other reason, they can fix PEP8 errors at the same time. Having an open bug report for it would just clutter the ticket system for no practical purpose. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 13:03:15 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 Jan 2013 12:03:15 +0000 Subject: [issue16961] No regression tests for -E and individual environment vars Message-ID: <1358164994.53.0.497203238771.issue16961@psf.upfronthosting.co.za> New submission from Nick Coghlan: Accessing an environment variable without Py_GETENV (or breaking Py_IgnoreEnvironmentFlag configuration *cough*) may lead to environment variables being accessed even if -E is passed on the command line. As part of the PEP 432 implementation, I'm adding appropriate regression tests for affected environment variables as I go. Creating this as a reminder to look into backporting the relevant regression tests at least to 3.3 ---------- assignee: ncoghlan messages: 179934 nosy: ncoghlan priority: normal severity: normal status: open title: No regression tests for -E and individual environment vars versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 13:15:30 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 12:15:30 +0000 Subject: [issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays In-Reply-To: <1357821708.32.0.469925509105.issue16914@psf.upfronthosting.co.za> Message-ID: <1358165730.3.0.523487484377.issue16914@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the suggestion and patch. I haven't reviewed it thoroughly yet, but if you change _print_debug to be: def _print_debug(*args): then print(datetime.datetime.now(), *args, file=stderr) should do what you want for python3 (I don't think the [] are needed, personally). This patch won't be applied to 2.7, which I presume you know, so making that work would be for informational purposes only. ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 13:16:49 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 12:16:49 +0000 Subject: [issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays In-Reply-To: <1357821708.32.0.469925509105.issue16914@psf.upfronthosting.co.za> Message-ID: <1358165809.39.0.839055355703.issue16914@psf.upfronthosting.co.za> R. David Murray added the comment: Er, that should have been (self, *args), but actually I'd recommend making it a module function, not a method, in which case my signature would be correct :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 13:22:02 2013 From: report at bugs.python.org (Riku Voipio) Date: Mon, 14 Jan 2013 12:22:02 +0000 Subject: [issue16962] _posixsubprocess module uses outdated getdents system call Message-ID: <1358166122.64.0.0915225985014.issue16962@psf.upfronthosting.co.za> New submission from Riku Voipio: Getdents system call was superseded with with getdents64 in Linux 2.4 (January 2001). New architectures, such as 64-Bit ARM opt out not to support legacy system calls, and getdents is one of them. Since getdents64 has been supported for over a decade, I don't think adding ifdef to support both makes sense. Using getdents64 cleans up the current _posixsubprocess code as the entries are long long everywhere. The attached patch makes _posixsubprocess module compile on 64-Bit ARM and causes on regressions on the python3.3 testsuite on x86 and x86_64 ---------- components: Extension Modules files: movetogetdents64.diff keywords: patch messages: 179937 nosy: riku-voipio priority: normal severity: normal status: open title: _posixsubprocess module uses outdated getdents system call versions: Python 3.3 Added file: http://bugs.python.org/file28723/movetogetdents64.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 13:54:15 2013 From: report at bugs.python.org (sean) Date: Mon, 14 Jan 2013 12:54:15 +0000 Subject: [issue16963] module html.parser HTMLParser's strict mode don't work Message-ID: <1358168055.33.0.344614733443.issue16963@psf.upfronthosting.co.za> New submission from sean: NOTE: SAME AS Python 3.2.2, Python 3.3 from python.org/download Python 3.2.2 Stackless 3.1b3 060516 (default, Feb 20 2012, 13:36:12) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> from html.parser import HTMLParser >>> class LooseParser(HTMLParser): def __init__(self, strict=False): HTMLParser.__init__(self, strict=strict) def handle_starttag(self, tag, attrs): print('Tag:', tag) >>> p = LooseParser() >>> p.feed('

hello

') >>> ---------- components: Library (Lib) messages: 179938 nosy: pysean priority: normal severity: normal status: open title: module html.parser HTMLParser's strict mode don't work type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 14:00:02 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 Jan 2013 13:00:02 +0000 Subject: [issue16963] module html.parser HTMLParser's strict mode don't work In-Reply-To: <1358168055.33.0.344614733443.issue16963@psf.upfronthosting.co.za> Message-ID: <1358168402.33.0.076525274527.issue16963@psf.upfronthosting.co.za> Ezio Melotti added the comment: It works for me on 3.2.3, 3.2.3+, 3.3.0+, 3.4.0a0 >>> from html.parser import HTMLParser >>> class LooseParser(HTMLParser): ... def __init__(self, strict=False): ... HTMLParser.__init__(self, strict=strict) ... def handle_starttag(self, tag, attrs): ... print('Tag:', tag) ... >>> p = LooseParser() >>> p.feed('

hello

') Tag: p >>> ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 14:01:49 2013 From: report at bugs.python.org (sean) Date: Mon, 14 Jan 2013 13:01:49 +0000 Subject: [issue16963] module html.parser HTMLParser's strict mode don't work In-Reply-To: <1358168055.33.0.344614733443.issue16963@psf.upfronthosting.co.za> Message-ID: <1358168509.19.0.70166772656.issue16963@psf.upfronthosting.co.za> sean added the comment: SAME AS #issue13273 http://bugs.python.org/issue13273 ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 14:02:59 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 Jan 2013 13:02:59 +0000 Subject: [issue16963] module html.parser HTMLParser's strict mode don't work In-Reply-To: <1358168055.33.0.344614733443.issue16963@psf.upfronthosting.co.za> Message-ID: <1358168579.08.0.596573077136.issue16963@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 14:28:36 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 14 Jan 2013 13:28:36 +0000 Subject: [issue1602133] non-framework python fails to define os.environ properly Message-ID: <1358170116.7.0.474319885319.issue1602133@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The patch didn't work for me because I manually applied and missed a bit. The patches fixes for me, and the environ(7) manpage also indicates that the call to _NSEnvironment is needed in shared libraries. I've attached a slightly different version of the patch that only enabled the _NSGetEnvironment path for shared library builds (--enable-shared and --enable-framework) and doesn't change anything for the default static builds. Ned: I think this is a bugfix and should be merged into all active branches. Do you agree? If so, I'll apply the patch. ---------- nosy: +ned.deily versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 14:35:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 13:35:33 +0000 Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16) Message-ID: <1358170533.75.0.425658391122.issue1470548@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated. Fixed an error which Georg have found. Restored testing XMLGenerator with StringIO as Antoine pointed. Now XMLGenerator tested for StringIO, BytesIO and an user writer. Added tests for encoding. ---------- keywords: -easy Added file: http://bugs.python.org/file28724/XMLGenerator-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 14:36:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 13:36:14 +0000 Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16) Message-ID: <1358170574.17.0.340390488629.issue1470548@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 15:36:10 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 14 Jan 2013 14:36:10 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358174170.3.0.652970123754.issue12939@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Added some comments on Rietveld. The .fileno() method is missing. Can this cause a problem when the file is passed to stdlib functions? subprocess for example? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 15:42:27 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2013 14:42:27 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358174547.26.0.0943785723003.issue12939@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What does this proposal bring exactly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 16:49:37 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 14 Jan 2013 15:49:37 +0000 Subject: [issue16500] Add an 'atfork' module In-Reply-To: <1358033855.49.0.878450514405.issue16500@psf.upfronthosting.co.za> Message-ID: <50F4290D.6090702@egenix.com> Marc-Andre Lemburg added the comment: On 13.01.2013 00:37, STINNER Victor wrote: > By the way, OpenSSL expects that its PRNG is reseed somehow (call RNG_add) after a fork. I wrote a patch for OpenSSL, but I don't remember if I sent it to OpenSSL. > https://bitbucket.org/haypo/hasard/src/4a1be69a47eb1b2ec7ca95a341d4ca953a77f8c6/patches/openssl_rand_fork.patch?at=default Apparently not, and according to this thread, they don't think this is an OpenSSL problem to solve: http://openssl.6102.n7.nabble.com/recycled-pids-causes-PRNG-to-repeat-td41669.html Note that you don't have to reseed the RNG just make sure that the two forks use different sequences. Simply adding some extra data in each process will suffice, e.g. by adding the PID of the new process to the RNG pool. This is certainly doable without any major CPU overhead :-) ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 16:58:37 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2013 15:58:37 +0000 Subject: [issue16962] _posixsubprocess module uses outdated getdents system call In-Reply-To: <1358166122.64.0.0915225985014.issue16962@psf.upfronthosting.co.za> Message-ID: <1358179117.8.0.486037503211.issue16962@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +gregory.p.smith stage: -> patch review type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:01:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2013 16:01:23 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1358179283.8.0.517723255278.issue16935@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Still, raising SkipTest from the toplevel is useful when some toplevel setup code otherwise depends on the missing module. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:02:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 16:02:28 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1358179348.99.0.184958081173.issue13968@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I should add a symlink loop detecting to _rlistdir() as Antoine advised me on IRC. ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:03:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2013 16:03:32 +0000 Subject: [issue16956] Allow signed line number deltas in the code object's line number table In-Reply-To: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za> Message-ID: <1358179412.41.0.333930890183.issue16956@psf.upfronthosting.co.za> Antoine Pitrou added the comment: How does this interact with pdb? ---------- nosy: +georg.brandl, haypo, pitrou stage: -> patch review type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:06:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jan 2013 16:06:08 +0000 Subject: [issue16500] Add an 'atfork' module In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za> Message-ID: <1358179568.46.0.341885384038.issue16500@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It sounds strange to mix "at exit" and "at fork" in the same module. > Both are very different. That's true. The sys module would probably be the right place for both functionalities. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:17:15 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 16:17:15 +0000 Subject: [issue16715] Get rid of IOError. Use OSError instead In-Reply-To: <3YW0Xs2j15zRkN@mail.python.org> Message-ID: <1358180235.61.0.620191143423.issue16715@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Please email python-dev if you think LoadError should be directly specified. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:31:00 2013 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Jan 2013 16:31:00 +0000 Subject: [issue16944] German number separators not working using format language and locale "de_DE" In-Reply-To: <1357990016.64.0.159100060877.issue16944@psf.upfronthosting.co.za> Message-ID: <1358181060.35.0.784643288178.issue16944@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think this issue should be closed, since we're doing as we're instructed by the OS. If someone wants to open a new issue for the "m" format specifier type, I'd support that. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:34:47 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Jan 2013 16:34:47 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1358181287.87.0.808400606238.issue16935@psf.upfronthosting.co.za> Zachary Ware added the comment: I agree that raising SkipTest (or subclasses thereof, such as ResourceDenied) at module level should be supported. That would mean no changes would be needed in most of the should-be-skipped-but-fail-instead tests listed in issue 16748 to make test discovery play nicely, and in fact the changes to test_crypt could be mostly reverted. Personally, I don't find either of the suggestions given as alternates to what I did in test_crypt to be particularly prettier, not that what I did is pretty either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:49:42 2013 From: report at bugs.python.org (Stefan Krah) Date: Mon, 14 Jan 2013 16:49:42 +0000 Subject: [issue16944] German number separators not working using format language and locale "de_DE" In-Reply-To: <1357990016.64.0.159100060877.issue16944@psf.upfronthosting.co.za> Message-ID: <1358182182.79.0.535249997158.issue16944@psf.upfronthosting.co.za> Stefan Krah added the comment: I agree, we can't really do anything here. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:52:38 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Jan 2013 16:52:38 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358182358.88.0.391068480036.issue16893@psf.upfronthosting.co.za> Zachary Ware added the comment: Georg: > Note that Sphinx' "make text" output already should be suitable. We > already update the pydoc topics with that on every release, so we could > just as well do the same for the IDLE doc. No need for another > separate script. I take it this would mean generating help.txt and then checking it in? Otherwise, users who built their own Python would likely run into issues with IDLE not finding its help file, or would be required to have sphinx available. That's not quite what I had in mind, but if we already do it for pydoc topics, it sounds fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 17:54:54 2013 From: report at bugs.python.org (Stefan Krah) Date: Mon, 14 Jan 2013 16:54:54 +0000 Subject: [issue16964] Add 'm' format specifier for mon_grouping etc. Message-ID: <1358182494.33.0.0372215578091.issue16964@psf.upfronthosting.co.za> New submission from Stefan Krah: This issue proposes an additional 'm' format specifier that behaves like 'n', but uses mon_grouping, mon_decimal_point and mon_thousands_sep. See #16944 for the rationale. ---------- components: Interpreter Core messages: 179955 nosy: Peter.Stahl, eric.smith, mark.dickinson, skrah priority: low severity: normal stage: needs patch status: open title: Add 'm' format specifier for mon_grouping etc. type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 18:19:56 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Jan 2013 17:19:56 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1358183996.71.0.934435600005.issue16748@psf.upfronthosting.co.za> Zachary Ware added the comment: Chris: > There are lots of modules to change here. I wonder if some or most of > this couldn't be automated. Possibly, but I don't mind going through individually if Ezio (or others) don't mind committing individually. From what I've seen, the test suite is varied enough within itself that it would be pretty hard to properly automate the changes I've been making. Also, I'm of the opinion that we'll end up with a higher quality result doing things by hand anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 18:27:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Jan 2013 17:27:48 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <3YlM832zflzR26@mail.python.org> Roundup Robot added the comment: New changeset d1ef91025d70 by Andrew Svetlov in branch 'default': Issue #5066: Update IDLE docs http://hg.python.org/cpython/rev/d1ef91025d70 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 18:28:16 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 17:28:16 +0000 Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za> Message-ID: <1358184496.97.0.594759371407.issue5066@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Pushed. Thanks. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 18:31:04 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 17:31:04 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358184664.66.0.922614747849.issue16893@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Regenerating idle.txt and committing it is fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 18:34:40 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 17:34:40 +0000 Subject: [issue16932] urlparse fails at parsing "www.python.org:80/" In-Reply-To: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za> Message-ID: <1358184880.03.0.478222731649.issue16932@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:00:36 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 14 Jan 2013 18:00:36 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358186436.86.0.128557328409.issue16893@psf.upfronthosting.co.za> Georg Brandl added the comment: > I take it this would mean generating help.txt and then checking it in? Otherwise, users who built their own Python would likely run into issues with IDLE not finding its help file, or would be required to have sphinx available. Yes, it will be checked in. > That's not quite what I had in mind, but if we already do it for pydoc topics, it sounds fine to me. I don't think we have to worry about it getting out of date quickly. Automatically generating the IDLE help at run time from a documentation source file is not posssible anyway, since the doc sources are not available in a standard location for installed Pythons. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:06:19 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Jan 2013 18:06:19 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358186779.44.0.553755410795.issue16893@psf.upfronthosting.co.za> Zachary Ware added the comment: > I don't think we have to worry about it getting out of date quickly. Fair point :) > Automatically generating the IDLE help at run time from a documentation > source file is not posssible anyway, since the doc sources are not > available in a standard location for installed Pythons. This isn't quite what I meant either; I had intended it to be done at either Python build or install time. Your method is much simpler, though, I like it. That said, here's the diff between the (now) current Lib/idlelib/help.txt and the Sphinx ``make text`` output of Doc/library/idle.rst. I've not found where we've automated the pydoc topics generation, else I'd try to provide a patch to do this as well. ---------- keywords: +patch Added file: http://bugs.python.org/file28725/issue16893.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:15:22 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 14 Jan 2013 18:15:22 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358187322.73.0.672584899071.issue16893@psf.upfronthosting.co.za> Georg Brandl added the comment: The unified diff is not very helpful; I think somebody has to put the files side by side and merge. The pydoc topics are built with a custom Sphinx builder implemented in tools/sphinxext/pyspecific.py -- but if we just want the vanilla text builder output it should be enough to add a Doc/Makefile target: idledoc: BUILDER = text idledoc: SOURCES = library/idle idledoc: build @echo "Build finished; now copying build/text/library/idle.txt to ../Lib/idlelib/help.txt." @cp build/text/library/idle.txt ../Lib/idlelib/help.txt and I add a step to PEP 101 to run this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:16:07 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 14 Jan 2013 18:16:07 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358187367.76.0.505940606462.issue16893@psf.upfronthosting.co.za> Georg Brandl added the comment: To make it actually work, replace "library/idle" by "library/idle.rst". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:24:06 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 14 Jan 2013 18:24:06 +0000 Subject: [issue16965] 2to3 should rewrite execfile() to open in 'rb' mode Message-ID: <1358187846.57.0.700535378161.issue16965@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: In this distribute bug I describe a problem when pip installing mimeparse, which has a setup.py with a BOM. distribute uses execfile() which gets fixed in Python 3 to use a combination of compile(open()) as the fixer. https://bitbucket.org/tarek/distribute/issue/349/dont-rely-on-2to3-to-properly-rewrite I think the problem is that the fixer opens the file in text mode, which leaves the BOM as a bogus first character, causing the SyntaxError. Instead, if the fixer opened the file in binary mode, then the BOM would be handled correctly by compile(). ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 179964 nosy: barry priority: normal severity: normal status: open title: 2to3 should rewrite execfile() to open in 'rb' mode versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:28:43 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 Jan 2013 18:28:43 +0000 Subject: [issue1602133] non-framework python fails to define os.environ properly Message-ID: <1358188123.9.0.870188248358.issue1602133@psf.upfronthosting.co.za> Ned Deily added the comment: Ronald: the patch? ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:29:22 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 14 Jan 2013 18:29:22 +0000 Subject: [issue1602133] non-framework python fails to define os.environ properly Message-ID: <1358188162.43.0.731914268947.issue1602133@psf.upfronthosting.co.za> Changes by Ronald Oussoren : Added file: http://bugs.python.org/file28726/1602133.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:31:03 2013 From: report at bugs.python.org (John Brearley) Date: Mon, 14 Jan 2013 18:31:03 +0000 Subject: [issue16955] multiprocessing.connection poll() always returns false In-Reply-To: <1358110719.21.0.62997322184.issue16955@psf.upfronthosting.co.za> Message-ID: <052D93B9FBAF4346AFD227B575266D0B@jrb> John Brearley added the comment: Hi Rchard: Thanks very much. The wait() method works fine. Regards, John Brearley 613-259-5622 (H) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:39:00 2013 From: report at bugs.python.org (John Brearley) Date: Mon, 14 Jan 2013 18:39:00 +0000 Subject: [issue16920] multiprocessing.connection listener gets MemoryErroronrecv In-Reply-To: <1358106995.42.0.980699350211.issue16920@psf.upfronthosting.co.za> Message-ID: John Brearley added the comment: Hi Richard: Thanks for pointers on other methods. I am coming from a TCL background, and learning Python. I have gone through regular sockets, select, asyncore, sockserv, threading and multiprocessing modules. Only multiprocessing seems to be able to use more than a single CPU and the listener is nicely shared between proceses. Is there another module that that would be better suited spreading tasks around CPUS and communicating between hosts? I am trying to understand your reservations about using them for communication over a network Yes, if I was doing a production server, I would turn on authentication. Regards, John Brearley 613-259-5622 (H) ---------- title: multiprocessing.connection listener gets MemoryError onrecv -> multiprocessing.connection listener gets MemoryErroronrecv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 19:42:54 2013 From: report at bugs.python.org (John Brearley) Date: Mon, 14 Jan 2013 18:42:54 +0000 Subject: [issue16966] Publishing multiprocessing listener code Message-ID: <8053927136E1407BA60A52EA84F498B8@jrb> New submission from John Brearley: Hi Richard: I have published my multiprocessing server & client scripts on the 2 web sites shown below in the hopes that they will help others learning this module. I haven't seen anyplace on the python.org web site that might be suitable for a copy. Are people encouraged to post sample scripts on python.org? http://codereview.stackexchange.com/questions/20516/sample-python-multiprocessin g-connection-server http://www.tek-tips.com/viewthread.cfm?qid=1701937 Regards, John Brearley 613-259-5622 (H) ---------- messages: 179968 nosy: jbrearley priority: normal severity: normal status: open title: Publishing multiprocessing listener code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 20:03:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 19:03:15 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1358190195.41.0.464608766177.issue1159051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: At the moment gzip can raise two errors on unexpected EOF: struct.error from struct.unpack() or TypeError from ord(). Both bz2 and lzma raise EOFError in such cases. The proposed patch converts both truncated gzip errors to EOFError as for bz2 and lzma. Added similar tests for gzip, bz2 and lzma. I?doubt about backward compatibility. It's obvious that struct.error and TypeError are unintentional, and EOFError is purposed for this case. However users can catch undocumented but de facto exceptions and doesn't expect EOFError. ---------- nosy: +nadeem.vawda stage: needs patch -> patch review versions: +Python 3.3, Python 3.4 -Python 3.1 Added file: http://bugs.python.org/file28727/gzip_eof-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 20:37:14 2013 From: report at bugs.python.org (Kay Hayen) Date: Mon, 14 Jan 2013 19:37:14 +0000 Subject: [issue16967] Keyword keyword only default parameters are evaluated before po Message-ID: <1358192234.34.0.230545519043.issue16967@psf.upfronthosting.co.za> New submission from Kay Hayen: Suprisingly, keyword only arguments become evaluated first: >>> def f(a=undefined1,*,b=undefined2):pass ... Traceback (most recent call last): File "", line 1, in NameError: name 'undefined2' is not defined It should be "undefined1". I am sure, this is going to surprise developers and breaks assumptions, people tend to make. So far (to my knowledge) nothing that was separated by a "," could be evaluated in a mixed order. Please consider to change this around. ---------- components: Interpreter Core messages: 179970 nosy: Kay.Hayen priority: normal severity: normal status: open title: Keyword keyword only default parameters are evaluated before po versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 20:45:42 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 14 Jan 2013 19:45:42 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1358192742.08.0.156316558614.issue16748@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Also, I'm of the opinion that we'll end up with a higher quality result doing things by hand anyway. Automation doesn't (and shouldn't) preclude careful review and modifications by hand. My point was that it seems like it might be able to get you, say, 80% of the way there (e.g. by deleting test_main(), determining which classes are called by test_main(), adding ", unittest.TestCase", creating stub classes that could be retained or deleted). Or at least provide some additional checks or info. There are nearly 400 test files using test_main(), no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 20:47:51 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 14 Jan 2013 19:47:51 +0000 Subject: [issue16967] Keyword only argument default values are evaluated before other defaults In-Reply-To: <1358192234.34.0.230545519043.issue16967@psf.upfronthosting.co.za> Message-ID: <1358192871.71.0.998951523949.issue16967@psf.upfronthosting.co.za> Georg Brandl added the comment: Looks like a bug to me, although it isn't likely to cause great harm. ---------- nosy: +georg.brandl title: Keyword keyword only default parameters are evaluated before po -> Keyword only argument default values are evaluated before other defaults _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 20:55:51 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 14 Jan 2013 19:55:51 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358193351.48.0.0910036004229.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Added some comments on Rietveld. > The .fileno() method is missing. Can this cause a problem when the file > is passed to stdlib functions? subprocess for example? Thanks. An older version of the patch had a fileno() method which returned the handle -- but that would have confused anything that expects fileno() to return a true fd. It would be possible to make fileno() lazily create an fd using open_osfhandle(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 21:05:45 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Jan 2013 20:05:45 +0000 Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1358193945.33.0.740123195661.issue6975@psf.upfronthosting.co.za> R. David Murray added the comment: Vis the discussion of x[:0] in the review. This kind of construct is only unfamiliar because it is new in Python3, and there are not *that* many places that you want to (and can) deal with both bytes and strings using the same code. But when you can, it is the more-or-less obvious way to write the code. In this particular case you could also write type(x)(). There are pluses and minuses to both forms, but if any of the rest of the code uses slicing to work around the fact that byte strings index into ints, then I would definitely prefer the slice form. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 21:17:11 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 14 Jan 2013 20:17:11 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358194631.15.0.863876207099.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > What does this proposal bring exactly? Unless we are willing to completely replace fds with handles on Windows, perhaps not too much. (At one point I had assumed that that was the plan for py3k.) Although not advertised, openhandle() does have a share_flags parameter to control the share mode of the file. This makes it possible to delete files for which there are open handles. Mercurial needs a C extension to support this. regrtest could certainly benefit from such a feature. But one thing that I would at least like to do is create a FileIO replacement for overlapped pipe/socket handles. Then multiprocessing.Connection could be a simple wrapper round a file object, and most of the platform specific code in multiprocessing.connection can go away. The current patch does not support overlapped IO, but that could be added easily enough. (Overlapped IO for normal files might be more complicated.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:08:39 2013 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 14 Jan 2013 21:08:39 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1358197719.48.0.82059947908.issue1683368@psf.upfronthosting.co.za> Jason R. Coombs added the comment: For reference, I encountered an issue due to this change and didn't quite understand what was going on. I distilled the problem down and posted a question on stack overflow: http://stackoverflow.com/questions/14300153/why-does-this-datetime-subclass-fail-on-python-3/14324503#14324503 The answer led me here, so now I understand. I wanted to share this use-case for posterity. I didn't find anything in the "what's new" documents for Python 3.3 or 3.0. Was this fundamental signature change to all objects documented anywhere? Any objection if I draft a change to the docs? ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:09:02 2013 From: report at bugs.python.org (Marco Buccini) Date: Mon, 14 Jan 2013 21:09:02 +0000 Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1358197742.83.0.054957284693.issue6975@psf.upfronthosting.co.za> Changes by Marco Buccini : ---------- nosy: -markon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:09:42 2013 From: report at bugs.python.org (Marco Buccini) Date: Mon, 14 Jan 2013 21:09:42 +0000 Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the process has terminated In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za> Message-ID: <1358197782.6.0.334529124925.issue6973@psf.upfronthosting.co.za> Changes by Marco Buccini : ---------- nosy: -markon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:11:03 2013 From: report at bugs.python.org (Marco Buccini) Date: Mon, 14 Jan 2013 21:11:03 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1358197863.75.0.808268052785.issue6074@psf.upfronthosting.co.za> Changes by Marco Buccini : ---------- nosy: -markon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:35:35 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 14 Jan 2013 21:35:35 +0000 Subject: [issue16920] multiprocessing.connection listener gets MemoryErroronrecv In-Reply-To: <1357838372.36.0.779855402088.issue16920@psf.upfronthosting.co.za> Message-ID: <1358199335.73.0.618102899908.issue16920@psf.upfronthosting.co.za> Richard Oudkerk added the comment: If you want to communicate between processes of the same progam, you are best off calling multiprocessing.Pipe() or multiprocessing.Queue() in the main process. Queues or connections can then be inherited by the child processes. Usually all communication is between the main process and its children: sibling-to-sibling communication is rare. > I am trying to understand your reservations about using them for > communication over a network Since Connection.recv() automatically unpickles the data it receives it is effected by the issue discussed here http://nadiana.com/python-pickle-insecure Basically, unpickling malicious data can trigger *any* command it wants using the shell. So you *must* use recv_bytes()/send_bytes() when dealing with unauthenticated connections. Over a network you *could* use authentication. But securely sharing the authentication key between all the hosts is far from straight forward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:48:53 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 14 Jan 2013 21:48:53 +0000 Subject: [issue16966] Publishing multiprocessing listener code In-Reply-To: <8053927136E1407BA60A52EA84F498B8@jrb> Message-ID: <1358200133.82.0.105399524706.issue16966@psf.upfronthosting.co.za> Richard Oudkerk added the comment: For the reasons I wrote in the other issue, I don't think this an approach to encourage. There was no need to create a new issue: if you post to a closed issue then people on the nosy list will still see your message. So I will close this issue. (Maybe wiki.python.org is the sort of thing you are looking for, but I have never visited it, and it does not seem to be available currently. I think it was recently compromised, so it may be down for a while. Anyway, I don't think your example code is suitable.) ---------- nosy: +sbt resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:51:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 21:51:00 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1358200260.49.0.403780516876.issue13968@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In fact glob() is already protected against an endless recursion (in the same way as Bash). The level of recursion is simply limited by the maximum length of the path. So I did not change the implementation, I have just added a test for symlink loop. I also corrected the other new tests so that they should not fail on the platform without symlinks. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file28728/glob_recursive_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:53:44 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Jan 2013 21:53:44 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1358200424.16.0.510945060947.issue16748@psf.upfronthosting.co.za> Zachary Ware added the comment: For the conversion from test_main() to unittest.main(), I could certainly see automation helping a lot; most cases are very simple. But really, that issue is somewhat tangential to this one and in my last message I was thinking from the perspective of just the 80 or so modules that completely fail test discovery otherwise. I believe that trying to automate those would be more trouble than it's worth. Especially if issue 16935 is fixed, as that will knock out most of the tests I listed above that failed to skip properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:55:42 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 Jan 2013 21:55:42 +0000 Subject: [issue1602133] non-framework python fails to define os.environ properly Message-ID: <1358200542.98.0.286159994671.issue1602133@psf.upfronthosting.co.za> Ned Deily added the comment: LGTM and I agree that it should be considered a bug fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 22:58:13 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 21:58:13 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1358200693.29.0.963728241153.issue15539@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Is it fixed now? ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:00:55 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 22:00:55 +0000 Subject: [issue16823] Python crashes on running tkinter code with threads In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za> Message-ID: <1358200855.1.0.323752080112.issue16823@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:02:21 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 22:02:21 +0000 Subject: [issue16887] IDLE - tabify/untabify applied when clicking Cancel In-Reply-To: <1357592262.2.0.644397432764.issue16887@psf.upfronthosting.co.za> Message-ID: <1358200941.48.0.94146624804.issue16887@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:04:51 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 22:04:51 +0000 Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za> Message-ID: <1358201091.53.0.255738994721.issue16901@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:07:30 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 22:07:30 +0000 Subject: [issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong In-Reply-To: <1357839740.51.0.95267360969.issue16921@psf.upfronthosting.co.za> Message-ID: <1358201250.93.0.157355629742.issue16921@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:10:17 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 14 Jan 2013 22:10:17 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1358201417.88.0.571460577894.issue16935@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:19:34 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Jan 2013 22:19:34 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py Message-ID: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's an incomplete patch to test_concurrent_futures.py that does not convert from test_main() to unittest.main(); the decorator on test_main has me unsure how to make the conversion. I've attempted moving various parts of the decorator's functions to setUpModule and tearDownModule functions, but always wind up with a warning that the test has modified threading._dangling. Guidance on this one would be much appreciated :) ---------- components: Tests files: test_concurrent_futures_discovery.diff keywords: patch messages: 179983 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_concurrent_futures.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28729/test_concurrent_futures_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:28:56 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Jan 2013 22:28:56 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1358202536.32.0.186874863031.issue16968@psf.upfronthosting.co.za> Brett Cannon added the comment: The way I would replace test_main() would be: if __name__ == '__main__': try: test.support.reap_threads(unittest.main)() finally: test.support_reap_children() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:40:12 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Jan 2013 22:40:12 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1358203212.04.0.147812722588.issue16968@psf.upfronthosting.co.za> Zachary Ware added the comment: That looks quite good, except for the fact that discovery (of the form `python -m unittest discover Lib/test/ 'test_*.py'`) won't hit reap_threads or reap_children. It does cover `python -m test.test_concurrent_futures` and standard regrtest, though; is 2 out of three good enough? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:42:43 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 14 Jan 2013 22:42:43 +0000 Subject: [issue16967] Keyword only argument default values are evaluated before other defaults In-Reply-To: <1358192234.34.0.230545519043.issue16967@psf.upfronthosting.co.za> Message-ID: <1358203363.35.0.632166914231.issue16967@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:45:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 22:45:05 +0000 Subject: [issue15539] Fixing Tools/scripts/pindent.py In-Reply-To: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za> Message-ID: <1358203505.09.0.773038007497.issue15539@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it's fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:45:09 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Jan 2013 22:45:09 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za> Message-ID: <3YlVBD4mlzzS0r@mail.python.org> Roundup Robot added the comment: New changeset ce869b05762c by Serhiy Storchaka in branch '2.7': Issue #9720: zipfile now writes correct local headers for files larger than 4 GiB. http://hg.python.org/cpython/rev/ce869b05762c New changeset b93848ca7760 by Serhiy Storchaka in branch '3.2': Issue #9720: zipfile now writes correct local headers for files larger than 4 GiB. http://hg.python.org/cpython/rev/b93848ca7760 New changeset 656a45738e5e by Serhiy Storchaka in branch '3.3': Issue #9720: zipfile now writes correct local headers for files larger than 4 GiB. http://hg.python.org/cpython/rev/656a45738e5e New changeset 628a6af64a46 by Serhiy Storchaka in branch 'default': Issue #9720: zipfile now writes correct local headers for files larger than 4 GiB. http://hg.python.org/cpython/rev/628a6af64a46 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:47:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 22:47:49 +0000 Subject: [issue9290] IDLE and Command line present different behavior for sys.stdin In-Reply-To: <1279417895.54.0.811089047738.issue9290@psf.upfronthosting.co.za> Message-ID: <1358203669.47.0.679000380427.issue9290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If no one objects, I'm going to commit this next week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:49:08 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 22:49:08 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za> Message-ID: <1358203748.08.0.789906077842.issue9720@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed. Thank you for report, Craig de Stigter. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 14 23:54:35 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 Jan 2013 22:54:35 +0000 Subject: [issue16715] Get rid of IOError. Use OSError instead In-Reply-To: <3YW0Xs2j15zRkN@mail.python.org> Message-ID: <1358204075.51.0.269569235179.issue16715@psf.upfronthosting.co.za> ?ric Araujo added the comment: Source code says: # derives from OSError for backwards-compatibility with Python 2.4.0 class LoadError(OSError): pass In 3.0, LoadError could have been made a direct subclass of Exception. Now it?s too late, but a best practice IMO would still be to write LoadError in all new code. This makes no practical difference, unless test_cookiejar does not check that LoadError is properly raised and caught at the right places. In that case, it may be a little more future-proof to follow py-user?s advice. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 00:15:51 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Jan 2013 23:15:51 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <3YlVsg0XKRzR2R@mail.python.org> Roundup Robot added the comment: New changeset 13e2e44db99d by Serhiy Storchaka in branch 'default': Issue #15989: Fix several occurrences of integer overflow http://hg.python.org/cpython/rev/13e2e44db99d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 00:17:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Jan 2013 23:17:09 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1358205429.59.0.0154371156769.issue15989@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 00:20:18 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Jan 2013 23:20:18 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1358205618.72.0.970475933656.issue16968@psf.upfronthosting.co.za> Brett Cannon added the comment: Yes as even the current solution doesn't work with ``-m unittest discover`` anyway, right? And if you are running the tests independently then it is a separate process and thus you don't need to worry about dangling threads or processes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 00:28:35 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Jan 2013 23:28:35 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358205618.72.0.970475933656.issue16968@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Ok then, I'll update the patch. Thanks, Brett! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 01:50:12 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Jan 2013 00:50:12 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <3YlXyW4qlNzRyf@mail.python.org> Roundup Robot added the comment: New changeset da5e520a7ba5 by Richard Oudkerk in branch '2.7': Issue #10527: Use poll() instead of select() for multiprocessing pipes http://hg.python.org/cpython/rev/da5e520a7ba5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 02:08:30 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Jan 2013 01:08:30 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <3YlYMc6cvzzS0r@mail.python.org> Roundup Robot added the comment: New changeset abf111b9a464 by Richard Oudkerk in branch '3.2': Issue #10527: Use poll() instead of select() for multiprocessing pipes http://hg.python.org/cpython/rev/abf111b9a464 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 02:45:26 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 01:45:26 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1358214326.67.0.99782947369.issue16748@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Okay, well the title of this issue is "Make CPython test package discoverable," so as part of that we should be confirming that test discovery finds the same tests that test_main() runs (and if not, to understand why and/or make them the same). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 03:31:06 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 02:31:06 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1358217066.24.0.575345562367.issue16968@psf.upfronthosting.co.za> Chris Jerdonek added the comment: If you want to get the same cleanup logic working with unittest discovery, you could try using the load_tests protocol, and wrapping the functions that actually run the tests there (which may simply mean wrapping the tests passed to load_tests, which I believe are callables). ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 03:36:44 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 02:36:44 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1358217404.65.0.0629201951317.issue16968@psf.upfronthosting.co.za> Chris Jerdonek added the comment: By the way, I think this process of using unittest (i.e. dog-fooding) is a good exercise in part because it helps us understand better where unittest could use improvement (e.g. the SkipTest during import issue, and the decorator issue raised here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 03:47:36 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 15 Jan 2013 02:47:36 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1358218056.83.0.425738467764.issue1683368@psf.upfronthosting.co.za> Terry J. Reedy added the comment: First, What's New " explains the new features in Python". This issue is a bugfix. AFAIK, object() has always been documented as having no parameters. The fact that passing extra args should raise a TypeError is no secret. Second, this *is* documented. The third sentence of http://docs.python.org/3/whatsnew/3.3.html is " For full details, see the changelog." We really mean that ;-). The changelog is derived from Misc/NEWS in the repository. It says "Issue #1683368: object.__new__ and object.__init__ raise a TypeError if they are passed arguments and their complementary method is not overridden." That is prefixed by "Issue #1683368:", which links to this issue. This entry is easily found by searching for 'object.__init__' (or a sufficient prefix thereof). For 3.2, the What's New sentence was "For full details, see the Misc/NEWS file" and the link went to the raw repository file. http://hg.python.org/cpython/file/3.2/Misc/NEWS My impression is that this issue played a role in including the prettified version, instead of just the repository link, in the on-line version of the docs. What's New for 2.7 does not even have the link. In any case, *any* bugfix breaks code that depends on the bug. Hence the decision to make the full changelog more available and more readable. I realize that the change to the header for What's New is hard to miss. But what are we to do? Add a new What's New in What's New doc for one release? Put the change in flashing red type? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 04:12:20 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 15 Jan 2013 03:12:20 +0000 Subject: [issue16823] Python quits on running tkinter code with threads In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za> Message-ID: <1358219540.1.0.482212716044.issue16823@psf.upfronthosting.co.za> Terry J. Reedy added the comment: We use 'crash' to mean a segfault (and core dump, on *nix) or the Windows equivalent. We avoid those if at all possible. A Python traceback is not a crash but a semi-graceful shutdown that has be planned for, given the circumstances. What is annoying here is getting a different exception (or at least message type) each time. I presume it depends on what data gets corrupted, and that is somewhat haphazard. The quote seems to be accurate. I know little about threading, but if it were possible to detect tkinter access from other than the main thread (without excessive slowdown), then a consistent exception might be raised. But I am doubtful that this can be done sensibly. Hence a doc change seems like the best first step. ---------- title: Python crashes on running tkinter code with threads -> Python quits on running tkinter code with threads _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 04:25:30 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 15 Jan 2013 03:25:30 +0000 Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with -E In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za> Message-ID: <1358220330.49.0.98891054753.issue16826@psf.upfronthosting.co.za> Meador Inge added the comment: I agree that it is better to cover both cases in one test irrespective of the interpreter command line options. I will take a look at creating a subprocess. Thanks for the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 04:30:24 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 15 Jan 2013 03:30:24 +0000 Subject: [issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex In-Reply-To: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za> Message-ID: <1358220624.52.0.920646830378.issue16899@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 04:32:52 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 15 Jan 2013 03:32:52 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1358220772.02.0.906585175447.issue10544@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 04:34:27 2013 From: report at bugs.python.org (Jason R. Coombs) Date: Tue, 15 Jan 2013 03:34:27 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1358220867.18.0.903894137698.issue1683368@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Aah. Indeed, that's where I should have looked. Thanks for the pointer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 04:37:16 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 15 Jan 2013 03:37:16 +0000 Subject: [issue16894] Function attribute access doesn't invoke methods in dict subclasses In-Reply-To: <1357670592.25.0.470525675752.issue16894@psf.upfronthosting.co.za> Message-ID: <1358221036.06.0.72849121372.issue16894@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 05:34:57 2013 From: report at bugs.python.org (David Lam) Date: Tue, 15 Jan 2013 04:34:57 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1358224497.7.0.535905330669.issue16954@psf.upfronthosting.co.za> Changes by David Lam : ---------- nosy: +dlam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 06:51:57 2013 From: report at bugs.python.org (Ry Erickson) Date: Tue, 15 Jan 2013 05:51:57 +0000 Subject: [issue16969] test_urlwithfrag fail Message-ID: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> New submission from Ry Erickson: Prevents correct installation. OS: Linux Mint 12 Lisa. ---------- components: Tests files: test messages: 180003 nosy: Ry priority: normal severity: normal status: open title: test_urlwithfrag fail type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file28730/test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 09:17:33 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 15 Jan 2013 08:17:33 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358237853.59.0.242719242589.issue16969@psf.upfronthosting.co.za> Ezio Melotti added the comment: That's because there's no test file called test_urlwithfrag.py. Do you see any failure if you do ./python -m test -v test_urllib2net? ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 10:09:07 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 15 Jan 2013 09:09:07 +0000 Subject: [issue15994] memoryview to freed memory can cause segfault In-Reply-To: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za> Message-ID: <1358240947.48.0.211857091761.issue15994@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 10:10:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 09:10:33 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1358241033.59.0.537267214232.issue15989@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Changeset 525407d89277: Fix test_socket broken in previous commit (changeset 13e2e44db99d). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 10:17:58 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 15 Jan 2013 09:17:58 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1358241478.57.0.0903115759479.issue15948@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 10:26:26 2013 From: report at bugs.python.org (Mark Shannon) Date: Tue, 15 Jan 2013 09:26:26 +0000 Subject: [issue16956] Allow signed line number deltas in the code object's line number table In-Reply-To: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za> Message-ID: <1358241986.28.0.471673172826.issue16956@psf.upfronthosting.co.za> Mark Shannon added the comment: The interaction between bdb/pdb and the line number table is via the frame.f_lineno attribute. Allowing signed offsets changes the one-to-one line muber => bytecode offset relation into a one-to-many relation. Reading frame.f_lineno is not an issue as each bytecode offset will always refer to exactly one line number. Setting frame.f_lineno requires some thought as each line number could potentially refer to several bytecode offsets. However, the proposed patch retains the one-to-one relation, as the test in the while statement is merely moved, not duplicated. I am reluctant to change frame_setlineno() until there really is a one-to-many relation as it will be untestable. Once a one-to-many relation exists (e.g. duplicating finally blocks to avoid 'pseudo excpetions') then frame_setlineno should be modified (and tests added) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 10:44:01 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 15 Jan 2013 09:44:01 +0000 Subject: [issue16086] tp_flags: Undefined behaviour with 32 bits long In-Reply-To: <1348934655.6.0.704339106877.issue16086@psf.upfronthosting.co.za> Message-ID: <1358243041.59.0.240546895936.issue16086@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 11:21:29 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 10:21:29 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1358245289.0.0.578773342226.issue16954@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: serhiy.storchaka -> docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 12:13:29 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 11:13:29 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358248409.64.0.0691258372512.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Adding a failing test. I will supply a patch shortly. ---------- keywords: +patch stage: -> needs patch Added file: http://bugs.python.org/file28731/issue-16468-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 12:14:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 11:14:42 +0000 Subject: [issue16096] Get rid of dangerous integer overflow tricks In-Reply-To: <1357583626.37.0.67161725156.issue16096@psf.upfronthosting.co.za> Message-ID: <201301151314.07426.storchaka@gmail.com> Serhiy Storchaka added the comment: Here are updated to current codebase patches for 2.7 and 3.2. It seems that all the rest of overflows are hypothetical bugs and do not appear on the current supported platforms. Fix them is not necessary (rather for purity). If no one can see visible bugs, I'll close this issue soon. ---------- Added file: http://bugs.python.org/file28732/size_overflow-2.7_2.patch Added file: http://bugs.python.org/file28733/size_overflow-3.2_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r f2353e74b335 Modules/_randommodule.c --- a/Modules/_randommodule.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/_randommodule.c Wed Jan 09 19:00:27 2013 +0200 @@ -283,7 +283,8 @@ n = newn; if (keyused >= keymax) { unsigned long bigger = keymax << 1; - if ((bigger >> 1) != keymax) { + if ((bigger >> 1) != keymax || + bigger > PY_SSIZE_T_MAX / sizeof(*key)) { PyErr_NoMemory(); goto Done; } diff -r f2353e74b335 Modules/arraymodule.c --- a/Modules/arraymodule.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/arraymodule.c Wed Jan 09 19:00:27 2013 +0200 @@ -423,11 +423,11 @@ return NULL; } - nbytes = size * descr->itemsize; /* Check for overflow */ - if (nbytes / descr->itemsize != (size_t)size) { + if (size > PY_SSIZE_T_MAX / descr->itemsize) { return PyErr_NoMemory(); } + nbytes = size * descr->itemsize; op = (arrayobject *) type->tp_alloc(type, 0); if (op == NULL) { return NULL; @@ -1205,13 +1205,10 @@ char *item = self->ob_item; Py_ssize_t itemsize = self->ob_descr->itemsize; size_t nread; - Py_ssize_t newlength; size_t newbytes; - /* Be careful here about overflow */ - if ((newlength = Py_SIZE(self) + n) <= 0 || - (newbytes = newlength * itemsize) / itemsize != - (size_t)newlength) + if (n > (PY_SSIZE_T_MAX - Py_SIZE(self)) / itemsize) goto nomem; + newbytes = (Py_SIZE(self) + n) * itemsize; PyMem_RESIZE(item, char, newbytes); if (item == NULL) { nomem: diff -r f2353e74b335 Modules/audioop.c --- a/Modules/audioop.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/audioop.c Wed Jan 09 19:00:27 2013 +0200 @@ -1094,8 +1094,7 @@ PyErr_SetString(AudioopError, "# of channels should be >= 1"); return NULL; } - bytes_per_frame = size * nchannels; - if (bytes_per_frame / nchannels != size) { + if (size > INT_MAX / nchannels) { /* This overflow test is rigorously correct because both multiplicands are >= 1. Use the argument names from the docs for the error msg. */ @@ -1103,6 +1102,7 @@ "width * nchannels too big for a C int"); return NULL; } + bytes_per_frame = size * nchannels; if (weightA < 1 || weightB < 0) { PyErr_SetString(AudioopError, "weightA should be >= 1, weightB should be >= 0"); diff -r f2353e74b335 Modules/cPickle.c --- a/Modules/cPickle.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Modules/cPickle.c Wed Jan 09 19:00:27 2013 +0200 @@ -218,14 +218,12 @@ size_t nbytes; PyObject **tmp; + if (self->size == 0 || self->size > (INT_MAX >> 1)) + goto nomemory; bigger = self->size << 1; - if (bigger <= 0) /* was 0, or new value overflows */ - goto nomemory; - if ((int)(size_t)bigger != bigger) + if ((size_t)bigger > PY_SSIZE_T_MAX / sizeof(PyObject *)) goto nomemory; nbytes = (size_t)bigger * sizeof(PyObject *); - if (nbytes / sizeof(PyObject *) != (size_t)bigger) - goto nomemory; tmp = realloc(self->data, nbytes); if (tmp == NULL) goto nomemory; diff -r f2353e74b335 Objects/bytearrayobject.c --- a/Objects/bytearrayobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/bytearrayobject.c Wed Jan 09 19:00:27 2013 +0200 @@ -357,9 +357,9 @@ if (count < 0) count = 0; mysize = Py_SIZE(self); + if (count != 0 && mysize > PY_SSIZE_T_MAX / count) + return PyErr_NoMemory(); size = mysize * count; - if (count != 0 && size / count != mysize) - return PyErr_NoMemory(); result = (PyByteArrayObject *)PyByteArray_FromStringAndSize(NULL, size); if (result != NULL && size != 0) { if (mysize == 1) @@ -382,9 +382,9 @@ if (count < 0) count = 0; mysize = Py_SIZE(self); + if (count != 0 && mysize > PY_SSIZE_T_MAX / count) + return PyErr_NoMemory(); size = mysize * count; - if (count != 0 && size / count != mysize) - return PyErr_NoMemory(); if (size < self->ob_alloc) { Py_SIZE(self) = size; self->ob_bytes[Py_SIZE(self)] = '\0'; /* Trailing null byte */ @@ -1568,7 +1568,7 @@ { char *self_s, *result_s; Py_ssize_t self_len, result_len; - Py_ssize_t count, i, product; + Py_ssize_t count, i; PyByteArrayObject *result; self_len = PyByteArray_GET_SIZE(self); @@ -1580,18 +1580,13 @@ /* Check for overflow */ /* result_len = count * to_len + self_len; */ - product = count * to_len; - if (product / to_len != count) { + assert(count > 0); + if (to_len > (PY_SSIZE_T_MAX - self_len) / count) { PyErr_SetString(PyExc_OverflowError, "replace string is too long"); return NULL; } - result_len = product + self_len; - if (result_len < 0) { - PyErr_SetString(PyExc_OverflowError, - "replace string is too long"); - return NULL; - } + result_len = count * to_len + self_len; if (! (result = (PyByteArrayObject *) PyByteArray_FromStringAndSize(NULL, result_len)) ) @@ -1821,7 +1816,7 @@ char *self_s, *result_s; char *start, *next, *end; Py_ssize_t self_len, result_len; - Py_ssize_t count, product; + Py_ssize_t count; PyByteArrayObject *result; self_s = PyByteArray_AS_STRING(self); @@ -1835,16 +1830,12 @@ /* use the difference between current and new, hence the "-1" */ /* result_len = self_len + count * (to_len-1) */ - product = count * (to_len-1); - if (product / (to_len-1) != count) { + assert(count > 0); + if (to_len - 1 > (PY_SSIZE_T_MAX - self_len) / count) { PyErr_SetString(PyExc_OverflowError, "replace bytes is too long"); return NULL; } - result_len = self_len + product; - if (result_len < 0) { - PyErr_SetString(PyExc_OverflowError, "replace bytes is too long"); - return NULL; - } + result_len = self_len + count * (to_len - 1); if ( (result = (PyByteArrayObject *) PyByteArray_FromStringAndSize(NULL, result_len)) == NULL) @@ -1888,7 +1879,7 @@ char *self_s, *result_s; char *start, *next, *end; Py_ssize_t self_len, result_len; - Py_ssize_t count, offset, product; + Py_ssize_t count, offset; PyByteArrayObject *result; self_s = PyByteArray_AS_STRING(self); @@ -1905,16 +1896,12 @@ /* Check for overflow */ /* result_len = self_len + count * (to_len-from_len) */ - product = count * (to_len-from_len); - if (product / (to_len-from_len) != count) { + assert(count > 0); + if (to_len - from_len > (PY_SSIZE_T_MAX - self_len) / count) { PyErr_SetString(PyExc_OverflowError, "replace bytes is too long"); return NULL; } - result_len = self_len + product; - if (result_len < 0) { - PyErr_SetString(PyExc_OverflowError, "replace bytes is too long"); - return NULL; - } + result_len = self_len + count * (to_len - from_len); if ( (result = (PyByteArrayObject *) PyByteArray_FromStringAndSize(NULL, result_len)) == NULL) diff -r f2353e74b335 Objects/longobject.c --- a/Objects/longobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/longobject.c Wed Jan 09 19:00:27 2013 +0200 @@ -483,10 +483,9 @@ assert(ndigits == 0 || v->ob_digit[ndigits - 1] != 0); if (ndigits > 0) { digit msd = v->ob_digit[ndigits - 1]; - - result = (ndigits - 1) * PyLong_SHIFT; - if (result / PyLong_SHIFT != (size_t)(ndigits - 1)) + if ((size_t)(ndigits - 1) > PY_SIZE_MAX / (size_t)PyLong_SHIFT) goto Overflow; + result = (size_t)(ndigits - 1) * (size_t)PyLong_SHIFT; do { ++result; if (result == 0) diff -r f2353e74b335 Objects/stringobject.c --- a/Objects/stringobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/stringobject.c Wed Jan 09 19:00:27 2013 +0200 @@ -922,13 +922,15 @@ PyString_Repr(PyObject *obj, int smartquotes) { register PyStringObject* op = (PyStringObject*) obj; - size_t newsize = 2 + 4 * Py_SIZE(op); + size_t newsize; PyObject *v; - if (newsize > PY_SSIZE_T_MAX || newsize / 4 != Py_SIZE(op)) { + if (Py_SIZE(op) > (PY_SSIZE_T_MAX - 2) / 4) { + PyErr_SetString(PyExc_OverflowError, "string is too large to make repr"); return NULL; } + newsize = 2 + 4 * Py_SIZE(op); v = PyString_FromStringAndSize((char *)NULL, newsize); if (v == NULL) { return NULL; @@ -1079,12 +1081,12 @@ /* watch out for overflows: the size can overflow int, * and the # of bytes needed can overflow size_t */ - size = Py_SIZE(a) * n; - if (n && size / n != Py_SIZE(a)) { + if (n > 0 && Py_SIZE(a) > PY_SSIZE_T_MAX / n) { PyErr_SetString(PyExc_OverflowError, "repeated string is too long"); return NULL; } + size = Py_SIZE(a) * n; if (size == Py_SIZE(a) && PyString_CheckExact(a)) { Py_INCREF(a); return (PyObject *)a; @@ -2354,7 +2356,7 @@ { char *self_s, *result_s; Py_ssize_t self_len, result_len; - Py_ssize_t count, i, product; + Py_ssize_t count, i; PyStringObject *result; self_len = PyString_GET_SIZE(self); @@ -2366,18 +2368,13 @@ /* Check for overflow */ /* result_len = count * to_len + self_len; */ - product = count * to_len; - if (product / to_len != count) { + assert(count > 0); + if (to_len > (PY_SSIZE_T_MAX - self_len) / count) { PyErr_SetString(PyExc_OverflowError, "replace string is too long"); return NULL; } - result_len = product + self_len; - if (result_len < 0) { - PyErr_SetString(PyExc_OverflowError, - "replace string is too long"); - return NULL; - } + result_len = count * to_len + self_len; if (! (result = (PyStringObject *) PyString_FromStringAndSize(NULL, result_len)) ) @@ -2606,7 +2603,7 @@ char *self_s, *result_s; char *start, *next, *end; Py_ssize_t self_len, result_len; - Py_ssize_t count, product; + Py_ssize_t count; PyStringObject *result; self_s = PyString_AS_STRING(self); @@ -2620,16 +2617,12 @@ /* use the difference between current and new, hence the "-1" */ /* result_len = self_len + count * (to_len-1) */ - product = count * (to_len-1); - if (product / (to_len-1) != count) { + assert(count > 0); + if (to_len - 1 > (PY_SSIZE_T_MAX - self_len) / count) { PyErr_SetString(PyExc_OverflowError, "replace string is too long"); return NULL; } - result_len = self_len + product; - if (result_len < 0) { - PyErr_SetString(PyExc_OverflowError, "replace string is too long"); - return NULL; - } + result_len = self_len + count * (to_len - 1); if ( (result = (PyStringObject *) PyString_FromStringAndSize(NULL, result_len)) == NULL) @@ -2672,7 +2665,7 @@ char *self_s, *result_s; char *start, *next, *end; Py_ssize_t self_len, result_len; - Py_ssize_t count, offset, product; + Py_ssize_t count, offset; PyStringObject *result; self_s = PyString_AS_STRING(self); @@ -2689,16 +2682,12 @@ /* Check for overflow */ /* result_len = self_len + count * (to_len-from_len) */ - product = count * (to_len-from_len); - if (product / (to_len-from_len) != count) { + assert(count > 0); + if (to_len - from_len > (PY_SSIZE_T_MAX - self_len) / count) { PyErr_SetString(PyExc_OverflowError, "replace string is too long"); return NULL; } - result_len = self_len + product; - if (result_len < 0) { - PyErr_SetString(PyExc_OverflowError, "replace string is too long"); - return NULL; - } + result_len = self_len + count * (to_len-from_len); if ( (result = (PyStringObject *) PyString_FromStringAndSize(NULL, result_len)) == NULL) diff -r f2353e74b335 Objects/tupleobject.c --- a/Objects/tupleobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/tupleobject.c Wed Jan 09 19:00:27 2013 +0200 @@ -79,11 +79,9 @@ else #endif { - Py_ssize_t nbytes = size * sizeof(PyObject *); /* Check for overflow */ - if (nbytes / sizeof(PyObject *) != (size_t)size || - (nbytes > PY_SSIZE_T_MAX - sizeof(PyTupleObject) - sizeof(PyObject *))) - { + if (size > (PY_SSIZE_T_MAX - sizeof(PyTupleObject) - + sizeof(PyObject *)) / sizeof(PyObject *)) { return PyErr_NoMemory(); } @@ -490,9 +488,9 @@ if (Py_SIZE(a) == 0) return PyTuple_New(0); } + if (n > PY_SSIZE_T_MAX / Py_SIZE(a)) + return PyErr_NoMemory(); size = Py_SIZE(a) * n; - if (size/Py_SIZE(a) != n) - return PyErr_NoMemory(); np = (PyTupleObject *) PyTuple_New(size); if (np == NULL) return NULL; diff -r f2353e74b335 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Tue Jan 08 23:12:00 2013 +0200 +++ b/Objects/unicodeobject.c Wed Jan 09 19:00:27 2013 +0200 @@ -1758,8 +1758,6 @@ const char *errors) { PyObject *v; - /* It might be possible to tighten this worst case */ - Py_ssize_t allocated = 8 * size; int inShift = 0; Py_ssize_t i = 0; unsigned int base64bits = 0; @@ -1767,13 +1765,14 @@ char * out; char * start; - if (allocated / 8 != size) + /* It might be possible to tighten this worst case */ + if (size > PY_SSIZE_T_MAX / 8) return PyErr_NoMemory(); if (size == 0) return PyString_FromStringAndSize(NULL, 0); - v = PyString_FromStringAndSize(NULL, allocated); + v = PyString_FromStringAndSize(NULL, size * 8); if (v == NULL) return NULL; @@ -2097,10 +2096,9 @@ } else { /* Overallocate on the heap, and give the excess back at the end. */ - nallocated = size * 4; - if (nallocated / 4 != size) /* overflow! */ + if (size > PY_SSIZE_T_MAX / 4) return PyErr_NoMemory(); - v = PyString_FromStringAndSize(NULL, nallocated); + v = PyString_FromStringAndSize(NULL, size * 4); if (v == NULL) return NULL; p = PyString_AS_STRING(v); @@ -2360,7 +2358,7 @@ { PyObject *v; unsigned char *p; - Py_ssize_t nsize, bytesize; + Py_ssize_t nsize; #ifndef Py_UNICODE_WIDE Py_ssize_t i, pairs; #else @@ -2391,10 +2389,9 @@ pairs++; #endif nsize = (size - pairs + (byteorder == 0)); - bytesize = nsize * 4; - if (bytesize / 4 != nsize) + if (nsize > PY_SSIZE_T_MAX / 4) return PyErr_NoMemory(); - v = PyString_FromStringAndSize(NULL, bytesize); + v = PyString_FromStringAndSize(NULL, nsize * 4); if (v == NULL) return NULL; @@ -2637,7 +2634,7 @@ { PyObject *v; unsigned char *p; - Py_ssize_t nsize, bytesize; + Py_ssize_t nsize; #ifdef Py_UNICODE_WIDE Py_ssize_t i, pairs; #else @@ -2667,10 +2664,9 @@ size > PY_SSIZE_T_MAX - pairs - (byteorder == 0)) return PyErr_NoMemory(); nsize = size + pairs + (byteorder == 0); - bytesize = nsize * 2; - if (bytesize / 2 != nsize) + if (nsize > PY_SSIZE_T_MAX / 2) return PyErr_NoMemory(); - v = PyString_FromStringAndSize(NULL, bytesize); + v = PyString_FromStringAndSize(NULL, nsize * 2); if (v == NULL) return NULL; @@ -5863,7 +5859,7 @@ } else { Py_ssize_t n, i, j; - Py_ssize_t product, new_size, delta; + Py_ssize_t new_size, delta; Py_UNICODE *p; /* replace strings */ @@ -5876,18 +5872,14 @@ if (delta == 0) { new_size = self->length; } else { - product = n * (str2->length - str1->length); - if ((product / (str2->length - str1->length)) != n) { + if (str2->length > str1->length && + str2->length - str1->length > + (PY_SSIZE_T_MAX - self->length) / n) { PyErr_SetString(PyExc_OverflowError, "replace string is too long"); return NULL; } - new_size = self->length + product; - if (new_size < 0) { - PyErr_SetString(PyExc_OverflowError, - "replace string is too long"); - return NULL; - } + new_size = self->length + n * (str2->length - str1->length); } u = _PyUnicode_New(new_size); if (!u) @@ -7132,7 +7124,6 @@ PyUnicodeObject *u; Py_UNICODE *p; Py_ssize_t nchars; - size_t nbytes; if (len < 0) len = 0; @@ -7146,18 +7137,12 @@ /* ensure # of chars needed doesn't overflow int and # of bytes * needed doesn't overflow size_t */ - nchars = len * str->length; - if (len && nchars / len != str->length) { + if (len && str->length > (PY_SSIZE_T_MAX / sizeof(Py_UNICODE) - 1) / len) { PyErr_SetString(PyExc_OverflowError, "repeated string is too long"); return NULL; } - nbytes = (nchars + 1) * sizeof(Py_UNICODE); - if (nbytes / sizeof(Py_UNICODE) != (size_t)(nchars + 1)) { - PyErr_SetString(PyExc_OverflowError, - "repeated string is too long"); - return NULL; - } + nchars = len * str->length; u = _PyUnicode_New(nchars); if (!u) return NULL; -------------- next part -------------- diff -r f28aff31900a Modules/_codecsmodule.c --- a/Modules/_codecsmodule.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/_codecsmodule.c Wed Jan 09 19:00:20 2013 +0200 @@ -174,12 +174,12 @@ return NULL; size = PyBytes_GET_SIZE(str); - newsize = 4*size; - if (newsize > PY_SSIZE_T_MAX || newsize / 4 != size) { + if (size > PY_SSIZE_T_MAX / 4) { PyErr_SetString(PyExc_OverflowError, "string is too large to encode"); return NULL; } + newsize = 4*size; v = PyBytes_FromStringAndSize(NULL, newsize); if (v == NULL) { diff -r f28aff31900a Modules/_datetimemodule.c --- a/Modules/_datetimemodule.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/_datetimemodule.c Wed Jan 09 19:00:20 2013 +0200 @@ -1286,14 +1286,13 @@ assert(ptoappend != NULL); assert(ntoappend > 0); while (usednew + ntoappend > totalnew) { - size_t bigger = totalnew << 1; - if ((bigger >> 1) != totalnew) { /* overflow */ + if (totalnew > (PY_SSIZE_T_MAX >> 1)) { /* overflow */ PyErr_NoMemory(); goto Done; } - if (_PyBytes_Resize(&newfmt, bigger) < 0) + totalnew <<= 1; + if (_PyBytes_Resize(&newfmt, totalnew) < 0) goto Done; - totalnew = bigger; pnew = PyBytes_AsString(newfmt) + usednew; } memcpy(pnew, ptoappend, ntoappend); diff -r f28aff31900a Modules/_randommodule.c --- a/Modules/_randommodule.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/_randommodule.c Wed Jan 09 19:00:20 2013 +0200 @@ -283,7 +283,8 @@ n = newn; if (keyused >= keymax) { unsigned long bigger = keymax << 1; - if ((bigger >> 1) != keymax) { + if ((bigger >> 1) != keymax || + bigger > PY_SSIZE_T_MAX / sizeof(*key)) { PyErr_NoMemory(); goto Done; } diff -r f28aff31900a Modules/arraymodule.c --- a/Modules/arraymodule.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/arraymodule.c Wed Jan 09 19:00:20 2013 +0200 @@ -426,11 +426,11 @@ return NULL; } - nbytes = size * descr->itemsize; /* Check for overflow */ - if (nbytes / descr->itemsize != (size_t)size) { + if (size > PY_SSIZE_T_MAX / descr->itemsize) { return PyErr_NoMemory(); } + nbytes = size * descr->itemsize; op = (arrayobject *) type->tp_alloc(type, 0); if (op == NULL) { return NULL; @@ -1196,11 +1196,15 @@ if (!PyArg_ParseTuple(args, "On:fromfile", &f, &n)) return NULL; - nbytes = n * itemsize; - if (nbytes < 0 || nbytes/itemsize != n) { + if (n < 0) { + PyErr_SetString(PyExc_ValueError, "negative count"); + return NULL; + } + if (n > PY_SSIZE_T_MAX / itemsize) { PyErr_NoMemory(); return NULL; } + nbytes = n * itemsize; b = PyObject_CallMethod(f, "read", "n", nbytes); if (b == NULL) diff -r f28aff31900a Modules/audioop.c --- a/Modules/audioop.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Modules/audioop.c Wed Jan 09 19:00:20 2013 +0200 @@ -1110,8 +1110,7 @@ PyErr_SetString(AudioopError, "# of channels should be >= 1"); return NULL; } - bytes_per_frame = size * nchannels; - if (bytes_per_frame / nchannels != size) { + if (size > INT_MAX / nchannels) { /* This overflow test is rigorously correct because both multiplicands are >= 1. Use the argument names from the docs for the error msg. */ @@ -1119,6 +1118,7 @@ "width * nchannels too big for a C int"); return NULL; } + bytes_per_frame = size * nchannels; if (weightA < 1 || weightB < 0) { PyErr_SetString(AudioopError, "weightA should be >= 1, weightB should be >= 0"); diff -r f28aff31900a Objects/longobject.c --- a/Objects/longobject.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Objects/longobject.c Wed Jan 09 19:00:20 2013 +0200 @@ -658,10 +658,9 @@ assert(ndigits == 0 || v->ob_digit[ndigits - 1] != 0); if (ndigits > 0) { digit msd = v->ob_digit[ndigits - 1]; - - result = (ndigits - 1) * PyLong_SHIFT; - if (result / PyLong_SHIFT != (size_t)(ndigits - 1)) + if ((size_t)(ndigits - 1) > PY_SIZE_MAX / (size_t)PyLong_SHIFT) goto Overflow; + result = (size_t)(ndigits - 1) * (size_t)PyLong_SHIFT; do { ++result; if (result == 0) diff -r f28aff31900a Objects/tupleobject.c --- a/Objects/tupleobject.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Objects/tupleobject.c Wed Jan 09 19:00:20 2013 +0200 @@ -80,15 +80,11 @@ else #endif { - Py_ssize_t nbytes = size * sizeof(PyObject *); /* Check for overflow */ - if (nbytes / sizeof(PyObject *) != (size_t)size || - (nbytes > PY_SSIZE_T_MAX - sizeof(PyTupleObject) - sizeof(PyObject *))) - { + if (size > (PY_SSIZE_T_MAX - sizeof(PyTupleObject) - + sizeof(PyObject *)) / sizeof(PyObject *)) { return PyErr_NoMemory(); } - nbytes += sizeof(PyTupleObject) - sizeof(PyObject *); - op = PyObject_GC_NewVar(PyTupleObject, &PyTuple_Type, size); if (op == NULL) return NULL; @@ -465,9 +461,9 @@ if (Py_SIZE(a) == 0) return PyTuple_New(0); } + if (n > PY_SSIZE_T_MAX / Py_SIZE(a)) + return PyErr_NoMemory(); size = Py_SIZE(a) * n; - if (size/Py_SIZE(a) != n) - return PyErr_NoMemory(); np = (PyTupleObject *) PyTuple_New(size); if (np == NULL) return NULL; diff -r f28aff31900a Objects/unicodeobject.c --- a/Objects/unicodeobject.c Wed Jan 09 12:21:57 2013 +0200 +++ b/Objects/unicodeobject.c Wed Jan 09 19:00:20 2013 +0200 @@ -2427,8 +2427,6 @@ const char *errors) { PyObject *v; - /* It might be possible to tighten this worst case */ - Py_ssize_t allocated = 8 * size; int inShift = 0; Py_ssize_t i = 0; unsigned int base64bits = 0; @@ -2439,10 +2437,10 @@ if (size == 0) return PyBytes_FromStringAndSize(NULL, 0); - if (allocated / 8 != size) + /* It might be possible to tighten this worst case */ + if (size > PY_SSIZE_T_MAX / 8) return PyErr_NoMemory(); - - v = PyBytes_FromStringAndSize(NULL, allocated); + v = PyBytes_FromStringAndSize(NULL, size * 8); if (v == NULL) return NULL; @@ -2940,9 +2938,9 @@ } else { /* Overallocate on the heap, and give the excess back at the end. */ + if (size > PY_SSIZE_T_MAX / 4) + return PyErr_NoMemory(); nallocated = size * 4; - if (nallocated / 4 != size) /* overflow! */ - return PyErr_NoMemory(); result = PyBytes_FromStringAndSize(NULL, nallocated); if (result == NULL) return NULL; @@ -3270,7 +3268,7 @@ { PyObject *v; unsigned char *p; - Py_ssize_t nsize, bytesize; + Py_ssize_t nsize; #ifndef Py_UNICODE_WIDE Py_ssize_t i, pairs; #else @@ -3301,10 +3299,9 @@ pairs++; #endif nsize = (size - pairs + (byteorder == 0)); - bytesize = nsize * 4; - if (bytesize / 4 != nsize) + if (nsize > PY_SSIZE_T_MAX / 4) return PyErr_NoMemory(); - v = PyBytes_FromStringAndSize(NULL, bytesize); + v = PyBytes_FromStringAndSize(NULL, nsize * 4); if (v == NULL) return NULL; @@ -3659,7 +3656,7 @@ { PyObject *v; unsigned char *p; - Py_ssize_t nsize, bytesize; + Py_ssize_t nsize; #ifdef Py_UNICODE_WIDE Py_ssize_t i, pairs; #else @@ -3689,10 +3686,9 @@ size > PY_SSIZE_T_MAX - pairs - (byteorder == 0)) return PyErr_NoMemory(); nsize = size + pairs + (byteorder == 0); - bytesize = nsize * 2; - if (bytesize / 2 != nsize) + if (nsize > PY_SSIZE_T_MAX / 2) return PyErr_NoMemory(); - v = PyBytes_FromStringAndSize(NULL, bytesize); + v = PyBytes_FromStringAndSize(NULL, nsize * 2); if (v == NULL) return NULL; @@ -7035,7 +7031,7 @@ } else { Py_ssize_t n, i, j; - Py_ssize_t product, new_size, delta; + Py_ssize_t new_size, delta; Py_UNICODE *p; /* replace strings */ @@ -7048,18 +7044,14 @@ if (delta == 0) { new_size = self->length; } else { - product = n * (str2->length - str1->length); - if ((product / (str2->length - str1->length)) != n) { + if (str2->length > str1->length && + str2->length - str1->length > + (PY_SSIZE_T_MAX - self->length) / n) { PyErr_SetString(PyExc_OverflowError, "replace string is too long"); return NULL; } - new_size = self->length + product; - if (new_size < 0) { - PyErr_SetString(PyExc_OverflowError, - "replace string is too long"); - return NULL; - } + new_size = self->length + n * (str2->length - str1->length); } u = _PyUnicode_New(new_size); if (!u) @@ -8316,7 +8308,6 @@ PyUnicodeObject *u; Py_UNICODE *p; Py_ssize_t nchars; - size_t nbytes; if (len < 1) { Py_INCREF(unicode_empty); @@ -8332,18 +8323,12 @@ /* ensure # of chars needed doesn't overflow int and # of bytes * needed doesn't overflow size_t */ - nchars = len * str->length; - if (nchars / len != str->length) { + if (str->length > (PY_SSIZE_T_MAX / sizeof(Py_UNICODE) - 1) / len) { PyErr_SetString(PyExc_OverflowError, "repeated string is too long"); return NULL; } - nbytes = (nchars + 1) * sizeof(Py_UNICODE); - if (nbytes / sizeof(Py_UNICODE) != (size_t)(nchars + 1)) { - PyErr_SetString(PyExc_OverflowError, - "repeated string is too long"); - return NULL; - } + nchars = len * str->length; u = _PyUnicode_New(nchars); if (!u) return NULL; From report at bugs.python.org Tue Jan 15 12:36:52 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 11:36:52 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358249812.91.0.860254598091.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch. With this patch, passing a non-iterable choices argument to parser.add_argument() raises (for example): Traceback (most recent call last): ... File ".../Lib/argparse.py", line 558, in _metavar_formatter choice_strs = [str(choice) for choice in action.choices] TypeError: 'MyChoices' object is not iterable instead of the incorrect: File ".../Lib/argparse.py", line 1333, in add_argument raise ValueError("length of metavar tuple does not match nargs") ValueError: length of metavar tuple does not match nargs Is it okay to change this exception type in maintenance releases? The other option is to keep the error as a ValueError but to change the error message, though I think TypeError is the correct exception to allow through. Note that the existing ValueError is preserved for other code paths. Indeed, there are several tests checking for this ValueError and its error message, which the attached patch does not break. If we want to consider accepting non-iterable choices for 3.4, we can still have that discussion as part of a separate patch. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file28734/issue-16468-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 12:43:43 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 11:43:43 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358250223.33.0.031810238686.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Slight doc tweak: s/container/sequence/. ---------- Added file: http://bugs.python.org/file28735/issue-16468-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 12:55:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 11:55:27 +0000 Subject: [issue16216] Arithmetic operations with NULL In-Reply-To: <1350081908.35.0.947627906901.issue16216@psf.upfronthosting.co.za> Message-ID: <1358250927.08.0.533772578273.issue16216@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, I forgot to mention the issue number in commit messages. There are changeset ad9b5c69b8b6 (for 3.3) and changeset 1f66fc397c8d (for default). ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 13:09:51 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 12:09:51 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message Message-ID: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> New submission from Chris Jerdonek: >>> parser = argparse.ArgumentParser() >>> parser.add_argument('foo', nargs='a') ... File ".../Lib/argparse.py", line 1333, in add_argument raise ValueError("length of metavar tuple does not match nargs") ValueError: length of metavar tuple does not match nargs The message should really be about nargs not having a valid value. The nargs value is invalid regardless of the metavar. There is also this: >>> parser.add_argument('foo', nargs=-1) _StoreAction(option_strings=[], dest='foo', nargs=-1, const=None, default=None, type=None, choices=None, help=None, metavar=None) which is not consistent with this: >>> parser.add_argument('foo', nargs=0) ... raise ValueError('nargs for store actions must be > 0; if you ' ValueError: nargs for store actions must be > 0; if you have nothing to store, actions such as store true or store const may be more appropriate ---------- components: Library (Lib) keywords: easy messages: 180012 nosy: bethard, chris.jerdonek priority: normal severity: normal stage: needs patch status: open title: argparse: bad nargs value raises misleading message type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 13:32:00 2013 From: report at bugs.python.org (Stefan Krah) Date: Tue, 15 Jan 2013 12:32:00 +0000 Subject: [issue16422] Decimal constants should be the same for py & c module versions In-Reply-To: <1352243072.7.0.172202427654.issue16422@psf.upfronthosting.co.za> Message-ID: <1358253120.15.0.768297700819.issue16422@psf.upfronthosting.co.za> Stefan Krah added the comment: In the absence of an enum type, string constants are nicer to read in the REPL, so here's a patch. Translating between strings and ints is fast if you use the module constants. ---------- keywords: +patch Added file: http://bugs.python.org/file28736/issue16422.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 13:34:01 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 15 Jan 2013 12:34:01 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358253241.32.0.908257925073.issue12939@psf.upfronthosting.co.za> Richard Oudkerk added the comment: New patch reflecting Amaury's comments. ---------- Added file: http://bugs.python.org/file28737/winfileio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 13:34:12 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 15 Jan 2013 12:34:12 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358253252.39.0.766393057056.issue12939@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file28707/winfileio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 13:35:43 2013 From: report at bugs.python.org (Christian Heimes) Date: Tue, 15 Jan 2013 12:35:43 +0000 Subject: [issue15994] memoryview to freed memory can cause segfault In-Reply-To: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za> Message-ID: <1358253343.37.0.373586817178.issue15994@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 14:14:42 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Jan 2013 13:14:42 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <3YlsTY3wN0zP57@mail.python.org> Roundup Robot added the comment: New changeset f07435fa6736 by Richard Oudkerk in branch '2.7': Issue #10527: Remove dead code http://hg.python.org/cpython/rev/f07435fa6736 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 14:24:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Jan 2013 13:24:39 +0000 Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in select()" In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za> Message-ID: <3Ylsj10tnfzPCZ@mail.python.org> Roundup Robot added the comment: New changeset 49d45151b9ed by Richard Oudkerk in branch '3.2': Issue #10527: Remove dead code http://hg.python.org/cpython/rev/49d45151b9ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 14:40:03 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Jan 2013 13:40:03 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1337352396.54.0.468921009595.issue14850@psf.upfronthosting.co.za> Message-ID: <3Ylt2k0BkLzNlw@mail.python.org> Roundup Robot added the comment: New changeset 33a8ef498b1e by Serhiy Storchaka in branch '2.7': Issue #14850: Now a chamap decoder treates U+FFFE as "undefined mapping" http://hg.python.org/cpython/rev/33a8ef498b1e New changeset 13cd78a2a17b by Serhiy Storchaka in branch '3.2': Issue #14850: Now a chamap decoder treates U+FFFE as "undefined mapping" http://hg.python.org/cpython/rev/13cd78a2a17b New changeset 6ac4f1609847 by Serhiy Storchaka in branch '3.3': Issue #14850: Now a chamap decoder treates U+FFFE as "undefined mapping" http://hg.python.org/cpython/rev/6ac4f1609847 New changeset 03e22cc9407a by Serhiy Storchaka in branch 'default': Issue #14850: Now a chamap decoder treates U+FFFE as "undefined mapping" http://hg.python.org/cpython/rev/03e22cc9407a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 15:05:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 14:05:51 +0000 Subject: [issue16971] Refleaks in charmap decoder Message-ID: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Charmap decoder can leak a reference in case of error. ---------- components: Unicode files: charmap_decode_leaks-3.3.patch keywords: 3.3regression, patch messages: 180018 nosy: ezio.melotti, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Refleaks in charmap decoder type: resource usage versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28738/charmap_decode_leaks-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 15:06:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 14:06:47 +0000 Subject: [issue16971] Refleaks in charmap decoder In-Reply-To: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za> Message-ID: <1358258807.44.0.166518037662.issue16971@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file28739/charmap_decode_leaks-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 15:08:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 14:08:56 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1337352396.54.0.468921009595.issue14850@psf.upfronthosting.co.za> Message-ID: <1358258936.59.0.571760518136.issue14850@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed. Thank you for your answers, Martin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 15:09:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 14:09:39 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1337352396.54.0.468921009595.issue14850@psf.upfronthosting.co.za> Message-ID: <1358258979.03.0.264473648337.issue14850@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 15:12:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 14:12:15 +0000 Subject: [issue16971] Refleaks in charmap decoder In-Reply-To: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za> Message-ID: <1358259135.83.0.833519010749.issue16971@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 15:13:40 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 15 Jan 2013 14:13:40 +0000 Subject: [issue16971] Refleaks in charmap decoder In-Reply-To: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za> Message-ID: <1358259220.6.0.463221642306.issue16971@psf.upfronthosting.co.za> Ezio Melotti added the comment: How difficult would it be to write a test for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 16:13:34 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Jan 2013 15:13:34 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358262814.86.0.18841170844.issue16468@psf.upfronthosting.co.za> R. David Murray added the comment: Since the line between a type error and a value error is fuzzy anyway, I'd be in favor of maintaining the backward compatibility here. We don't consider exception message content part of the API (though we do occasionally work to preserve it when we know people are depending on it), but the exception *types* generally are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 16:19:18 2013 From: report at bugs.python.org (Kirill) Date: Tue, 15 Jan 2013 15:19:18 +0000 Subject: [issue16972] Useless function call in site.py Message-ID: <1358263158.12.0.256435330615.issue16972@psf.upfronthosting.co.za> New submission from Kirill: In Lib/site.py:149 [1] _init_pathinfo call has no effect. Looks like it's here because in the past _init_pathinfo was changing a global variable [2]. I believe that it should be changed to `known_paths = _init_pathinfo()`, in the same way as it's done in addsitedir function [3]. [1] http://hg.python.org/cpython/file/fb17969ace93/Lib/site.py#l149 [2] http://hg.python.org/cpython/annotate/ac13a6ce13e2/Lib/site.py#l102 [3] http://hg.python.org/cpython/file/fb17969ace93/Lib/site.py#l189 ---------- components: Library (Lib) files: patch.diff keywords: patch messages: 180022 nosy: x746e priority: normal severity: normal status: open title: Useless function call in site.py type: enhancement Added file: http://bugs.python.org/file28740/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 16:27:44 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 15:27:44 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358263664.75.0.399613798665.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Sounds fine. Does that mean a test should still be added for the message? I was never clear on this because on the one hand we want to be sure we use the right message (and that we're actually fixing the issue), but on the other hand we don't want the message to be part of the API. By the way, to make things slightly less brittle, I could be clever and trigger a TypeError to get the right message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 16:28:43 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 15:28:43 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358263723.59.0.0472669695909.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I guess another option would be to mark the test CPython-only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 16:57:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Jan 2013 15:57:32 +0000 Subject: [issue13773] Support sqlite3 uri filenames In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za> Message-ID: <1358265452.65.0.406928515099.issue13773@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 16:59:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Jan 2013 15:59:29 +0000 Subject: [issue13773] Support sqlite3 uri filenames In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za> Message-ID: <1358265569.41.0.862184483983.issue13773@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This would definitely be useful. I would have liked to have this feature today. poq, could you sign a contributor agreement? See http://www.python.org/psf/contrib/ Also, it's better if you can use a real name (or at least a well-known pseudonym). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:01:52 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Jan 2013 16:01:52 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1358265712.57.0.0590971559853.issue9303@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This would be nice to have in 3.4. When were the _v2 APIs introduced? See also issue13773 which uses sqlite3_open_v2() to pass some flags. ---------- nosy: +larry, pitrou versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:04:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Jan 2013 16:04:35 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <3YlxFb0JGqzP6n@mail.python.org> Roundup Robot added the comment: New changeset 411bb75be5d1 by Serhiy Storchaka in branch '3.2': Issue #15861: tkinter now correctly works with lists and tuples containing http://hg.python.org/cpython/rev/411bb75be5d1 New changeset 927352d7e994 by Serhiy Storchaka in branch '3.3': Issue #15861: tkinter now correctly works with lists and tuples containing http://hg.python.org/cpython/rev/927352d7e994 New changeset 340e97ebe911 by Serhiy Storchaka in branch 'default': Issue #15861: tkinter now correctly works with lists and tuples containing http://hg.python.org/cpython/rev/340e97ebe911 New changeset 917ae14831ec by Serhiy Storchaka in branch '2.7': Issue #15861: tkinter now correctly works with lists and tuples containing http://hg.python.org/cpython/rev/917ae14831ec ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:06:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 16:06:40 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <1358266000.95.0.484816006961.issue15861@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed. Thank you for report, Bryan Oakley. ---------- resolution: -> fixed stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:07:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 16:07:09 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <1358266029.01.0.911257586641.issue15861@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:07:47 2013 From: report at bugs.python.org (Grant) Date: Tue, 15 Jan 2013 16:07:47 +0000 Subject: [issue16973] Extending the datetime package by adding a workDayMath module Message-ID: <1358266067.49.0.788080325558.issue16973@psf.upfronthosting.co.za> New submission from Grant: This module would allow programmers to perform high level workday addition and subtraction - a commonly needed function in the finance and accounting world not yet provided in a standard python module. ---------- components: Extension Modules files: workDayMath.py messages: 180029 nosy: belopolsky, grantf priority: normal severity: normal status: open title: Extending the datetime package by adding a workDayMath module type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file28741/workDayMath.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:09:07 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 16:09:07 +0000 Subject: [issue11290] ttk.Combobox['values'] String Conversion to Tcl In-Reply-To: <1298394325.28.0.0845611659637.issue11290@psf.upfronthosting.co.za> Message-ID: <1358266147.95.0.873399874256.issue11290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in issue15861. Thank you for report, Clayton Darwin. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:11:50 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 15 Jan 2013 16:11:50 +0000 Subject: [issue16973] Extending the datetime package by adding a workDayMath module In-Reply-To: <1358266067.49.0.788080325558.issue16973@psf.upfronthosting.co.za> Message-ID: <1358266310.21.0.596102228455.issue16973@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think it would be better to propose this on the Python-ideas mailing list first. Adding a new module usually requires a PEP, and the module should be tested "in the wild" beforehand (i.e. it should be published on PyPI and should have a decent user base). The module you attached also doesn't respect some of the guidelines listed in the PEP 8. ---------- components: +Library (Lib) -Extension Modules nosy: +ezio.melotti resolution: -> rejected stage: -> committed/rejected status: open -> closed versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:22:00 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Jan 2013 16:22:00 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358266920.59.0.761408485631.issue16468@psf.upfronthosting.co.za> R. David Murray added the comment: CPython only would not be appropriate, as it is not. What I usually do in such cases is use AssertRaisesRegex looking for some critical part of the message that represents the functionality we are looking for rather than the exact text. In this case, it would be looking for the type name of the problem value in the message, since that is how we are identifying the specific source of the error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:24:20 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 15 Jan 2013 16:24:20 +0000 Subject: [issue9501] Logging shutdown regressions with weakrefs In-Reply-To: <1280875181.95.0.557870097374.issue9501@psf.upfronthosting.co.za> Message-ID: <1358267060.22.0.728865571005.issue9501@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Still randomly getting ignored exceptions on 3.3 and the default branch, got for example: Exception TypeError: TypeError("argument of type 'NoneType' is not iterable",) in ignored This happens in a threaded application. The root cause is explained in http://bugs.python.org/issue1722344#msg62078 Instead of building a test case to reproduce the problem, the attached teardown_module.py script is a contrived example that shows the issue 9501 is not fully fixed. Ignored exceptions appear randomly, so teardown_module.py must be run in a loop, for example: $ while [ 1 ]; do python teardown_module.py; sleep .1; done The attached patch fix the issue by testing all the globals used in _removeHandlerRef and teardown_module.py runs fine with this patch applied. ---------- nosy: +xdegaye Added file: http://bugs.python.org/file28742/teardown_module.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:24:46 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 15 Jan 2013 16:24:46 +0000 Subject: [issue9501] Logging shutdown regressions with weakrefs In-Reply-To: <1280875181.95.0.557870097374.issue9501@psf.upfronthosting.co.za> Message-ID: <1358267086.64.0.352675111976.issue9501@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- keywords: +patch Added file: http://bugs.python.org/file28743/teardown_module.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:34:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 16:34:00 +0000 Subject: [issue6933] Threading issue with Tkinter Frame.insert In-Reply-To: <1253206861.41.0.487118668051.issue6933@psf.upfronthosting.co.za> Message-ID: <1358267640.87.0.486973254937.issue6933@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tkinter as perhaps any other GUI library must be used only from one thread. ---------- nosy: +serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:41:07 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 16:41:07 +0000 Subject: [issue6160] Tkinter.Spinbox: fix for bbox and removed some uninteresting returns In-Reply-To: <1243826530.3.0.945381049334.issue6160@psf.upfronthosting.co.za> Message-ID: <1358268067.17.0.15185954042.issue6160@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It should be "self._getints(...) or None" as in other methods. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:53:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 16:53:27 +0000 Subject: [issue4333] Reworked Dialog.py In-Reply-To: <1226881404.91.0.533308530681.issue4333@psf.upfronthosting.co.za> Message-ID: <1358268807.25.0.546497696169.issue4333@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can you please update the patch for the default branch tip? It looks too outdated. ---------- nosy: +serhiy.storchaka versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 17:57:06 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 16:57:06 +0000 Subject: [issue15019] String termination on Linux In-Reply-To: <1338994065.34.0.987983176333.issue15019@psf.upfronthosting.co.za> Message-ID: <1358269026.1.0.489680368432.issue15019@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 18:12:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 17:12:21 +0000 Subject: [issue6167] Tkinter.Scrollbar: the activate method needs to return a value, and set should take only two args In-Reply-To: <1243887092.8.0.492821608561.issue6167@psf.upfronthosting.co.za> Message-ID: <1358269941.16.0.830460688882.issue6167@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In versions of Tk before 4.0, the set command accepted 4 arguments. I think this is a new feature and can be applied only to 3.4. Agree with Jim that for backward compatibility we should keep name "index" and arbitrary number of arguments at least for one release (with deprecation warnings etc). ---------- nosy: +serhiy.storchaka type: behavior -> enhancement versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 18:16:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 17:16:44 +0000 Subject: [issue6225] Fixing several minor bugs in Tkinter.Canvas and one in Misc._configure In-Reply-To: <1244325396.24.0.788727463424.issue6225@psf.upfronthosting.co.za> Message-ID: <1358270204.32.0.697347281559.issue6225@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For backward compatibility we must keep accepting arbitrary amount of arguments at least a one release (with warnings). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 18:57:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Jan 2013 17:57:34 +0000 Subject: [issue9501] Logging shutdown regressions with weakrefs In-Reply-To: <1280875181.95.0.557870097374.issue9501@psf.upfronthosting.co.za> Message-ID: <3Ylzlx4k3zzNy8@mail.python.org> Roundup Robot added the comment: New changeset 966887830011 by Vinay Sajip in branch '2.7': Issue #9501: Improved shutdown handling to deal with module attributes correctly. http://hg.python.org/cpython/rev/966887830011 New changeset 8eac88f49cc0 by Vinay Sajip in branch '3.2': Issue #9501: Improved shutdown handling to deal with module attributes correctly. http://hg.python.org/cpython/rev/8eac88f49cc0 New changeset 3161a94ff73c by Vinay Sajip in branch '3.3': Issue #9501: Merged fix from 3.2. http://hg.python.org/cpython/rev/3161a94ff73c New changeset 4fd8c35a05b2 by Vinay Sajip in branch 'default': Issue #9501: Merged fix from 3.3. http://hg.python.org/cpython/rev/4fd8c35a05b2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 18:58:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 17:58:38 +0000 Subject: [issue16971] Refleaks in charmap decoder In-Reply-To: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za> Message-ID: <1358272718.72.0.27971829168.issue16971@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Enough difficult. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 19:16:11 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 15 Jan 2013 18:16:11 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1358273771.59.0.503011246749.issue16968@psf.upfronthosting.co.za> Zachary Ware added the comment: Hmmm, actually, I was wrong; Brett's suggestion doesn't cover running as part of regrtest. It looks like Chris is right and some kind of load_tests magic will have to happen. I'm looking into it now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 19:27:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 18:27:39 +0000 Subject: [issue15436] __sizeof__ is not documented In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za> Message-ID: <1358274459.36.0.625740580451.issue15436@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 19:27:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 18:27:47 +0000 Subject: [issue16643] Wrong documented default value for timefunc parameter in sched.scheduler() In-Reply-To: <1354964381.71.0.639628706124.issue16643@psf.upfronthosting.co.za> Message-ID: <1358274467.71.0.839195316058.issue16643@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 19:28:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 18:28:12 +0000 Subject: [issue16700] Document that bytes OS API can returns unusable results on Windows In-Reply-To: <1355677117.39.0.191453655217.issue16700@psf.upfronthosting.co.za> Message-ID: <1358274492.93.0.233246530354.issue16700@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 19:30:16 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 18:30:16 +0000 Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1358274616.01.0.279725120401.issue15984@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 20:22:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 19:22:58 +0000 Subject: [issue7340] Doc for sys.exc_info has warning that is no longer valid In-Reply-To: <1258481567.01.0.124523901293.issue7340@psf.upfronthosting.co.za> Message-ID: <1358277778.9.0.0148642595794.issue7340@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 20:21:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 19:21:00 +0000 Subject: [issue7468] PyErr_Format documentation doesn't mention all format codes In-Reply-To: <1260444170.83.0.494210811062.issue7468@psf.upfronthosting.co.za> Message-ID: <1358277660.28.0.16232506873.issue7468@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in r86838. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 20:26:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 19:26:56 +0000 Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za> Message-ID: <1358278016.54.0.357999048279.issue9669@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 20:27:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 19:27:24 +0000 Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za> Message-ID: <1358278044.87.0.541099427767.issue9669@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Regular Expressions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 20:31:13 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Jan 2013 19:31:13 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358278273.79.0.625518217076.issue12939@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The current patch does not support overlapped IO, but that could be > added easily enough. (Overlapped IO for normal files might be more > complicated.) That could be cool. Wouldn't it belong in the fabled winapi module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 20:32:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 19:32:39 +0000 Subject: [issue9889] PyUnicode_FormatV and Py_UNICODE*? In-Reply-To: <1284751931.03.0.894481141092.issue9889@psf.upfronthosting.co.za> Message-ID: <1358278359.29.0.525519504655.issue9889@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The Py_UNICODE* representation is deprecated since 3.3. New features can be added only to 3.4. ---------- nosy: +serhiy.storchaka resolution: -> rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 20:55:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 19:55:00 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1358279700.44.0.129654141667.issue10590@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed, xml.dom.minidom.parseString() and xml.etree.ElementTree.fromstring() accepts both bytes and strings, xml.dom.minidom.parse(), xml.etree.ElementTree.parse() and even xml.sax.parse() accepts both byte and text streams. Only xml.sax.parseString() rejects strings in contrast to its name. This looks as 2 to 3 porting bug. ---------- components: +Unicode nosy: +ezio.melotti, serhiy.storchaka stage: -> needs patch versions: +Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 21:06:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 20:06:37 +0000 Subject: [issue10701] Error pickling a dict In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za> Message-ID: <1358280397.38.0.766761979252.issue10701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It's interesting. The example behaves unstable on 3.3+ with C?implementation of picle, sometimes works, sometimes fails. With Python implementation and on 3.2 it works always. On 2.7 it fails always. A?difference between C?and Python implementations of pickle is a bug and should be fixed. ---------- nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 21:12:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 20:12:43 +0000 Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za> Message-ID: <1358280763.45.0.991980984337.issue11367@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Already fixed in 3.3+. ---------- keywords: +easy nosy: +eli.bendersky, serhiy.storchaka stage: -> needs patch type: -> enhancement versions: +Python 2.7, Python 3.2 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 21:16:25 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Jan 2013 20:16:25 +0000 Subject: [issue10701] Error pickling a dict In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za> Message-ID: <1358280985.9.0.4458424823.issue10701@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I find the posted code mystifying. As the name suggests, __getstate__ should probably not mutate anything. It would be nice if you could post a simpler example to reproduce issue. Even better if it doesn't have a mutating __getstate__, I would say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 21:24:11 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 15 Jan 2013 20:24:11 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358281451.32.0.993449826824.issue16468@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The exception question is messy, but I think it is the wrong question. The doc is correct in that it says what the code should be doing. To test whether an argument is in a collection of choices, the code should just say that: 'arg in choices' (as far as I know, it does -- for the actual check). In other words, I think the original intent of this issue is correct. "Clearly the module was written under the assumption (in multiple places) that choices are iterable." I think it should not. We implement 'in' with '__contains__', rather than forcing the use of iteration, for good reason. I discussed some examples in msg175520. As far as I know, the reason argparse iterates is to bypass the object's representation methods and produce custom, one-size-fits-all, usage and error messages. As discussed in #16418, this supposed user-friendliness may not be. To me, restricting input for this reason is a tail-wags-dog situation. If the object is not iterable, just use repr for the messages instead of exiting. Let the app writer be responsible for making them user-friendly and not absurdly long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 21:54:15 2013 From: report at bugs.python.org (David Beazley) Date: Tue, 15 Jan 2013 20:54:15 +0000 Subject: [issue16723] io.TextIOWrapper on urllib.request.urlopen terminates prematurely In-Reply-To: <1355899334.66.0.683261774989.issue16723@psf.upfronthosting.co.za> Message-ID: <1358283255.8.0.0497941550955.issue16723@psf.upfronthosting.co.za> David Beazley added the comment: I have run into this bug myself. Agree that a file-like object should never report itself as closed unless .close() has been explicitly called on it. HTTPResponse should not return itself as closed after the end-of-file has been reached. I think there is also a bug in the implementation of TextIOWrapper as well. Even if the underlying file reports itself as closed, previously read and buffered data should be processed first before reporting an error about the file being closed. ---------- nosy: +dabeaz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 22:08:26 2013 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 15 Jan 2013 21:08:26 +0000 Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za> Message-ID: <1358284106.79.0.0448984848183.issue9669@psf.upfronthosting.co.za> Matthew Barnett added the comment: I've attached my attempt at a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file28744/issue9669.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 22:12:10 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 21:12:10 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358284330.07.0.140012108756.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I don't disagree that this feature could be useful. I'm just not sure it should go into a maintenance release. It feels like an enhancement to me because to use this feature, the user will have to use the API in a way they haven't before, and we will probably have to do things like add documentation and examples for this new use case (e.g. explaining that users passing non-iterable choices will need to implement a user-friendly repr() for help to render nicely). Also, it introduces new questions like: if we're going to be using repr() for that case, then why wouldn't we allow repr() to be used for iterable choices if the user would like to better control the behavior (e.g. for very long lists)? Why not have a unified way to deal with this situation (e.g. something like __argparse_repr__ with a better name, or else provide or document that certain formatters should be used)? These don't seem like bug-fix questions. > As far as I know, the reason argparse iterates is to bypass the object's representation methods and produce custom, one-size-fits-all, usage and error messages. Another possibility is that it was the most helpful message for the use case the writers originally had in mind. Certainly, for example, seeing the available choices '0, 1, 2, 3, 4' is more useful than seeing 'xrange(5)'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 22:23:56 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 15 Jan 2013 21:23:56 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358285036.22.0.784760853546.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Note that we would also have to deal with not just the error text but also the usage string. From the docs: >>> parser.parse_args('11'.split()) usage: PROG [-h] {5,6,7,8,9} PROG: error: argument foo: invalid choice: 11 (choose from 5, 6, 7, 8, 9) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 22:37:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 21:37:19 +0000 Subject: [issue12983] byte string literals with invalid hex escape codes raise ValueError instead of SyntaxError In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za> Message-ID: <1358285839.43.0.106878491793.issue12983@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which include position number in the invalid bytes exception, wrap it into SyntaxError, and adds tests for bytes and strings. ---------- keywords: +patch nosy: +serhiy.storchaka stage: test needed -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file28745/parse_strlit_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 22:40:06 2013 From: report at bugs.python.org (Eric Lammerts) Date: Tue, 15 Jan 2013 21:40:06 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" Message-ID: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za> New submission from Eric Lammerts: $ echo lovely spam > "" $ python -c 'open("nonexistent","r")' Traceback (most recent call last): File "", line 1, in lovely spam IOError: [Errno 2] No such file or directory: 'nonexistent' I see this in python 2.7.3 and 3.2.3 from Ubuntu 12.04. ---------- messages: 180055 nosy: eric-bugs-python priority: normal severity: normal status: open title: when "python -c command" does a traceback, it open the file "" type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 22:42:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 21:42:51 +0000 Subject: [issue16975] Broken error handling in codecs.escape_decode() Message-ID: <1358286171.54.0.132780688137.issue16975@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import codecs >>> codecs.escape_decode(r'\x1\x2\x3\x4\x5\x6\x7\x8\x9', 'replace') (b'?\\x1?\\x2?\\x3?\\x4?\\x5?\\x6?\\x', 27) >>> codecs.escape_decode(r'\x1\x2\x3\x4\x5\x6\x7\x8\x9' * 1000, 'replace') Segmentation fault ---------- components: Interpreter Core messages: 180056 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Broken error handling in codecs.escape_decode() type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 22:46:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 21:46:48 +0000 Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za> Message-ID: <1358286408.23.0.881097432477.issue9669@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 22:49:42 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Jan 2013 21:49:42 +0000 Subject: [issue7340] Doc for sys.exc_info has warning that is no longer valid In-Reply-To: <1258481567.01.0.124523901293.issue7340@psf.upfronthosting.co.za> Message-ID: <3Ym4vn3YDxzRGV@mail.python.org> Roundup Robot added the comment: New changeset 3fa3e7975724 by Benjamin Peterson in branch '3.3': remove warning about tb circular reference (closes #7340) http://hg.python.org/cpython/rev/3fa3e7975724 New changeset d866bbdd68e8 by Benjamin Peterson in branch 'default': merge 3.3 (#7340) http://hg.python.org/cpython/rev/d866bbdd68e8 ---------- nosy: +python-dev resolution: accepted -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 23:02:45 2013 From: report at bugs.python.org (Anthony Lozano) Date: Tue, 15 Jan 2013 22:02:45 +0000 Subject: [issue16976] Asyncore/asynchat hangs when used with ssl sockets Message-ID: <1358287365.37.0.159760356153.issue16976@psf.upfronthosting.co.za> New submission from Anthony Lozano: If you create a asynchat subclass with a SSL socket asyncore can hang when data larger than the ac_in_buffer_size comes in. What (I think) happens is that asyncore uses a select.select call to determine when to read more data from the socket. On the first call, this will correctly see that there is data to recv and we will continue on to the handle_read function in asynchat. Once there, if there is more than ac_in_buffer_size data to read, handle_read will not find the terminator, and thus not call find_terminator, expecting to find it on the next pass with another self.recv. Unfortunately, the SSL wrapped socket will not play nicely with next select call (the one that should be triggering the next handle_read) because the ssl socket might internally read more data, and select is looking at the raw socket which is empty now thanks to ssl (at least according to an answer here: http://stackoverflow.com/questions/3187565/select-and-ssl-in-python). A solution would be to check the if the socket has any data pending with the sslsock.pending() method and read the rest out. I am doing this in the handle_read function of my child class as attached, but I don't know if that's a generic enough solution for everyone. ---------- components: None files: asychat_fix.py messages: 180058 nosy: Anthony.Lozano priority: normal severity: normal status: open title: Asyncore/asynchat hangs when used with ssl sockets type: crash versions: Python 2.7 Added file: http://bugs.python.org/file28746/asychat_fix.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 23:03:33 2013 From: report at bugs.python.org (Anthony Lozano) Date: Tue, 15 Jan 2013 22:03:33 +0000 Subject: [issue16976] Asyncore/asynchat hangs when used with ssl sockets In-Reply-To: <1358287365.37.0.159760356153.issue16976@psf.upfronthosting.co.za> Message-ID: <1358287413.35.0.262946769528.issue16976@psf.upfronthosting.co.za> Changes by Anthony Lozano : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 23:03:34 2013 From: report at bugs.python.org (Frank Wierzbicki) Date: Tue, 15 Jan 2013 22:03:34 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1358287414.81.0.950332639246.issue16886@psf.upfronthosting.co.za> Frank Wierzbicki added the comment: I have addressed all of the comments, but I don't know the exact procedure here. Does someone need to say "Looks good to me" before I push? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 23:05:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Jan 2013 22:05:00 +0000 Subject: [issue16976] Asyncore/asynchat hangs when used with ssl sockets In-Reply-To: <1358287365.37.0.159760356153.issue16976@psf.upfronthosting.co.za> Message-ID: <1358287500.47.0.329194922249.issue16976@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 23:13:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Jan 2013 22:13:09 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1358287989.86.0.914208573.issue16886@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you addressed last Ezio's comments, it will be good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 23:18:29 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 15 Jan 2013 22:18:29 +0000 Subject: [issue16976] Asyncore/asynchat hangs when used with ssl sockets In-Reply-To: <1358287365.37.0.159760356153.issue16976@psf.upfronthosting.co.za> Message-ID: <1358288309.01.0.994629074223.issue16976@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: asyncore simply does not support SSL. That is tracked in issue 10084. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 23:25:31 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Jan 2013 22:25:31 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <1358288731.66.0.330156063073.issue16886@psf.upfronthosting.co.za> R. David Murray added the comment: The ideal is if someone says "looks good to me". The practical path is that if you have addressed all the comments, and no one objects after a couple-three days, you should feel free to commit (unless you feel like you want another review, in which case you can ask for one). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 15 23:30:01 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Jan 2013 22:30:01 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" In-Reply-To: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za> Message-ID: <1358289001.57.0.73985343381.issue16974@psf.upfronthosting.co.za> R. David Murray added the comment: Heh. Nice find. I'm not sure how practical it is to fix, though. We don't have any actual rules about what indicates a 'non-file-stand-in' for the __file__ attribute, just a loose convention that it is an identifier in angle brackets. If we make that a hard rule, though, and someone really has a file named ''.... :) ---------- nosy: +r.david.murray versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 00:08:31 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 15 Jan 2013 23:08:31 +0000 Subject: [issue9501] Logging shutdown regressions with weakrefs In-Reply-To: <1280875181.95.0.557870097374.issue9501@psf.upfronthosting.co.za> Message-ID: <1358291311.0.0.57138795794.issue9501@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The reason why this happens in python 3.3.0 and not in 3.2: 1) lastResort holds a reference to an instance of _StderrHandler at module tear down, thus potentially triggering a TypeError in _removeHandlerRef. 2) The logging code has the following two lines that are meant to avoid the occurence of this problem: _defaultLastResort = _StderrHandler(WARNING) lastResort = _defaultLastResort Issue 12637 describes another unrelated problem with lastResort in python 3.2. As a workaround to this issue 12637, my application sets lastResort to None and this works fine in 3.2 (the logging howto states 'To obtain the pre-3.2 behaviour, logging.lastResort can be set to None'). With python 3.3 it is this setting of lastResort to None that causes these spurious 'exception ignored' messages, after removing this setting no messages are printed anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 00:18:39 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 15 Jan 2013 23:18:39 +0000 Subject: [issue9501] Logging shutdown regressions with weakrefs In-Reply-To: <1280875181.95.0.557870097374.issue9501@psf.upfronthosting.co.za> Message-ID: <1358291919.79.0.0296062971846.issue9501@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The initial teardown_module.py can be simply replaced with (not a contrived example anymore) the following statements to print the spurious ignored Exceptions: # Run the script in a loop: # while [ 1 ]; do python3 teardown_module.py; sleep .1; done import logging logging.lastResort = None print('Fin') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 02:00:48 2013 From: report at bugs.python.org (Ry Erickson) Date: Wed, 16 Jan 2013 01:00:48 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358298048.09.0.0011217984429.issue16969@psf.upfronthosting.co.za> Ry Erickson added the comment: ./python -m test -v test_urllib2net == CPython 3.3.0 (default, Jan 14 2013, 20:45:36) [GCC 4.6.1] == Linux-3.0.0-29-generic-i686-with-debian-wheezy-sid little-endian == /home/ry/Desktop/Python-3.3.0/build/test_python_2080 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_urllib2net test_urllib2net skipped -- Use of the 'network' resource not enabled 1 test skipped: test_urllib2net Those skips are all expected on linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 02:10:16 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Jan 2013 01:10:16 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358298616.23.0.814706081214.issue16468@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I took a good look at the 3.3 code. With respect to the main purpose of choices -- checking user input -- argparse does not require that choices be iterable, as it *does* use 'in', as it should. Line 2274: if action.choices is not None and value not in action.choices: So unless the usage message is generated even when not needed (I did not delve that far), non-iterables should work now as long as the user does not request the usage message or make an input mistake. If that is so, then this issue is strictly about the string representation of non-iterable choices. A mis-behaving tail is not a reason to kill the dog ;-). The easy answer, and the only sensible one I see, is to use either str() or repr(). But how to do that? I think this and #16418 have to be fixed together. The current format-by-iteration method, used for both usage and exceptions, works well for small iterable collections. But it is obnoxious for non-small collections. As I mentioned before, it will just hang for infinite iterables, which is even worse. So the method needs to be changed anyway. And to do that, it should be factored out of the three places where it is currently done in-line. At 557: elif action.choices is not None: choice_strs = [str(choice) for choice in action.choices] result = '{%s}' % ','.join(choice_strs) To match the code below, so it can be factored out into a function, change the last two lines to choices_str = ','.join(str(c) for c in action.choices) result = '{%s}' % choices_str At 597: (note that 'params' is adjusted action.__dict__) if params.get('choices') is not None: choices_str = ', '.join([str(c) for c in params['choices']]) params['choices'] = choices_str The intermediate list in the 2nd line is not needed choices_str = ', '.join(str(c) for c in params['choices']) I am aware of but do not understand ',' versus ', ' as joiner. I also do not understand why both versions of choices_str are needed. Are there two different usage messages? At 2276: 'choices': ', '.join(map(repr, action.choices))} or, replacing map with comprehension choices_str = ', '.join(repr(c) for c in action.choices) 'choices': choices_str} Now define choices_str(src, joiner, rep), delete 559 and 598, and modify 559: ... result = '{%s}' % choices_str(action.choices, ',', str) 599: ... params['choices'] = choices_str(param['choices'], ', ', str) 2276: ... 'choices': choices_str(action.choices, ', ', repr} (I am assuming that the two joiners are really needed. If not, delete.) Now we should be able to write choices_str to solve all 3 problems in the two issues. My coded suggestion: from itertools import islice N = 21 # maximum number (+1) of choices for the current nice string. # This is just an illustrative value, experiment might show better #. def choices_str(src, joiner, rep): prefix = list(islice(src, N)) if len(prefix) < N: # short iterables return joiner.join(rep(c) for c in prefix) # current string else: try: # non-short sliceable finite sequences head = joiner.join(rep(c) for c in src[:N//2]) tail = joiner.join(rep(c) for c in src[N//4:]) return head + ' ..., ' + tail except AttributeError: # no __getindex__(slice), everything else return repr(src) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 03:30:07 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 16 Jan 2013 02:30:07 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message Message-ID: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> New submission from Chris Jerdonek: When passing a string for the choices argument, argparse's usage and error messages differ from its behavior: >>> p = argparse.ArgumentParser() >>> p.add_argument('a', choices='abc') >>> p.parse_args(['d']) usage: [-h] {a,b,c} : error: argument a: invalid choice: 'd' (choose from 'a', 'b', 'c') >>> p.parse_args(['bc']) Namespace(a='bc') This is because argparse uses the "in" operator instead of sequence iteration to check whether an argument value is valid. Any resolution should also consider the behavior for string subclasses as well as perhaps bytes-like objects. ---------- components: Library (Lib) messages: 180068 nosy: chris.jerdonek priority: normal severity: normal stage: test needed status: open title: argparse: mismatch between choices parsing and usage/error message type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 03:40:38 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 16 Jan 2013 02:40:38 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message In-Reply-To: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> Message-ID: <1358304038.19.0.334285858821.issue16977@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I forgot to mention that argparse uses such cases as examples in its documentation (one of which was replaced in bddbaaf332d7). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 03:49:53 2013 From: report at bugs.python.org (Brian Thorne) Date: Wed, 16 Jan 2013 02:49:53 +0000 Subject: [issue15359] Sockets support for CAN_BCM In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za> Message-ID: <1358304593.29.0.611809329534.issue15359@psf.upfronthosting.co.za> Brian Thorne added the comment: I've added a single BCM test. Any feedback on it would be good and then I'll add more complex ones. Should the documentation be updated in this patch as well? ---------- Added file: http://bugs.python.org/file28747/bcm2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 04:00:28 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 16 Jan 2013 03:00:28 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358305228.93.0.00112891483264.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > argparse does not require that choices be iterable, as it *does* use 'in', as it should. Line 2274: > if action.choices is not None and value not in action.choices: There are cases where it's incorrect for argparse to being using "in" instead of sequence iteration, which again leads me to think that iteration is what was intended. See issue 16977. > So unless the usage message is generated even when not needed (I did not delve that far), non-iterables should work now as long as the user does not request the usage message or make an input mistake. As I said in the second comment of this issue, this doesn't work in any case because the ValueError is raised on add_argument(). So I don't see how the lack of this option can be affecting any users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 04:20:39 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 16 Jan 2013 03:20:39 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" In-Reply-To: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za> Message-ID: <1358306439.48.0.0750918311039.issue16974@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Well, it should't open "" IMHO. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 05:26:13 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Jan 2013 04:26:13 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" In-Reply-To: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za> Message-ID: <1358310373.56.0.337193686935.issue16974@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 05:37:40 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Jan 2013 04:37:40 +0000 Subject: [issue16972] Useless function call in site.py In-Reply-To: <1358263158.12.0.256435330615.issue16972@psf.upfronthosting.co.za> Message-ID: <1358311060.97.0.425293379845.issue16972@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 06:23:22 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 16 Jan 2013 05:23:22 +0000 Subject: [issue5773] Crash on shutdown after os.fdopen(2) in debug builds In-Reply-To: <1239885549.06.0.444041706295.issue5773@psf.upfronthosting.co.za> Message-ID: <1358313802.22.0.49081572981.issue5773@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Is this still valid because this seems fixed in latest Python 3.4 tip. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 06:30:36 2013 From: report at bugs.python.org (Eric Lammerts) Date: Wed, 16 Jan 2013 05:30:36 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" In-Reply-To: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za> Message-ID: <1358314236.32.0.737327213937.issue16974@psf.upfronthosting.co.za> Eric Lammerts added the comment: Does it have to be an identifier in angle brackets? An empty string makes more sense to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 07:39:36 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 16 Jan 2013 06:39:36 +0000 Subject: [issue16978] fix grammar in 'threading' documentation Message-ID: <1358318376.01.0.33023815863.issue16978@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- assignee: docs at python components: Documentation files: grammar.diff keywords: patch nosy: docs at python, tshepang priority: normal severity: normal status: open title: fix grammar in 'threading' documentation versions: Python 2.7 Added file: http://bugs.python.org/file28748/grammar.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 08:00:18 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Jan 2013 07:00:18 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358319618.78.0.708035241109.issue16468@psf.upfronthosting.co.za> Terry J. Reedy added the comment: _Actions_container(object) [1198 in 3.3.0 code] .add_argument() [1281] does not directly check for choices.__iter__ ('__iter__' is not in the file). Nor does it use the 3.x-only alternative isinstance(choices, collections) ('Iterable' is also not in the file). Rather it formats the help string for each argument as added. The complete statement that raises the error is (now at 1321): try: self._get_formatter()._format_args(action, None) except TypeError: raise ValueError("length of metavar tuple does not match nargs") def _get_formatter is part of class ArgumentParser(_AttributeHolder, _ActionsContainer): so 'self' has to be an ArguementParser for the above exception. _format_args calls get_metavar, which is returned by _metavar_formatter. The last contains the first of the three choices iterations that I propose to factor out and revise. So that proposal should eliminate the particular exception from add_argument. The docstring for class Action mirrors the doc: ''' - choices -- A container of values that should be allowed. If not None, after a command-line argument has been converted to the appropriate type, an exception will be raised if it is not a member of this collection. ''' This directly translates to the code line if action.choices is not None and value not in action.choices: Trying to prettily format messages peripheral to the main goal should not take indefinitely or infinitely long, nor make the message worse, nor raise an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 08:10:00 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 16 Jan 2013 07:10:00 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358320200.92.0.49840568829.issue16969@psf.upfronthosting.co.za> Ezio Melotti added the comment: Sorry, the right command is: ./python -m test -v -uall test_urllib2net ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 08:58:27 2013 From: report at bugs.python.org (wim glenn) Date: Wed, 16 Jan 2013 07:58:27 +0000 Subject: [issue16697] argparse kwarg 'choices' documentation In-Reply-To: <1355666035.13.0.877787561314.issue16697@psf.upfronthosting.co.za> Message-ID: <1358323107.93.0.79253207058.issue16697@psf.upfronthosting.co.za> Changes by wim glenn : ---------- nosy: -wim.glenn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 08:59:20 2013 From: report at bugs.python.org (wim glenn) Date: Wed, 16 Jan 2013 07:59:20 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358323160.82.0.264352698566.issue16468@psf.upfronthosting.co.za> Changes by wim glenn : ---------- nosy: -wim.glenn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 11:46:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 10:46:45 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() Message-ID: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: An error handler in unicode_escape_decode() eats at least one byte (or more) after illegal escape sequence. >>> import codecs >>> codecs.unicode_escape_decode(br'\u!@#', 'replace') ('?', 5) >>> codecs.unicode_escape_decode(br'\u!@#$', 'replace') ('?@#$', 6) raw_unicode_escape_decode() works right: >>> codecs.raw_unicode_escape_decode(br'\u!@#', 'replace') ('?!@#', 5) >>> codecs.raw_unicode_escape_decode(br'\u!@#$', 'replace') ('?!@#$', 6) See also issue16975. ---------- assignee: serhiy.storchaka components: Unicode messages: 180077 nosy: ezio.melotti, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Broken error handling in codecs.unicode_escape_decode() type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 11:47:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 10:47:38 +0000 Subject: [issue16975] Broken error handling in codecs.escape_decode() In-Reply-To: <1358286171.54.0.132780688137.issue16975@psf.upfronthosting.co.za> Message-ID: <1358333258.25.0.570726695682.issue16975@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue16979. ---------- assignee: -> serhiy.storchaka stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 12:30:16 2013 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 16 Jan 2013 11:30:16 +0000 Subject: [issue9501] Logging shutdown regressions with weakrefs In-Reply-To: <1280875181.95.0.557870097374.issue9501@psf.upfronthosting.co.za> Message-ID: <1358335816.65.0.13640351603.issue9501@psf.upfronthosting.co.za> Vinay Sajip added the comment: Thanks for hunting these down. With the latest version, neither variant of the teardown script produces any error message on my system, either with 3.3 or 3.4 (default). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:02:10 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Jan 2013 12:02:10 +0000 Subject: [issue16422] Decimal constants should be the same for py & c module versions In-Reply-To: <1352243072.7.0.172202427654.issue16422@psf.upfronthosting.co.za> Message-ID: <3YmRqP5Cb6zQSc@mail.python.org> Roundup Robot added the comment: New changeset 733bb4fd9888 by Stefan Krah in branch '3.3': Issue #16422: Use strings for rounding mode constants for better readability http://hg.python.org/cpython/rev/733bb4fd9888 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:02:40 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 16 Jan 2013 12:02:40 +0000 Subject: [issue9501] Logging shutdown regressions with weakrefs In-Reply-To: <1280875181.95.0.557870097374.issue9501@psf.upfronthosting.co.za> Message-ID: <1358337760.44.0.81597986082.issue9501@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Yes, my last two messages refer to python 3.3.0 only. The changes logged in http://bugs.python.org/issue9501#msg180039 do fix the behavior of both versions of teardown_module.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:04:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 12:04:04 +0000 Subject: [issue16975] Broken error handling in codecs.escape_decode() In-Reply-To: <1358286171.54.0.132780688137.issue16975@psf.upfronthosting.co.za> Message-ID: <1358337844.68.0.472772293637.issue16975@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which fixes error handling in codecs.escape_decode(). >>> codecs.escape_decode(r'[\x1]\x2', 'replace') (b'[?]?', 8) New tests for escape_decode() added. ---------- keywords: +patch nosy: +doerwalter, lemburg stage: needs patch -> patch review Added file: http://bugs.python.org/file28749/escape_decode_error_handling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:04:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 12:04:40 +0000 Subject: [issue16975] Broken error handling in codecs.escape_decode() In-Reply-To: <1358286171.54.0.132780688137.issue16975@psf.upfronthosting.co.za> Message-ID: <1358337880.93.0.610517760836.issue16975@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file28750/escape_decode_error_handling-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:13:09 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Jan 2013 12:13:09 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" In-Reply-To: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za> Message-ID: <1358338389.97.0.292712760089.issue16974@psf.upfronthosting.co.za> R. David Murray added the comment: Ideally there would be an unambiguous way to know if the object came from a file or some other source (say, __file__ is None and another special attribute gives the clue to the actual source), but that's not the way things work now, and for backward compatibility reasons I doubt that we can change it. I'm sure there are programs that depend on at least '', if not some of the other places where a similar thing is done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:15:20 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Jan 2013 12:15:20 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" In-Reply-To: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za> Message-ID: <1358338520.92.0.91608495508.issue16974@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. A backward compatible fix would be to add an attribute that indicates whether or not the __file__ attribute is supposed to be pointing to a real file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:15:43 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Jan 2013 12:15:43 +0000 Subject: [issue16422] Decimal constants should be the same for py & c module versions In-Reply-To: <1352243072.7.0.172202427654.issue16422@psf.upfronthosting.co.za> Message-ID: <1358338542.99.0.431586698262.issue16422@psf.upfronthosting.co.za> Stefan Krah added the comment: In the version I committed the string constants are interned, so anything but legacy strings should be reasonably fast. ---------- assignee: -> skrah components: +Extension Modules resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:29:31 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 16 Jan 2013 12:29:31 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" In-Reply-To: <1358338389.97.0.292712760089.issue16974@psf.upfronthosting.co.za> Message-ID: Ramchandra Apte added the comment: +1 On 16 January 2013 17:43, R. David Murray wrote: > > R. David Murray added the comment: > > Ideally there would be an unambiguous way to know if the object came from > a file or some other source (say, __file__ is None and another special > attribute gives the clue to the actual source), but that's not the way > things work now, and for backward compatibility reasons I doubt that we can > change it. I'm sure there are programs that depend on at least '', > if not some of the other places where a similar thing is done. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 13:29:58 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 16 Jan 2013 12:29:58 +0000 Subject: [issue5773] Crash on shutdown after os.fdopen(2) in debug builds In-Reply-To: <1358313802.22.0.49081572981.issue5773@psf.upfronthosting.co.za> Message-ID: Ramchandra Apte added the comment: Though it may be valid in Python 2.7 still. On 16 January 2013 10:53, Ramchandra Apte wrote: > > Ramchandra Apte added the comment: > > Is this still valid because this seems fixed in latest Python 3.4 tip. > > ---------- > nosy: +ramchandra.apte > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 14:07:33 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 16 Jan 2013 13:07:33 +0000 Subject: [issue10701] Error pickling a dict In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za> Message-ID: <1358341653.75.0.835467239237.issue10701@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > It's interesting. The example behaves unstable on 3.3+ with C implementation of picle, sometimes works, sometimes fails. With Python implementation and on 3.2 it works always. On 2.7 it fails always. That's hash randomization. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 14:42:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 13:42:27 +0000 Subject: [issue16980] SystemError in codecs.unicode_escape_decode() Message-ID: <1358343747.58.0.471745996102.issue16980@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import codecs >>> codecs.unicode_escape_decode(b'\\\x80') Traceback (most recent call last): File "", line 1, in SystemError: invalid maximum character passed to PyUnicode_New ---------- assignee: serhiy.storchaka components: Unicode keywords: 3.3regression messages: 180089 nosy: ezio.melotti, serhiy.storchaka priority: high severity: normal stage: needs patch status: open title: SystemError in codecs.unicode_escape_decode() type: crash versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 15:46:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 14:46:28 +0000 Subject: [issue16980] SystemError in codecs.unicode_escape_decode() In-Reply-To: <1358343747.58.0.471745996102.issue16980@psf.upfronthosting.co.za> Message-ID: <1358347588.61.0.280210327997.issue16980@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a fix. The complete test suite will be in issue16979. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file28751/unicode_escape_decode_escaped_nonascii.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 15:50:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 14:50:05 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() In-Reply-To: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za> Message-ID: <1358347805.83.0.744932901412.issue16979@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch for 3.4. Patches for other versions will be different a lot. ---------- dependencies: +SystemError in codecs.unicode_escape_decode() keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file28752/unicode_escape_decode_error_handling-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 16:07:05 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 16 Jan 2013 15:07:05 +0000 Subject: [issue3585] pkg-config support In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za> Message-ID: <1358348825.81.0.243955728772.issue3585@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 17:18:05 2013 From: report at bugs.python.org (Brian Sutherland) Date: Wed, 16 Jan 2013 16:18:05 +0000 Subject: [issue16981] ImportError hides real error when there too many open files during an import Message-ID: <1358353085.87.0.599698387339.issue16981@psf.upfronthosting.co.za> New submission from Brian Sutherland: When running Python inside PostgreSQL using plpython on OSX 10.7.5 I started coming across very strange and apparently random ImportErrors. For example, failing to find the stat module while importing site: Traceback (most recent call last): File "/Users/jinty/.buildout/eggs/setuptools-0.6c11-py2.7.egg/site.py", line 73, in __boot() File "/Users/jinty/.buildout/eggs/setuptools-0.6c11-py2.7.egg/site.py", line 2, in __boot import sys, imp, os, os.path File "/Users/jinty/src/mp/lib/python2.7/os.py", line 49, in import posixpath as path File "/Users/jinty/src/mp/lib/python2.7/posixpath.py", line 15, in import stat ImportError: No module named stat I debugged this by using PYTHONVERBOSE and modifying import.c with the attached patch. I found that stat.py was not found because fopen() failed with "Too many open files". There were not enough open files because OSX has insanely low limits and PostgreSQL was using a large chunk of that. ulimit -n 4096 resolved the errors. I spent a LOT of time trying to figure that out (see the thread at http://www.postgresql.org/message-id/20130114163014.GA600 at Brians-MacBook-Air.local). The bug I wish to report is that the real error (Too many open files) is hidden by "ImportError: No module named stat". For anyone who does not want to modify import.c and rebuild python, it is almost impossible to figure out what is really happening. ---------- files: patch-Python-import.c.diff keywords: patch messages: 180092 nosy: jinty priority: normal severity: normal status: open title: ImportError hides real error when there too many open files during an import type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file28753/patch-Python-import.c.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 17:49:43 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Jan 2013 16:49:43 +0000 Subject: [issue16981] ImportError hides real error when there too many open files during an import In-Reply-To: <1358353085.87.0.599698387339.issue16981@psf.upfronthosting.co.za> Message-ID: <1358354983.01.0.737871503507.issue16981@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder if importlib replicates this behavior, it may need fixing as well. ---------- nosy: +brett.cannon, eric.snow, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 17:56:21 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Jan 2013 16:56:21 +0000 Subject: [issue16982] _ssl not built --without-threads Message-ID: <1358355380.96.0.943245942304.issue16982@psf.upfronthosting.co.za> New submission from Stefan Krah: _ssl is not built on the Fedora buildbot: http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/3798/steps/test/logs/stdio building '_ssl' extension gcc -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/usr/local/include -I/home/buildbot/buildarea/3.x.krah-fedora/build/Include -I/home/buildbot/buildarea/3.x.krah-fedora/build -c /home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.c -o build/temp.linux-x86_64-3.4-pydebug/home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.o /home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.c: In function ?_servername_callback?: /home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.c:2398:5: warning: implicit declaration of function ?PyGILState_Ensure? [-Wimplicit-function-declaration] /home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.c:2403:9: warning: implicit declaration of function ?PyGILState_Release? [-Wimplicit-function-declaration] gcc -shared build/temp.linux-x86_64-3.4-pydebug/home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-x86_64-3.4-pydebug/_ssl.cpython-34dm.so *** WARNING: renaming "_ssl" since importing it failed: build/lib.linux-x86_64-3.4-pydebug/_ssl.cpython-34dm.so: undefined symbol: PyGILState_Release Python build finished, but the necessary bits to build these modules were not found: _lzma _multiprocessing To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _ssl ---------- components: Extension Modules messages: 180094 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: _ssl not built --without-threads type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:25:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 18:25:58 +0000 Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za> Message-ID: <1358360758.89.0.634429201443.issue1483@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:26:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 18:26:43 +0000 Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za> Message-ID: <1358360803.31.0.127925417398.issue2175@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:27:08 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 18:27:08 +0000 Subject: [issue16981] ImportError hides real error when there too many open files during an import In-Reply-To: <1358353085.87.0.599698387339.issue16981@psf.upfronthosting.co.za> Message-ID: <1358360828.0.0.00835772284453.issue16981@psf.upfronthosting.co.za> Brett Cannon added the comment: A quick trace through importlib._bootstrap through hg.python.org would suggest that the OSError would propagate when accessing source (OSError is swallowed when you try and write bytecode, but that's legitimate semantics). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:35:48 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 16 Jan 2013 18:35:48 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358361348.46.0.663117988468.issue16893@psf.upfronthosting.co.za> Zachary Ware added the comment: Sorry, I wasn't as clear as I meant to be in my last message, I was suddenly rushed and didn't realize I'd left out what I meant to say, which was: Now that Andrew has committed Todd's fix to issue 5066, idle.rst and help.txt are very well-aligned. I believe the transition could be made now with no negative impact on the quality or usefulness of help.txt. Here now is a patch to Doc/Makefile and Doc/make.bat to add an 'idledoc' target. I haven't been able to test the Makefile change yet, but as it's a direct quote of your suggestion (with correction), Georg, I figure it ought to work :). I have tested the make.bat change, though, and it works well for me. ---------- Added file: http://bugs.python.org/file28754/issue16893_makefiles.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:43:18 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 18:43:18 +0000 Subject: [issue13028] python wastes linux users time by checking for dylib on each dynamic library load In-Reply-To: <1316717807.43.0.635056141333.issue13028@psf.upfronthosting.co.za> Message-ID: <1358361798.08.0.892389744159.issue13028@psf.upfronthosting.co.za> Brett Cannon added the comment: Since this has been pending for over two months I'm claiming it's outdated. ---------- resolution: -> out of date status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:45:37 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 18:45:37 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1358361937.46.0.184325226862.issue4347@psf.upfronthosting.co.za> Brett Cannon added the comment: Since this has been sitting here for two months as pending I'm closing as won't fix since mucking with the grammar is such a rarity and getting the build rules right is so complicated it isn't worth changing. ---------- resolution: -> wont fix status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:47:54 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 18:47:54 +0000 Subject: [issue10535] Enable warnings by default in unittest In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za> Message-ID: <1358362074.97.0.483515322229.issue10535@psf.upfronthosting.co.za> Brett Cannon added the comment: Ezio, do you want to create separate issues for any of the TODOs you wanted in http://bugs.python.org/issue10535#msg122779 so we can close this bug? ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:47:59 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 18:47:59 +0000 Subject: [issue10535] Enable warnings by default in unittest In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za> Message-ID: <1358362079.29.0.290102260193.issue10535@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: pending -> open versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:51:04 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 18:51:04 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1358362264.9.0.498097234543.issue11983@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:51:50 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 18:51:50 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <1358362310.38.0.569864823546.issue11729@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:57:27 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Jan 2013 18:57:27 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1358362647.26.0.443347525413.issue11983@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It doesn't actually fix the bug and makes hash inconsistent with cmp. The only constraint is that a == b imply hash(a) == hash(b). But the converse doesn't have to be true, i.e. if it perfectly possible to have hash(a) == hash(b) and a != b (pretty much by definition of a hash function, actually). What Brett's change means is that the hash function isn't as fine-grained as it could be, but I'm not sure it's very important for code objects. Of course, that Brett's commit doesn't fix the original bug (if confirmed) is a more annoying issue :-) ---------- nosy: +brett.cannon, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 19:58:01 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Jan 2013 18:58:01 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1358362681.92.0.563330311018.issue11983@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Woops, I saw Brett unnosied himself, sorry for nosying him by mistake. ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 20:04:21 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 16 Jan 2013 19:04:21 +0000 Subject: [issue12939] Add new io.FileIO using the native Windows API In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za> Message-ID: <1358363061.13.0.0671826062582.issue12939@psf.upfronthosting.co.za> Guido van Rossum added the comment: Just a note of support for Richard -- having I/O use the native APIs directly rather than via emulation or other wrappers is a good idea, because the emulations / wrappers usually add restrictions that are not present in the native API. This is also the reason why we dropped going through stdio -- it did not give enough control over buffering and made integration with (UNIX native) file descriptors complex. Integration with native I/O primitives on Windows seems sense in the light of e.g. PEP 3156. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 20:19:28 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Jan 2013 19:19:28 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <1358363968.02.0.433292404933.issue11729@psf.upfronthosting.co.za> Stefan Krah added the comment: In 3.3 libffi has been updated to 3.0.11. Our clang buildbot does not show this particular warning, but still fails to compile libffi: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.3/builds/320/steps/compile/logs/stdio It would help if you provided a link to the upstream patch. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 20:30:22 2013 From: report at bugs.python.org (Georg Brandl) Date: Wed, 16 Jan 2013 19:30:22 +0000 Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1358364622.11.0.577466581128.issue16893@psf.upfronthosting.co.za> Georg Brandl added the comment: I did test the Makefile change, so this should be good to go. I'll upate PEP 101 once it's in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 20:42:20 2013 From: report at bugs.python.org (Ismail Donmez) Date: Wed, 16 Jan 2013 19:42:20 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <1358365340.86.0.335342747593.issue11729@psf.upfronthosting.co.za> Ismail Donmez added the comment: See http://sourceware.org/ml/libffi-discuss/2011/msg00024.html for the libffi patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 21:17:46 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 20:17:46 +0000 Subject: [issue10535] Enable warnings by default in unittest In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za> Message-ID: <1358367466.03.0.734641583712.issue10535@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 21:20:30 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Jan 2013 20:20:30 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1358367630.4.0.390903375831.issue11983@psf.upfronthosting.co.za> Brett Cannon added the comment: Making as pending for someone to prove my fix is bad for the problem (since it passes an explicit test), else I will close it in the near-ish future. ---------- nosy: +brett.cannon status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 21:48:08 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Jan 2013 20:48:08 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1358369288.72.0.694319338333.issue10590@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 22:07:20 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 16 Jan 2013 21:07:20 +0000 Subject: [issue16978] fix grammar in 'threading' documentation Message-ID: <1358370440.72.0.85153283969.issue16978@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe: Also, sentence starting with "Due to the" does not flow so nice for me... maybe a comma is needed after "CPython"? ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 22:13:44 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Jan 2013 21:13:44 +0000 Subject: [issue16983] header parsing could apply postel's law to encoded words inside quotes Message-ID: <1358370824.34.0.785969797245.issue16983@psf.upfronthosting.co.za> New submission from R. David Murray: It has come to my attention that at least some mail agents apply postel's law to addresses like the following: From: "=?utf-8?Q?not_really_valid?=" Since encountering something that looks like an encoded word but that is not is a very unlikely occurrence, we could go ahead and decode such strings, resulting in "not really valid" a defect would be registered, and some sort of 'strict' policy mode could refuse to do the decode (as well as several other non-compliant patterns, such as encoded words not separated by whitespace). I think the decoding should be the default, though. This applies also to other headers where words or phrases can be quoted, such as in filenames. I have also encountered the quoted-encoded-word-as-filename in the wild. ---------- components: email messages: 180108 nosy: barry, r.david.murray priority: normal severity: normal stage: needs patch status: open title: header parsing could apply postel's law to encoded words inside quotes type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 22:43:44 2013 From: report at bugs.python.org (Craig McQueen) Date: Wed, 16 Jan 2013 21:43:44 +0000 Subject: [issue12758] time.time() returns local time instead of UTC In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za> Message-ID: <1358372624.63.0.994213163229.issue12758@psf.upfronthosting.co.za> Craig McQueen added the comment: Alexander Belopolsky wrote: > No. Seconds since the epoch is neither local nor UTC. It is just > an elapsed number of seconds since an agreed upon time called the > "epoch". This statement just seems wrong. And I have just been confused by the current documentation, hence finding this issue. In what timezone is the "epoch"? It makes a difference. It seems with the current behaviour, the "epoch" is _in the local timezone_. So I reckon the documentation is unclear, because the way I read it, I interpretted it to mean UTC. I think it does need to state "in local time". However, what I'd really prefer is a new function that returns the seconds since the epoch in UTC. ---------- nosy: +cmcqueen1975 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 22:53:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Jan 2013 21:53:00 +0000 Subject: [issue12758] time.time() returns local time instead of UTC In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za> Message-ID: <1358373180.02.0.525948062265.issue12758@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It makes a difference. It seems with the current behaviour, the > "epoch" is _in the local timezone_. No it isn't. Two different machines: $ LANG=C date Wed Jan 16 21:47:03 UTC 2013 $ python -c "import time; print(time.time())" 1358372827.5 $ LANG=C date Wed Jan 16 22:47:21 CET 2013 $ python -c "import time; print(time.time())" 1358372848.2 time.time() *is* timezone-independent. Now to your question: > However, what I'd really prefer is a new function that returns the > seconds since the epoch in UTC. >>> epoch = datetime(1970, 1, 1) >>> (datetime.utcnow() - epoch).total_seconds() 1358372978.448235 >>> time.time() 1358372980.176238 ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 22:53:03 2013 From: report at bugs.python.org (Sureyya Sahin) Date: Wed, 16 Jan 2013 21:53:03 +0000 Subject: [issue16984] idle problem with dark color schemes in kde Message-ID: <1358373183.37.0.59367070531.issue16984@psf.upfronthosting.co.za> New submission from Sureyya Sahin: I am trying to use IDLE in kde linux environment (kubuntu 12.10). I recently switched to a dark color scheme from kde settings and discovered that IDLE is having issues with dark colors. The Completions boxes are not readable, after I switched to the dark color scheme in kde. The completions are white text on white background colored boxes which is making the text unreadable. If I select the options in the completions dialog box, my selection is highlighted and thus I can read the text. ---------- components: IDLE files: snapshot-idle.png messages: 180111 nosy: sahin priority: normal severity: normal status: open title: idle problem with dark color schemes in kde type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file28755/snapshot-idle.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 22:59:06 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Jan 2013 21:59:06 +0000 Subject: [issue16886] Doctests in test_dictcomp depend on dict order In-Reply-To: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za> Message-ID: <3Ymj4927HDzS4g@mail.python.org> Roundup Robot added the comment: New changeset 6d06b223c664 by Frank Wierzbicki in branch '2.7': Closed #16886: test_dictcomps no longer depends on dict order http://hg.python.org/cpython/rev/6d06b223c664 New changeset c7dfc307b88e by Frank Wierzbicki in branch '3.2': Closed #16886: test_dictcomps no longer depends on dict order http://hg.python.org/cpython/rev/c7dfc307b88e New changeset 8ab5bd5f95b3 by Frank Wierzbicki in branch '3.3': #16886: merge with 3.2 http://hg.python.org/cpython/rev/8ab5bd5f95b3 New changeset d0cef6c90efc by Frank Wierzbicki in branch 'default': #16886: merge with 3.3 http://hg.python.org/cpython/rev/d0cef6c90efc ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 23:09:15 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Jan 2013 22:09:15 +0000 Subject: [issue12758] time.time() returns local time instead of UTC In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za> Message-ID: <1358374155.91.0.72311489008.issue12758@psf.upfronthosting.co.za> R. David Murray added the comment: On linux/posix, the epoch is *defined* to be 1970, 1, 1 in UTC. Python just uses whatever the OS defines the epoch to be, as far as I know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 23:27:09 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Jan 2013 22:27:09 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <3YmjhY0MT4zR9W@mail.python.org> Roundup Robot added the comment: New changeset 190a115b7748 by Stefan Krah in branch '3.3': Issue #11729: Backport commit bff052d9 from libffi upstream in order to fix http://hg.python.org/cpython/rev/190a115b7748 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 23:35:47 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Jan 2013 22:35:47 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <1358375747.51.0.675882836791.issue11729@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks for the link. The diff was committed last week to the upstream libffi development tree, so I backported it. ---------- assignee: -> skrah resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 16 23:59:25 2013 From: report at bugs.python.org (Daniel Stutzbach) Date: Wed, 16 Jan 2013 22:59:25 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1358377165.01.0.17393980334.issue2226@psf.upfronthosting.co.za> Changes by Daniel Stutzbach : ---------- assignee: stutzbach -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 00:43:25 2013 From: report at bugs.python.org (Sven Brauch) Date: Wed, 16 Jan 2013 23:43:25 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1358379805.57.0.926338638456.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: I think I got it mostly working now (it was quite simple in fact), but there's one issue which I can't seem to solve. This fails: >>> compile(ast.parse("def fun(): pass"), "", "exec") Traceback (most recent call last): File "", line 1, in TypeError: required field "arg" missing from arg However, this succeeds: >>> compile(ast.parse("def fun(*va, **kwa): pass"), "", "exec") at 0x7fb390323780, file "", line 1> The reason is quite simple: vararg and kwarg are optional in arguments, but they're of type arg, and arg has mandatory attributes ("arg", the name of the argument). Still, when calling ast.parse(), Python creates attributes called vararg, kwarg on the "attributes" object, which are set to None: >>> ast.parse('def fun(): pass').body[0].args.vararg.__repr__() 'None' Thus, when in compile(), the code in Python_ast.c does "if ( _PyObject_HasAttrId(obj, &PyId_vararg) ) { ... }" this check says "yes there's a vararg" altough there really is none, which leads to the above error message. I checked the asdl file, and in fact I think this is a general issue, which was not noticed so far, since only things without mandatory attributes are used in conjunction with the question mark "?" operator there (expr and the integral types identifier, int...). Is this correct? An easy way to solve this problem would be to check whether the attribute is None in Python_ast.c, but I'm everything but sure this is the correct way to fix this. Alternatively, one could not create the attributes on the ast objects when they're not present in the parsed code (i.e. leave the "vararg" attribute nonexistent instead of setting it to none). What should I do about this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 01:38:27 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 17 Jan 2013 00:38:27 +0000 Subject: [issue15436] __sizeof__ is not documented In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za> Message-ID: <1358383107.27.0.513633107818.issue15436@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 04:41:45 2013 From: report at bugs.python.org (Eugene Toder) Date: Thu, 17 Jan 2013 03:41:45 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1358394105.89.0.0920844035093.issue11983@psf.upfronthosting.co.za> Eugene Toder added the comment: My comment will make more sense if you follow the links that I provided. Brett's check-in (http://hg.python.org/cpython-fullhistory/rev/8127a55a57cb) says that it fixes bug #1190011 (http://www.mail-archive.com/python-bugs-list at python.org/msg02440.html). The bug claims that: >> def f(): return ((lambda x=1: x), (lambda x=2: x)) >> f1, f2 = f() >> id(f1.func_code) != id(f2.func_code) The above does not hold true. It should according to test_compile (reported in HEAD as bug #1048870). Certainly comparing co_firstlineno can't fix this, as both lambdas are defined at the same line. There are some more comments by Nick Coghlan on that bug, but I can't find anything clearly stating what the problem is believed to be and what the resolution is. I understand the reason for Brett's fix and why fixing 1190011 literally is not required. The issue was strange debugger/profiler/etc behavior with identical lambdas defined on _different_ lines. Since python tools typically have line resolution (e.g. debugger doesn't know column position of the current statement), merging lambdas defined on the same line is mostly invisible, and does not cause problems. So to clarify my opening comment -- this is mostly a documentation issue. The only documentation for the behavior of code cmp is the comment in Include/code.h, which says: /* The rest doesn't count for hash or comparisons */ Both hash and compare break this in different ways. At a minimum the comment should be fixed. If the current behavior is considered right, this can be it. My other point is that we can have code objects with different co_firstlineno compare equal and still not have them deduplicated by the compiler (thus avoid problems with debugger). This can be done similar to how float -0.0 is equal to 0.0, but still not deduplicated. Separating these concerns can allow both most logical compare behavior and good support for debugging. Re hash legally returning same values for non-equal objects -- sure, only a==b implies hash(a)==hash(b), and not the other way round. But this doesn't mean that we should just return 42 from all hash functions. Not including a field in hash that you include compare needs a very good reason. If there's such a reason in this case, please let me know. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 07:03:23 2013 From: report at bugs.python.org (Brian Thorne) Date: Thu, 17 Jan 2013 06:03:23 +0000 Subject: [issue15359] Sockets support for CAN_BCM In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za> Message-ID: <1358402603.29.0.569220722449.issue15359@psf.upfronthosting.co.za> Brian Thorne added the comment: Thanks for the review Charles-Fran?ois. I can't make your suggested bcm_msg_fmt work - it was deadlocking on my machine! ---------- Added file: http://bugs.python.org/file28756/bcm3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 07:46:34 2013 From: report at bugs.python.org (Roger Serwy) Date: Thu, 17 Jan 2013 06:46:34 +0000 Subject: [issue16984] idle problem with dark color schemes in kde In-Reply-To: <1358373183.37.0.59367070531.issue16984@psf.upfronthosting.co.za> Message-ID: <1358405194.55.0.293724443092.issue16984@psf.upfronthosting.co.za> Roger Serwy added the comment: This is a duplicate of issue7949, but for KDE instead of GTK. I will close this report in favor of the prior one. ---------- nosy: +serwy resolution: -> duplicate status: open -> closed superseder: -> idle does not handle dark gtk color schemes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 07:48:29 2013 From: report at bugs.python.org (Roger Serwy) Date: Thu, 17 Jan 2013 06:48:29 +0000 Subject: [issue7949] IDLE: problems with dark GTK or KDE color schemes In-Reply-To: <1266372113.11.0.0197701157976.issue7949@psf.upfronthosting.co.za> Message-ID: <1358405309.9.0.316674290513.issue7949@psf.upfronthosting.co.za> Roger Serwy added the comment: Updated the issue to reflect information from 16984. A screenshot was provided in that report. ---------- nosy: +sahin, serwy title: idle does not handle dark gtk color schemes -> IDLE: problems with dark GTK or KDE color schemes versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 09:35:48 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 17 Jan 2013 08:35:48 +0000 Subject: [issue14576] IDLE: closes when writing warnings on Windows In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> Message-ID: <1358411748.61.0.85886088441.issue14576@psf.upfronthosting.co.za> Terry J. Reedy added the comment: >I think the next interesting question is to find out why an invalid home directory causes idle to not start up. There's no obvious reason why that should be the case in principle, As Roger showed, IDLE will start up with an invalid home directory. > so I suspect there's some error handling missing somewhere Yes, the uncaught exception raised when attempting to display a non-essential but user-useful messages (this is the third issue I know of about this). There are 5 places in configHandler.py where a warning is directly printed to sys.stderr. There are two similar writes in PyShell.py. The first warning is the problem here, but any of them could be a problem and all should be handled better. Lib/idlelib\PyShell.py: 1357: sys.stderr.write("Error: %s\n" % str(msg)) Lib/idlelib\PyShell.py: 1358: sys.stderr.write(usage_msg) Lib/idlelib\configHandler.py: 209: sys.stderr.write(warn) Lib/idlelib\configHandler.py: 223: sys.stderr.write(warn) Lib/idlelib\configHandler.py: 255: sys.stderr.write(warning) Lib/idlelib\configHandler.py: 367: sys.stderr.write(warning) Lib/idlelib\configHandler.py: 624: sys.stderr.write(warning) Why are warning used instead of message boxes? Perhaps easier, perhaps the latter are not available because the tk loop is not running. Possible solutions: * Discard the message by just catching AttributeError (clikkeb) -- at each place indicated above. This would be better than nothing, but only as a temporary measure, and there is a better temporary measure below. * Rearrange the start up process to make message boxes available, with default configuraton, before the configuration process. * Make a list of messages and display them when it must (on exit, if that is possible with atexit) or in message boxes when it can. * Solve the more general problem of writing to None by making sys.stdout and sys.stderr not be None, #13582. At minimum, even as a temporary measure, use something that just swallows output. Something like import io class DummyOut(io.IOBase): def write(self, s): return len(s) dum = DummyOut() print(dum.write('sixsix')) # 6 ---------- title: IDLE cannot connect to subprocess - New solution -> IDLE: closes when writing warnings on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 12:09:42 2013 From: report at bugs.python.org (Jerome Dubois) Date: Thu, 17 Jan 2013 11:09:42 +0000 Subject: [issue16633] os.environ updates only one copy of env vars under Windows (GetEnvironmentVariable vs. getenv) In-Reply-To: <1354881703.99.0.276690917603.issue16633@psf.upfronthosting.co.za> Message-ID: <1358420982.06.0.279434226511.issue16633@psf.upfronthosting.co.za> Jerome Dubois added the comment: We encountered the same issue when upgrading our application's JRE from 1.5 to 1.6. We use a kind of grid, which has engines written in C, which uses an embedded JAVA JVM, which loads C dll. One of these uses python. Here is what happens: 1. C executable launches an embedded JVM, which loads its required dlls. 2. JVM sets PYTHONHOME environment variable through windows kernel API: SetEnvironmentVariable 3. JVM loads our C dlls to start computations 3. One of the dlls invokes Py_InitializeEx, which must read PYTHONHOME in some way (C runtime getenv?). Python 2.5 here, with MSVCR71.dll loaded. 4. Computations are done with invoked python With JRE 1.5, Python is able to get correct PYTHONHOME, and can do "import os" in our script. With JRE 1.6, this is not the case, as JRE 1.6 loads MSVCR71.dll @ step 1. JRE 1.5 did not. As stated in the previous comments, and from my understanding, in Windows there is the "Process Environment Variables Space" and possibly several "C Runtime Environment Variables Space". The first time a C runtime dll is loaded, it copies the Process Env Var into its own buffer. Our JRE 1.6 loads msvcr71.dll (C runtime), and so copies env var @ step 1. It happens before we set PYTHONHOME with JAVA @ step 2. To correct this, we had to use the Py_SetPythonHome function before calling Py_PyInit to set PYTHONHOME ourselves This way, Python executes our code fine when we use JRE 1.6. But this is because we do not call any getenv functionality within python at the moment, but it could happen in the future... As stated by eudoxos, the safest solution for windows is to use GetEnvironmentVariable (win32 kernel API). Is there any schedule for a fix for this problem? Thanks for you time and answer. Regards. ---------- nosy: +goungy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 12:28:56 2013 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Thu, 17 Jan 2013 11:28:56 +0000 Subject: [issue15448] utimes() functions fail with ENOSYS even when detected by configure In-Reply-To: <1343235007.8.0.870502159269.issue15448@psf.upfronthosting.co.za> Message-ID: <1358422136.95.0.600203108358.issue15448@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: I have a similar problem with python 3.3.0. During installation, I get running install_lib creating /builddir/build/BUILDROOT/python33-python-3.3.0-3.el6.i386/opt/rh/python33/root/usr/lib/python3.3/lib-dynload copying build/lib.linux-i686-3.3-pydebug/_codecs_cn.cpython-33dm.so -> /builddir/build/BUILDROOT/python33-python-3.3.0-3.el6.i386/opt/rh/python33/root/usr/lib/python3.3/lib-dynload [?1034herror: Function not implemented I tracked it down to distutils calling os.utime. When I comment the two lines [1] that use utime, everything works fine (well, except all the tests using utime fail, too). I'm running RHEL 6.4. Any chance to fix this? Richard's patch doesn't work for me. Thanks. [1] http://hg.python.org/cpython/file/f3e348ab08c6/Lib/distutils/file_util.py#l149 ---------- nosy: +bkabrda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 13:13:33 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 12:13:33 +0000 Subject: [issue8714] Delayed signals in the REPL on OpenBSD (possibly libpthread related) In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za> Message-ID: <1358424813.26.0.601757680046.issue8714@psf.upfronthosting.co.za> Stefan Krah added the comment: Fixed in OpenBSD 5.2. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 13:15:31 2013 From: report at bugs.python.org (Andrew Clegg) Date: Thu, 17 Jan 2013 12:15:31 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1358424930.99.0.455337936962.issue15443@psf.upfronthosting.co.za> Andrew Clegg added the comment: I would like to add a real-world use case I have for nanosecond-precision support. I deal with data loggers that are controlled by GPS clocks, and I am writing some processing software in Python that requires the input of high-precision timestamps for calculating clock drifts and offsets. The addition of nanosecond-precision support in datetime would allow me to use this rather than a homebrew solution. ---------- nosy: +andrewclegg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 13:31:10 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 12:31:10 +0000 Subject: [issue8712] Skip libpthread related test failures on OpenBSD In-Reply-To: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za> Message-ID: <1358425870.39.0.620408979182.issue8712@psf.upfronthosting.co.za> Stefan Krah added the comment: All threading issues are fixed in OpenBSD 5.2. ---------- resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 13:40:00 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 12:40:00 +0000 Subject: [issue3876] multiprocessing does not compile on systems which do not define sem_timedwait In-Reply-To: <1221541852.59.0.453473189868.issue3876@psf.upfronthosting.co.za> Message-ID: <1358426400.48.0.120344546614.issue3876@psf.upfronthosting.co.za> Stefan Krah added the comment: On OpenBSD 5.2 this is fixed. The AIX buildbot looks okay and I doubt that anyone will commit something for Solaris 9. ---------- nosy: +skrah resolution: -> out of date stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 13:49:36 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 12:49:36 +0000 Subject: [issue16952] test_kqueue failure on NetBSD/OpenBSD In-Reply-To: <1358087097.62.0.636962955587.issue16952@psf.upfronthosting.co.za> Message-ID: <1358426976.08.0.369763250871.issue16952@psf.upfronthosting.co.za> Stefan Krah added the comment: Could we merge this with #6419? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 14:19:39 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 13:19:39 +0000 Subject: [issue12812] libffi does not build with clang on amd64 In-Reply-To: <1313994656.23.0.148190380431.issue12812@psf.upfronthosting.co.za> Message-ID: <1358428779.63.0.719430162721.issue12812@psf.upfronthosting.co.za> Stefan Krah added the comment: This is a duplicate of #11729, which is fixed. ---------- nosy: +skrah resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> libffi assembler relocation check is not robust, fails with clang type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 14:23:46 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 13:23:46 +0000 Subject: [issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. In-Reply-To: <1345584581.07.0.102502771699.issue15757@psf.upfronthosting.co.za> Message-ID: <1358429026.8.0.5488345751.issue15757@psf.upfronthosting.co.za> Stefan Krah added the comment: Trent, do you want to keep this open? I think sys.mk is behaving exactly as intended. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 14:26:35 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 13:26:35 +0000 Subject: [issue15362] pyport.h includes antiquated UTF handling for FreeBSD In-Reply-To: <1342387162.35.0.975176855172.issue15362@psf.upfronthosting.co.za> Message-ID: <1358429195.36.0.806510736582.issue15362@psf.upfronthosting.co.za> Stefan Krah added the comment: Does this apply to Python 3.3 as well? I don't think we're going to fix this in 2.7. ---------- nosy: +skrah status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 15:02:07 2013 From: report at bugs.python.org (Sebastian Kraft) Date: Thu, 17 Jan 2013 14:02:07 +0000 Subject: [issue16525] wave file module does not support 32bit float format In-Reply-To: <1353528827.37.0.543069044809.issue16525@psf.upfronthosting.co.za> Message-ID: <1358431327.62.0.314203237144.issue16525@psf.upfronthosting.co.za> Sebastian Kraft added the comment: Any news or feedback regarding my patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 15:10:08 2013 From: report at bugs.python.org (gac) Date: Thu, 17 Jan 2013 14:10:08 +0000 Subject: [issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays In-Reply-To: <1357821708.32.0.469925509105.issue16914@psf.upfronthosting.co.za> Message-ID: <1358431808.41.0.458731654589.issue16914@psf.upfronthosting.co.za> gac added the comment: Thanks, I'll look into your suggestions and try to submit a further improved patch :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 15:32:05 2013 From: report at bugs.python.org (Ry Erickson) Date: Thu, 17 Jan 2013 14:32:05 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358433125.49.0.218460754673.issue16969@psf.upfronthosting.co.za> Ry Erickson added the comment: ./python -m test -v -uall test_urllib2net == CPython 3.3.0 (default, Jan 14 2013, 20:45:36) [GCC 4.6.1] == Linux-3.0.0-29-generic-i686-with-debian-wheezy-sid little-endian == /home/ry/Desktop/Python-3.3.0/build/test_python_2264 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_urllib2net test_sni (test.test_urllib2net.HTTPSTests) ... skipped 'requires SSL support' test_custom_headers (test.test_urllib2net.OtherNetworkTests) ... ok test_file (test.test_urllib2net.OtherNetworkTests) ... ok test_ftp (test.test_urllib2net.OtherNetworkTests) ... ok test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... ok test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ... FAIL test_close (test.test_urllib2net.CloseSocketTest) ... ok test_ftp_basic (test.test_urllib2net.TimeoutTest) ... ok test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... ok test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_basic (test.test_urllib2net.TimeoutTest) ... ok test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_timeout (test.test_urllib2net.TimeoutTest) ... ok ====================================================================== FAIL: test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ry/Desktop/Python-3.3.0/Lib/test/test_urllib2net.py", line 165, in test_urlwithfrag "http://docs.python.org/glossary.html#glossary") AssertionError: 'http://docs.python.org/2/glossary.html' != 'http://docs.python.org/glossary.html#glossary' - http://docs.python.org/2/glossary.html ? -- + http://docs.python.org/glossary.html#glossary ? +++++++++ ---------------------------------------------------------------------- Ran 15 tests in 26.079s FAILED (failures=1, skipped=1) test test_urllib2net failed 1 test failed: test_urllib2net ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 15:36:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Jan 2013 14:36:01 +0000 Subject: [issue14110] FreeBSD: test_os fails if user is in the wheel group In-Reply-To: <1330111475.14.0.550886598364.issue14110@psf.upfronthosting.co.za> Message-ID: <3Yn7BS4wT0zS97@mail.python.org> Roundup Robot added the comment: New changeset a94752d75c74 by Stefan Krah in branch '3.3': Issue #14110: Fix test failures on FreeBSD if the user is in the wheel group. http://hg.python.org/cpython/rev/a94752d75c74 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 15:40:36 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 14:40:36 +0000 Subject: [issue14110] FreeBSD: test_os fails if user is in the wheel group In-Reply-To: <1330111475.14.0.550886598364.issue14110@psf.upfronthosting.co.za> Message-ID: <1358433636.6.0.000307719944914.issue14110@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: -> skrah resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 15:55:06 2013 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 17 Jan 2013 14:55:06 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message In-Reply-To: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> Message-ID: <1358434506.39.0.762354367644.issue16977@psf.upfronthosting.co.za> Eric V. Smith added the comment: Isn't this really just an inappropriate use of a string instead of a list? If indeed this is in the documentation, it should be changed. I still don't like: >>> p.add_argument('a', choices=list('abc')) but at least it would work. This call to list() could be done internally, but I think passing in a string is a bad practice and argparse should not contain internal workarounds to cater to this usage. If you're proposing that argparse should use sequence iteration instead of the "in" operator, I disagree with that solution. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 16:04:07 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 15:04:07 +0000 Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za> Message-ID: <1358435047.47.0.322770705048.issue12210@psf.upfronthosting.co.za> Stefan Krah added the comment: Since this occurs only on 2.7 and *very* rarely, let's close it. ---------- resolution: out of date -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 16:10:39 2013 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 17 Jan 2013 15:10:39 +0000 Subject: [issue16985] Docs reference a concrete UTC tzinfo, but none exists Message-ID: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za> New submission from Jason R. Coombs: The Python 2.7 docs for datetime state, "The standard library has no tzinfo instances except for UTC," but if I read issue5094 correctly, Python 2.7 does not even have a UTC tzinfo instance, and never will. Is there any reason I shouldn't correct the docs to remove 'except for UTC'? ---------- assignee: docs at python components: Documentation messages: 180138 nosy: docs at python, jason.coombs priority: normal severity: normal status: open title: Docs reference a concrete UTC tzinfo, but none exists versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:08:20 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Jan 2013 16:08:20 +0000 Subject: [issue16982] _ssl not built --without-threads In-Reply-To: <1358355380.96.0.943245942304.issue16982@psf.upfronthosting.co.za> Message-ID: <3Yn9F015RkzMmV@mail.python.org> Roundup Robot added the comment: New changeset 8630fa732cf6 by Stefan Krah in branch 'default': Issue #16982: Fix --without-threads build failure. http://hg.python.org/cpython/rev/8630fa732cf6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:08:51 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 16:08:51 +0000 Subject: [issue16982] _ssl not built --without-threads In-Reply-To: <1358355380.96.0.943245942304.issue16982@psf.upfronthosting.co.za> Message-ID: <1358438931.55.0.725240385782.issue16982@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: -> skrah resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:27:57 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 17 Jan 2013 16:27:57 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1358440077.16.0.195086258971.issue15443@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:45:32 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 17 Jan 2013 16:45:32 +0000 Subject: [issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1? In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za> Message-ID: <1358441132.77.0.939212553366.issue7353@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Bump... is this still valid? ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:50:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Jan 2013 16:50:23 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1358441423.06.0.600577076491.issue10590@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which fixes this issue and a couple of related issues:?issue1483, issue2174, issue2175, issue10590. ---------- keywords: +patch nosy: +BreamoreBoy, akuchling, eli.bendersky, georg.brandl, loewis, terry.reedy, tshepang, ygale stage: needs patch -> patch review Added file: http://bugs.python.org/file28757/sax_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:53:15 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 17 Jan 2013 16:53:15 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358441595.7.0.155090068778.issue16969@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Hmmm. Because of the recent doc changes, that link is redirecting to "http://docs.python.org/2...". Even if we change that, for some reason, the fragment is disappearing when redirecting. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:53:36 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 17 Jan 2013 16:53:36 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358441616.86.0.158519934891.issue16969@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:54:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Jan 2013 16:54:19 +0000 Subject: [issue16986] ElementTree incorrectly parses strings with declared encoding not UTF-8 Message-ID: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import xml.etree.ElementTree >>> data = '\n$\xa3\u20ac\U0001017b' >>> xml.etree.ElementTree.tostring(xml.etree.ElementTree.fromstring(data), 'unicode') '$???\x82??\x90\x85?' ---------- components: XML messages: 180143 nosy: eli.bendersky, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: ElementTree incorrectly parses strings with declared encoding not UTF-8 type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 17:54:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Jan 2013 16:54:46 +0000 Subject: [issue16986] ElementTree incorrectly parses strings with declared encoding not UTF-8 In-Reply-To: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za> Message-ID: <1358441686.59.0.84459418442.issue16986@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch for issue10590 fixes this for Python implementation of ElementTree, but not for C implementation. ---------- dependencies: +Parameter type error for xml.sax.parseString(string, ...) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 18:24:26 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 17 Jan 2013 17:24:26 +0000 Subject: [issue16952] test_kqueue failure on NetBSD/OpenBSD In-Reply-To: <1358087097.62.0.636962955587.issue16952@psf.upfronthosting.co.za> Message-ID: <1358443466.24.0.214312616673.issue16952@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> duplicate stage: patch review -> committed/rejected status: open -> closed superseder: -> Broken test_kqueue.py on OpenBSD _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 18:39:32 2013 From: report at bugs.python.org (Armin Rigo) Date: Thu, 17 Jan 2013 17:39:32 +0000 Subject: [issue16273] f.tell() returning negative number on Windows build In-Reply-To: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za> Message-ID: <1358444372.26.0.671906847512.issue16273@psf.upfronthosting.co.za> Armin Rigo added the comment: FWIW, on Windows only, "open('foo', 'a').tell()" always returns 0, which I think is broken too. It usually works anyway, because it updates the position before the first .write(). But it does not work in case the writing occurs in another process, like described here: http://stackoverflow.com/questions/13821708/ (Tested only on Python 2.6.2, but according to the link above, Python 2.7.3 has the same problem.) ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 19:32:48 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 18:32:48 +0000 Subject: [issue16273] f.tell() returning negative number on Windows build In-Reply-To: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za> Message-ID: <1358447568.85.0.20901776817.issue16273@psf.upfronthosting.co.za> Stefan Krah added the comment: What is in sample.txt? I cannot reproduce this with a source build (Windows 7, 64-bit pgo build): Python 2.7.3+ (default, Jan 17 2013, 20:26:24) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> f = open('sample.txt') >>> f.read(3) 'abc' >>> f.read(3) 'def' >>> f.tell() 6L ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 20:05:04 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Jan 2013 19:05:04 +0000 Subject: [issue16273] f.tell() returning negative number on Windows build In-Reply-To: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za> Message-ID: <1358449504.68.0.622471725098.issue16273@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I am afraid I cannot reproduce with the 2.7.3 64-bit installer either: C:\>python27\python.exe Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> f = open("sample.txt") >>> f.read(3) 'xxx' >>> f.read(3) 'xxx' >>> f.tell() 6L ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 20:24:46 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 19:24:46 +0000 Subject: [issue16987] HP-UX: SHLIB_EXT is not set Message-ID: <1358450686.82.0.952706053804.issue16987@psf.upfronthosting.co.za> New submission from Stefan Krah: Since 5e33b27c71a8 SHLIB_EXT is not set in configure.ac, since the block in which $SO is defined has been moved below this line: AC_DEFINE_UNQUOTED(SHLIB_EXT, "$SO", [Define this to be extension of shared libraries (including the dot!).]) This prevents extension module loading on HP-UX. ---------- components: Extension Modules messages: 180148 nosy: skrah priority: normal severity: normal status: open title: HP-UX: SHLIB_EXT is not set type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 20:45:08 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Jan 2013 19:45:08 +0000 Subject: [issue16987] HP-UX: SHLIB_EXT is not set In-Reply-To: <1358450686.82.0.952706053804.issue16987@psf.upfronthosting.co.za> Message-ID: <3YnG372pfYzSDm@mail.python.org> Roundup Robot added the comment: New changeset 937e9df47ccd by Stefan Krah in branch '3.3': Issue #16987: Fix definition of SHLIB_EXT. http://hg.python.org/cpython/rev/937e9df47ccd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 20:53:54 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 17 Jan 2013 19:53:54 +0000 Subject: [issue15448] utimes() functions fail with ENOSYS even when detected by configure In-Reply-To: <1343235007.8.0.870502159269.issue15448@psf.upfronthosting.co.za> Message-ID: <1358452434.52.0.542953502509.issue15448@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: There are actually two distinct issues. For the first one, the problem is really a distribution issue: the libc is more recent than the kernel, and exports *utimes() whereas the kernel doesn't implement those syscalls, which results in ENOSYS. I don't like the idea of adding explicit check for this, because any syscall can fail with ENOSYS (we've had recently pipe2(), accept4(), etc). It's really a distribution issue. For the second one, it seems that RHEL6.4 doesn't have utime() anymore, which I find really strange (although POSIX.1-2008 marks utime() as obsolete). Could you provide the output of: $ strace ./python -c "import os; os.utime('.')" ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 21:22:59 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 20:22:59 +0000 Subject: [issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1? In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za> Message-ID: <1358454179.56.0.00883104304568.issue7353@psf.upfronthosting.co.za> Stefan Krah added the comment: I tend to agree with the argument that the removal of intobject.h was a good thing, since it avoids subtle errors. Probably no one wants to reinstate intobject.h at this point, so unless there are objections, I'll update the docs in a couple of days. ---------- keywords: +patch nosy: +skrah Added file: http://bugs.python.org/file28758/issue7353.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 21:41:15 2013 From: report at bugs.python.org (Robert Leenders) Date: Thu, 17 Jan 2013 20:41:15 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1358455275.77.0.668069982501.issue16970@psf.upfronthosting.co.za> Robert Leenders added the comment: Attached is a patch which solves these problems and adds test cases of Chris Jerdonek. When nargs is negative the same ValueError is raised as when nargs is zero. Also when nargs is any other invalid value a ValueError("invalid value for nargs") is raised. I have one question and that is about the value PARSER="A..." for nargs, it's a valid option and there are test cases with nargs="A...", however it is not listed in the documentation: http://docs.python.org/dev/library/argparse.html#nargs ---------- keywords: +patch nosy: +ReDAeR Added file: http://bugs.python.org/file28759/argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 21:48:46 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 17 Jan 2013 20:48:46 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message In-Reply-To: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> Message-ID: <1358455726.92.0.520485227484.issue16977@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This wasn't just in the documentation. It was the *first* example of how to use the choices argument out of the two examples in that section (from the time Python first adopted argparse and before): ---- 16.4.3.7. choices Some command-line arguments should be selected from a restricted set of values. These can be handled by passing a container object as the choices keyword argument to add_argument(). When the command line is parsed, argument values will be checked, and an error message will be displayed if the argument was not one of the acceptable values: >>> parser = argparse.ArgumentParser(prog='PROG') >>> parser.add_argument('foo', choices='abc') >>> parser.parse_args('c'.split()) Namespace(foo='c') >>> parser.parse_args('X'.split()) usage: PROG [-h] {a,b,c} PROG: error: argument foo: invalid choice: 'X' (choose from 'a', 'b', 'c') (from http://hg.python.org/cpython/file/c0ddae67f4df/Doc/library/argparse.rst#l1021 ) ---- So I think it's a bit late to say it's an inappropriate usage or bad practice. To preserve backwards compatibility, I think we should use sequence iteration for strings, or equivalently apply "in" to iter(choices), set(choices), etc. when choices is a string. I don't think, however, that we should alter the choices attribute because that could break things for people: >>> p = argparse.ArgumentParser() >>> a = p.add_argument("letter", choices='abcd') >>> a.choices 'abcd' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 22:11:04 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 17 Jan 2013 21:11:04 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1358457064.95.0.387607320369.issue16970@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for the patch. I will take a look. And good observation re: PARSER. Can you open a separate documentation issue for that where it can be discussed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 22:30:15 2013 From: report at bugs.python.org (Robert Leenders) Date: Thu, 17 Jan 2013 21:30:15 +0000 Subject: [issue16988] argparse: PARSER option for nargs not documented Message-ID: <1358458215.07.0.403888123098.issue16988@psf.upfronthosting.co.za> New submission from Robert Leenders: There is a value for nargs: PARSER="A..." which is not documented at http://docs.python.org/3.4/library/argparse.html#nargs. The docstring for the action class in argparse.py also does not list PARSER as a valid value for nargs. In argparse.py on line 2199-2201 it says: # Allow one argument followed by any number of options or arguments elif nargs == PARSER: nargs_pattern = '(-*A[-AO]*)' This is the only hint that I could find on what it is about. ---------- assignee: docs at python components: Documentation messages: 180155 nosy: ReDAeR, bethard, docs at python priority: normal severity: normal status: open title: argparse: PARSER option for nargs not documented type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 22:33:08 2013 From: report at bugs.python.org (Robert Leenders) Date: Thu, 17 Jan 2013 21:33:08 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1358458388.44.0.474878240974.issue16970@psf.upfronthosting.co.za> Robert Leenders added the comment: The new issue about PARSER can be found here: http://bugs.python.org/issue16988 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 22:38:10 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 17 Jan 2013 21:38:10 +0000 Subject: [issue16988] argparse: PARSER option for nargs not documented In-Reply-To: <1358458215.07.0.403888123098.issue16988@psf.upfronthosting.co.za> Message-ID: <1358458690.47.0.20949995823.issue16988@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 23:14:24 2013 From: report at bugs.python.org (Joseph Perry) Date: Thu, 17 Jan 2013 22:14:24 +0000 Subject: [issue6135] subprocess seems to use local encoding and give no choice In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za> Message-ID: <1358460864.25.0.280510380883.issue6135@psf.upfronthosting.co.za> Joseph Perry added the comment: I've found a workaround by specifying the enviroment variable: my_env = os.environ my_env['PYTHONIOENCODING'] = 'utf-8' p = subprocess.Popen(shlex.split(command), stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE, env=my_env) I've attached an example script for testing. It calls itself recursively 10 times. Pleased note the 'fix' variable. ---------- nosy: +berwin22 Added file: http://bugs.python.org/file28760/subProcessTest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 23:37:26 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Jan 2013 22:37:26 +0000 Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x" In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za> Message-ID: <3YnKsy2NYDzRLf@mail.python.org> Roundup Robot added the comment: New changeset cd54b48946ca by Stefan Krah in branch '3.3': Issue #11870: Skip test_3_join_in_forked_from_thread() on HP-UX. http://hg.python.org/cpython/rev/cd54b48946ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 23:38:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 17 Jan 2013 22:38:43 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1358462323.68.0.505991078006.issue11983@psf.upfronthosting.co.za> Brett Cannon added the comment: I have no issue with the current behaviour, so it sounds like the source comment just needs updating. Care to suggest some wording, Eugene? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 17 23:44:59 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 17 Jan 2013 22:44:59 +0000 Subject: [issue16987] HP-UX: SHLIB_EXT is not set In-Reply-To: <1358450686.82.0.952706053804.issue16987@psf.upfronthosting.co.za> Message-ID: <1358462699.53.0.336458604338.issue16987@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: -> skrah keywords: +3.3regression resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 00:29:30 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 17 Jan 2013 23:29:30 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358465370.7.0.765869200083.issue16957@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I've added a patch with my suggested fix, as well as a test for this. test_shutil all passes on Linux - I haven't run the tests on Windows. ---------- keywords: +patch Added file: http://bugs.python.org/file28761/shutil_which_cwd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 00:41:55 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 17 Jan 2013 23:41:55 +0000 Subject: [issue16989] allow distutils debug mode to be enabled more easily Message-ID: <1358466115.01.0.322407717365.issue16989@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to allow distutils's debug mode [1] to be enabled more easily (e.g. programmatically). Currently, for example, distutils.core does the following: from distutils.debug import DEBUG (from http://hg.python.org/cpython/file/cb297930d2cf/Lib/distutils/core.py#l12) which means that it's not sufficient to set the DEBUG attribute on the distutils.debug module. Instead, to enable debug mode programmatically you have to do something like the following prior to importing from distutils: import os os.environ['DISTUTILS_DEBUG'] = "1" # "" for False or "1" for True. This issue can be fixed simply by changing the affected import statements from importing the value to importing just the module (and subsequently accessing the value via the module). [1] http://docs.python.org/dev/distutils/setupscript.html#debugging-the-setup-script ---------- assignee: eric.araujo components: Distutils keywords: easy messages: 180161 nosy: chris.jerdonek, eric.araujo, tarek priority: normal severity: normal status: open title: allow distutils debug mode to be enabled more easily type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 00:49:03 2013 From: report at bugs.python.org (Jared Grubb) Date: Thu, 17 Jan 2013 23:49:03 +0000 Subject: [issue16990] re: match of nongreedy regex not grouping right Message-ID: <1358466543.42.0.996552051054.issue16990@psf.upfronthosting.co.za> New submission from Jared Grubb: re.match matches, but the capture groups are empty. That's not possible. Python 2.7.2 (default, Oct 11 2012, 20:14:37) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.match('.*', 'stuff').group() # greedy matches and captures; cool. 'stuff' >>> re.match('.*?', 'stuff').group() # nongreedy matches (cool) but doesnt capture (huh?) '' ---------- components: Library (Lib) messages: 180162 nosy: jaredgrubb priority: normal severity: normal status: open title: re: match of nongreedy regex not grouping right versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 00:50:39 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 17 Jan 2013 23:50:39 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1358466639.23.0.150589380872.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think "None" should be treated as meaning not present for an optional argument. By the way, it would be good if we could get you to sign a contributor agreement. http://www.python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 01:12:21 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 18 Jan 2013 00:12:21 +0000 Subject: [issue16990] re: match of nongreedy regex not grouping right In-Reply-To: <1358466543.42.0.996552051054.issue16990@psf.upfronthosting.co.za> Message-ID: <1358467941.55.0.795519724558.issue16990@psf.upfronthosting.co.za> R. David Murray added the comment: Wouldn't a non-greedy .* match the null string? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 01:14:07 2013 From: report at bugs.python.org (Jared Grubb) Date: Fri, 18 Jan 2013 00:14:07 +0000 Subject: [issue16990] re: match of nongreedy regex not grouping right In-Reply-To: <1358466543.42.0.996552051054.issue16990@psf.upfronthosting.co.za> Message-ID: <1358468047.03.0.353323399708.issue16990@psf.upfronthosting.co.za> Jared Grubb added the comment: Yes: >>> re.match('.*', '') <_sre.SRE_Match object at 0x107c6d308> >>> re.match('.*?', '') <_sre.SRE_Match object at 0x107c6d370> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 01:16:53 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 18 Jan 2013 00:16:53 +0000 Subject: [issue16990] re: match of nongreedy regex not grouping right In-Reply-To: <1358466543.42.0.996552051054.issue16990@psf.upfronthosting.co.za> Message-ID: <1358468213.76.0.112301389876.issue16990@psf.upfronthosting.co.za> R. David Murray added the comment: So, group() is returning the correct value, then. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 01:21:39 2013 From: report at bugs.python.org (Jared Grubb) Date: Fri, 18 Jan 2013 00:21:39 +0000 Subject: [issue16990] re: match of nongreedy regex not grouping right In-Reply-To: <1358466543.42.0.996552051054.issue16990@psf.upfronthosting.co.za> Message-ID: <1358468499.45.0.285236576808.issue16990@psf.upfronthosting.co.za> Jared Grubb added the comment: You're right. My mistake. I thought "match" meant "the full string must match", but in Python it means "the beginning must match". Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 01:51:05 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 18 Jan 2013 00:51:05 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358470265.02.0.606199042687.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I have a new suggestion that I hope will satisfy Terry. After looking at the code more, I noticed that add_argument() does currently work for non-iterable choices provided that metavar is passed. This was also noted in the report for the duplicate issue 16697. On reflection, this makes sense because that's what metavar is for -- providing a replacement string for the usual formatting in the help text. The only thing that doesn't work in this case is error message formatting. With that, I'd like to propose the following: (1) Change the add_argument() error raised for non-iterable choices from: ValueError("length of metavar tuple does not match nargs") to something like: ValueError("metavar must be provided for non-iterable choices") This provides the help string representation for non-iterable choices (in the spirit of "Explicit is better than implicit"). (2) Make the error text the following for non-iterable choices (the error message currently breaks for non-iterable choices): PROG: error: argument FOO: invalid choice: 'xxx' compared with (for iterable choices)-- PROG: error: argument FOO: invalid choice: 'xxx' (choose from ...) I think this is preferable to inserting the str() or repr() (especially for maintenance releases) because str() and repr() may not be meant for displaying to the end-users of a script. The instructions/description of such choices is already in the add_argument() "help" string. We could consider appending that to provide substantive guidance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 02:04:43 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 18 Jan 2013 01:04:43 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358471083.63.0.156029794836.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Actually, let me relax (1). We can just use what the argparse code calls the "default_metavar" in that case (which it constructs from the argument name). The important thing for me is not displaying the str/repr when it might not be intended. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 05:08:31 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 18 Jan 2013 04:08:31 +0000 Subject: [issue16991] Add OrderedDict written in C Message-ID: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> New submission from Eric Snow: Here's an initial stab at writing OrderedDict in C. Though, the implementation is not heavily optimized and isn't super subclass-friendly, my hope is that it's relatively close to the final version. I'm getting this up now to get some eyes on it. The spot in the builtins is mostly for convenience, but I expect it will need to be exposed somewhere (perhaps _collections?). My experience with the C-API is relatively limited and my C-fu is not at a professional level. However, I'm pretty sure that I have most everything correct. The ultimate goal for this type is to use it for **kwargs. Note: this first patch has some reference leaks that I'm tracking down. ---------- assignee: eric.snow components: Interpreter Core files: odict.diff keywords: patch messages: 180170 nosy: eric.snow, rhettinger priority: normal severity: normal stage: patch review status: open title: Add OrderedDict written in C type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28762/odict.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 05:28:59 2013 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 18 Jan 2013 04:28:59 +0000 Subject: [issue16992] signal.set_wakeup_fd(400) crashes on Windows Message-ID: <1358483339.76.0.550693501788.issue16992@psf.upfronthosting.co.za> New submission from Guido van Rossum: On Windows I get an immediate crash with the following code: import signal signal.set_wakeup_fd(400) I think there's a range check missing somewhere. (I found this because I was passing a socket's fileno() -- my bug, but shouldn't crash.) ---------- messages: 180171 nosy: gvanrossum priority: normal severity: normal status: open title: signal.set_wakeup_fd(400) crashes on Windows versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 05:55:10 2013 From: report at bugs.python.org (Ry Erickson) Date: Fri, 18 Jan 2013 04:55:10 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358484910.64.0.327552907848.issue16969@psf.upfronthosting.co.za> Ry Erickson added the comment: I don't think compile is a valid command in mint. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 06:12:58 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Jan 2013 05:12:58 +0000 Subject: [issue16992] signal.set_wakeup_fd(400) crashes on Windows In-Reply-To: <1358483339.76.0.550693501788.issue16992@psf.upfronthosting.co.za> Message-ID: <3YnVfK3vBHzRMJ@mail.python.org> Roundup Robot added the comment: New changeset 2adc83b4738f by Benjamin Peterson in branch '3.3': check windows fd validity (closes #16992) http://hg.python.org/cpython/rev/2adc83b4738f New changeset 1a1989021451 by Benjamin Peterson in branch '2.7': check windows fd validity (closes #16992) http://hg.python.org/cpython/rev/1a1989021451 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 06:13:03 2013 From: report at bugs.python.org (py.user) Date: Fri, 18 Jan 2013 05:13:03 +0000 Subject: [issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64 In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net> Message-ID: <1358485983.28.0.387115052635.issue13057@psf.upfronthosting.co.za> py.user added the comment: found a redundant code (stdlib.h already defines the NULL macro) commit e33747a4b1a45acdd696a4e07bbd40ea7fb37366 Author: Stefan Krah Date: Thu Nov 22 22:49:11 2012 +0100 Issue #13057: Include stdio.h when NULL is used in configure.ac. --HG-- branch : 3.3 diff --git a/configure b/configure index 4a861ed..534c8df 100755 --- a/configure +++ b/configure ... @@ -14833,6 +14834,7 @@ else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ +#include #include int main() { size_t len = -1; ---------- nosy: +py.user _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 06:20:15 2013 From: report at bugs.python.org (Trent Nelson) Date: Fri, 18 Jan 2013 05:20:15 +0000 Subject: [issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64 In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net> Message-ID: <1358486415.79.0.4870684187.issue13057@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 06:22:35 2013 From: report at bugs.python.org (py.user) Date: Fri, 18 Jan 2013 05:22:35 +0000 Subject: [issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64 In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net> Message-ID: <1358486555.18.0.123554619383.issue13057@psf.upfronthosting.co.za> py.user added the comment: the hunk is from commit commit b2edc2629f5e0f11280ba9846d1a86346f4a7287 Author: Stefan Krah Date: Thu Nov 22 23:47:32 2012 +0100 Fix more usages of NULL without including stdio.h. --HG-- branch : 3.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 06:22:41 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 18 Jan 2013 05:22:41 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1358486561.85.0.587569838164.issue16991@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Nit: This really not be exposed through _collections rather than hacked into builtins. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 08:37:50 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 07:37:50 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358494670.94.0.287843026796.issue16957@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it should be if os.path.dirname(cmd) and _access_check(cmd, mode): ---------- nosy: +hynek, serhiy.storchaka, tarek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 08:42:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 07:42:34 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358494954.18.0.500649239248.issue16957@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, it should be if os.path.dirname(cmd): if _access_check(cmd, mode): return cmd return None ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 08:59:23 2013 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Fri, 18 Jan 2013 07:59:23 +0000 Subject: [issue15448] utimes() functions fail with ENOSYS even when detected by configure In-Reply-To: <1343235007.8.0.870502159269.issue15448@psf.upfronthosting.co.za> Message-ID: <1358495963.93.0.477059153713.issue15448@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Ouch, the problem was in fact on my side. I was building python inside a mock [1] chroot that had different version of headers than the actual kernel. When I figured this out and made the versions the same, everything passed perfectly. Sorry for the confusion. [1] http://fedoraproject.org/wiki/Projects/Mock ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 09:07:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 08:07:34 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1358496454.63.0.545513116492.issue16991@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 10:08:25 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 18 Jan 2013 09:08:25 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1358500105.92.0.132714407473.issue16970@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I added some Rietveld comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 10:25:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 09:25:25 +0000 Subject: [issue16993] shutil.which() should preserve path case Message-ID: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Now which lowercase found directory name and extension on Windows. >>> shutil.which("python") 'c:\\python33\\python.exe' Proposed patch preserve case. >>> shutil.which("python") 'C:\\Python33\\python.exe' Please test this on Windows. ---------- messages: 180181 nosy: hynek, serhiy.storchaka, tarek priority: normal severity: normal status: open title: shutil.which() should preserve path case type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 10:26:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 09:26:11 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1358501171.9.0.415171917549.issue16993@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Library (Lib), Windows stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 11:15:10 2013 From: report at bugs.python.org (koobs) Date: Fri, 18 Jan 2013 10:15:10 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <1358504110.48.0.185280569203.issue11729@psf.upfronthosting.co.za> koobs added the comment: Stefan, can we merge this to the 2.7 branch as well please? http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%202.7/builds/308/steps/compile/logs/stdio ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 11:35:29 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 18 Jan 2013 10:35:29 +0000 Subject: [issue16939] Broken link in 14. Cryptographic Service In-Reply-To: <1357959551.72.0.678573558111.issue16939@psf.upfronthosting.co.za> Message-ID: <1358505329.07.0.772391660285.issue16939@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This was fixed a year and a half ago by issue 12351. For example, see: http://docs.python.org/3/library/crypto.html ---------- nosy: +chris.jerdonek resolution: -> out of date stage: -> committed/rejected status: open -> closed superseder: -> Update URL for pycrypto project _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 11:36:53 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 18 Jan 2013 10:36:53 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1358504110.48.0.185280569203.issue11729@psf.upfronthosting.co.za> Message-ID: <20130118103655.GA10926@sleipnir.bytereef.org> Stefan Krah added the comment: koobs wrote: > Stefan, can we merge this to the 2.7 branch as well please? If Benjamin is okay with it, yes. The problem with these configure fixes is that they might break other systems in unexpected ways. I already hesitated to put it into 3.3, but the buildbots are fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 11:38:50 2013 From: report at bugs.python.org (koobs) Date: Fri, 18 Jan 2013 10:38:50 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <1358505530.41.0.329197490508.issue11729@psf.upfronthosting.co.za> koobs added the comment: Thanks for the quick response. I'd be happy for it to be FreeBSD conditional/specific if that's more suitable, safer? Having said that, our buildbot OS coverage is pretty good, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 11:44:08 2013 From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=) Date: Fri, 18 Jan 2013 10:44:08 +0000 Subject: [issue7563] yield in except clause causes exception context to be lost In-Reply-To: <1261511318.07.0.56759832135.issue7563@psf.upfronthosting.co.za> Message-ID: <1358505848.87.0.771985695788.issue7563@psf.upfronthosting.co.za> Changes by Adam Biela?ski : ---------- nosy: +Adam.Biela?ski _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 11:55:00 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Jan 2013 10:55:00 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358506500.14.0.984931157886.issue16468@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If you can somewhat solve the problem by better using the existing api, good. I am not 'stuck' on reusing str/repr*. If metavar is non-optional for non-iterable choices, the doc should say so in the entry for choices. (Does the test suite already have a testcase already for non-iterable choices + metavar?) If you can solve it even better and remove that limitation by extending the 'default_metaver' idea from positional and optional args to choices ('choiced' args), even better. I think the refactoring may still be needed, especially for #16418, but that is that issue. * My main concern is that the attempt to provide helpful info to end users not hang or kill a program. IDLE used to sometimes quit while attempting to provide a nice calltip (#12510). It currently quits on Windows when attempting to warn users about bad custom configuration (#14576). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 12:07:46 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 18 Jan 2013 11:07:46 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message In-Reply-To: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> Message-ID: <1358507266.04.0.745168738086.issue16977@psf.upfronthosting.co.za> Chris Jerdonek added the comment: There are also test cases with a string being passed for choices. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 12:19:36 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 18 Jan 2013 11:19:36 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358507976.71.0.343350162952.issue16957@psf.upfronthosting.co.za> Thomas Kluyver added the comment: That makes sense - foo/setup.py can be run from the working directory, but you can't refer to subdirectories on $PATH like that. I've added a revised version of the patch. ---------- Added file: http://bugs.python.org/file28763/shutil_which_cwd2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 13:24:34 2013 From: report at bugs.python.org (David Coallier) Date: Fri, 18 Jan 2013 12:24:34 +0000 Subject: [issue16994] collections.Counter.least_common Message-ID: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> New submission from David Coallier: The `collections.Counter` library contains very useful methods for playing with dicts and sets (mainly the most_common()) function. Even though it is fairly trivial to retrieve the least common elements in a Counter() by doing Counter(...).most_common(n)[:-n:-1] I believe that for the sake of consistency, the `least_common` method should also be available. The attached patch contains the following: - The method definition in Lib/__init__.py to support least_common; - The tests to make sure least_common behaves as expected; - The documentation for 2.7 and the general documentation. Everywhere `most_common` was mentioned, you will now find `least_common` mentioned as well. ---------- components: Library (Lib) files: collections.Counter.least_common.patch keywords: patch messages: 180189 nosy: davidcoallier priority: normal severity: normal status: open title: collections.Counter.least_common type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file28764/collections.Counter.least_common.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 14:12:19 2013 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 18 Jan 2013 13:12:19 +0000 Subject: [issue16994] collections.Counter.least_common In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> Message-ID: <1358514739.19.0.679340610246.issue16994@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 14:16:21 2013 From: report at bugs.python.org (Takayuki SHIMIZUKAWA) Date: Fri, 18 Jan 2013 13:16:21 +0000 Subject: [issue14255] tempfile.gettempdir() didn't return the path with correct case. In-Reply-To: <1331514762.82.0.635964063955.issue14255@psf.upfronthosting.co.za> Message-ID: <1358514981.69.0.425584992967.issue14255@psf.upfronthosting.co.za> Takayuki SHIMIZUKAWA added the comment: > I think that moving to 'normpath' instead of 'normcase' Official manual says 'abspath' include 'normpath' functionality. I think it is need JUST remove '_os.path.normcase' calling. But, I do not understand the circumstances which use 'normcase'. ---------- nosy: +shimizukawa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 14:30:18 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 18 Jan 2013 13:30:18 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1358515818.34.0.469223596561.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a patch for discussion that allows non-iterable choices with or without metavar. It refactors as suggested. However, the patch does not yet have tests. > Does the test suite already have a testcase already for non-iterable choices + metavar? No, not that I saw. Also, to answer a previous question, the three places in which the choices string is used are: in the usage string (separator=','), in the help string when expanding "%(choices)s" (separator=', '), and in the error message text (separator=', ' with repr() instead of str()). ---------- Added file: http://bugs.python.org/file28765/issue-16468-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 14:56:23 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Jan 2013 13:56:23 +0000 Subject: [issue10115] Support accept4() for atomic setting of flags at socket creation In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za> Message-ID: <1358517383.94.0.805737457536.issue10115@psf.upfronthosting.co.za> STINNER Victor added the comment: My implementation of the PEP 433 uses accept4() for socket.accept() if the (new) cloexec parameter is True: http://hg.python.org/features/pep-433/file/46b7a077ae87/Modules/socketmodule.c#l1961 The code fallbacks to accept() if accept4() fails with ENOSYS. It happens if the glibc version is 2.10 or newer, whereas the Linux kernel is older than 2.6.28. I didn't test the fallback yet. I see in changeset 12442ac3f7dd (issue #7523) that SOCK_NONBLOCK is also set in the flags parameters of accept4(). I should probably also do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 15:22:08 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 14:22:08 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358518928.77.0.590019473483.issue16969@psf.upfronthosting.co.za> Ezio Melotti added the comment: This has been fixed already in 652286ee23f8, but apparently the fix is not included in 3.3.0. I think it's safe to ignore the failure. In the first message you said that this "prevents correct installation". What did you mean exactly? ---------- type: behavior -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 15:48:19 2013 From: report at bugs.python.org (Robert Leenders) Date: Fri, 18 Jan 2013 14:48:19 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1358520499.76.0.34572660284.issue16970@psf.upfronthosting.co.za> Robert Leenders added the comment: Chris, you said (in the review) "Hmm, since this is for maintenance releases ... This change could cause "working" code to no longer work." I understood from our original message that you wanted it to change since it is inconsistent. I vote for changing it (so that it gives an error) but since this is my first bug/patch, I don't really know what usually happens. Either way, I adjusted the patch conform your comments. For now I removed the original changes to handle negative numbers and changed the message from "nargs must be > 0" to "nargs must be != 0". ---------- Added file: http://bugs.python.org/file28766/argparse-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 15:56:54 2013 From: report at bugs.python.org (Robert Leenders) Date: Fri, 18 Jan 2013 14:56:54 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1358521014.67.0.289847086409.issue16970@psf.upfronthosting.co.za> Changes by Robert Leenders : Removed file: http://bugs.python.org/file28766/argparse-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 15:58:15 2013 From: report at bugs.python.org (Robert Leenders) Date: Fri, 18 Jan 2013 14:58:15 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1358521095.33.0.539025826346.issue16970@psf.upfronthosting.co.za> Changes by Robert Leenders : Added file: http://bugs.python.org/file28767/argparse-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 16:11:01 2013 From: report at bugs.python.org (Jeff Knupp) Date: Fri, 18 Jan 2013 15:11:01 +0000 Subject: [issue16988] argparse: PARSER option for nargs not documented In-Reply-To: <1358458215.07.0.403888123098.issue16988@psf.upfronthosting.co.za> Message-ID: <1358521861.86.0.384728687708.issue16988@psf.upfronthosting.co.za> Jeff Knupp added the comment: This is not a bug. The 'PARSER' nargs choice is an implementation detail as a way to handle subparsers. The parser needs to know that the first value should be handled, but everything that follows will be handled by the subparser. By using a subparser, you're effectively using 'PARSER', but it wouldn't make sense to allow 'PARSER' to be set directly as it only makes sense when used in conjunction with a subparser. ---------- nosy: +jeffknupp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 16:13:25 2013 From: report at bugs.python.org (Alexey Kachayev) Date: Fri, 18 Jan 2013 15:13:25 +0000 Subject: [issue16774] Additional recipes for itertools docs In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za> Message-ID: <1358522005.82.0.915301100672.issue16774@psf.upfronthosting.co.za> Alexey Kachayev added the comment: Updated patch with: * fix error in islice function name * made n=None default second argument for consume(iterator, n=None) cause it provides specific behavior when n is None which can be assumed as default for function ---------- Added file: http://bugs.python.org/file28768/itertools.doc.v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 16:51:21 2013 From: report at bugs.python.org (Jeff Knupp) Date: Fri, 18 Jan 2013 15:51:21 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message In-Reply-To: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> Message-ID: <1358524281.51.0.106498842895.issue16977@psf.upfronthosting.co.za> Jeff Knupp added the comment: Attached a patch. Rather than altering choices or making a special check for string instances, I just changed the if statement to if action.choices is not None and value not in list(action.choices): from if action.choices is not None and value not in action.choices: It has the added benefit of handling all sequence types correctly (rather than just strings). I tried to think of a case where this wouldn't work as expected, but wasn't able to. ---------- keywords: +patch nosy: +jeffknupp Added file: http://bugs.python.org/file28769/argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 18:21:59 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 18 Jan 2013 17:21:59 +0000 Subject: [issue16953] select module compile errors with broken poll() In-Reply-To: <1358090207.46.0.168893562031.issue16953@psf.upfronthosting.co.za> Message-ID: <1358529719.2.0.153771534357.issue16953@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Could you provide the patch? It's trivial, but at least we'll make sure the patch fixes the problem on your platform. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 18:49:53 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 18 Jan 2013 17:49:53 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358531393.91.0.668197274548.issue16957@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 18:52:24 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 18 Jan 2013 17:52:24 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358531544.95.0.865785821199.issue16957@psf.upfronthosting.co.za> ?ric Araujo added the comment: I assume that ./script is working just like dir/script (what the tests exercize is not crystal clear to me). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 18:59:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Jan 2013 17:59:34 +0000 Subject: [issue16978] fix grammar in 'threading' documentation In-Reply-To: <1358370440.72.0.85153283969.issue16978@psf.upfronthosting.co.za> Message-ID: <3Ynqfs4BtJzNS8@mail.python.org> Roundup Robot added the comment: New changeset 8886d7ca159b by Ezio Melotti in branch '2.7': #16978: rephrase sentence and fix typo. Initial patch by Tshepang Lekhonkhobe. http://hg.python.org/cpython/rev/8886d7ca159b New changeset 4a1a88d25fec by Ezio Melotti in branch '3.2': #16978: rephrase sentence and fix typo. Initial patch by Tshepang Lekhonkhobe. http://hg.python.org/cpython/rev/4a1a88d25fec New changeset ad0af795c345 by Ezio Melotti in branch '3.3': #16978: merge with 3.2. http://hg.python.org/cpython/rev/ad0af795c345 New changeset e1118ff088be by Ezio Melotti in branch 'default': #16978: merge with 3.3. http://hg.python.org/cpython/rev/e1118ff088be ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:00:17 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 18:00:17 +0000 Subject: [issue16978] fix grammar in 'threading' documentation In-Reply-To: <1358370440.72.0.85153283969.issue16978@psf.upfronthosting.co.za> Message-ID: <1358532017.84.0.495793544161.issue16978@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report and the patch! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:02:02 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 18:02:02 +0000 Subject: [issue16985] Docs reference a concrete UTC tzinfo, but none exists In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za> Message-ID: <1358532122.98.0.690039643501.issue16985@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +belopolsky, brett.cannon, rafe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:06:39 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 18:06:39 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1358532399.37.0.958751355553.issue16991@psf.upfronthosting.co.za> Ezio Melotti added the comment: The tests should probably be updated to use the PEP 399 idiom in order to test both the implementations. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:12:40 2013 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 18 Jan 2013 18:12:40 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1358532760.03.0.822868159846.issue16991@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:15:06 2013 From: report at bugs.python.org (Jeff Knupp) Date: Fri, 18 Jan 2013 18:15:06 +0000 Subject: [issue16989] allow distutils debug mode to be enabled more easily In-Reply-To: <1358466115.01.0.322407717365.issue16989@psf.upfronthosting.co.za> Message-ID: <1358532906.65.0.596789851333.issue16989@psf.upfronthosting.co.za> Jeff Knupp added the comment: Patch uploaded. Note that updating the test_distutils.core test revealed that the test was importing DEBUG from the wrong module (which only existed because distutils.core use the 'from ... import DEBUG' form). I've corrected the import and updated the test case. Also updated the documentation to reflect the change. ---------- keywords: +patch nosy: +jeffknupp Added file: http://bugs.python.org/file28770/distutils.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:17:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 18:17:15 +0000 Subject: [issue16994] collections.Counter.least_common In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> Message-ID: <1358533035.07.0.28959352884.issue16994@psf.upfronthosting.co.za> Ezio Melotti added the comment: I left a review on Rietveld. Since this is a new feature it can't go on 2.7, and it should target 3.4 instead. ---------- nosy: +ezio.melotti stage: -> patch review versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:18:11 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 18 Jan 2013 18:18:11 +0000 Subject: [issue16985] Docs reference a concrete UTC tzinfo, but none exists In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za> Message-ID: <1358533091.08.0.808336556323.issue16985@psf.upfronthosting.co.za> Brett Cannon added the comment: Nope, no reason. I bet it was a bad merge somewhere in the docs from Python 3 to 2.7 at some point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:20:29 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 18:20:29 +0000 Subject: [issue16972] Useless function call in site.py In-Reply-To: <1358263158.12.0.256435330615.issue16972@psf.upfronthosting.co.za> Message-ID: <1358533229.33.0.58003731567.issue16972@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +brett.cannon stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:21:19 2013 From: report at bugs.python.org (=?utf-8?q?Matth=C3=A4us_Wander?=) Date: Fri, 18 Jan 2013 18:21:19 +0000 Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached) Message-ID: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za> New submission from Matth?us Wander: RFC4648 specifies two different alphabets for Base32: 1) the common one already used in RFC3548 and implemented in Python, and 2) an "Extended Hex" alphabet which is used by e.g. DNSSEC NSEC3 but not yet implemented in Python. The attached patches add the "Extended Hex" alphabet to Python 2.7 and 3 via an optional parameter 'base32hex=False'. Default behavior is not changed. patch Lib/base64.py < py27_base64.patch patch Lib/test/test_base64.py < py27_test_base64.patch ---------- components: Library (Lib) files: base32hex.tar.gz messages: 180206 nosy: matthaeus.wander priority: normal severity: normal status: open title: Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached) type: enhancement versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file28771/base32hex.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:26:11 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 18:26:11 +0000 Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached) In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za> Message-ID: <1358533571.81.0.589822571522.issue16995@psf.upfronthosting.co.za> Ezio Melotti added the comment: Since this is a new feature it can go on 3.4 only. It would also be better to include both the changes for base64.py and test_base64.py in a single patch and attach that, rather than uploading an archive that contains both. FTR the links to the relevant RFCs are: http://tools.ietf.org/html/rfc3548 http://tools.ietf.org/html/rfc4648 ---------- nosy: +ezio.melotti versions: +Python 3.4 -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:32:43 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 18 Jan 2013 18:32:43 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message In-Reply-To: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> Message-ID: <1358533963.59.0.333976388042.issue16977@psf.upfronthosting.co.za> Chris Jerdonek added the comment: See issue 16468 for why that won't work in general. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:37:53 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 18 Jan 2013 18:37:53 +0000 Subject: [issue16972] Useless function call in site.py In-Reply-To: <1358263158.12.0.256435330615.issue16972@psf.upfronthosting.co.za> Message-ID: <1358534273.15.0.951150334933.issue16972@psf.upfronthosting.co.za> Brett Cannon added the comment: I suspect Kirill is right, although the function that calls addpackage() in site.py always passes in a value, so it won't change anything for Python itself, only third-party code. And addpackage() has been that way since 2004. But, in looking at the function itself, the function seems wrong without the change, so I say fix it in 3.4 but leave it out of 3.3. And honestly that whole module needs to be cleaned up (again). ---------- assignee: -> brett.cannon stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:51:10 2013 From: report at bugs.python.org (=?utf-8?q?Matth=C3=A4us_Wander?=) Date: Fri, 18 Jan 2013 18:51:10 +0000 Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached) In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za> Message-ID: <1358535070.68.0.879188914852.issue16995@psf.upfronthosting.co.za> Matth?us Wander added the comment: Added single patch as requested. ---------- keywords: +patch Added file: http://bugs.python.org/file28772/py3_base32hex.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:56:34 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 18 Jan 2013 18:56:34 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1358535394.4.0.666405265483.issue16954@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 19:57:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 18:57:59 +0000 Subject: [issue16994] collections.Counter.least_common In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> Message-ID: <1358535479.2.0.71858754617.issue16994@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is use case for this method? Actually, any element which is not in a collection, is a least common for this collection. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 20:14:41 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 19:14:41 +0000 Subject: [issue16774] Additional recipes for itertools docs In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za> Message-ID: <1358536481.85.0.980039200428.issue16774@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: How are popular the proposed recipes? Not every possible combination of functions is worth to mention in the documentation. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 20:27:03 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 18 Jan 2013 19:27:03 +0000 Subject: [issue16965] 2to3 should rewrite execfile() to open in 'rb' mode In-Reply-To: <1358187846.57.0.700535378161.issue16965@psf.upfronthosting.co.za> Message-ID: <1358537223.78.0.4533607794.issue16965@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 20:30:10 2013 From: report at bugs.python.org (David Coallier) Date: Fri, 18 Jan 2013 19:30:10 +0000 Subject: [issue16994] collections.Counter.least_common In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> Message-ID: <1358537410.58.0.962294880849.issue16994@psf.upfronthosting.co.za> David Coallier added the comment: Latest patch after code review round #1 ---------- Added file: http://bugs.python.org/file28773/collections.Counter.least_common.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 20:32:12 2013 From: report at bugs.python.org (David Coallier) Date: Fri, 18 Jan 2013 19:32:12 +0000 Subject: [issue16994] collections.Counter.least_common In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> Message-ID: <1358537532.26.0.155026510486.issue16994@psf.upfronthosting.co.za> Changes by David Coallier : Removed file: http://bugs.python.org/file28773/collections.Counter.least_common.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 20:36:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 19:36:37 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358537797.05.0.214092381412.issue16957@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps the comment in which() is misleading now, if I understand correctly the meaning of the words "short circuit". Native speakers, please correct me if I wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 20:38:31 2013 From: report at bugs.python.org (Jeff Knupp) Date: Fri, 18 Jan 2013 19:38:31 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message In-Reply-To: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> Message-ID: <1358537911.03.0.475675074608.issue16977@psf.upfronthosting.co.za> Jeff Knupp added the comment: The only time this would be an issue is for infinite sequences via range or a generator, which doesn't work anyway. >>> p = argparse.ArgumentParser() >>> a = p.add_argument('a', choices=itertools.count(0), type=int) >>> p.parse_args(['10000']) ... hangs Are there any other cases where coercing to a list wouldn't work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 20:54:49 2013 From: report at bugs.python.org (David Coallier) Date: Fri, 18 Jan 2013 19:54:49 +0000 Subject: [issue16994] collections.Counter.least_common In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> Message-ID: <1358538889.85.0.672650416025.issue16994@psf.upfronthosting.co.za> David Coallier added the comment: Hi there @serhiy.storchaka, Consider the case where one would calculate the k-combination of set S. When the set has `n` elements, the number of k-combination is equal to its binomial coefficient. e.g. ( n!/( (k!(n-k)! ). One method of statistically optimising the computation is to remove n least common elements from the set S. I do agree that this new method is merely for consistency because right now it is quite easy to simply do c.most_common(...)[:-(n+1):-1] to get th e least common elements. The goal of this patch is to make it intuitive to get the least common elements of a Counter, therefore making it easy to remove them from a collection. Does it make any sense to you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 21:04:18 2013 From: report at bugs.python.org (David Coallier) Date: Fri, 18 Jan 2013 20:04:18 +0000 Subject: [issue16994] collections.Counter.least_common In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> Message-ID: <1358539458.02.0.38762626267.issue16994@psf.upfronthosting.co.za> Changes by David Coallier : Added file: http://bugs.python.org/file28774/16994.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 21:23:16 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 18 Jan 2013 20:23:16 +0000 Subject: [issue16977] argparse: mismatch between choices parsing and usage/error message In-Reply-To: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za> Message-ID: <1358540596.92.0.487804871966.issue16977@psf.upfronthosting.co.za> Chris Jerdonek added the comment: When choices isn't iterable but supports the "in" operator, e.g. class MyChoices(object): def __contains__(self, item): return True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 21:35:57 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Jan 2013 20:35:57 +0000 Subject: [issue16985] Docs reference a concrete UTC tzinfo, but none exists In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za> Message-ID: <3Ynv7J5HPvzPNG@mail.python.org> Roundup Robot added the comment: New changeset 582ecb9a4061 by Jason R. Coombs in branch '2.7': #16985: Remove incorrect phrase indication presence of non-present concrete UTC tzinfo instance. http://hg.python.org/cpython/rev/582ecb9a4061 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 21:36:23 2013 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 18 Jan 2013 20:36:23 +0000 Subject: [issue16985] Docs reference a concrete UTC tzinfo, but none exists In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za> Message-ID: <1358541383.26.0.701567154356.issue16985@psf.upfronthosting.co.za> Changes by Jason R. Coombs : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 21:40:39 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 18 Jan 2013 20:40:39 +0000 Subject: [issue16985] Docs reference a concrete UTC tzinfo, but none exists In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za> Message-ID: <1358541639.73.0.0656285016357.issue16985@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 21:44:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 20:44:35 +0000 Subject: [issue16996] Reuse shutil.which() in webbrowser module Message-ID: <1358541875.07.0.897350417662.issue16996@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: We can get rid of private webbrowser functions and reuse shutil.which(). ---------- components: Library (Lib) files: webbrowser_which.patch keywords: patch messages: 180220 nosy: georg.brandl, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Reuse shutil.which() in webbrowser module type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28775/webbrowser_which.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 22:07:11 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2013 21:07:11 +0000 Subject: [issue16997] subtests Message-ID: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> New submission from Antoine Pitrou: subtests are a light alternative to parametered tests as in issue7897. They don't generate the tests for you, they simply allow to partition a given test case in several logical units. Meaning, when a subtest fails, the other subtests in the test will still run (and the failures will print their respective parameters). Concretely, running the follow example: class MyTest(unittest.TestCase): def test_b(self): """some test""" for i in range(2, 5): for j in range(0, 3): with self.subTest(i=i, j=j): self.assertNotEqual(i % 3, j) will give the following output: ====================================================================== FAIL: test_b (__main__.MyTest) (i=2, j=2) some test ---------------------------------------------------------------------- Traceback (most recent call last): File "subtests.py", line 11, in test_b self.assertNotEqual(i % 3, j) AssertionError: 2 == 2 ====================================================================== FAIL: test_b (__main__.MyTest) (i=3, j=0) some test ---------------------------------------------------------------------- Traceback (most recent call last): File "subtests.py", line 11, in test_b self.assertNotEqual(i % 3, j) AssertionError: 0 == 0 ====================================================================== FAIL: test_b (__main__.MyTest) (i=4, j=1) some test ---------------------------------------------------------------------- Traceback (most recent call last): File "subtests.py", line 11, in test_b self.assertNotEqual(i % 3, j) AssertionError: 1 == 1 ---------------------------------------------------------------------- ---------- components: Library (Lib) messages: 180221 nosy: Julian, Yaroslav.Halchenko, abingham, bfroehle, borja.ruiz, brian.curtin, chris.jerdonek, eric.araujo, eric.snow, exarkun, ezio.melotti, florian-rathgeber, fperez, hpk, michael.foord, nchauvat, ncoghlan, pitrou, r.david.murray, santa4nt, spiv priority: normal severity: normal status: open title: subtests type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 22:08:12 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2013 21:08:12 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358543292.29.0.945360414921.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Attaching patch. ---------- keywords: +patch Added file: http://bugs.python.org/file28776/subtests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 22:08:19 2013 From: report at bugs.python.org (Ry Erickson) Date: Fri, 18 Jan 2013 21:08:19 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358543299.71.0.243963560232.issue16969@psf.upfronthosting.co.za> Ry Erickson added the comment: Oops. I just realized that it works, I just had not added python3 to PATH. It installed correctly, and there was never any issue. My mistake. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 22:08:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2013 21:08:20 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358543300.02.0.525081472096.issue16997@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 22:09:19 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 21:09:19 +0000 Subject: [issue16969] test_urlwithfrag fail In-Reply-To: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za> Message-ID: <1358543359.82.0.365053396001.issue16969@psf.upfronthosting.co.za> Ezio Melotti added the comment: OK, I'll close the issue then. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 22:19:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Jan 2013 21:19:19 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358543959.11.0.11356283204.issue16997@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: +1. I was going to suggest something similar for displaying the I was going to suggest something similar to display the clarification message in case of a fail: for arg, expected in [(...),...]: with self.somegoodname(msg="arg=%s"%arg): self.assertEqual(foo(arg), expected) But your idea is even better. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 22:22:53 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2013 21:22:53 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358544173.08.0.752844876903.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Since I was asked on IRC, an example of converting an existing test. It's quite trivial really: diff --git a/Lib/test/test_codecs.py b/Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py +++ b/Lib/test/test_codecs.py @@ -630,9 +630,10 @@ class UTF16BETest(ReadTest, unittest.Tes (b'\xdc\x00\x00A', '\ufffdA'), ] for raw, expected in tests: - self.assertRaises(UnicodeDecodeError, codecs.utf_16_be_decode, - raw, 'strict', True) - self.assertEqual(raw.decode('utf-16be', 'replace'), expected) + with self.subTest(raw=raw, expected=expected): + self.assertRaises(UnicodeDecodeError, codecs.utf_16_be_decode, + raw, 'strict', True) + self.assertEqual(raw.decode('utf-16be', 'replace'), expected) def test_nonbmp(self): self.assertEqual("\U00010203".encode(self.encoding), ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 22:50:18 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 18 Jan 2013 21:50:18 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358545818.33.0.998809542602.issue16997@psf.upfronthosting.co.za> Ezio Melotti added the comment: I like the idea, and I think this would be a useful addition to unittest. OTOH while this would be applicable to most of the tests (almost every test has a "for" loop to check valid/invalid values, or a few related "subtests" in the same test method), I'm not sure I would use it too often. The reason is that often there's a single bug that causes the failure(s), and most likely the error reported by unittest is the same (or anyway it's very similar) for all the subtests, so using subtests would just add more noise (at least for me). However it might be useful in case of sporadic failures or whenever having the full set of failures would be useful to diagnose the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 23:31:22 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 18 Jan 2013 22:31:22 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358548282.41.0.0955768046776.issue16957@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Yes, as far as I know, ./script works in the same way as dir/script - from the current directory, but not from $PATH. The first test added is for the case I reported - which('script') shouldn't look in the current directory on Unix. The second test would have failed without Serhiy's correction. Serhiy, I agree that the comment wasn't quite right. I've uploaded a new version of the patch with a modified comment. ---------- versions: -Python 3.4 Added file: http://bugs.python.org/file28777/shutil_which_cwd3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 18 23:33:03 2013 From: report at bugs.python.org (W. Trevor King) Date: Fri, 18 Jan 2013 22:33:03 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1358548383.4.0.926066732729.issue9253@psf.upfronthosting.co.za> W. Trevor King added the comment: Since [1] it seems like subparsers *are* optional by default. At least I get ?error: too few arguments? for version 70740 of Lib/argparse.py, but no error for version 70741. It looks like this may be an unintentional side effect, since I see no mention of subparsers in #10424. [1]: http://hg.python.org/cpython/rev/cab204a79e09 ---------- nosy: +labrat Added file: http://bugs.python.org/file28778/check.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 00:18:11 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 18 Jan 2013 23:18:11 +0000 Subject: [issue16997] subtests In-Reply-To: <1358545818.33.0.998809542602.issue16997@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: This looks very nice. For cases where you decide you don't want it, some kind of "fail fast" mechanism would be helpful (e.g. when you've seen the full set of failures, and are now just trying to resolve the first one) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 00:21:49 2013 From: report at bugs.python.org (Jeffrey Armstrong) Date: Fri, 18 Jan 2013 23:21:49 +0000 Subject: [issue16953] select module compile errors with broken poll() In-Reply-To: <1358090207.46.0.168893562031.issue16953@psf.upfronthosting.co.za> Message-ID: <1358551309.05.0.397075094686.issue16953@psf.upfronthosting.co.za> Jeffrey Armstrong added the comment: I've attached the patch, and I probably should have done so in the first place. It applies to Python 3.3.0. The resulting code compiles fine on m68k-atari-mint. It shouldn't affect any of the major platforms. ---------- Added file: http://bugs.python.org/file28779/select_module_patch.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 00:47:48 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Jan 2013 23:47:48 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358552868.2.0.740383356105.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch make subtests play nice with unittest's failfast flag: http://docs.python.org/dev/library/unittest.html#cmdoption-unittest-f ---------- Added file: http://bugs.python.org/file28780/subtests2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 01:33:30 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 19 Jan 2013 00:33:30 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358555610.83.0.527134617854.issue16997@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Nice/elegant idea. A couple comments: (1) What will be the semantics of TestCase/subtest failures? Currently, it looks like each subtest failure registers as an additional failure, meaning that the number of test failures can exceed the number of test cases. For example (with a single test case with 2 subtests): $ ./python.exe test_subtest.py FF ====================================================================== FAIL: test (__main__.MyTests) (i=0) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_subtest.py", line 9, in test self.assertEqual(0, 1) AssertionError: 0 != 1 ====================================================================== FAIL: test (__main__.MyTests) (i=1) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_subtest.py", line 9, in test self.assertEqual(0, 1) AssertionError: 0 != 1 ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=2) With the way I understand it, it seems like a subtest failure should register as a failure of the TestCase as a whole, unless the subtests should be enumerated and considered tests in their own right (in which case the total test count should reflect this). (2) Related to (1), it doesn't seem like decorators like expectedFailure are being handled correctly. For example: @unittest.expectedFailure def test(self): for i in range(2): with self.subTest(i=i): self.assertEqual(i, 0) This results in: Ran 1 test in 0.001s FAILED (failures=1, unexpected successes=1) In other words, it seems like the decorator is being applied to each subtest as opposed to the test case as a whole (though actually, I think the first should read "expected failures=1"). It seems like one subtest failing should qualify as an expected failure, or are the semantics such that expectedFailure means that every subtest must fail? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 01:52:04 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Jan 2013 00:52:04 +0000 Subject: [issue16997] subtests In-Reply-To: <1358555610.83.0.527134617854.issue16997@psf.upfronthosting.co.za> Message-ID: <1358556573.3462.7.camel@localhost.localdomain> Antoine Pitrou added the comment: Le samedi 19 janvier 2013 ? 00:33 +0000, Chris Jerdonek a ?crit : > With the way I understand it, it seems like a subtest failure should > register as a failure of the TestCase as a whole, unless the subtests > should be enumerated and considered tests in their own right (in which > case the total test count should reflect this). It does register as a failure of the TestCase as a whole. Simply, a test case can encounter several failures: for example, one in the test method and one in the tearDown method. Perhaps unittest should be made to show better reporting, e.g. show the number of successful and failed tests. I suppose there is a reason for the current behaviour, though. > This results in: > > Ran 1 test in 0.001s > > FAILED (failures=1, unexpected successes=1) > > In other words, it seems like the decorator is being applied to each > subtest as opposed to the test case as a whole (though actually, I > think the first should read "expected failures=1"). It seems like one > subtest failing should qualify as an expected failure, or are the > semantics such that expectedFailure means that every subtest must > fail? I don't know. I never use expectedFailure. There doesn't seem to be any obviously preferable answer here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 08:31:32 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 19 Jan 2013 07:31:32 +0000 Subject: [issue16997] subtests In-Reply-To: <1358556573.3462.7.camel@localhost.localdomain> Message-ID: Chris Jerdonek added the comment: Either way, something isn't right about how it's integrated now. With the patch, this: @unittest.expectedFailure def test(self): with self.subTest(): self.assertEqual(0, 1) gives: FAILED (failures=1, unexpected successes=1) And this: @unittest.expectedFailure def test(self): with self.subTest(): self.assertEqual(0, 0) gives: OK (unexpected successes=1) But without the patch, this: @unittest.expectedFailure def test(self): self.assertEqual(0, 1) gives: OK (expected failures=1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 09:37:05 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 19 Jan 2013 08:37:05 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1358584625.23.0.276542447878.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: @Benjamin: Yeah, I've fixed that. @Ezio: Good point. I've touched that up. Once I have cleared up reference counting issues I'll put up a new patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 10:31:10 2013 From: report at bugs.python.org (Alexey Kachayev) Date: Sat, 19 Jan 2013 09:31:10 +0000 Subject: [issue16774] Additional recipes for itertools docs In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za> Message-ID: <1358587870.25.0.701910334724.issue16774@psf.upfronthosting.co.za> Alexey Kachayev added the comment: It's hard to evaluate how popular given recipes, but: * drop is opposite to take, so it's as popular as take * the same situation with splitat, splitby - it's one case of partition that's hard to write each time with enumerator (partition is already in documentation) * takelast, droplast was added cause itertools.islice doesn't support negative indices (which is ok). both functions have not obvious implementation - I'm sure that recipes will be good example for users how to work with iterators even if concrete functions aren't so widely-spreaded ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 10:49:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Jan 2013 09:49:49 +0000 Subject: [issue16994] collections.Counter.least_common In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za> Message-ID: <1358588989.9.0.770895767358.issue16994@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > One method of statistically optimising the computation is to remove n least common elements from the set S. May be you need not remove least common elements from the set, but *get* a set of (len(S)-n) most common elements? > Does it make any sense to you? Frankly, not very much. Note, that least common element is not defined in most cases. Usually there are only a few most (or even one) common elements, but a lot of least common elements. Result of least_common(n) is practically random due to hash randomization. Another note is that most_common()[:-n] in many cases faster than least_common(n) for n >> 1. This is right for most_common(n) too, but it usually used for very small n (in particular for n=1) and this has more sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 11:46:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Jan 2013 10:46:34 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <3YpG0n0xBKzSLn@mail.python.org> Roundup Robot added the comment: New changeset 974ace29ee2d by Serhiy Storchaka in branch '3.2': Issue #15989: Fix several occurrences of integer overflow http://hg.python.org/cpython/rev/974ace29ee2d New changeset 8f10c9eae183 by Serhiy Storchaka in branch '3.3': Issue #15989: Fix several occurrences of integer overflow http://hg.python.org/cpython/rev/8f10c9eae183 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 11:56:49 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Jan 2013 10:56:49 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <3YpGDc3zZHzSMD@mail.python.org> Roundup Robot added the comment: New changeset d544873d62e9 by Serhiy Storchaka in branch '2.7': Issue #15989: Fix several occurrences of integer overflow http://hg.python.org/cpython/rev/d544873d62e9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 12:40:31 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Jan 2013 11:40:31 +0000 Subject: [issue16953] select module compile errors with broken poll() In-Reply-To: <1358090207.46.0.168893562031.issue16953@psf.upfronthosting.co.za> Message-ID: <3YpHC22VwXzSLB@mail.python.org> Roundup Robot added the comment: New changeset 1d33c79d2f6b by Charles-Fran?ois Natali in branch '2.7': Issue #16953: Fix socket module compilation on platforms with HAVE_BROKEN_POLL. http://hg.python.org/cpython/rev/1d33c79d2f6b New changeset 101e821e5e70 by Charles-Fran?ois Natali in branch '3.2': Issue #16953: Fix socket module compilation on platforms with HAVE_BROKEN_POLL. http://hg.python.org/cpython/rev/101e821e5e70 New changeset f04c97bbb241 by Charles-Fran?ois Natali in branch '3.3': Issue #16953: Fix socket module compilation on platforms with HAVE_BROKEN_POLL. http://hg.python.org/cpython/rev/f04c97bbb241 New changeset 79912bb1a884 by Charles-Fran?ois Natali in branch 'default': Issue #16953: Fix socket module compilation on platforms with HAVE_BROKEN_POLL. http://hg.python.org/cpython/rev/79912bb1a884 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 12:58:50 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 19 Jan 2013 11:58:50 +0000 Subject: [issue16945] rewrite CGIHTTPRequestHandler to always use subprocess In-Reply-To: <1358000083.64.0.0773347996342.issue16945@psf.upfronthosting.co.za> Message-ID: <1358596730.91.0.181176352655.issue16945@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- nosy: +v+python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 13:03:26 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 19 Jan 2013 12:03:26 +0000 Subject: [issue16953] select module compile errors with broken poll() In-Reply-To: <1358090207.46.0.168893562031.issue16953@psf.upfronthosting.co.za> Message-ID: <1358597006.9.0.351604123637.issue16953@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed, thanks for the patch! ---------- stage: -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 13:47:16 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 19 Jan 2013 12:47:16 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1358505530.41.0.329197490508.issue11729@psf.upfronthosting.co.za> Message-ID: <20130119124718.GA2028@sleipnir.bytereef.org> Stefan Krah added the comment: The buildbot coverage is good, but the number of (OS, shell, compiler) combinations is much higher. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 13:54:24 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 19 Jan 2013 12:54:24 +0000 Subject: [issue10535] Enable warnings by default in unittest In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za> Message-ID: <1358600064.77.0.494595285337.issue10535@psf.upfronthosting.co.za> Ezio Melotti added the comment: The two TODOs left are: 1) adding UnittestWarning; 2) improving the error message for deprecations; Technically these are new features, so they can go in 3.4 only, but 2) might be simple enough to be backported. Regarding 1) it might be a bit too late, given that most deprecations have been around for 2-3 versions already. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 14:02:20 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 19 Jan 2013 13:02:20 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1358600540.03.0.98210170804.issue15989@psf.upfronthosting.co.za> Stefan Krah added the comment: Several 2.7 buildbots are failing. > Unfortunately I have only platforms where sizeof(int) == sizeof(long) == sizeof(size_t). You can use your cpython ssh key to login to all snakebite buildbot machines. They are tagged with [SB]. http://mail.python.org/pipermail/python-dev/2012-September/121651.html ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 14:56:28 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 19 Jan 2013 13:56:28 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1358603788.63.0.640226850318.issue16993@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Somehow the patch is not showing for me. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 15:49:31 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Jan 2013 14:49:31 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358606971.41.0.253488148199.issue16997@psf.upfronthosting.co.za> Nick Coghlan added the comment: I think we're going to have to separate out two counts in the metrics - the total number of tests (the current counts), and the total number of subtests (the executed subtest blocks). (Other parameterisation solutions can then choose whether to treat each pair of parameters as a distinct test case or as a subtest - historical solutions would appear as distinct test cases, while new approaches might choose to use the subtest machinery). The aggregation of subtest results to test case results would then be that the test case fails if either: - an assertion directly in the test case fails - an assertion fails in at least one subtest of that test case The interpretation of "expected failure" in a world with subtests is then clear: as long as at least one subtest or assertion fails, the decorator is satisfied that the expected test case failure is occurred. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 16:56:30 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 19 Jan 2013 15:56:30 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1358610990.18.0.456362341523.issue10590@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: -eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 17:45:08 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Jan 2013 16:45:08 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1358613908.35.0.115097572363.issue16993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry. Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file28781/shutil_which_normcase.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 19:35:27 2013 From: report at bugs.python.org (Eugene Toder) Date: Sat, 19 Jan 2013 18:35:27 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1358620527.49.0.116527035927.issue11983@psf.upfronthosting.co.za> Eugene Toder added the comment: If you add co_firstlineno into code_hash you can say something like /* The rest isn't used in hash and comparisons, except co_name and co_firstlineno, which are preserved for tracebacks and debuggers. */ (Otherwise you'd need to explain why co_firstlineno is not in hash.) BTW, since co_firstlineno is used including co_name is redundant -- there's no way to have 2 named code objects on the same line, AFAIK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 20:10:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Jan 2013 19:10:35 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <3YpTBC67XkzSKG@mail.python.org> Roundup Robot added the comment: New changeset a78ebf9aed06 by Serhiy Storchaka in branch '2.7': Ensure that width and precision in string formatting test have type int, not long. http://hg.python.org/cpython/rev/a78ebf9aed06 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 20:13:57 2013 From: report at bugs.python.org (Jens Lechtenboerger) Date: Sat, 19 Jan 2013 19:13:57 +0000 Subject: [issue16998] Lost updates with multiprocessing.Value Message-ID: <1358622837.13.0.603431337609.issue16998@psf.upfronthosting.co.za> New submission from Jens Lechtenboerger: Maybe I'm misreading the documentation of multiprocessing.Value and multiprocessing.sharedctypes.Value. I thought that access to the value field of Value instances was protected by locks to avoid lost updates. Specifically, for multiprocessing.Value(typecode_or_type, *args[, lock]) and multiprocessing.sharedctypes.Value(typecode_or_type, *args[, lock]) the documentation states: > By default the return value is actually a synchronized wrapper for the > object. [...] > If lock is True (the default) then a new lock object is created to > synchronize access to the value. If lock is a Lock or RLock object then that > will be used to synchronize access to the value. If lock is False then > access to the returned object will not be automatically protected by a lock, > so it will not necessarily be ?process-safe?. (By the way, I'm not sure why both, multiprocessing.Value and multiprocessing.sharedctypes.Value are documented. They appear to be the same thing.) The following tests (also attached as file) show that lost updates may occur if several instances of multiprocessing.Process increment the same Value that is passed as args parameter. def do_inc(integer): """Increment integer.value for multiprocessing.Value integer.""" integer.value += 1 def do_test(notasks): """Create notasks processes, each incrementing the same Value. As the Value is initialized to 0, its final value is expected to be notasks. """ tasks = list() integer = multiprocessing.sharedctypes.Value("i", 0) for run in range(notasks): proc = multiprocessing.Process(target=do_inc, args=(integer,)) proc.start() tasks.append(proc) for proc in tasks: proc.join() if integer.value != notasks: logging.error( "Unexpected value: %d (expected: %d)", integer.value, notasks) if __name__ == "__main__": do_test(100) Sample invocations and results: Note that on a single CPU machine the error is not reported for every execution but only for about every third run. $ python --version Python 2.6.5 $ uname -a Linux ubuntu-desktop 2.6.32.11+drm33.2 #2 Fri Jun 18 20:30:49 CEST 2010 i686 GNU/Linux $ python test_multiprocessing.py ERROR:root:Unexpected value: 99 (expected: 100) On a quadcore, the error occurs almost every time. $ uname -a Linux PC 2.6.35.13 #4 SMP Tue Dec 20 15:22:02 CET 2011 x86_64 GNU/Linux $ ~/local/Python-2.7.3/python test_multiprocessing.py ERROR:root:Unexpected value: 95 (expected: 100) $ ~/local/Python-3.3.0/python test_multiprocessing.py ERROR:root:Unexpected value: 86 (expected: 100) ---------- components: Library (Lib) files: test_multiprocessing.py messages: 180251 nosy: lechten priority: normal severity: normal status: open title: Lost updates with multiprocessing.Value type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file28782/test_multiprocessing.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 20:14:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Jan 2013 19:14:46 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1358622886.15.0.451483545836.issue15989@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for point, Stefan. And thanks Trent for his project. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 20:20:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Jan 2013 19:20:29 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358623229.16.0.681603591445.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The way expectedFailure is currently implemented (it's a decorator which knows nothing about test cases and test results, it only expects an exception to be raised by its callee), it's gonna be difficult to make it participate with subtests without breaking compatibility. (that said, I also think it's a useless feature) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 20:20:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 19 Jan 2013 19:20:43 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358623243.84.0.624075296553.issue16997@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 20:21:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 19 Jan 2013 19:21:43 +0000 Subject: [issue10535] Enable warnings by default in unittest In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za> Message-ID: <1358623303.25.0.332825071176.issue10535@psf.upfronthosting.co.za> Brett Cannon added the comment: I wouldn't backport; not worth it. Anyway, since I consider this bug closed I'm taking myself off the nosy list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 20:28:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Jan 2013 19:28:05 +0000 Subject: [issue16997] subtests In-Reply-To: <1358606971.41.0.253488148199.issue16997@psf.upfronthosting.co.za> Message-ID: <1358623525.3619.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > I think we're going to have to separate out two counts in the metrics > - the total number of tests (the current counts), and the total number > of subtests (the executed subtest blocks). This is a reasonable proposal. On the other hand, it was already the case that a single test could count for several failures (for example, an exception in the test method and another in tearDown). Therefore, I think it is independent from the subtest proposal and could be tackled separately (which would also help keep this issue focussed :-)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 20:33:43 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 19 Jan 2013 19:33:43 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358624023.2.0.864032578154.issue16507@psf.upfronthosting.co.za> Guido van Rossum added the comment: This works well enough (tested in old version of Tulip), right? What's holding it up? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 21:09:36 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Jan 2013 20:09:36 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358626176.15.0.636435907826.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch attached: - makes _SubTest a TestCase subclass - clarifies test skipping for subtests (skipTest() only skips the subtest) - makes expected failures work as expected by resorting to a thread-local storage hack ---------- Added file: http://bugs.python.org/file28783/subtests3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 21:11:48 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Jan 2013 20:11:48 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358626308.27.0.0790978743202.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch attached: - makes _SubTest a TestCase subclass - clarifies test skipping for subtests (skipTest() only skips the subtest) - makes expected failures work as expected by resorting to a thread-local storage hack ---------- Added file: http://bugs.python.org/file28784/subtests3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 21:13:34 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Jan 2013 20:13:34 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358626414.98.0.195491314924.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch attached: - makes _SubTest a TestCase subclass - clarifies test skipping for subtests (skipTest() only skips the subtest) - makes expected failures work as expected by resorting to a thread-local storage hack ---------- Added file: http://bugs.python.org/file28785/subtests3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 21:54:10 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 19 Jan 2013 20:54:10 +0000 Subject: [issue14340] Update embedded copy of expat - fix security & crash issues In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za> Message-ID: <1358628850.49.0.290086484378.issue14340@psf.upfronthosting.co.za> Benjamin Peterson added the comment: If you could apply this to 2.7, that'd be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 22:00:37 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Jan 2013 21:00:37 +0000 Subject: [issue16998] Lost updates with multiprocessing.Value In-Reply-To: <1358622837.13.0.603431337609.issue16998@psf.upfronthosting.co.za> Message-ID: <1358629237.86.0.447022678329.issue16998@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 22:00:51 2013 From: report at bugs.python.org (Sven Brauch) Date: Sat, 19 Jan 2013 21:00:51 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1358629251.6.0.422733739862.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Here's the next version which I hope to be somewhat complete now. vararg and kwarg are now of type arg, and I did all the changes which are required to make this possible. The ast tests pass. Do you prefer to have this as one large patch all together, or would you rather like to review (and apply) 3..4 patches split into the individual features I implemented? ---------- Added file: http://bugs.python.org/file28786/full3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 22:01:58 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 19 Jan 2013 21:01:58 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1358629318.1.0.614095028985.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Individual patches would be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 22:08:53 2013 From: report at bugs.python.org (Sven Brauch) Date: Sat, 19 Jan 2013 21:08:53 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1358629733.64.0.125751079898.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Alright, I'll be back with those shortly (as soon as I found out how to do this best with hg -- I'm used to git ;). I'll also sign the contributor agreement, that's no problem of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 22:36:56 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Jan 2013 21:36:56 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <3YpXR34RNxzSLW@mail.python.org> Roundup Robot added the comment: New changeset ee93a89b4e0f by Serhiy Storchaka in branch '2.7': Issue #15989: Fix possible integer overflow in str formatting as in unicode formatting. http://hg.python.org/cpython/rev/ee93a89b4e0f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 22:40:22 2013 From: report at bugs.python.org (florian-rathgeber) Date: Sat, 19 Jan 2013 21:40:22 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358631622.81.0.10169954249.issue16997@psf.upfronthosting.co.za> Changes by florian-rathgeber : ---------- nosy: -florian-rathgeber _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 22:57:12 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Sat, 19 Jan 2013 21:57:12 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1358632632.21.0.155131144362.issue1159051@psf.upfronthosting.co.za> Nadeem Vawda added the comment: I've reviewed the patch and posted some comments on Rietveld. > I doubt about backward compatibility. It's obvious that struct.error and TypeError are unintentional, and EOFError is purposed for this case. However users can catch undocumented but de facto exceptions and doesn't expect EOFError. I think it's fine for us to change it to raise EOFError in these cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 23:14:36 2013 From: report at bugs.python.org (Sven Brauch) Date: Sat, 19 Jan 2013 22:14:36 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1358633676.42.0.292390274043.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Okay, here they are. I'm not sure how to make hg include a commit message in the patch... 81299-extend-asdl.diff: Changes required to the ASDL framework, in order to allow attributes ( ... ) on a product 81300-change-var-kwargs.diff: Makes var/kwarg be instances of arg, and adds the lineno / col_offset attributes to arg. 81301-change-attr-ranges.diff: Changes power ranges as described in the first post of this report. All three patches include the corresponding changes to the unit tests, and hopefully the correct set of changes to the generated (Python-ast.h/.c) files. ---------- Added file: http://bugs.python.org/file28787/81299-extend-asdl.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 23:14:52 2013 From: report at bugs.python.org (Sven Brauch) Date: Sat, 19 Jan 2013 22:14:52 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1358633692.12.0.226787298478.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: second patch file ---------- Added file: http://bugs.python.org/file28788/81300-change-var-kwargs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 23:15:09 2013 From: report at bugs.python.org (Sven Brauch) Date: Sat, 19 Jan 2013 22:15:09 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1358633709.21.0.577226607689.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: third patch file (... is there a better way to upload three files?) ---------- Added file: http://bugs.python.org/file28789/81301-change-attr-ranges.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 23:18:08 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 19 Jan 2013 22:18:08 +0000 Subject: [issue16998] Lost updates with multiprocessing.Value In-Reply-To: <1358622837.13.0.603431337609.issue16998@psf.upfronthosting.co.za> Message-ID: <1358633888.74.0.0672288305869.issue16998@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I thought that access to the value field of Value instances was > protected by locks to avoid lost updates. Loads and stores are both atomic. But "+=" is made up of two operations, a load followed by a store, and the lock is dropped between the two. The same lack of atomicity applies when using "+=" to modify an attribute of a normal python object in a multithreaded program. If you want an atomic increment you could try def do_inc(integer): with integer.get_lock(): integer.value += 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 23:21:31 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Jan 2013 22:21:31 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1358634091.24.0.999080866335.issue16042@psf.upfronthosting.co.za> R. David Murray added the comment: Christian, do you want to try to complete this before the 2.7.4 RC? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 23:24:11 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Sat, 19 Jan 2013 22:24:11 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1358634251.87.0.567671967839.issue15955@psf.upfronthosting.co.za> Nadeem Vawda added the comment: > What if unconsumed_tail is not empty but less than needed to decompress at > least one byte? We need read more data until unconsumed_tail grow enought to > be decompressed. This is possible in zlib, but not in bz2. According to the manual [1], it is perfectly OK to supply one byte at a time. For xz, I'm not sure whether this problem could occur. I had assumed that it could not, but I may be mistaken ;-). Unfortunately liblzma has no proper manual, so I'll have to dig into the implementation to find out, and I haven't had the time to do this yet. [As an aside, it would be nice if the documentation for the zlib module mentioned this problem. We can't assume that users of the Python module are familiar with the C API for zlib...] [1] http://www.bzip.org/1.0.5/bzip2-manual-1.0.5.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 19 23:48:00 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 19 Jan 2013 22:48:00 +0000 Subject: [issue10535] Enable warnings by default in unittest In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za> Message-ID: <1358635680.54.0.482100337304.issue10535@psf.upfronthosting.co.za> Ezio Melotti added the comment: Agreed, closing. ---------- resolution: -> fixed stage: patch review -> status: open -> closed versions: +Python 3.2 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 01:36:59 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2013 00:36:59 +0000 Subject: [issue17000] Remove cruft from unittest docs Message-ID: <1358642170.4.0.68119991166.issue17000@psf.upfronthosting.co.za> New submission from Antoine Pitrou: There's a lot of obsolete or simply pointless cruft in the unittest docs, including references to the runTest method, or a detailed description of how to manually collect test suites. Following patch simplifies things a lot and makes the doc easier to read. ---------- assignee: docs at python components: Documentation files: unittest-doc-fix.patch keywords: patch messages: 180273 nosy: docs at python, ezio.melotti, michael.foord, pitrou priority: normal severity: normal stage: patch review status: open title: Remove cruft from unittest docs type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28791/unittest-doc-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 01:36:59 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2013 00:36:59 +0000 Subject: [issue16999] Remove cruft from unittest docs Message-ID: <1358642170.4.0.233806283226.issue16999@psf.upfronthosting.co.za> New submission from Antoine Pitrou: There's a lot of obsolete or simply pointless cruft in the unittest docs, including references to the runTest method, or a detailed description of how to manually collect test suites. Following patch simplifies things a lot and makes the doc easier to read. ---------- assignee: docs at python components: Documentation files: unittest-doc-fix.patch keywords: patch messages: 180274 nosy: docs at python, ezio.melotti, michael.foord, pitrou priority: normal severity: normal stage: patch review status: open title: Remove cruft from unittest docs type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28790/unittest-doc-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 04:51:39 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 03:51:39 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering Message-ID: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> New submission from Ramchandra Apte: This would reduce the complexity of uuid.UUID and also if the way it compares changes, one would't have to change all the compare methods. Attached is a patch. ---------- components: Library (Lib) files: issue.patch keywords: patch messages: 180275 nosy: ramchandra.apte priority: normal severity: normal status: open title: Make uuid.UUID use functools.total_ordering versions: Python 3.4 Added file: http://bugs.python.org/file28792/issue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 04:52:47 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 03:52:47 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358653967.37.0.869175939065.issue17001@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 06:16:44 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 05:16:44 +0000 Subject: [issue16557] PEP 380 isn't reflected in the Functional Programming HOWTO In-Reply-To: <1353931638.82.0.313274646017.issue16557@psf.upfronthosting.co.za> Message-ID: <1358659004.08.0.916553643782.issue16557@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Attached is a patch. Note that this is my first Doc patch; please apologize errors. ---------- keywords: +patch nosy: +ramchandra.apte Added file: http://bugs.python.org/file28793/issue16557.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 06:22:02 2013 From: report at bugs.python.org (Brian Curtin) Date: Sun, 20 Jan 2013 05:22:02 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358659322.48.0.289815900195.issue17001@psf.upfronthosting.co.za> Brian Curtin added the comment: Can you provide test cases for this code? ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 06:22:41 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 05:22:41 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358659361.72.0.989758638518.issue17001@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Yes, will do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 06:23:54 2013 From: report at bugs.python.org (Brian Curtin) Date: Sun, 20 Jan 2013 05:23:54 +0000 Subject: [issue16273] f.tell() returning negative number on Windows build In-Reply-To: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za> Message-ID: <1358659434.73.0.104704927469.issue16273@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 06:24:38 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 05:24:38 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358659478.34.0.774223016695.issue17001@psf.upfronthosting.co.za> Ramchandra Apte added the comment: @Brian Curtin It appears that there are tests for UUID ordering. [0] I will run the tests. [0] http://hg.python.org/cpython/file/d1e6a48dfb0d/Lib/test/test_uuid.py#l188 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 06:34:17 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 05:34:17 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358660057.29.0.412302021286.issue17001@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Damn, I forgot to add import functools. Here is a fixed version that passes test_uuid. ---------- Added file: http://bugs.python.org/file28794/issue-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 06:43:22 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 05:43:22 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1358660602.93.0.53628544852.issue13598@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Buump. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 09:54:47 2013 From: report at bugs.python.org (Jens Lechtenboerger) Date: Sun, 20 Jan 2013 08:54:47 +0000 Subject: [issue16998] Lost updates with multiprocessing.Value In-Reply-To: <1358622837.13.0.603431337609.issue16998@psf.upfronthosting.co.za> Message-ID: <1358672087.52.0.543971914898.issue16998@psf.upfronthosting.co.za> Jens Lechtenboerger added the comment: > Loads and stores are both atomic. But "+=" is made up of two operations, a load followed by a store, and the lock is dropped between the two. I see. Then this is a documentation bug. The examples in the documentation use such non-thread-safe assignments (combined with the statement "These shared objects will be process and thread safe."). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 11:20:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Jan 2013 10:20:48 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <3YpsLK2KYGzMvF@mail.python.org> Roundup Robot added the comment: New changeset 260a9afd999a by Ezio Melotti in branch '3.2': #4153: update the Unicode howto. http://hg.python.org/cpython/rev/260a9afd999a New changeset 572ca3d35c2f by Ezio Melotti in branch '3.3': #4153: merge with 3.2. http://hg.python.org/cpython/rev/572ca3d35c2f New changeset 034e1e076c77 by Ezio Melotti in branch 'default': #4153: merge with 3.3. http://hg.python.org/cpython/rev/034e1e076c77 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 11:31:46 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Jan 2013 10:31:46 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1358677906.8.0.939263914702.issue4153@psf.upfronthosting.co.za> Ezio Melotti added the comment: I committed the attached patch with some minor modifications, but there are still comments that should be addressed on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 11:54:01 2013 From: report at bugs.python.org (=?utf-8?q?Cillian_de_R=C3=B3iste?=) Date: Sun, 20 Jan 2013 10:54:01 +0000 Subject: [issue17002] html.entities ImportError in distutils2/pypi/simple.py on Python2.7 Message-ID: <1358679241.64.0.323379841838.issue17002@psf.upfronthosting.co.za> New submission from Cillian de R?iste: I guess it should be wrapped in a try, except: try: from html.entities import name2codepoint except ImportError: from htmlentitydefs import name2codepoint This works locally Here's a sample traceback: Traceback (most recent call last): File "python2nix.py", line 119, in egg_release = pypi.get_release(egg['name'] + '==' + version) File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 201, in get_release releases = self.get_releases(predicate, prefer_final) File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 189, in get_releases self._process_index_page(predicate.name) File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 75, in wrapped return func(self, *args, **kwargs) File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 397, in _process_index_page self._process_url(url, name) File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 320, in _process_url for link, is_download in link_matcher(f.read().decode(), base_url): File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 362, in _simple_link_matcher url = self._get_full_url(match.group(1), base_url) File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 349, in _get_full_url return urlparse.urljoin(base_url, self._htmldecode(url)) File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 469, in _htmldecode return ENTITY_SUB(self._decode_entity, text) File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 463, in _decode_entity from html.entities import name2codepoint ImportError: No module named html.entities ---------- assignee: eric.araujo components: Distutils2 messages: 180285 nosy: alexis, eric.araujo, goibhniu, tarek priority: normal severity: normal status: open title: html.entities ImportError in distutils2/pypi/simple.py on Python2.7 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 11:57:28 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 20 Jan 2013 10:57:28 +0000 Subject: [issue16998] Lost updates with multiprocessing.Value In-Reply-To: <1358622837.13.0.603431337609.issue16998@psf.upfronthosting.co.za> Message-ID: <1358679448.22.0.329808637303.issue16998@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I see. Then this is a documentation bug. The examples in the > documentation use such non-thread-safe assignments (combined with the > statement "These shared objects will be process and thread safe."). Are you talking about this documentation: If lock is True (the default) then a new lock object is created to synchronize access to the value. If lock is a Lock or RLock object then that will be used to synchronize access to the value. If lock is False then access to the returned object will not be automatically protected by a lock, so it will not necessarily be ?process-safe?. It only says that accesses are synchronized. The problem is that you were assuming that "+=" involves a single access -- but that is not how python works. Where in the examples is there "non-process-safe" access? (Note that waiting for the only process which modifies a value to terminate using join() will prevent races.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 12:12:09 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Jan 2013 11:12:09 +0000 Subject: [issue17002] html.entities ImportError in distutils2/pypi/simple.py on Python2.7 In-Reply-To: <1358679241.64.0.323379841838.issue17002@psf.upfronthosting.co.za> Message-ID: <1358680329.33.0.702737431141.issue17002@psf.upfronthosting.co.za> Ezio Melotti added the comment: htmlentitydefs was renamed to html.entities in Python 3. If this is supposed to run with Python 2 it should use the former, otherwise the latter (unless it has the same codebase on both). ---------- nosy: +ezio.melotti type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 12:51:52 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 11:51:52 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1358682712.39.0.465700907631.issue1159051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is an updated patch addressing Nadeem Vawda's comments. Thank you. ---------- Added file: http://bugs.python.org/file28795/gzip_eof-3.4_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 13:00:13 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 20 Jan 2013 12:00:13 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1358683213.72.0.258249216628.issue1159051@psf.upfronthosting.co.za> Nadeem Vawda added the comment: The updated patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 13:17:29 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 20 Jan 2013 12:17:29 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1358684249.79.0.514689723601.issue16997@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 14:03:20 2013 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 20 Jan 2013 13:03:20 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1358687000.07.0.307081706345.issue13598@psf.upfronthosting.co.za> Vinay Sajip added the comment: Looking at Phil Elson's patch: I didn't see a test case relating to the example in his comment, namely f.format("{0:{}}", 'foo', 5) Did I miss it? The documentation also needs to be updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 14:51:57 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 13:51:57 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358689917.77.0.643747133799.issue17001@psf.upfronthosting.co.za> Changes by Ramchandra Apte : Removed file: http://bugs.python.org/file28794/issue-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 14:54:19 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 20 Jan 2013 13:54:19 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358690059.55.0.0592580883623.issue17001@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Oh darn, I included another bugs changes in it. I unlinked the v2 patch and have attached issue17001-v2.patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 14:55:06 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 13:55:06 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358690106.57.0.944820871194.issue17001@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Except for mistakenly included functional.rst changes, the patch looks good for me. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 15:35:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Jan 2013 14:35:25 +0000 Subject: [issue16557] PEP 380 isn't reflected in the Functional Programming HOWTO In-Reply-To: <1353931638.82.0.313274646017.issue16557@psf.upfronthosting.co.za> Message-ID: <3Ypz2M6tVTzS9C@mail.python.org> Roundup Robot added the comment: New changeset e0de6e6e992e by Ezio Melotti in branch '3.3': #16557: update functional howto -- "return value" is valid after PEP 380. Initial patch by Ramchandra Apte. http://hg.python.org/cpython/rev/e0de6e6e992e New changeset 81b2a30da853 by Ezio Melotti in branch 'default': #16557: merge with 3.3. http://hg.python.org/cpython/rev/81b2a30da853 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 15:36:24 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Jan 2013 14:36:24 +0000 Subject: [issue16557] PEP 380 isn't reflected in the Functional Programming HOWTO In-Reply-To: <1353931638.82.0.313274646017.issue16557@psf.upfronthosting.co.za> Message-ID: <1358692584.35.0.0477525685229.issue16557@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report and the patch! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 15:36:51 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 14:36:51 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1358692611.54.0.313432988705.issue16042@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, I'm going to work on this issue for 2.7 and 3.3. ---------- assignee: -> christian.heimes priority: normal -> critical stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 15:37:35 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 14:37:35 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <1358692655.49.0.56046350168.issue16041@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> christian.heimes priority: normal -> critical stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 15:38:02 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 14:38:02 +0000 Subject: [issue16040] nntplib: unlimited readline() from connection In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za> Message-ID: <1358692682.27.0.182462231893.issue16040@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> christian.heimes priority: normal -> critical versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 15:38:25 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 14:38:25 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1358692705.92.0.855621711098.issue16039@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> christian.heimes priority: normal -> critical stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 15:38:44 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 14:38:44 +0000 Subject: [issue16038] ftplib: unlimited readline() from connection In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za> Message-ID: <1358692724.1.0.314604997031.issue16038@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> christian.heimes priority: normal -> critical stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 15:39:08 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 14:39:08 +0000 Subject: [issue16037] httplib: header parsing is not delimited In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za> Message-ID: <1358692748.65.0.979174376899.issue16037@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> christian.heimes priority: normal -> critical stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 16:14:03 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 15:14:03 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> Message-ID: <1358694843.16.0.275262833572.issue16043@psf.upfronthosting.co.za> Christian Heimes added the comment: The attached patch adds a limitation to xmlrpclib.gzip_decode(). ---------- assignee: -> christian.heimes dependencies: -gzip, bz2, lzma: add option to limit output size keywords: +patch priority: normal -> critical stage: -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file28796/xmlrpc_gzip_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 16:32:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 15:32:51 +0000 Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16) Message-ID: <1358695971.6.0.617355350009.issue1470548@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated. Now I?get rid of __del__ to prevent hanging on reference cicles as Antoine suggested on IRC. Added test for check that XMLGenerator doesn't close the file passed as argument. ---------- Added file: http://bugs.python.org/file28797/XMLGenerator-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 17:13:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 16:13:14 +0000 Subject: =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0and_readline=28?= =?utf-8?q?=29_argument_names?= Message-ID: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: read()?and readline() optional parameter which limit the amount of read data has different names in different classes. All this classes mimic (less or more) io classes. Keyword parameter name is a part of method specification. Therefore it will be good made all read() arguments names the same and all readline() arguments names the same (and be consistent with documentation and C implementation). At least we should choose most consistent name for new implementations. If existent C implementation of some method doesn't support keyword argument (all _io classes) or argument names in C and Python implementations are different then we are free to change this name without breaking existing code. For example, read()'s parameter named as: "n" in _pyio, zipfile, and io documentation; "size" in gzip, bz2, imaplib, tarfile, codecs, mailbox; "len"?in ssl; "wtd" or "totalwtd" in binhex; "amt" in http/client; "chars" in codecs; "buffersize" in os. readline()'s parameter named as: "limit" in _pyio, zipfile, and io documentation; "size" in gzip, bz2, codecs, mailbox, lzma. ---------- assignee: docs at python components: Documentation, IO, Library (Lib) messages: 180298 nosy: benjamin.peterson, christian.heimes, docs at python, hynek, pitrou, serhiy.storchaka, stutzbach priority: normal severity: normal status: open title: Unification of read()?and readline() argument names type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 17:15:16 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 16:15:16 +0000 Subject: [issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1? In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za> Message-ID: <1358698516.59.0.144460248297.issue7353@psf.upfronthosting.co.za> Christian Heimes added the comment: Go ahead! The intobject header file used to make porting to Python 3 easier. Nowadays it's no longer required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 17:22:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 16:22:49 +0000 Subject: =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0and_readline=28?= =?utf-8?q?=29_argument_names?= In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za> Message-ID: <1358698969.35.0.34348647691.issue17003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as size is most common parameter name for both read() and readline(). First, we can change the io documentation and _pyio signatures (it shouldn't break anything because _io doesn't support keyword arguments). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 17:45:58 2013 From: report at bugs.python.org (Catalin Iacob) Date: Sun, 20 Jan 2013 16:45:58 +0000 Subject: [issue16273] f.tell() returning negative number on Windows build In-Reply-To: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za> Message-ID: <1358700358.89.0.692643130361.issue16273@psf.upfronthosting.co.za> Catalin Iacob added the comment: Could it be that Raymond's file had Unix line endings? I tried to reproduce this, picked a file on my disk and indeed I got a negative number, but that file has Unix line endings. This is documented at http://docs.python.org/2/library/stdtypes.html#file.tell so probably there's nothing to do then. As for Armin's report in msg180145, even though it's not intuitive, this matches ftell's behavior on Windows, as documented in the Remarks section of http://msdn.microsoft.com/en-us/library/0ys3hc0b%28v=vs.100%29.aspx. The tell() method on fileobjects is explicitly documented as matching ftell behavior: "Return the file?s current position, like stdio?s ftell()". So even though it's not intuitive at all, it's probably better to leave it as is. tell() returns the intuitive non zero position when opening with 'a' on Python3 and on Python 2.7 when using io.open so it's fixed for the future anyway. ---------- nosy: +catalin.iacob _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 18:14:49 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2013 17:14:49 +0000 Subject: =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0and_readline=28?= =?utf-8?q?=29_argument_names?= In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za> Message-ID: <1358702089.07.0.69641910413.issue17003@psf.upfronthosting.co.za> Antoine Pitrou added the comment: "n" is the best choice IMO. "size" is ok too, although it may be confused with the byte-size of the result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 18:19:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 17:19:47 +0000 Subject: =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0and_readline=28?= =?utf-8?q?=29_argument_names?= In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za> Message-ID: <1358702387.65.0.392362553531.issue17003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which changes name of optional parameter of read(), read1(), peek(), and readline() methods to most common name "size" in the documentation and _pyio module. truncate() in _pyio fixed to conform with documentation. This changes are safe. There is open question about readlines(). It's optional parameter named as: "hint" in _pyio and the documentation; "size" in bz2; "sizehint" in codecs and mailbox. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file28798/io_parameter_names.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 18:21:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 17:21:36 +0000 Subject: =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0and_readline=28?= =?utf-8?q?=29_argument_names?= In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za> Message-ID: <1358702496.08.0.292000609221.issue17003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > "n" is the best choice IMO. Unfortunately most stdlib modules vote for "size". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 18:25:18 2013 From: report at bugs.python.org (Tres Seaver) Date: Sun, 20 Jan 2013 17:25:18 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1358702718.92.0.0561429623197.issue15881@psf.upfronthosting.co.za> Tres Seaver added the comment: I can reproduce the bug against the 2.7 tip. Reviewing the 2.7 patch: - The 2.7 tip has 'Misc/ACKS' instead of 'Doc/ACKS.txt'. - In 'Misc/ACKS', the line adding 'Chris McDonough' should add it in alpha order. - The remainder of the patch looks correct, and applies cleanly to the tip of the 2.7 branch. - After applying the patch to the 2.7 tip, I can no longer reproduce the bug. - After applying the patch, the full test suite ('./python -m test.testall -j3') passes all tests. ---------- nosy: +tseaver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 18:37:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 17:37:28 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1358703448.96.0.649552299422.issue16042@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: mock_socket violates readline() contract. It can return more than size bytes, and this can break SMTP.readline(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 19:41:42 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 20 Jan 2013 18:41:42 +0000 Subject: [issue17004] Expand zipimport to include other compression methods Message-ID: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Only a little of the existing logic is tied to the zipfile format. Consider adding support for xz, tar, tar.gz, tar.bz2, etc. In particular, xz has better compression, resulting in both space savings and faster load times. ---------- messages: 180307 nosy: rhettinger priority: normal severity: normal status: open title: Expand zipimport to include other compression methods type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 19:45:44 2013 From: report at bugs.python.org (Brian Curtin) Date: Sun, 20 Jan 2013 18:45:44 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> Message-ID: <1358707544.3.0.481106621597.issue17004@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- components: +Library (Lib) nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 20:20:51 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 20 Jan 2013 19:20:51 +0000 Subject: [issue17002] html.entities ImportError in distutils2/pypi/simple.py on Python2.7 In-Reply-To: <1358679241.64.0.323379841838.issue17002@psf.upfronthosting.co.za> Message-ID: <1358709651.01.0.321969397861.issue17002@psf.upfronthosting.co.za> ?ric Araujo added the comment: Good call. All function-level imports are avoided in d2 unless absolutely necessary, and this one slipped through the cracks. distutils2 went from Python 2 to 3 to 2 and 3 again, so these things happen (and it?s one of the reasons why I?ve always insisted on trying to keep as much history as possible in one repo). Will fix, as even though d2 will not continue to live as one monolithic project, the pypi submodule will certainly be extracted in a smaller lib reusable by other tools. ---------- stage: -> test needed versions: +3rd party -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 20:23:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 19:23:48 +0000 Subject: [issue8745] zipimport is a bit slow In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za> Message-ID: <1358709828.64.0.124108492755.issue8745@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 20:41:08 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 20 Jan 2013 19:41:08 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1358624023.2.0.864032578154.issue16507@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Oh, it needs a new patch -- the patch fails to apply in the 3.4 (default) branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 21:19:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 20:19:58 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> Message-ID: <1358713198.1.0.753955083483.issue17004@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: tar.* is not a good choice because it doesn't allow random access. Bare tar better than zip only in case when you need to save additional file attributes (Unix file access mode, times, owner, group, links). ZIP format supports all this too, but not zipfile module yet. Adding bz2 or lzma compression to ZIP file shouldn't be too hard. ---------- nosy: +nadeem.vawda, serhiy.storchaka stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 21:32:22 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 20:32:22 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> Message-ID: <1358713942.26.0.726763718766.issue17004@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are some tests. time 7z a -tzip -mx=0 python-0.zip $(find Lib -type f -name '*.py') >/dev/null time 7z a -tzip python.zip $(find Lib -type f -name '*.py') >/dev/null time 7z a -tzip -mx=9 python-9.zip $(find Lib -type f -name '*.py') >/dev/null time 7z a -tzip -mm=bzip2 python-bzip2.zip $(find Lib -type f -name '*.py') >/dev/null time 7z a -tzip -mm=bzip2 -mx=9 python-bzip2-9.zip $(find Lib -type f -name '*.py') >/dev/null time 7z a -tzip -mm=lzma python-lzma.zip $(find Lib -type f -name '*.py') >/dev/null time 7z a -tzip -mm=lzma -mx=9 python-lzma-9.zip $(find Lib -type f -name '*.py') >/dev/null time 7z t python-0.zip >/dev/null time 7z t python.zip >/dev/null time 7z t python-9.zip >/dev/null time 7z t python-bzip2.zip >/dev/null time 7z t python-bzip2-9.zip >/dev/null time 7z t python-lzma >/dev/null time 7z t python-lzma.zip >/dev/null time 7z t python-lzma-9.zip >/dev/null wc -c python*.zip Results: pack* unpack size time time (MB) store 0.5 0.2 19.42 deflate 6 0.4 4.59 deflate-max 40 0.4 4.52 bzip2 6 2.1 4.45 bzip2-max 79 2.0 4.39 lzma 37 0.7 4.42 lzma-max 62 0.7 4.39 *) For pack time I?take user time because 7-zip well parallelize deflate and bzip2 compression. As you can see, a size difference between maximal compression with different methods only 3%. lzma decompress almost twice slower then deflate, and bzip2 decompress 5 times slower. Python files are too small to get benefit from advanced compression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 21:40:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 20:40:58 +0000 Subject: [issue8745] zipimport is a bit slow In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za> Message-ID: <1358714458.51.0.197192579081.issue8745@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, Brian. Raymond is an initiator of issue17004. ---------- nosy: +rhettinger -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 21:47:05 2013 From: report at bugs.python.org (Trent Nelson) Date: Sun, 20 Jan 2013 20:47:05 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1358714825.25.0.600878847408.issue13405@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 21:54:27 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2013 20:54:27 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> Message-ID: <1358715267.0.0.0187565460952.issue17004@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Here are some tests. I think you want to put pyc files in the zip file as well. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:09:12 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 20 Jan 2013 21:09:12 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> Message-ID: <1358716152.65.0.994849351778.issue17004@psf.upfronthosting.co.za> Raymond Hettinger added the comment: xz will likely be the best win -- it is purported to compress smaller than bz2 while retaining the decompression speed of zip. As Antoine says, the usual practice is to add py, pyc, and pyo files to the compressed library; otherwise, there is an added cost with Python tries to write a missing pyc/pyo file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:09:14 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 20 Jan 2013 21:09:14 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358716154.25.0.617603989926.issue16507@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a new version of the patch. (Will test on Windows next.) ---------- Added file: http://bugs.python.org/file28799/runtime_wsapoll.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:12:24 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 20 Jan 2013 21:12:24 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358716344.09.0.868924936429.issue17001@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I recommend against this patch. The code generated by functools.total_ordering is less efficient than the existing code and it doesn't handle the NotImplemented logic very well. total_ordering() is a shortcut, not a best practice. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:35:06 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 20 Jan 2013 21:35:06 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358717706.19.0.445938908035.issue16507@psf.upfronthosting.co.za> Guido van Rossum added the comment: That compiles (after hacking the line endings). One Tulip test fails, PollEventLooptests.testSockClientFail. But that's probably because the PollSelector class hasn't been adjusted for Windows yet (need to dig this out of the Pollster code that was deleted when switching to neologix's Selector). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:35:09 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 20 Jan 2013 21:35:09 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358717709.5.0.172581296818.issue16507@psf.upfronthosting.co.za> Guido van Rossum added the comment: That compiles (after hacking the line endings). One Tulip test fails, PollEventLooptests.testSockClientFail. But that's probably because the PollSelector class hasn't been adjusted for Windows yet (need to dig this out of the Pollster code that was deleted when switching to neologix's Selector). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:39:12 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 20 Jan 2013 21:39:12 +0000 Subject: [issue17005] Add a topological sort algorithm Message-ID: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za> New submission from Raymond Hettinger: I suggest adding a topological sort algorithm to the standard library. In addition to being a fundamental algorithm, it is immediately useful in demonstrating how the MRO computation works and for pure Python implementations of MRO logic. IIRC, the pgen code was also expressed in pure Python for the same reason. I've attached a first-draft of the algorithm and an alternative that only implements a topological merge. This is just an early draft and there are a number of open points: * which module to put it in * a better implementation may be possible (perhaps using fewer dictionaries and sets). ---------- files: mro_merge.py messages: 180319 nosy: rhettinger priority: low severity: normal status: open title: Add a topological sort algorithm type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28800/mro_merge.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:40:27 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Jan 2013 21:40:27 +0000 Subject: [issue15050] Python 3.2.3 fail to make In-Reply-To: <1339488103.99.0.17701742584.issue15050@psf.upfronthosting.co.za> Message-ID: <1358718027.54.0.814273322922.issue15050@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm going to close this as out of date. Feel free to reopen if it turns out that this is indeed a Python issue. ---------- nosy: +ezio.melotti resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:48:33 2013 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Jan 2013 21:48:33 +0000 Subject: [issue17005] Add a topological sort algorithm In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za> Message-ID: <1358718513.83.0.520233208246.issue17005@psf.upfronthosting.co.za> Christian Heimes added the comment: Good idea! I'm using http://pypi.python.org/pypi/topsort/0.9 for a couple of years. The initial code was written by Tim Peters. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:54:51 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 20 Jan 2013 21:54:51 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358718891.82.0.584853974572.issue16507@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > That compiles (after hacking the line endings). One Tulip test fails, > PollEventLooptests.testSockClientFail. But that's probably because the > PollSelector class hasn't been adjusted for Windows yet (need to dig this > out of the Pollster code that was deleted when switching to neologix's > Selector). Sorry I did not deal with this earlier. I can make the modifications to PollSelector tommorrow. Just to describe the horrible hack: every time poll() needs to be called we first check if there are any registered async connects. If so then I first use select([], [], connectors) to detect any failed connections, and then use poll() normally. This does mean that to detect failed connections we must never use too large a timeout with poll() when there are outstanding connects. Of course one must decide what is an acceptable maximum timeout -- too short and you might damage battery life, too long and you will not get prompt notification of failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:55:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Jan 2013 21:55:40 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> Message-ID: <1358718940.0.0.114176676637.issue17004@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well. ./python -m compileall $(find Lib -type f -name '*.py') ./python -O -m compileall $(find Lib -type f -name '*.py') Tests: FILES="$(find Lib -name '*.py' -o -name '*.py[co]')" time 7z a -tzip -mx=0 python-0.zip $FILES >/dev/null time 7z a -tzip python.zip $FILES >/dev/null time 7z a -tzip -mx=9 python-9.zip $FILES >/dev/null time 7z a -tzip -mm=bzip2 python-bzip2.zip $FILES >/dev/null time 7z a -tzip -mm=bzip2 -mx=9 python-bzip2-9.zip $FILES >/dev/null time 7z a -tzip -mm=lzma python-lzma.zip $FILES >/dev/null time 7z a -tzip -mm=lzma -mx=9 python-lzma-9.zip $FILES >/dev/null time 7z t python-0.zip >/dev/null time 7z t python.zip >/dev/null time 7z t python-9.zip >/dev/null time 7z t python-bzip2.zip >/dev/null time 7z t python-bzip2-9.zip >/dev/null time 7z t python-lzma.zip >/dev/null time 7z t python-lzma-9.zip >/dev/null wc -c python*.zip Results: pack unpack size time time (MB) store 1.6 0.5 65.4 deflate 19 0.9 17.5 deflate-max 134 0.9 17.2 bzip2 21 4.2 16.5 bzip2-max 294 4.1 16.3 lzma 120 2.3 15.9 lzma-max 204 2.3 15.8 All numbers are about 3x larger. lzma-max is 8% less than deflate-max but 2.5 times slower. Bzip2 is out of the game. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 22:58:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Jan 2013 21:58:08 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358718940.0.0.114176676637.issue17004@psf.upfronthosting.co.za> Message-ID: <1358718932.3429.23.camel@localhost.localdomain> Antoine Pitrou added the comment: Agreed it doesn't look very promising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 23:03:04 2013 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 20 Jan 2013 22:03:04 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1358719384.55.0.461235574973.issue15881@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 23:05:01 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 20 Jan 2013 22:05:01 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1358718891.82.0.584853974572.issue16507@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Ow. How painful. I'll leave this for you to do. Note that this also requires separating EVENT_WRITE from EVENT_CONNECT -- I am looking into this now, but I am not sure how far I will get with this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 23:31:07 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Jan 2013 22:31:07 +0000 Subject: [issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1? In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za> Message-ID: <3Yq9bG5SFTzMjc@mail.python.org> Roundup Robot added the comment: New changeset 6df456f8fc6d by Stefan Krah in branch '3.3': Issue #7353: Remove references to Include/intobject.h in the C-porting howto. http://hg.python.org/cpython/rev/6df456f8fc6d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 23:33:00 2013 From: report at bugs.python.org (Stefan Krah) Date: Sun, 20 Jan 2013 22:33:00 +0000 Subject: [issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1? In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za> Message-ID: <1358721180.14.0.533000247745.issue7353@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.3, Python 3.4 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 23:42:35 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 20 Jan 2013 22:42:35 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: Message-ID: Guido van Rossum added the comment: (FWIW, I've got the EVENT_CONNECT separation done.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 20 23:45:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 20 Jan 2013 22:45:57 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358721957.27.0.919987384037.issue16507@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Time for a stupid question from someone who doesn't know anything about Windows: if WSAPoll() is really terminally broken, is it really worth the hassle exposing it and warping the API? AFAICT, FD_SETSIZE is already bumped to 512 on Windows, and Windows select() is limited by the fd_set size, not the maximum descriptor: so what exactly does WSAPoll() bring over select() on Windows? (Especially if there are plans to support IOCP, wouldn't that make WSAPoll() obsolete?) ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 00:28:41 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 20 Jan 2013 23:28:41 +0000 Subject: [issue17005] Add a topological sort algorithm In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za> Message-ID: <1358724521.1.0.395892255008.issue17005@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 02:13:40 2013 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 21 Jan 2013 01:13:40 +0000 Subject: [issue17005] Add a topological sort algorithm In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za> Message-ID: <1358730820.67.0.296628412887.issue17005@psf.upfronthosting.co.za> Eric V. Smith added the comment: +1 I'll note (by inspection only) your example code doesn't work under Python 3.x! :) (print as a statement) ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 09:48:02 2013 From: report at bugs.python.org (Christian Heimes) Date: Mon, 21 Jan 2013 08:48:02 +0000 Subject: [issue17006] Warn users about hashing secrets? Message-ID: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za> New submission from Christian Heimes: Lot's of people still think that something like sha512(secret + message), sha1(password + salt) or even sha1(password) is secure. Except it isn't. Most crypto hash functions like md5, sha1, sha2 family (sha256, sha384, sha512) use a Merkle?Damg?rd construction [1]. The construction is vulnerable to several attack vectors like length extension attacks. Passwords needs special care, too. I propose we add a warning to the documentation of hashlib. It's not the right place to teach cryptographics but it's a good place to raise attention. The warning should explain that you shouldn't solely hash secrets or messages containing a secret. For messages a MAC algorithm like HMAC should be used. For passwords a key stretching and key derivation function like PBKDF2, bcrypt or scrypt is much more secure. [1] http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction ---------- assignee: docs at python components: Documentation messages: 180330 nosy: christian.heimes, docs at python priority: normal severity: normal status: open title: Warn users about hashing secrets? type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 10:06:15 2013 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 21 Jan 2013 09:06:15 +0000 Subject: [issue17006] Warn users about hashing secrets? In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za> Message-ID: <1358759175.74.0.894702976601.issue17006@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I think since we ship cryptographic functions, we should take responsibility and warn against the most common mistakes people do. ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 10:06:53 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Jan 2013 09:06:53 +0000 Subject: [issue17006] Warn users about hashing secrets? In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za> Message-ID: <1358759213.85.0.719772579271.issue17006@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 10:46:20 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Jan 2013 09:46:20 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <3YqSZM6WJVzSNK@mail.python.org> Roundup Robot added the comment: New changeset 7625866f8127 by Serhiy Storchaka in branch '3.2': Issue #16335: Fix integer overflow in unicode-escape decoder. http://hg.python.org/cpython/rev/7625866f8127 New changeset 494d341e9143 by Serhiy Storchaka in branch '3.3': Issue #16335: Fix integer overflow in unicode-escape decoder. http://hg.python.org/cpython/rev/494d341e9143 New changeset 8488febf7d79 by Serhiy Storchaka in branch 'default': Issue #16335: Fix integer overflow in unicode-escape decoder. http://hg.python.org/cpython/rev/8488febf7d79 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 10:49:14 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Jan 2013 09:49:14 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <3YqSdj4JzFzSNf@mail.python.org> Roundup Robot added the comment: New changeset f4d30d1a529e by Serhiy Storchaka in branch '2.7': Issue #16335: Fix integer overflow in unicode-escape decoder. http://hg.python.org/cpython/rev/f4d30d1a529e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 10:51:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Jan 2013 09:51:30 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <1358761890.39.0.973509986951.issue16335@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I?rewrote the test in EAFP?style. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 11:30:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Jan 2013 10:30:09 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358764209.52.0.662679710304.issue16957@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 12:06:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Jan 2013 11:06:21 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <3YqVLh21MTzSCc@mail.python.org> Roundup Robot added the comment: New changeset f84a6c89ccbc by Serhiy Storchaka in branch '3.2': Fix memory error in test_ucn. http://hg.python.org/cpython/rev/f84a6c89ccbc New changeset 7c2aae472b27 by Serhiy Storchaka in branch '3.3': Fix memory error in test_ucn. http://hg.python.org/cpython/rev/7c2aae472b27 New changeset f90d6ce49772 by Serhiy Storchaka in branch 'default': Fix memory error in test_ucn. http://hg.python.org/cpython/rev/f90d6ce49772 New changeset 38a10d0778d2 by Serhiy Storchaka in branch '2.7': Fix memory error in test_ucn. http://hg.python.org/cpython/rev/38a10d0778d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 12:16:04 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2013 11:16:04 +0000 Subject: [issue17006] Warn users about hashing secrets? In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za> Message-ID: <1358766964.96.0.0366488975918.issue17006@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 12:36:42 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2013 11:36:42 +0000 Subject: [issue16038] ftplib: unlimited readline() from connection In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za> Message-ID: <1358768202.2.0.671801139287.issue16038@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 12:36:49 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2013 11:36:49 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1358768209.78.0.559239781318.issue16042@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 12:37:11 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2013 11:37:11 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1358768231.87.0.65272517652.issue16039@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 12:37:14 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2013 11:37:14 +0000 Subject: [issue16040] nntplib: unlimited readline() from connection In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za> Message-ID: <1358768234.87.0.319434462137.issue16040@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 12:37:27 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Jan 2013 11:37:27 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <1358768247.76.0.87582707081.issue16041@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 13:55:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Jan 2013 12:55:02 +0000 Subject: [issue16822] execv (et al.) should invoke atexit handlers before executing new code In-Reply-To: <1356907108.89.0.568486797575.issue16822@psf.upfronthosting.co.za> Message-ID: <1358772902.5.0.808153338808.issue16822@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Charles-Fran?ois, this is a too risky change. However, we could definitely have a separate "atexec" handler, like the "atfork" handlers which are proposed in issue16500. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 13:57:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Jan 2013 12:57:37 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1358773057.92.0.434876682777.issue16993@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 14:04:15 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Jan 2013 13:04:15 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <3YqXyl04KyzR4P@mail.python.org> Roundup Robot added the comment: New changeset d2db601a53b3 by Serhiy Storchaka in branch '3.3': Issue #16993: shutil.which() now preserves the case of the path and extension http://hg.python.org/cpython/rev/d2db601a53b3 New changeset 5faae2bdf1e0 by Serhiy Storchaka in branch 'default': Issue #16993: shutil.which() now preserves the case of the path and extension http://hg.python.org/cpython/rev/5faae2bdf1e0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 14:14:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Jan 2013 13:14:57 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1358774097.09.0.93861417741.issue16993@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 14:23:51 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 21 Jan 2013 13:23:51 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358774631.2.0.0737492953551.issue17001@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Performance info using the attached program: ~2.5 sec, original ~3.5 sec, patched (patched version is 40% slower) Is anybody doing the comparison in performance-critical cases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 14:25:48 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 21 Jan 2013 13:25:48 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358716344.09.0.868924936429.issue17001@psf.upfronthosting.co.za> Message-ID: Ramchandra Apte added the comment: On 21 January 2013 02:42, Raymond Hettinger wrote: > NotImplemented Can you please elaborate on "it doesn't handle the NotImplemented logic very well". AFAIK both will give NotImplemented for the same values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 14:30:58 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 21 Jan 2013 13:30:58 +0000 Subject: [issue17006] Warn users about hashing secrets? In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za> Message-ID: <1358775058.51.0.895147119361.issue17006@psf.upfronthosting.co.za> Ramchandra Apte added the comment: +1 "Better to be safe than sorry" ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 14:51:49 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 21 Jan 2013 13:51:49 +0000 Subject: [issue17006] Warn users about hashing secrets? In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za> Message-ID: <1358776309.14.0.576643364189.issue17006@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 14:54:36 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 21 Jan 2013 13:54:36 +0000 Subject: [issue16699] Mountain Lion buildbot lacks disk space In-Reply-To: <1355675210.52.0.0088069164146.issue16699@psf.upfronthosting.co.za> Message-ID: <1358776476.16.0.838797029639.issue16699@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Invalid. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 15:50:38 2013 From: report at bugs.python.org (Jens Lechtenboerger) Date: Mon, 21 Jan 2013 14:50:38 +0000 Subject: [issue16998] Lost updates with multiprocessing.Value In-Reply-To: <1358622837.13.0.603431337609.issue16998@psf.upfronthosting.co.za> Message-ID: <1358779838.19.0.563422075024.issue16998@psf.upfronthosting.co.za> Jens Lechtenboerger added the comment: > It only says that accesses are synchronized. The problem is that you were assuming that "+=" involves a single access -- but that is not how python works. Yes, I understand that by now (actually since your first comment). > Where in the examples is there "non-process-safe" access? (Note that waiting for the only process which modifies a value to terminate using join() will prevent races.) In section "The multiprocessing.sharedctypes module" the assignments in the first example (function modify()) are unsafe. None of them is protected by a lock as suggested in your first comment. Strictly speaking, no lock is necessary in the example as there are no race conditions (the processes work in an alternating fashion without concurrency). I certainly did not see that the example (for a *shared* memory data structure) is based on the implicit assumption of a single writer. In contrast, I assumed that some "magic" should offer process-safe usage of "+=", which made me file this bug. That assumption has turned out to be wrong. To prevent others from being mislead in the same way I suggest to either protect those operations with locks (and comment on their effect) or to state the implicit assumption explicitly. Maybe add the following after "Below is an example where a number of ctypes objects are modified by a child process:" Note that assignments such n.value **= 2 are not executed atomically but involve two operations, a load followed by a store. Each of these operations is protected by the Value's lock, which is dropped in between. Thus, in scenarios with concurrent modifying processes you may want to explicitly acquire the Value's lock to ensure atomic execution (avoiding race conditions and lost updates), e.g.: with n.get_lock(): n.value **= 2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 18:31:40 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 21 Jan 2013 17:31:40 +0000 Subject: [issue17007] logging documentation clarifications Message-ID: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Here are some suggestions of things to clarify in the logging documentation after consulting it as an end-user: 1. Clarify in Logger.filter(), Handler.filter(), and probably also in the Filter section that the case of more than filter behaves as follows: filters are applied until a filter says the record should not be processed. In particular, a record gets processed only if all filters say it should be processed rather than at least one. This is especially worth clarifying because with the above behavior combined with the Filter class's default behavior, it never makes sense to add more than one filter (because you can replace a group of filters with their lowest common ancestor). It's only needed with custom filters. 2. Clarify that a handler can log the same record multiple times if it is attached to an ancestor logger. This clarification perhaps best goes in the Logger.propagate section. Currently, it's not clear whether loggers/handlers are "smart" in the sense that they keep track of whether a given message has already been passed to a given handler (independent of what loggers it is attached to): "Logger.propagate: If this evaluates to true, logging messages are passed by this logger and by its child loggers to the handlers of higher level (ancestor) loggers." Incidentally, is there any case where you would want the same handler to process the same record more than once? 3. Clarify in the LogRecord section that the "name" attribute refers to the name of the logger used in the end-user's code rather than the name of the logger handling the message. In particular, a record logged by a logger and an ancestor logger will have the same "name" field for both. 4. Clarify the last part of this sentence: "Note that filters attached to handlers are consulted whenever an event is emitted by the handler, whereas filters attached to loggers are consulted whenever an event is logged to the handler (using debug(), info(), etc.)" It should say something like, "whereas filters attached to loggers are consulted prior to sending an event to its handlers." In particular, there can be more than one handler, and it happens before rather than after being logged to the handlers ("whenever" is somewhat ambiguous). ---------- assignee: docs at python components: Documentation keywords: easy messages: 180344 nosy: chris.jerdonek, docs at python, vinay.sajip priority: normal severity: normal status: open title: logging documentation clarifications type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 18:38:50 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 21 Jan 2013 17:38:50 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358789930.53.0.0249198701676.issue16507@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is a very good question to which I have no good answer. If it weren't for this, we could probably do away with the distinction between add_writer and add_connector, and a lot of code could be simpler. (Or is that distinction also needed for IOCP?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 18:49:12 2013 From: report at bugs.python.org (stuart) Date: Mon, 21 Jan 2013 17:49:12 +0000 Subject: [issue17008] Descriptor __get__() invoke is bypassed in the class context Message-ID: <1358790552.82.0.446038520087.issue17008@psf.upfronthosting.co.za> New submission from stuart: I emulated a real classmethod using python: class cm(object): def __init__(self, o): self.o = o def __get__(self, obj, type=None): return self.o.__get__(obj, type) then I check whether it is workable in the interactive mode and it is working: Python 2.7.3 (default, Sep 26 2012, 21:53:58) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def foo(cls): ... print cls ... >>> cm = cm(foo) >>> cm.__get__(int, type) > then I tried it in the real class but it failed: >>> class C(object): ... @cm ... def foo(cls): ... print cls ... >>> C.foo ---------- components: None messages: 180346 nosy: Stuart priority: normal severity: normal status: open title: Descriptor __get__() invoke is bypassed in the class context type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 19:00:53 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 21 Jan 2013 18:00:53 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> Message-ID: <1358791253.18.0.728872232406.issue17004@psf.upfronthosting.co.za> Brett Cannon added the comment: So this seems like a confluence of both supporting compressed files for loading source code as well as supporting new archive formats (e.g. xz vs. tar); zip just happens to do both implicitly. And there is also the question of if you explicitly plan to do this in C code or in pure Python as I plan to introduce a pure Python version of zipimport into importlib for 3.4 so that it can use zipfile directly and thus all of its full support of zipfile abilities. And there doesn't have to be any performance cost in trying to write bytecode files; it's very simple to have a loader which simply skips that step entirely. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 19:30:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Jan 2013 18:30:04 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <3YqhBh1WLDzMgv@mail.python.org> Roundup Robot added the comment: New changeset ec3a35ab3659 by Serhiy Storchaka in branch '2.7': Add bigmemtest decorator to test of issue #16335. http://hg.python.org/cpython/rev/ec3a35ab3659 New changeset 6e0c3e4136b1 by Serhiy Storchaka in branch '3.2': Add bigmemtest decorator to test of issue #16335. http://hg.python.org/cpython/rev/6e0c3e4136b1 New changeset 0e622d2cbcf8 by Serhiy Storchaka in branch '3.3': Use bigmemtest decorator for test of issue #16335. http://hg.python.org/cpython/rev/0e622d2cbcf8 New changeset cdd1e60d31e5 by Serhiy Storchaka in branch 'default': Use bigmemtest decorator for test of issue #16335. http://hg.python.org/cpython/rev/cdd1e60d31e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 19:40:31 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 21 Jan 2013 18:40:31 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1358789930.53.0.0249198701676.issue16507@psf.upfronthosting.co.za> Message-ID: <50FD8B93.8030407@gmail.com> Richard Oudkerk added the comment: On 21/01/2013 5:38pm, Guido van Rossum wrote: > This is a very good question to which I have no good answer. > If it weren't for this, we could probably do away with the distinction > between add_writer and add_connector, and a lot of code could be > simpler. (Or is that distinction also needed for IOCP?) The distinction is not needed by IOCP. I am also not too sure that running tulip on WSAPoll() is a good idea, even if the select module provides it. OFF-TOPIC: Although it is not the optimal way of running tulip with IOCP, I have managed to implement IocpSelector and IocpSocket classes well enough to pass tulip's unittests (except for the ssl one). I did have to make some changes to the tests: selectors have a wrap_socket() method which prepares a socket for use with the selector. On Unix it just returns the socket unchanged, whereas for IocpSelector it returns an IocpSocket wrapper. I also had to make the unittests behave gracefully if there is a "spurious wakeup", i.e. the socket is reported as readable, but trying to read fails with BlockingIOError. (Spurious wakeups are possible but very rare with select() etc.) It would be possible to make IocpSelector deal with pipe handles too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 20:00:18 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 21 Jan 2013 19:00:18 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <50FD8B93.8030407@gmail.com> Message-ID: Guido van Rossum added the comment: Thanks -- I am now close to rejecting the WSAPoll() patch, and even closer to rejecting its use for Tulip on Windows. That would in turn mean that we should kill add/remove_connector() and also the EVENT_CONNECT flag in selector.py. Anyone not in favor please speak up! Regarding your IOCP changes, that sounds pretty exciting. Richard, could you check those into the Tulip as a branch? (Maybe a new branch named 'iocp'.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 20:06:18 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 21 Jan 2013 19:06:18 +0000 Subject: [issue17008] Descriptor __get__() invoke is bypassed in the class context In-Reply-To: <1358790552.82.0.446038520087.issue17008@psf.upfronthosting.co.za> Message-ID: <1358795178.02.0.604444879356.issue17008@psf.upfronthosting.co.za> Benjamin Peterson added the comment: If you want to emulate classmethod, calling __get__() on the function is the wrong thing to do. f.__get__(None, X) -> f You need to create a bound yourself instead. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 20:46:32 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Jan 2013 19:46:32 +0000 Subject: [issue17007] logging documentation clarifications In-Reply-To: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za> Message-ID: <3Yqjtw1KhTzP30@mail.python.org> Roundup Robot added the comment: New changeset 871519e1f146 by Vinay Sajip in branch '2.7': Issue #17007: Improved logging documentation based on suggestions in the issue. http://hg.python.org/cpython/rev/871519e1f146 New changeset 029785354dbc by Vinay Sajip in branch '3.2': Issue #17007: Improved logging documentation based on suggestions in the issue. http://hg.python.org/cpython/rev/029785354dbc New changeset 1902e86dbb88 by Vinay Sajip in branch '3.3': Issue #17007: Merged doc update from 3.2. http://hg.python.org/cpython/rev/1902e86dbb88 New changeset 6110ed94f86d by Vinay Sajip in branch 'default': Closes #17007: Merged doc update from 3.3. http://hg.python.org/cpython/rev/6110ed94f86d ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 20:51:22 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 21 Jan 2013 19:51:22 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: Message-ID: <50FD9C2E.4020001@gmail.com> Richard Oudkerk added the comment: On 21/01/2013 7:00pm, Guido van Rossum wrote: > Regarding your IOCP changes, that sounds pretty exciting. Richard, > could you check those into the Tulip as a branch? (Maybe a new branch > named 'iocp'.) OK. It may take me a while to rebase them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 20:53:35 2013 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 21 Jan 2013 19:53:35 +0000 Subject: [issue17007] logging documentation clarifications In-Reply-To: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za> Message-ID: <1358798015.06.0.25326115035.issue17007@psf.upfronthosting.co.za> Vinay Sajip added the comment: Your suggestions are good, and I implemented them more or less as you suggested. Additional comments: > it never makes sense to add more than one filter Except for readability. Although in theory one filter could do the work of several, it may be that different filters are added independently from configurations based on particular requirements. > Clarify that a handler can log the same record multiple times I've mentioned this as *emit* the same record multiple times. > Incidentally, is there any case where you would want the same handler to process the same record more than once? I can't think why you'd ever want this - it would just duplicate information in the log output. > Clarify in the LogRecord section that the "name" attribute refers to the name of the logger used in the end-user's code I think that part is clear enough by saying that it's the name of the logger used to log the event, but I've added a rider that this is so even when the event is emitted by a handler attached to an ancestor logger. > Clarify the last part of this sentence: "Note that filters attached to handlers are consulted ..." Done, this should now be clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 21:20:22 2013 From: report at bugs.python.org (Ned Batchelder) Date: Mon, 21 Jan 2013 20:20:22 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed Message-ID: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> New submission from Ned Batchelder: Sorry if this is the wrong bug tracker for this issue. Someone just asked in #python what they should do about the fact that Python has no threads on the Mac. When asked why they thought that, they pointed to this: http://www.python.org/doc/essays/threads.html This essay is undated and unsigned, and is out of date. It should be removed from the site, or significantly edited, or at least marked at the top as "For Historical Interest Only." ---------- components: None messages: 180355 nosy: nedbat priority: normal severity: normal status: open title: "Thread Programming With Python" should be removed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 21:22:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Jan 2013 20:22:00 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> Message-ID: <1358799720.8.0.796605492753.issue17009@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think these files are outside of the CPython doc tree, they are probably static files on the server. That said, I agree it would be good to either add the "deprecated, kept only for historical purposes" note at the top of every file there, or simply remove them. ---------- assignee: -> docs at python components: +Documentation -None nosy: +docs at python, ezio.melotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 21:40:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Jan 2013 20:40:37 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1358800837.18.0.79227555805.issue16993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Test broken on Windows because PATHEXT contains uppercased extension ".EXT". Proposed solutions: 1. Fix the test: expect uppercased extension, or do case-insensitive extension comparison, or get extension from PATHEXT. 2. Rollback the part of previous changes which preserve case of extensions from PATHEXT and always lowercase them. 3. Rollback the changes overall. 4. Use not used for now ntpath._getfinalpathname() to get a real file name (it resolves symlinks, though). ---------- nosy: +pitrou resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 21:41:56 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 21 Jan 2013 20:41:56 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: Message-ID: <50FDA808.1080005@gmail.com> Richard Oudkerk added the comment: I have created an iocp branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 21:42:55 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 21 Jan 2013 20:42:55 +0000 Subject: [issue17007] logging documentation clarifications In-Reply-To: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za> Message-ID: <1358800975.29.0.070530137407.issue17007@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Great, that looks a lot better. Thanks! A couple comments though: + .. note:: If you attach a handler to several loggers, it may emit the same + record multiple times. In general, you should not need to attach a + handler to more than one logger - if you just attach it to the + appropriate logger which is highest in the logger hierarchy, then it + will see all events logged by all descendant loggers, provided that + their propagate setting is left set to ``True``. A common scenario is to + attach handlers only to the root logger, and let propagation take care of + the rest. Would it be better to say something like, "If you attach a handler to a logger and one of its ancestors [and similar changes later]..." The reason I ask is that it seems like there is a valid use case for attaching a handler to more than one logger (which I have used), which is if the loggers aren't in the same ancestry chain. For example, if I want loggers "app1" and "app2" to log and nothing else, I could attach a StreamHandler to those two loggers and a NullHandler to the root logger. It seems like the above would discourage that pattern. Or is that not recommended? (I suppose you could also do this using a custom filter by name on the root logger, though I don't know which technique is preferred.) > it never makes sense to add more than one filter Here I was referring to the restricted case of using default filters by name. For example, it seems like it would never make sense to filter by "A.B" and "A.C" because that is just an obfuscated way of filtering by the simpler and equivalent "A." Does that make sense? (I'm not suggesting any changes to the docs in this comment.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 21:55:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 21 Jan 2013 20:55:57 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <50FDA808.1080005@gmail.com> Message-ID: Charles-Fran?ois Natali added the comment: > I have created an iocp branch. You could probably report the fixes for spurious notifications in the default branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 21 22:58:44 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Jan 2013 21:58:44 +0000 Subject: [issue17007] logging documentation clarifications In-Reply-To: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za> Message-ID: <3YqmqS2nTszPRY@mail.python.org> Roundup Robot added the comment: New changeset 8de6f92c89e6 by Vinay Sajip in branch '2.7': Issue #17007: Made minor changes to documentation wording. http://hg.python.org/cpython/rev/8de6f92c89e6 New changeset c8614ec54a63 by Vinay Sajip in branch '3.2': Issue #17007: Made minor changes to documentation wording. http://hg.python.org/cpython/rev/c8614ec54a63 New changeset d0e9f64bd55c by Vinay Sajip in branch '3.3': Issue #17007: Merged minor changes from 3.2. http://hg.python.org/cpython/rev/d0e9f64bd55c New changeset 6877957a5e91 by Vinay Sajip in branch 'default': Issue #17007: Merged minor changes from 3.3. http://hg.python.org/cpython/rev/6877957a5e91 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 00:57:37 2013 From: report at bugs.python.org (Bryan G. Olson) Date: Mon, 21 Jan 2013 23:57:37 +0000 Subject: [issue17010] Windows launcher ignores active virtual environment Message-ID: <1358812657.25.0.839528896034.issue17010@psf.upfronthosting.co.za> New submission from Bryan G. Olson: Python 3.3 includes PEP 397, a Python launcher for Windows, and PEP 405, virtual environment support in core. Unfortunately the Windows launcher does not respect virtual environments. Even with with a virtual environment activated and the current directory at the virtual environment's root, the Windows launcher will start python with the system environment, not the active virtual environment. To demo: Install python 3.3 for windows. Create a virtual environment: C:\>c:\Python33\Tools\Scripts\pyvenv.py c:\virtpy Activate the virtual environment: C:\>virtpy\Scripts\activate.bat (virtpy) C:\> Optionally cd to the virtual environment: (virtpy) C:\>cd virtpy (virtpy) C:\virtpy> Start Python 3 with the new windows launcher: (virtpy) C:\virtpy>py -3 Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> Check sys.path >>> import sys >>> >>> sys.path ['', 'C:\\Windows\\system32\\python33.zip', 'C:\\bin\\Python33\\DLLs', 'C:\\bin\\Python33\\lib', 'C:\\bin\\Python33', 'C:\\bin\\Python33\\lib\\site-packages'] >>> The worst effect I've found is that installation of a package with windows launcher, "py -3 setup.py install", will ignore the active virtual environment and will change the system Python environment. That's bad because users frequently employ virtual environments to isolate changes that could damage a system configuration. ---------- components: Installation, Windows messages: 180362 nosy: bryangeneolson priority: normal severity: normal status: open title: Windows launcher ignores active virtual environment type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 02:11:56 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 01:11:56 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> Message-ID: <1358817116.4.0.0237436017677.issue17009@psf.upfronthosting.co.za> Ezio Melotti added the comment: Given that the note at the top says that it's an unfinished draft, I think removing it would be fine. It might be nice to see if there's anything still relevant that could be moved to the official docs, and possibly find out who wrote it and if he's ok with the removal. ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 05:03:09 2013 From: report at bugs.python.org (Ned Deily) Date: Tue, 22 Jan 2013 04:03:09 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> Message-ID: <1358827389.32.0.927264246194.issue17009@psf.upfronthosting.co.za> Ned Deily added the comment: It's included in a directory of Guido's essays (http://www.python.org/doc/essays/). Guido, any thoughts about this and the others? ---------- nosy: +gvanrossum, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 06:09:18 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 05:09:18 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> Message-ID: <1358831358.57.0.295702595668.issue17009@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'd like to keep the essay around as a permalink, but I don't object against putting some red text at the top warning people is is horribly out of date, and linking to a better tutorial. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 08:13:46 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Jan 2013 07:13:46 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358838826.32.0.0907757364053.issue17001@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 08:16:24 2013 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 22 Jan 2013 07:16:24 +0000 Subject: [issue17011] ElementPath ignores different namespace mappings for the same path expression Message-ID: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za> New submission from Stefan Behnel: There's a bug originally report for lxml that also applies to ElementTree: https://github.com/lxml/lxml/issues/95 Passing different namespace mappings into the Element.find*() methods will always reuse the first one due to incorrect caching based only on the literal path, not all parameters. My fix is here: https://github.com/lxml/lxml/commit/8bafbdc13ffb4fb8436eda01594780aac4735528 The lookup performance regression when a namespace mapping is passed (sorting etc.) is acceptable as most use cases won't pass any namespaces anyway, so this is a problem that rarely shows in practice. ---------- components: XML messages: 180366 nosy: scoder priority: normal severity: normal status: open title: ElementPath ignores different namespace mappings for the same path expression type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 08:16:36 2013 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 22 Jan 2013 07:16:36 +0000 Subject: [issue17011] ElementPath ignores different namespace mappings for the same path expression In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za> Message-ID: <1358838996.24.0.758360448268.issue17011@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- components: +Library (Lib) -XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 08:16:47 2013 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 22 Jan 2013 07:16:47 +0000 Subject: [issue17011] ElementPath ignores different namespace mappings for the same path expression In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za> Message-ID: <1358839007.85.0.376485286486.issue17011@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- components: +XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 08:25:12 2013 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 22 Jan 2013 07:25:12 +0000 Subject: [issue17011] ElementPath ignores different namespace mappings for the same path expression In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za> Message-ID: <1358839512.98.0.567398535802.issue17011@psf.upfronthosting.co.za> Stefan Behnel added the comment: Here is a test case (for lxml): https://github.com/lxml/lxml/commit/76f2ee991afd15d4f8c98cee3e095967bbf9937f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 08:39:34 2013 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 22 Jan 2013 07:39:34 +0000 Subject: [issue11379] Remove "lightweight" from minidom description In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za> Message-ID: <1358840374.33.0.757265423368.issue11379@psf.upfronthosting.co.za> Stefan Behnel added the comment: I'm not sure if it's a good idea to keep bikeshedding about this for another two years. Personally, I would prefer having someone with commit rights fix this and be done with it. Eric's last patch looks ok and parts of it went in already, so it's mostly just the heading that remains to be fixed. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 08:59:36 2013 From: report at bugs.python.org (Marc Schlaich) Date: Tue, 22 Jan 2013 07:59:36 +0000 Subject: [issue8858] socket.getaddrinfo returns wrong results for IPv6 addresses In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za> Message-ID: <1358841576.31.0.916214356552.issue8858@psf.upfronthosting.co.za> Marc Schlaich added the comment: I get the same result from `getaddrinfo` if Python is compiled with `--disable-ipv6`. Is this the correct behaviour? I would expect no IP v6 address at all. Python 2.5.6 (r256:88840, Jan 22 2013, 08:41:04) [GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.has_ipv6 False >>> socket.getaddrinfo(None, 9966, socket.AF_UNSPEC, socket.SOCK_STREAM, 0, socket.AI_PASSIVE) [(2, 1, 6, '', ('0.0.0.0', 9966)), (10, 1, 6, '', (10, '&\xee\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'))] ---------- nosy: +schlamar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 09:29:06 2013 From: report at bugs.python.org (Marc Schlaich) Date: Tue, 22 Jan 2013 08:29:06 +0000 Subject: [issue8858] socket.getaddrinfo returns wrong results for IPv6 addresses In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za> Message-ID: <1358843346.75.0.914461640219.issue8858@psf.upfronthosting.co.za> Marc Schlaich added the comment: Ok, I found #16208, just ignore me :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 09:33:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Jan 2013 08:33:23 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <3Yr2vk6HBzzQlT@mail.python.org> Roundup Robot added the comment: New changeset 28282e4e9d04 by Serhiy Storchaka in branch '3.3': Fix shutil.which() test for issue #16993. http://hg.python.org/cpython/rev/28282e4e9d04 New changeset e8f40d4f497c by Serhiy Storchaka in branch 'default': Fix shutil.which() test for issue #16993. http://hg.python.org/cpython/rev/e8f40d4f497c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 09:37:51 2013 From: report at bugs.python.org (Marc Schlaich) Date: Tue, 22 Jan 2013 08:37:51 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1358843871.24.0.383673427118.issue16208@psf.upfronthosting.co.za> Marc Schlaich added the comment: I agree with schmir, this is really unexpected behavior. At least it should be fixed in the documentation. The doc currently says you get a 4-tuple for IPv6, which is just wrong in this case. Prominent library stumbled about this issue is Tornado (https://github.com/facebook/tornado/pull/670) and there are likely more. ---------- nosy: +schlamar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 09:52:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Jan 2013 08:52:56 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1358844776.48.0.320437274647.issue16993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I chose the first simplest variant. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 10:07:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Jan 2013 09:07:34 +0000 Subject: [issue17011] ElementPath ignores different namespace mappings for the same path expression In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za> Message-ID: <1358845654.87.0.382532206896.issue17011@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 11:51:48 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 10:51:48 +0000 Subject: [issue11379] Remove "lightweight" from minidom description In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za> Message-ID: <1358851908.78.0.492115210702.issue11379@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Someone should go ahead and apply this. ?ric, perhaps? ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:11:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Jan 2013 12:11:37 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358856697.14.0.244709671555.issue16957@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have reorganized tests a little. ---------- assignee: -> serhiy.storchaka stage: patch review -> commit review versions: +Python 3.4 Added file: http://bugs.python.org/file28801/shutil_which_cwd4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:14:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Jan 2013 12:14:00 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() Message-ID: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ PATH= /usr/bin/which python $ PATH=: /usr/bin/which python ./python $ PATH=/usr: /usr/bin/which python ./python >>> shutil.which('python', path='') '/usr/bin/python' >>> shutil.which('python', path=':') 'python' >>> shutil.which('python', path='/usr:') 'python' First, I propose interpret path='' as an empty path, not as a default path (we have None for this). However the interpreting of an empty directory in non-empty PATH can be platform-depending. ---------- components: Library (Lib) messages: 180376 nosy: brian.curtin, hynek, pitrou, serhiy.storchaka, tarek priority: normal severity: normal status: open title: Differences between /usr/bin/which and shutil.which() type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:15:47 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 12:15:47 +0000 Subject: [issue17013] Allow waiting on a mock Message-ID: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za> New submission from Antoine Pitrou: In non-trivial tests, you may want to wait for a method to be called in another thread. This is a case where unittest.mock currently doesn't help. It would be nice to be able to write: myobj.some_method = Mock(side_effect=myobj.some_method) # launch some thread myobj.some_method.wait_until_called() And perhaps myobj.some_method.wait_until_called_with(...) (with an optional timeout?) If we don't want every Mock object to embed a threading.Event, perhaps there could be a ThreadedMock subclass? Or perhaps even: WaitableMock(..., event_class=threading.Event) so that people can pass multiprocessing.Event if they want to wait on the mock from another process? ---------- components: Library (Lib) messages: 180377 nosy: michael.foord, pitrou priority: normal severity: normal status: open title: Allow waiting on a mock type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:16:34 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:16:34 +0000 Subject: [issue17013] Allow waiting on a mock In-Reply-To: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za> Message-ID: <1358856994.21.0.626550977912.issue17013@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:18:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 12:18:10 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358857090.84.0.278814355024.issue17012@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure reproducing the quirks of /usr/bin/which is a good idea. shutil.which() is meant to be useful and easy to understand, not to be 100% bash-compatible. And, anyway, what would be the point of passing an empty path, if the return value is guaranteed to be None? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:28:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Jan 2013 12:28:39 +0000 Subject: [issue17014] _getfinalpathname() no more used in 3.4 Message-ID: <1358857719.02.0.193361070638.issue17014@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: It was a helper function for samepath on windows and not used more since samepath implementation was changed. Here is a patch which remove it. ---------- components: Extension Modules, Library (Lib), Windows files: drop_getfinalpathname.patch keywords: patch messages: 180379 nosy: brian.curtin, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: _getfinalpathname() no more used in 3.4 type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28802/drop_getfinalpathname.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:33:16 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:33:16 +0000 Subject: [issue11551] test_dummy_thread.py test coverage improvement In-Reply-To: <1300167076.06.0.564640850905.issue11551@psf.upfronthosting.co.za> Message-ID: <1358857996.15.0.759354622453.issue11551@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti, ramchandra.apte stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:34:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:34:43 +0000 Subject: [issue15483] CROSS: initialise include and library paths in setup.py In-Reply-To: <1343554833.66.0.976178324221.issue15483@psf.upfronthosting.co.za> Message-ID: <1358858083.79.0.482819204437.issue15483@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy stage: -> patch review type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:36:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Jan 2013 12:36:30 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358858190.2.0.571739998263.issue17012@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: /usr/bin/which is not a Bash. ;) The path can be unexpectedly empty. If we got None then we can detect the error, but if we got something out of the path then we can miss our fault. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:38:39 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:38:39 +0000 Subject: [issue8730] Spurious test failure in distutils In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za> Message-ID: <1358858319.0.0.436029137446.issue8730@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:39:59 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:39:59 +0000 Subject: [issue1554] socketmodule cleanups: allow the use of keywords in socket functions In-Reply-To: <1196784173.07.0.425557098914.issue1554@psf.upfronthosting.co.za> Message-ID: <1358858399.55.0.526260860766.issue1554@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:44:11 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 12:44:11 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature Message-ID: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> New submission from Antoine Pitrou: This is a bit annoying: >>> def f(a, b): pass ... >>> mock = Mock(spec=f) >>> mock(1, 2) >>> mock.assert_called_with(1, 2) >>> mock.assert_called_with(a=1, b=2) Traceback (most recent call last): File "", line 1, in File "/home/antoine/cpython/default/Lib/unittest/mock.py", line 726, in assert_called_with raise AssertionError(msg) AssertionError: Expected call: mock(b=2, a=1) Actual call: mock(1, 2) This means your test assertions will depend unduly on some code style details (whether some function is called using positional or keyword arguments). Note: if this is fixed, it should be made to work with method calls too. ---------- components: Library (Lib) messages: 180381 nosy: michael.foord, pitrou priority: normal severity: normal status: open title: mock could be smarter and inspect the spec's signature type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:44:49 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:44:49 +0000 Subject: [issue4965] Can doc index of html version be separately scrollable? In-Reply-To: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za> Message-ID: <1358858689.19.0.0808931526707.issue4965@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy stage: -> patch review versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:45:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 12:45:19 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1358858719.11.0.38937253116.issue17015@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (note: also fails if I use `mock = Mock(wraps=f)` instead of `mock = Mock(spec=f)`) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:49:37 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:49:37 +0000 Subject: [issue10994] implementation details in sys module In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za> Message-ID: <1358858977.74.0.148375943424.issue10994@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:51:50 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:51:50 +0000 Subject: [issue8350] Document lack of support for keyword arguments in C functions In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za> Message-ID: <1358859110.03.0.10099265698.issue8350@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti title: Document lack of support for keyword arguments in C functions -> Document lack of support for keyword arguments in C functions versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:53:18 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:53:18 +0000 Subject: [issue12323] ElementPath 1.3 expressions In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za> Message-ID: <1358859198.48.0.646347102517.issue12323@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:54:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:54:43 +0000 Subject: [issue9708] cElementTree iterparse does not support "parser" argument In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za> Message-ID: <1358859283.13.0.456749301318.issue9708@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:55:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:55:36 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1358859336.2.0.601153586045.issue17015@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 13:57:14 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 12:57:14 +0000 Subject: [issue10048] urllib.request documentation confusing In-Reply-To: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za> Message-ID: <1358859434.98.0.863530246491.issue10048@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 14:00:40 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 22 Jan 2013 13:00:40 +0000 Subject: [issue4934] tp_del and tp_version_tag undocumented In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za> Message-ID: <1358859640.4.0.720981095155.issue4934@psf.upfronthosting.co.za> Ronald Oussoren added the comment: tp_cache and tp_weaklist are also for internal use only, but are documented. One reason for documenting them is that users will run into them when running with a high enough warning level in GCC. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 14:04:25 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 13:04:25 +0000 Subject: [issue4934] tp_del and tp_version_tag undocumented In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za> Message-ID: <1358859865.3.0.707781647912.issue4934@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 14:06:07 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Tue, 22 Jan 2013 13:06:07 +0000 Subject: [issue17014] _getfinalpathname() no more used in 3.4 In-Reply-To: <1358857719.02.0.193361070638.issue17014@psf.upfronthosting.co.za> Message-ID: <1358859967.14.0.789289721046.issue17014@psf.upfronthosting.co.za> Ramchandra Apte added the comment: LGTM ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 14:09:11 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Tue, 22 Jan 2013 13:09:11 +0000 Subject: [issue17001] Make uuid.UUID use functools.total_ordering In-Reply-To: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za> Message-ID: <1358860151.0.0.241596765752.issue17001@psf.upfronthosting.co.za> Ramchandra Apte added the comment: @Raymond Hettinger Why? Please respond to my comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 14:31:10 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 22 Jan 2013 13:31:10 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358861470.65.0.64670252928.issue16507@psf.upfronthosting.co.za> Richard Oudkerk added the comment: It appears that Linux's "spurious readiness notifications" are a deliberate deviation from the POSIX standard. (They are mentioned in the BUGS section of the man page for select.) Should I just apply the following patch to the default branch? diff -r 3ef7f1fe286c tulip/events_test.py --- a/tulip/events_test.py Mon Jan 21 18:55:29 2013 -0800 +++ b/tulip/events_test.py Tue Jan 22 12:09:21 2013 +0000 @@ -200,7 +200,12 @@ r, w = unix_events.socketpair() bytes_read = [] def reader(): - data = r.recv(1024) + try: + data = r.recv(1024) + except BlockingIOError: + # Spurious readiness notifications are possible + # at least on Linux -- see man select. + return if data: bytes_read.append(data) else: @@ -218,7 +223,12 @@ r, w = unix_events.socketpair() bytes_read = [] def reader(): - data = r.recv(1024) + try: + data = r.recv(1024) + except BlockingIOError: + # Spurious readiness notifications are possible + # at least on Linux -- see man select. + return if data: bytes_read.append(data) else: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 14:52:11 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 22 Jan 2013 13:52:11 +0000 Subject: [issue9708] cElementTree iterparse does not support "parser" argument In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za> Message-ID: <1358862731.53.0.470246108906.issue9708@psf.upfronthosting.co.za> Eli Bendersky added the comment: Could you point out specifically which methods in ET don't work with the argument, and describe the problem in general? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 14:59:29 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Jan 2013 13:59:29 +0000 Subject: [issue15546] Iteration breaks with bz2.open(filename,'rt') In-Reply-To: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za> Message-ID: <3YrB8118rNzMjZ@mail.python.org> Roundup Robot added the comment: New changeset 0f25119ceee8 by Serhiy Storchaka in branch '3.2': #15546: Fix GzipFile.peek()'s handling of pathological input data. http://hg.python.org/cpython/rev/0f25119ceee8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:11:57 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 14:11:57 +0000 Subject: [issue17014] _getfinalpathname() no more used in 3.4 In-Reply-To: <1358857719.02.0.193361070638.issue17014@psf.upfronthosting.co.za> Message-ID: <1358863917.01.0.00177255839765.issue17014@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Rejecting. It will be used for Windows realpath() (issue14094) and, even if it's a private function, it can also be useful for third-party libs such as pathlib. ---------- resolution: -> rejected stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:17:13 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 22 Jan 2013 14:17:13 +0000 Subject: [issue12323] ElementPath 1.3 expressions In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za> Message-ID: <1358864233.47.0.318931451779.issue12323@psf.upfronthosting.co.za> Eli Bendersky added the comment: The official documentation of XML ET is at http://docs.python.org/dev/library/xml.etree.elementtree.html The arguments to XPath are clearly described, and the implementation behaves correctly. We will continue supporting XPath syntax there, rather than Python syntax, because this is explicitly a XPath feature. ---------- priority: normal -> low resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:31:13 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 22 Jan 2013 14:31:13 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358865073.72.0.881555425013.issue16672@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Attached is a patch for the current head of 2.7. It would nice to have this patch on 2.7 too. With this patch, an implementation of pdb running on 2.7 with an extension module, runs at 1.2 times the speed of the interpreter when the trace function is active (see http://code.google.com/p/pdb-clone/wiki/Performances). The performance gain is 30%. ---------- Added file: http://bugs.python.org/file28803/f_trace_perfs-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:34:55 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 22 Jan 2013 14:34:55 +0000 Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za> Message-ID: <1358865295.28.0.614339198529.issue11367@psf.upfronthosting.co.za> Eli Bendersky added the comment: Patches to documentation of 3.2 and 2.7 are welcome ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:36:03 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 22 Jan 2013 14:36:03 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358865363.29.0.779024993212.issue16672@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- assignee: -> benjamin.peterson nosy: +benjamin.peterson resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:36:41 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 22 Jan 2013 14:36:41 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358865401.4.0.235324810734.issue16672@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Benjamin, ans the previous commiter, could you possibly check the 2.7 proposed patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:36:41 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 22 Jan 2013 14:36:41 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1358861470.65.0.64670252928.issue16507@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > It appears that Linux's "spurious readiness notifications" are a deliberate deviation from the POSIX standard. (They are mentioned in the BUGS section of the man page for select.) I don't think it's a deliberate deviation, but really bugs/limitations (I can remember at least one occurrence case where a UDP segment would be received, which triggered a notification, but the segment was subsequently discarded because of an invalid checksum). AFAICT kernel developers tried to fix those spurious notifications, but some of them were quite tricky (see e.g. http://lwn.net/Articles/318264/ for epoll() patches, and http://lists.schmorp.de/pipermail/libev/2009q1/000627.html for an example spurious epoll() notification scenario). That's something we have to live with (like pthread condition spurious wakeups), select()/poll()/epoll() are mere hints that the FD is readable/writable... Also, in real code you have to be prepared to catch EAGAIN regardless of spurious notifications: when a FD is reported as read ready, it just means that there are some data to read. Depending on the watermark, it could mean that only one byte is available. So if you want to receive e.g. a large amount of data and the FD is non-blocking, you can do something like: """ buffer = [] while True: try: data = s.recv(8096) except BlockingIOError: break if data is None: break buffer += data """ Otherwise, you'd have to read() only one byte at a time, and go back to the select()/poll() syscall. (For write ready, you can obviously have "spurious" notifications if you try to write more than what is available in the output socket buffer). > Should I just apply the following patch to the default branch? LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:46:36 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 22 Jan 2013 14:46:36 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358865996.05.0.246955993001.issue16672@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This patch causes test_hotshot to fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 15:56:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 14:56:23 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: Message-ID: <1694693851.412642169.1358866577556.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Also, in real code you have to be prepared to catch EAGAIN regardless > of spurious notifications: when a FD is reported as read ready, it > just means that there are some data to read. Depending on the > watermark, it could mean that only one byte is available. If only one byte is available, recv(4096) should simply return a partial result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:00:56 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 22 Jan 2013 15:00:56 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358866856.49.0.992194620767.issue16507@psf.upfronthosting.co.za> Richard Oudkerk added the comment: According to Alan Cox It's a design decision and a huge performance win. It's one of the areas where POSIX read in its strictest form cripples your performance. See https://lkml.org/lkml/2011/6/18/103 > (For write ready, you can obviously have "spurious" notifications if > you try to write more than what is available in the output socket > buffer). Wouldn't you just get a partial write (assuming an AF_INET, SOCK_STREAM socket)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:12:00 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 22 Jan 2013 15:12:00 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358867520.19.0.406990796174.issue17012@psf.upfronthosting.co.za> R. David Murray added the comment: What I think it is suppose to do (the user expects it to do) is find the program that would be run if the command were typed at the command prompt. rdmurray at hey:~>which python /usr/bin/python rdmurray at hey:~>export PATH= rdmurray at hey:~>which python python not found rdmurray at hey:~>python zsh: command not found: python As Serhiy noted, this result may be platform dependent. Which is unfortunate. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:17:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Jan 2013 15:17:01 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <3YrCsS6DJrzN9h@mail.python.org> Roundup Robot added the comment: New changeset 174332b89a0d by Serhiy Storchaka in branch '3.2': Issue #1159051: GzipFile now raises EOFError when reading a corrupted file http://hg.python.org/cpython/rev/174332b89a0d New changeset 87171e88847b by Serhiy Storchaka in branch '3.3': Issue #1159051: GzipFile now raises EOFError when reading a corrupted file http://hg.python.org/cpython/rev/87171e88847b New changeset f2f947cdc5fe by Serhiy Storchaka in branch 'default': Issue #1159051: GzipFile now raises EOFError when reading a corrupted file http://hg.python.org/cpython/rev/f2f947cdc5fe New changeset 214d8909513d by Serhiy Storchaka in branch '2.7': Issue #1159051: GzipFile now raises EOFError when reading a corrupted file http://hg.python.org/cpython/rev/214d8909513d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:25:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Jan 2013 15:25:26 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358868326.34.0.222635053132.issue17012@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, I noted that result of PATH=: or PATH=$PATH: can be platform dependent (I'm?not sure). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:26:17 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 15:26:17 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358868377.71.0.832497406406.issue16672@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think performance patches should be committed to bugfix branches (especially 2.7 which is in slow maintenance mode). Recommend closing. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:38:41 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 22 Jan 2013 15:38:41 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358869121.89.0.543597778472.issue16672@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That, too. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:54:28 2013 From: report at bugs.python.org (Nickolai Zeldovich) Date: Tue, 22 Jan 2013 15:54:28 +0000 Subject: [issue17016] _sre: avoid relying on pointer overflow Message-ID: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za> New submission from Nickolai Zeldovich: Modules/_sre.c relies on pointer overflow in 5 places to check that the supplied offset does not cause wraparound when added to a base pointer; e.g.: SRE_CODE prefix_len; GET_ARG; prefix_len = arg; GET_ARG; /* Here comes the prefix string */ if (code+prefix_len < code || code+prefix_len > newcode) FAIL; however, pointer wraparound is undefined behavior in C, and gcc will optimize away (code+prefix_len < code) to (true), since prefix_len is an unsigned value. This will happen with -O2 and even with -fwrapv: nickolai at sahara:/tmp$ cat x.c void bar(); void foo(int *p, unsigned int x) { if (p + x < p) bar(); } nickolai at sahara:/tmp$ gcc x.c -S -o - -O2 -fwrapv ... foo: .LFB0: .cfi_startproc rep ret .cfi_endproc ... nickolai at sahara:/tmp$ On a 32-bit platform with the development version of cpython, prefix_len seems to end up being an 'unsigned int', so I suspect that supplying a large prefix_len value (perhaps 0xffffffff) could lead to the subsequent loop writing garbage all over memory, or worse (but I have not tried to construct a concrete input that triggers this bug, so maybe there are some checks that make it difficult to trigger the bug). In any case, this might be worth fixing -- the attached patch provides one proposed fix. Another option might be to add -fno-strict-overflow to the gcc flags, which may be a reasonable additional measure to take, to avoid such problems biting Python in the future, but I would suggest doing this in addition to fixing the code (since not all compilers support such a flag to disable certain optimizations). ---------- components: None files: pp.patch keywords: patch messages: 180403 nosy: Nickolai.Zeldovich priority: normal severity: normal status: open title: _sre: avoid relying on pointer overflow type: security versions: Python 3.5 Added file: http://bugs.python.org/file28804/pp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:56:51 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 15:56:51 +0000 Subject: [issue17016] _sre: avoid relying on pointer overflow In-Reply-To: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za> Message-ID: <1358870211.87.0.0576936467612.issue17016@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions -None nosy: +ezio.melotti, mark.dickinson, mrabarnett, serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:58:47 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 22 Jan 2013 15:58:47 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358870327.44.0.146128856536.issue17012@psf.upfronthosting.co.za> R. David Murray added the comment: I was speaking in general of 'which program would be executed if the command is typed at the prompt' as being system dependent, which it demonstrably is since the behavior on unix and windows differs with regards to the current directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 16:59:14 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 22 Jan 2013 15:59:14 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358870354.0.0.286374232539.issue17012@psf.upfronthosting.co.za> R. David Murray added the comment: And no, what I wrote wasn't clear :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 17:01:54 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 22 Jan 2013 16:01:54 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1694693851.412642169.1358866577556.JavaMail.root@zimbra10-e2.priv.proxad.net> Message-ID: Charles-Fran?ois Natali added the comment: > If only one byte is available, recv(4096) should simply return a partial result. Of course, but how do you know if there's data left to read without calling select() again? It's much better to call read() until you get EAGAIN than calling select() between each read()/write() call. > Wouldn't you just get a partial write (assuming an AF_INET, SOCK_STREAM socket)? For SOCK_STREAM, yes, not for SOCK_DGRAM (or for a pipe when trying to write more than PIPE_BUF, although I guess any sensible implementation doesn't report the pipe write ready if there's less than PIPE_BUF space left). > It's a design decision and a huge performance win. It's one of the areas > where POSIX read in its strictest form cripples your performance. Yes, he's referring to the fact that there are cases where you could avoid some spurious notifications, but that would incur a performance hit: that's exactly the same rationale behind condition variables spurious wakups: since the user-code must be prepared to handle spurious notifications, let's take advantage of it. But there are been various fixes in the past years to avoid spurious notifications in epoll() for example, because while they allow certain optimizations in the kernel, spurious wakeups can cost to user-level applications... I'm 99% sure that Linux isn't the only OS allowing spurious wakeups, since it's essentially an unsolvable issue (temporary shortage of buffer, or the example given by Alan Cox of a pipe with two readers...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 17:06:31 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 22 Jan 2013 16:06:31 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > For SOCK_STREAM, yes, not for SOCK_DGRAM (or for a pipe when trying to > write more than PIPE_BUF, although I guess any sensible implementation > doesn't report the pipe write ready if there's less than PIPE_BUF > space left). That should be of course "when trying to write LESS than PIPE_BUF", since it's required to be atomic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 17:06:36 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 22 Jan 2013 16:06:36 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358870796.34.0.888268794693.issue16672@psf.upfronthosting.co.za> Xavier de Gaye added the comment: One may argue that this is not only a performances patch and that it fixes the wasting of cpu resources when tracing is on. Wasting cpu resources is a bug. Anyway, this is fine with me to close this minor issue on 2.7. The test_hotshot test is ok on my linux box and with the patch applied on 2.7 head. Just curious to know what the problem is. And thanks for applying the patch to 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 17:22:04 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 22 Jan 2013 16:22:04 +0000 Subject: [issue11379] Remove "lightweight" from minidom description In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za> Message-ID: <1358871724.26.0.517372164491.issue11379@psf.upfronthosting.co.za> ?ric Araujo added the comment: Sure, feel free to commit this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 17:27:37 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 16:27:37 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: Message-ID: Guido van Rossum added the comment: Short reads/writes are orthogonal to EAGAIN. All the mainline code treats readiness as a hint only, so tests should too. --Guido van Rossum (sent from Android phone) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 17:50:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Jan 2013 16:50:43 +0000 Subject: [issue17016] _sre: avoid relying on pointer overflow In-Reply-To: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za> Message-ID: <1358873443.13.0.52197467016.issue17016@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. There are other doubtful places, at lines: 658, 678, 1000, 1084, 2777, 3111. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 18:09:02 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 22 Jan 2013 17:09:02 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1353277974.19.0.012295377293.issue16507@psf.upfronthosting.co.za> Message-ID: <1358874542.87.0.523200241296.issue16507@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > For SOCK_STREAM, yes, not for SOCK_DGRAM I thought SOCK_DGRAM messages just got truncated at the receiving end. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 18:17:52 2013 From: report at bugs.python.org (Ned Deily) Date: Tue, 22 Jan 2013 17:17:52 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358875072.16.0.231965036915.issue17012@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, the POSIX standard gives some guidance on how PATH is to be interpreted for conforming systems, including: "A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent characters ( "::" ), as an initial preceding the rest of the list, or as a trailing following the rest of the list. A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH." http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 19:05:52 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 18:05:52 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358877952.23.0.717933888881.issue3982@psf.upfronthosting.co.za> Guido van Rossum added the comment: Twisted still would like to see this. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 19:24:22 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 22 Jan 2013 18:24:22 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358879062.14.0.877080922767.issue3982@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Implementing this certainly hasn't gotten any easier as 3.x str.format has evoled. The kind of format codes and modifiers wanted to for formatting byte strings might be different that those for text strings. I think it probably needs a pep. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 19:27:55 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 18:27:55 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358879062.14.0.877080922767.issue3982@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Would it be easier if the only format codes/types supported were bytes, int and float? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 19:39:04 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 18:39:04 +0000 Subject: [issue12411] cgi.parse_multipart is broken on 3.x In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za> Message-ID: <1358879944.88.0.916371037111.issue12411@psf.upfronthosting.co.za> Guido van Rossum added the comment: Twisted would really like to see this bug fixed. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 19:41:29 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Tue, 22 Jan 2013 18:41:29 +0000 Subject: [issue12411] cgi.parse_multipart is broken on 3.x In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za> Message-ID: <1358880089.43.0.540525218858.issue12411@psf.upfronthosting.co.za> Changes by Glyph Lefkowitz : ---------- nosy: +glyph _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 19:43:58 2013 From: report at bugs.python.org (patrick vrijlandt) Date: Tue, 22 Jan 2013 18:43:58 +0000 Subject: [issue12323] ElementPath 1.3 expressions In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za> Message-ID: <1358880238.63.0.0440119609646.issue12323@psf.upfronthosting.co.za> patrick vrijlandt added the comment: Dear Eli, According to the XPath spec, the 'position' as can be used in xpath expressions, should be positive. However, the current implementation (example below from 3.3.0) accepts some values that should not be ok. Therefore, I do not agree that it behaves correctly. Garbage positions should return [] or an exception, not a value. And if you accept one value before the first position, you should accept them all. DATA = ''' 2 2008 141100 5 2011 59900 69 2011 13600 ''' import xml.etree.ElementTree as ET root = ET.XML(DATA) print(root) for XP in (['./country'] + ['./country[%d]' % i for i in range(-1, 5)] + ['./country[last()%+d]' % i for i in range(-3, 5)]): print('{:20}'.format(XP), [elem.get('name') for elem in root.findall(XP)]) ## OUTPUT: ## ## ./country ['Liechtenstein', 'Singapore', 'Panama'] ## ./country[-1] [] ## ./country[0] ['Panama'] ## ./country[1] ['Liechtenstein'] ## ./country[2] ['Singapore'] ## ./country[3] ['Panama'] ## ./country[4] [] ## ./country[last()-3] [] ## ./country[last()-2] ['Liechtenstein'] ## ./country[last()-1] ['Singapore'] ## ./country[last()+0] ['Panama'] ## ./country[last()+1] ['Liechtenstein'] ## ./country[last()+2] ['Singapore'] ## ./country[last()+3] ['Panama'] ## ./country[last()+4] [] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 19:47:32 2013 From: report at bugs.python.org (Christian Heimes) Date: Tue, 22 Jan 2013 18:47:32 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358880452.53.0.147104357552.issue3982@psf.upfronthosting.co.za> Christian Heimes added the comment: IMHO a useful API has to provide a more low level functionality like "format number as 32 bit unsigned integer in network endian". A bytes.format() function should support all format chars from http://docs.python.org/3/library/struct.html#format-characters plus all endian and alignment modifiers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 19:48:21 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 22 Jan 2013 18:48:21 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358880501.52.0.962770332106.issue3982@psf.upfronthosting.co.za> Benjamin Peterson added the comment: The problem is not so much the types allowed the code for dealing with the format string. The parsing code for format specificers is pretty unicode specific now. If that was to be made generic again, it's worth considering exactly what features belong in a bytes format method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:02:47 2013 From: report at bugs.python.org (Silvan Jegen) Date: Tue, 22 Jan 2013 19:02:47 +0000 Subject: [issue9708] cElementTree iterparse does not support "parser" argument In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za> Message-ID: <1358881367.33.0.406004506317.issue9708@psf.upfronthosting.co.za> Silvan Jegen added the comment: The situation is as follows. According to the online documentation of Python 2.7 the xml.etree.ElementTree.iterparse() function takes up to three arguments, two of them named ones: xml.etree.ElementTree.iterparse(source, events=None, parser=None) In the C implementation of the function however, the "parser" argument does not seem to be supported: >>> import xml.etree.ElementTree as ET >>> import xml.etree.cElementTree as ETc # C version of the library >>> result = ET.iterparse("xmltest.xml", None, ET.XMLParser()) # Works >>> >>> result = ETc.iterparse("xmltest.xml", None, ET.XMLParser()) # C version does'nt Traceback (most recent call last): File "", line 1, in TypeError: __init__() takes at most 3 arguments (4 given) The documentation does not mention the C version of the function not taking the "parser" argument as far as I know. Additionally, the xml.etree.ElementTree.iterparse() online documentation for Python 3.3 mentions the "parser" argument as well. When using this argument however, Python throws an error: Python 3.3.0 (default, Dec 22 2012, 21:02:07) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import xml.etree.ElementTree as ET >>> ET.iterparse("xmltest.xml", None, ET.XMLParser()) Traceback (most recent call last): File "", line 1, in TypeError: __init__() takes from 2 to 3 positional arguments but 4 were given A look at the pydoc output for xml.etree.ElementTree actually does not mention a named "parser" argument to iterparse() at all (Please note that iterparse seems to be a constructor in Python 3.3): class iterparse(builtins.object) | Methods defined here: | | __init__(self, file, events=None) In these cases either the implementation or the documentation should be changed. Please feel free to ask away if you have more questions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:04:08 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 22 Jan 2013 19:04:08 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: <1358874542.87.0.523200241296.issue16507@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I thought SOCK_DGRAM messages just got truncated at the receiving end. You were referring to partial writes: for a datagram-oriented protocol, if the datagram can't be sent atomically (in one send()/write() call), the kernel will return EAGAIN. On the receiving side, it will get truncated is the buffer is too small. Going back to the subject: so what do we say, let's just forget about supporting WSAPoll at all (both in CPython and tulip)? If we ever choose to export it, I think the least we should do would be to not export it as select.poll(): since it has - not so subtle - semantic differences with poll(), code using previously select() on Windows may silently break when poll() is suddenly available: e.g. asyncore with use_poll=True would probably deadlock in case of unreachable host, if WSAPoll doesn't report connect() failures. When I see the hoops Richard had to go through to make WSAPoll usable in tulip, my gut feeling is that exposing it wouldn't be making a favor to poor unsuspecting Windows programmers :-\ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:07:55 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 22 Jan 2013 19:07:55 +0000 Subject: [issue17013] Allow waiting on a mock In-Reply-To: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za> Message-ID: <1358881675.93.0.515864768701.issue17013@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:11:45 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 19:11:45 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358880501.52.0.962770332106.issue3982@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Honestly, what Twisted is mostly after is a way to write code that works both with Python 2 and Python 3. They need the types I mentioned only (bytes, int, float) and not too many advanced features of .format() -- but if it's not called .format() or if the syntax is not a subset of the syntax of Python 2 format syntax, it's not very useful for them. (They would have to rewrite every protocol implementation in their tree to use something different, apparently, since .format() has proven to be the most efficient way to construct larger byte strings out of smaller pieces, in Python 2.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:13:38 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 19:13:38 +0000 Subject: [issue16507] Patch selectmodule.c to support WSAPoll on Windows In-Reply-To: Message-ID: Guido van Rossum added the comment: Agreed, it does not sound very useful to support WSAPoll(), neither in selector.py (which is intended to eventually be turned into stdlib/select.py) nor in PEP 3156. And then, what other use is there for it, really? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:16:07 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 19:16:07 +0000 Subject: [issue12411] cgi.parse_multipart is broken on 3.x In-Reply-To: <1358880089.47.0.247557612175.issue12411@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Does anyone who was on this bug previously (e.g. the original author or the reviewers) know what was holding up the patch? Does it need more review? More tests? Is there any reason to reject fixing this at all? (I hope not.) As far as replacing the whole thing with a call into the other code goes, I'm hesitant if only because we don't have enough unit tests for the edge cases of the implementation that would be deleted, so if the wholesale replacement were to break user code we wouldn't find out until after it's been released. Fixing it seems less risky. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:16:09 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 19:16:09 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358882169.43.0.289720616828.issue3982@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Given the issues which have been brought here, I agree that it's PEP material. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:17:23 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 19:17:23 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358882243.13.0.395356318454.issue3982@psf.upfronthosting.co.za> Ezio Melotti added the comment: Serhiy did a nice summary in msg171804, and I think this is PEP material too. What he wrote could be used as a starting point; the next step would be collecting use cases (the Twisted guys seem to have some). Once we have defined what we want we can figure out how to implement it (e.g. how much code can be shared with str.format, if it should be bytes.format or something in the struct module). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:22:17 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 22 Jan 2013 19:22:17 +0000 Subject: [issue12411] cgi.parse_multipart is broken on 3.x In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za> Message-ID: <1358882537.12.0.273997437881.issue12411@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I personally think, that the "grey area" of multipart form encoding and trying to use email's updated features for parsing was holding it, not the tests. This can be submitted IMO after looking at the "related bugs", I shall do a review on this one today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:23:25 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 19:23:25 +0000 Subject: [issue12411] cgi.parse_multipart is broken on 3.x In-Reply-To: <1358882537.12.0.273997437881.issue12411@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Thank you very much Senthil! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:32:28 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Jan 2013 19:32:28 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358883148.18.0.689720826989.issue3982@psf.upfronthosting.co.za> Guido van Rossum added the comment: Well, msg171804 makes it a much bigger project than the feature that Twisted actually needs. Quoting: * The default formatting should not use str(), but buffer protocol. Fine. * There is no place for floating point. Actually they do need it -- and it's trivial to define, since fp only returns ASCII characters. * There is no place for locale. Agreed. * There is no place for 'r' conversion (possible only for 'a'). Agreed. * It should include the features of struct.pack(), int.to_bytes() and ctypes. Not needed. * Padding should be not only by space, but also by zeros (and possibly by other values). Not needed. * Alignment (padding to position divisible by some number). Not needed. * In addition to padding and truncating should be the ability to raise an exception in case of discrepancy between the needed and actual lengths. Not needed. * It unlikely needed attribute access and indexing. I don't know, but these features certainly would be well-defined. * Builtin format() should not work with this. Fine. Probably bytes.format() should not try to call v.__format__(); if an extension mechanism is needed it would be called something else, but given the limited set of types needed I think this can be skipped. The most important requirement from Twisted is actually that it is called .format(), and that the overall format strings look like they did for 8-bit string formatting in Python 2. In particular b'a{}b{}c'.format(x, y), where x and y are bytes, should be equivalent to b'a' x + b'b' + y + b'c'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:36:53 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Tue, 22 Jan 2013 19:36:53 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1358883413.06.0.206815307342.issue15958@psf.upfronthosting.co.za> Changes by Glyph Lefkowitz : ---------- nosy: +glyph _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:37:17 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Tue, 22 Jan 2013 19:37:17 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358883437.74.0.0988661138634.issue3982@psf.upfronthosting.co.za> Changes by Glyph Lefkowitz : ---------- nosy: +glyph _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:39:58 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 19:39:58 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358883598.21.0.954277658398.issue3982@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Right, but we're not writing builtin type methods specifically for Twisted. I agree with the idea that the feature set should very limited, actually perhaps more limited than what you just said. For example, I think any kind of implicit str->bytes conversion is a no-no (including the "r" and "a" format codes). Still, IMO even a simple feature set warrants a PEP, because we want to devise something that's generally useful, not just something which makes porting easier for Twisted. I also kind of expect Twisted to have worked around the issue before 3.4 is out, anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 20:59:51 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Tue, 22 Jan 2013 19:59:51 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358883598.21.0.954277658398.issue3982@psf.upfronthosting.co.za> Message-ID: <28130E51-CBC2-48C2-886D-DEA001B8B78D@twistedmatrix.com> Glyph Lefkowitz added the comment: On Jan 22, 2013, at 11:39 AM, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > I agree with the idea that the feature set should very limited, actually perhaps more limited than what you just said. For example, I think any kind of implicit str->bytes conversion is a no-no (including the "r" and "a" format codes). Twisted doesn't particularly need str->bytes conversion in this step, implicit or otherwise, so I have no problem with leaving that out. > Still, IMO even a simple feature set warrants a PEP, because we want to devise something that's generally useful, not just something which makes porting easier for Twisted. Would it really be so bad to add features that would make porting Twisted easier? Even if you want porting Twisted to be as hard as possible, there are plenty of other Python applications that don't use Twisted which nevertheless need to emit formatted sequences of bytes. Twisted itself is a good proxy for this class of application; I really don't think that this is overly specific. > I also kind of expect Twisted to have worked around the issue before 3.4 is out, anyway. The problem is impossible to work around in the general case. While we can come up with clever workarounds for things internal to buffering implementations or our own protocols, Twisted exposes an API that allows third parties to write protocol implementations, which quite a few people do. Every one of those implementations (and every one of Twisted's internal implementations, none of which are ported yet, just the core) faces a series of frustrating implementation choices where the "old" style of b'x' % y or b'x'.format(y) resulted in readable, efficient value interpolation into protocol messages, but the "new" style of b''.join([b'x1', y_to_bytes(y), b'x2']) requires custom functions, inefficient copying, redundant bytes<->text transcoding, and harder-to-read protocol framing literals. This interacts even more poorly with oddities like bytes(int) returning zeroes now, so there's not even a reasonable 2<->3 compatible way of, say, setting an HTTP content-length header; b'Content-length: {}\r\n'.format(length) is now b''.join([b'Content-length: ', (bytes if bytes is str else str)(length).encode('ascii'), b'\r\n']). This has negative readability, performance, and convenience implications for the code running on both 2.x and 3.x and it would be really nice to see fixed. Honestly, it would still be a porting burden to have to use .format(); if you were going to do something _specifically_ to help Twisted, the thing to do would be to make both .format and .__mod__ work; most of our protocol code currently uses % to do its formatting. However, upgrading to a "modern" API is not an insurmountable burden for Twisted, and I can understand the desire to trade off that work for the simplicity of having less code to maintain in Python core (and less to write for this feature), as long as the "modern" API is actually functional enough to make very common operations close to equivalently convenient. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 21:13:27 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Jan 2013 20:13:27 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <28130E51-CBC2-48C2-886D-DEA001B8B78D@twistedmatrix.com> Message-ID: <1358885448.3460.17.camel@localhost.localdomain> Antoine Pitrou added the comment: > there are plenty of other Python applications that don't use Twisted > which nevertheless need to emit formatted sequences of bytes. The fact that "there are plenty of other Python applications that don't use Twisted which nevertheless need to emit formatted sequences of bytes" is *precisely* a good reason for this to be discussed more visibly. Even if it isn't a PEP, it will still benefit from being a python-dev or python-ideas discussion. We are talking about a method on a prominent built-in type, not some additional function or method in an obscure module. > > I also kind of expect Twisted to have worked around the issue before > 3.4 is out, anyway. > > The problem is impossible to work around in the general case. I'm not sure what the "general case" is. What I know from Twisted is there are many specific cases where, indeed, binary protocol strings are formed by string formatting, e.g. in the FTP implementation (and for good reason since those protocols are either ASCII or an ASCII superset). As a workaround, it would probably be reasonable to make these protocols use str objects at the heart, and only convert to bytes after the formatting is done. > This has negative readability, performance, and convenience > implications for the code running on both 2.x and 3.x and it would be > really nice to see fixed. Code running on both 2.x and 3.x will *by construction* have some performance pessimizations inside it. It is inherent to that strategy. Not saying this is necessarily a problem, but you should be aware of it. > Honestly, it would still be a porting burden to have to > use .format(); if you were going to do something _specifically_ to > help Twisted, the thing to do would be to make both .format > and .__mod__ work; most of our protocol code currently uses % to do > its formatting. I know that :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 21:50:22 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Jan 2013 20:50:22 +0000 Subject: [issue11379] Remove "lightweight" from minidom description In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za> Message-ID: <3YrMG54QcczSNw@mail.python.org> Roundup Robot added the comment: New changeset c2ae1ed03853 by Ezio Melotti in branch '2.7': #11379: rephrase minidom documentation to use the term "minimal" instead of "lightweight". Patch by ?ric Araujo. http://hg.python.org/cpython/rev/c2ae1ed03853 New changeset b9c0e050c935 by Ezio Melotti in branch '3.2': #11379: rephrase minidom documentation to use the term "minimal" instead of "lightweight". Patch by ?ric Araujo. http://hg.python.org/cpython/rev/b9c0e050c935 New changeset 8ff512910338 by Ezio Melotti in branch '3.3': #11379: merge with 3.2. http://hg.python.org/cpython/rev/8ff512910338 New changeset 9a0cd5363c2a by Ezio Melotti in branch 'default': #11379: merge with 3.3. http://hg.python.org/cpython/rev/9a0cd5363c2a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 21:51:53 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Jan 2013 20:51:53 +0000 Subject: [issue11379] Remove "lightweight" from minidom description In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za> Message-ID: <1358887913.5.0.162549713007.issue11379@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed type: performance -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 22:39:42 2013 From: report at bugs.python.org (Adam Collard) Date: Tue, 22 Jan 2013 21:39:42 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1358890782.64.0.773646968263.issue1100942@psf.upfronthosting.co.za> Changes by Adam Collard : ---------- nosy: +adam-collard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 22:46:29 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Jan 2013 21:46:29 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358877952.23.0.717933888881.issue3982@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2013/1/22 Guido van Rossum : > Twisted still would like to see this. Sorry, but this argument doesn't convince me. A better argument is that bytes+bytes+...+bytes is inefficient: it creates a lot of temporary objects instead of computing the final size directly, or using realloc. str%args and str.format() uses realloc() and overallocates its internal buffer to avoid too many calls to realloc(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 22 23:51:03 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Tue, 22 Jan 2013 22:51:03 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: Message-ID: Glyph Lefkowitz added the comment: On Jan 22, 2013, at 1:46 PM, STINNER Victor wrote: > 2013/1/22 Guido van Rossum : >> Twisted still would like to see this. > > Sorry, but this argument doesn't convince me. A better argument is > that bytes+bytes+...+bytes is inefficient: it creates a lot of > temporary objects instead of computing the final size directly, or > using realloc. Uh, yes. That's one of the reasons (given above) that Twisted would still like to see this. It seemed to me that Guido was stating a fact there, not making an argument. The Twisted project *would* like to see this, I can assure you, regardless of whether you're convinced or not :). > str%args and str.format() uses realloc() and overallocates its > internal buffer to avoid too many calls to realloc(). More importantly, it's fairly easy to add many optimizations of this type to an API in the style of .format(), even if it's not present in the first round; optimizing bytes + bytes + bytes requires slightly scary interactions with refcounting and potentially GC, like the += optimization. The API just has more information to go on, and that's a good thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 00:13:17 2013 From: report at bugs.python.org (Philip Jenvey) Date: Tue, 22 Jan 2013 23:13:17 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1358896397.39.0.040752012184.issue15881@psf.upfronthosting.co.za> Philip Jenvey added the comment: Targeting this for 2.7.4. If Alexander doesn't get to it, ping me and I'll do it ---------- nosy: +benjamin.peterson, georg.brandl, larry, pjenvey priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 00:34:32 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Jan 2013 23:34:32 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358897672.74.0.323995453244.issue3982@psf.upfronthosting.co.za> Terry J. Reedy added the comment: >it would probably be reasonable to make these protocols use str objects at the heart, and only convert to bytes after the formatting is done. I presume this would mean adding 'if py3: out = out.encode()' after the formatting. As I said before, this works much better in 3.3+ than in 3.2-. Some actual numbers: for len in (0, 100, 1000, 10000, 100000): a = 'a' * len print(timeit("a.encode()", "from __main__ import a")) >>> 0.19305401378265558 0.22193721412302575 0.2783227054755883 0.677596406192696 7.124387897799184 Given n = 1000000, these should be microseconds per encoding. Of note: the copying of bytes does not double the total time until there are a few thousand chars. Would protocols be using .format for much more than this? [If speed is really an issue, we could make binary file/socket write methods unicode implementation aware. They could directly access the ascii (or latin-1) bytes in a unicode object, just as they do with a bytes object, and the extra copy could be skipped.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 00:51:42 2013 From: report at bugs.python.org (Andreas Dewes) Date: Tue, 22 Jan 2013 23:51:42 +0000 Subject: [issue17017] email.utils.getaddresses fails for certain addresses Message-ID: <1358898702.5.0.0944995793434.issue17017@psf.upfronthosting.co.za> New submission from Andreas Dewes: email.utils.getaddresses doesn't seem to work if the quoted part of address contains "\r" or "\n" characters. An example: --- from email.utils import getaddresses address = '"Data Mining, Statistics, Big Data, and Data Visualization Group\r\n Members" ' getaddresses([address]) --- In Python 2.7.3, this returns: [('', u'Data Mining, Statistics, Big Data, and Data Visualization Group')] Not sure if this is a real bug or if the address is malformed, in any case I encountered this issue when parsing e-mails fetched from GMail. ---------- components: email messages: 180440 nosy: barry, japh44, r.david.murray priority: normal severity: normal status: open title: email.utils.getaddresses fails for certain addresses type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 01:59:30 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Wed, 23 Jan 2013 00:59:30 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358885448.3460.17.camel@localhost.localdomain> Message-ID: <44306121-4684-459E-AFAA-47B934BEF7DE@twistedmatrix.com> Glyph Lefkowitz added the comment: > Antoine Pitrou added the comment: > The fact that "there are plenty of other Python applications that don't > use Twisted which nevertheless need to emit formatted sequences of > bytes" is *precisely* a good reason for this to be discussed more > visibly. I don't think anyone is opposing discussing it. I don't personally think such a discussion would be useful, lots of points of view are represented on this ticket, but please feel free to raise it in whatever forum that you feel would be helpful. (Even if I did object to that I don't see how I could stop you :)). > I'm not sure what the "general case" is. The "general case" that I'm referring to is the case of an application writing some protocol logic in terms of constructing some bytes objects and passing them to Twisted. In other words, Twisted relied upon Python to provide a convenient way to assemble your bytes into protocol messages, and that was removed in 3.x. We never provided one ourselves and I don't think it would be a particularly good idea to build that kind of basic string-manipulation functionality into Twisted rather than Python. > What I know from Twisted is there are many specific cases where, indeed, > binary protocol strings are formed by string formatting, e.g. in the FTP > implementation (and for good reason since those protocols are either ASCII > or an ASCII superset). These protocols (SMTP, SIP, HTTP, IMAP, POP, FTP), are not ASCII (nor are they an "ASCII superset"); they are ASCII commands interspersed with binary data. It makes sense to treat them as bytes, not text. In many cases - such as when expressing a length, or a checksum - you _must_ treat them as bytes, or you will emit incorrect data on the wire. By the time you're dealing with text - if you ever are - you're already somewhere in the body of the protocol, decorated with appropriate metadata. But my point about the "general case" is that when implementing a *new* protocol with ASCII commands, or maintaining an existing one, bytes-object formatting is a convenient, expressive and performant way to express the interpolation of values in the protocol stream. > As a workaround, it would probably be reasonable to make > these protocols use str objects at the heart, and only convert to bytes > after the formatting is done. Protocols like SMTP (c.f. "8-bit MIME") and HTTP put binary data in-line; do you suggest that gzipped content be encoded as latin1 so it can squeeze into python 3's str type? I thought the whole point of the porting pain here was to get a clean separation between bytes and text. This is exactly why I do not particularly want bytes.format() to allow the presence of strs as formatted values, although that *would* make porting certain things easier. It makes sense to do your encoding first, then interpolate. > Code running on both 2.x and 3.x will *by construction* have some > performance pessimizations inside it. It is inherent to that strategy. > Not saying this is necessarily a problem, but you should be aware of it. This is certainly true *now*, but it doesn't necessarily have to be. Enhancements like this one could make this performance division go away. In any case, the reason that ported code suffers from a performance penalty is because python 3 has no efficient way of doing this type of bytes construction; even disregarding compatibility with a 2.x codebase, b''.join() and b'' + b'' and (''.format()).encode('charmap') are all slower _and_ more awkward than simply b''.format() or b''%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 02:03:22 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Wed, 23 Jan 2013 01:03:22 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358897672.74.0.323995453244.issue3982@psf.upfronthosting.co.za> Message-ID: <3ABE017B-5DCC-4569-A7D5-625707002EA3@twistedmatrix.com> Glyph Lefkowitz added the comment: On Jan 22, 2013, at 3:34 PM, Terry J. Reedy wrote: > I presume this would mean adding 'if py3: out = out.encode()' after the formatting. As I said before, this works much better in 3.3+ than in 3.2-. Some actual numbers: I'm glad that this operation has been optimized, but treating blocks of protocol data as text is a hackish workaround that still doesn't perform as well (even on 3.3+) as bytes formatting in 2.7. > [If speed is really an issue, we could make binary file/socket write methods unicode implementation aware. They could directly access the ascii (or latin-1) bytes in a unicode object, just as they do with a bytes object, and the extra copy could be skipped.] Yes, speed is really an issue - this kind of message construction is on the critical path of many of the more popular protocols implemented with Twisted. But trying to work around the performance issue by pretending that strings are bytes will just give new life to old bugs. We've been loudly rejecting unicode from sockets I think for as long as Python has had unicode, and that's the way it should remain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 04:03:08 2013 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 23 Jan 2013 03:03:08 +0000 Subject: [issue17016] _sre: avoid relying on pointer overflow In-Reply-To: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za> Message-ID: <1358910188.8.0.790321590735.issue17016@psf.upfronthosting.co.za> Matthew Barnett added the comment: Lines 1000 and 1084 will be a problem only if you're near the top of the address space. This is because: 1. ctx->pattern[1] will always be <= ctx->pattern[2]. 2. A value of 65535 in ctx->pattern[2] means unlimited, even though SRE_CODE is now UCS4. See also issue #13169. If the 'unlimited' value is raised then fixing those lines will become more urgent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 05:25:00 2013 From: report at bugs.python.org (Brian Thorne) Date: Wed, 23 Jan 2013 04:25:00 +0000 Subject: [issue15359] Sockets support for CAN_BCM In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za> Message-ID: <1358915100.92.0.782010614471.issue15359@psf.upfronthosting.co.za> Brian Thorne added the comment: I've added (some) docs and added checking of the BCM constants to the test_socket module. I would guess that checking each broadcast manager function provided by the kernel isn't required? ---------- Added file: http://bugs.python.org/file28805/bcm4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 08:11:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 07:11:30 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358897672.74.0.323995453244.issue3982@psf.upfronthosting.co.za> Message-ID: <1358924931.3453.0.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mardi 22 janvier 2013 ? 23:34 +0000, Terry J. Reedy a ?crit : > Terry J. Reedy added the comment: > > >it would probably be reasonable to make these protocols use str objects at the heart, and only convert to bytes after the formatting is done. > > I presume this would mean adding 'if py3: out = out.encode()' after > the formatting. As I said before, this works much better in 3.3+ than > in 3.2-. So what? We're discussing a feature that, at best, will be present in 3.4 and not before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 08:27:37 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 07:27:37 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <44306121-4684-459E-AFAA-47B934BEF7DE@twistedmatrix.com> Message-ID: <1358925897.3453.14.camel@localhost.localdomain> Antoine Pitrou added the comment: > > What I know from Twisted is there are many specific cases where, indeed, > > binary protocol strings are formed by string formatting, e.g. in the FTP > > implementation (and for good reason since those protocols are either ASCII > > or an ASCII superset). > > These protocols (SMTP, SIP, HTTP, IMAP, POP, FTP), are not ASCII (nor > are they an "ASCII superset"); they are ASCII commands interspersed > with binary data. The "ASCII superset commands" part is clearly separated from the "binary data" part. Your own LineReceiver is able to switch between "raw mode" and "line mode"; one is text and the other is binary. > In many cases - such as when expressing a length, or a checksum - you > _must_ treat them as bytes, or you will emit incorrect data on the > wire. This is a non-sequitur. You can fully well take the len() of some *binary* data, format it using "%d" in a *string* Content-Length header, then encode the headers using utf-8 (or whatever encoding scheme the protocol mandates). Then at the end you concatenate the encoded headers and the body. I'm sure you're already doing the moral equivalent of this, except that the encoding step is absent. So, yes, it is reasonably possible, and it even makes sense. > This is exactly why I do not particularly want bytes.format() to allow > the presence of strs as formatted values, although that *would* make > porting certain things easier. At this point, I would remind you that I'm not againt bytes.format(), but I'd like it to be discussed in the open rather on the bug tracker. And, yes, starting that discusssion is, IMO, the proponents' job :-) > even disregarding compatibility with a 2.x codebase, b''.join() and > b'' + b'' and (''.format()).encode('charmap') are all slower _and_ > more awkward than simply b''.format() or b''%. How can existing constructions be slower than non-existing constructions that don't have performance numbers at all? Besides, if b''.join() is too slow, it deserves to be improved. Or perhaps you should try bytearray instead, or even io.BytesIO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 08:29:08 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Jan 2013 07:29:08 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358926148.32.0.283164720724.issue3982@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After re-reading everything, I have somewhat changed my mind on this proposal. Perhaps 3.0 threw out too much, making it overly difficult to do some things that were to easy in 2.x and to write cross-version code. String formatting converts all arguments to strings, using str as the default converter, but gives particular attention to formatting ints and floats. It then interpolates the resulting strings into the template string. Until msg180430, posted just half a day ago, I did not see a coherent idea of what bytes.format should be. The main problem is that there is no general bytes converter equivalent to str. I believe this is the core reason bytes.format was eliminated in 3.0. Much of the discussion here and elsewhere has been about str.format + additions, where the additions would accommodate various possible conversions. But I now see that this was trying to do too much. Guido's subset proposal cuts this all out by proposing to only convert ints and floats as done in 2.x. So bytes.format would only convert ints and floats and otherwise would interpolate bytes into a bytes template. This should cover a large fraction of use cases. The user would be responsible for converting anything else, or converting ints and floats otherwise, with explicit calls to bytes, str.encode, struct.pack, or custom functions*.. I believe only two changes are needed to the specification of str.format, other than the obvious things like prefixing strings with 'b' and changing 'fill character' to 'fill byte'. Since general conversion would not be be done, the '! conversion' field would be eliminated. In the format specifier, the default 's' would mean that the corresponding argument must be a bytes objects, rather than any object converted by str. # possible portability function for 'other' classes: if py2: strb = str else: def strb(ob): return str(ob).encode() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 08:31:19 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 23 Jan 2013 07:31:19 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358926279.28.0.299507836287.issue3982@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I admit that it is puzzling that string interpolation is apparently the fastest way to assemble byte strings. It involves parsing the format string, so it ought to be slower than anything that merely concatenates (such as cStringIO). (I do understand why + is inefficient, as it creates temporary objects) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 09:02:35 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2013 08:02:35 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358926279.28.0.299507836287.issue3982@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I don't believe it either. I find join consistently faster than format: python2.7 -m timeit -s 'x = [b"x"*1000']*10 'b"".join(x)' 1000000 loops, best of 3: 0.686 usec per loop python2.7 -m timeit -s 'x = b"x"*1000' '(b"{}{}{}{}{}{}{}{}{}{}").format(x, x, x, x, x, x, x, x, x, x)' 100000 loops, best of 3: 2.37 usec per loop Try longer strings, same results (though less pronounced): python2.7 -m timeit -s 'x = [b"x"*10000']*10 'b"".join(x)' 100000 loops, best of 3: 3.54 usec per loop python2.7 -m timeit -s 'x = b"x"*10000' '(b"{}{}{}{}{}{}{}{}{}{}").format(x, x, x, x, x, x, x, x, x, x)' 100000 loops, best of 3: 7.35 usec per loop I'm guessing the advantage of format() is that it allows the occasional formatting of a float or int. And % is not significantly faster: python2.7 -m timeit -s 'x = b"x"*1000' '(b"%s%s%s%s%s%s%s%s%s%s") % (x, x, x, x, x, x, x, x, x, x)' 100000 loops, best of 3: 2.31 usec per loop python2.7 -m timeit -s 'x = b"x"*10000' '(b"%s%s%s%s%s%s%s%s%s%s") % (x, x, x, x, x, x, x, x, x, x)' 100000 loops, best of 3: 6.81 usec per loop python2.7 -m timeit -s 'x = b"x"*100000' '(b"%s%s%s%s%s%s%s%s%s%s") % (x, x, x, x, x, x, x, x, x, x)' 1000 loops, best of 3: 565 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 09:48:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Jan 2013 08:48:04 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <3YrgBC34FMzST5@mail.python.org> Roundup Robot added the comment: New changeset f18d11ab53a0 by Serhiy Storchaka in branch '3.3': Issue #16957: shutil.which() no longer searches a bare file name in the http://hg.python.org/cpython/rev/f18d11ab53a0 New changeset 7b51568cfbae by Serhiy Storchaka in branch 'default': Issue #16957: shutil.which() no longer searches a bare file name in the http://hg.python.org/cpython/rev/7b51568cfbae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 09:53:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 08:53:05 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <1358931185.55.0.946483268438.issue16957@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed. Thank you for for the patch. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 10:15:39 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 23 Jan 2013 09:15:39 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358932539.67.0.569063490788.issue14771@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 10:17:25 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 23 Jan 2013 09:17:25 +0000 Subject: [issue11201] Python installation error 2203 In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za> Message-ID: <1358932645.22.0.138923457892.issue11201@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> out of date stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 10:36:15 2013 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 23 Jan 2013 09:36:15 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358933775.67.0.0763907415483.issue3982@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think ''.join() will always be faster than ''.format(), for a number of reasons (some already stated): - it doesn't have to pass the format string - it doesn't have to do the __format__ lookup and call the resulting function (although I believe there's an optimization for str) - it doesn't have to consider the conversion and formatting steps Whether b''.format() would have to lookup and call __format__ remains to be seen. From what I've read, maybe baking in knowledge of bytes, float, and int would be good enough. I suspect there might be some need for datetimes, but I could be wrong. The above said, code using b''.format() would definitely be easier to write and understand that a lot of individual field formatting followed by a .join(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 10:58:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 09:58:10 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358935090.79.0.979595193234.issue3982@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Whether b''.format() would have to lookup and call __format__ remains > to be seen. From what I've read, maybe baking in knowledge of bytes, > float, and int would be good enough. I suspect there might be some > need for datetimes, but I could be wrong. The __bytes__ method (and/or tp_buffer) may be a better discriminator than __format__. It would also allow combining arbitrary buffer objects without making tons of copies. What it also means is that "format()" may not be the best method name for this. It is less about formatting than about combining. Also, it's not obvious what "formatting" a number as bytes should do. Should it mimick the bytes constructor: >>> bytes(5) b'\x00\x00\x00\x00\x00' Should it mimick the int to_bytes() method: >>> (5).to_bytes(4, 'little') b'\x05\x00\x00\x00' Numbers currently don't have a __bytes__ method: >>> (5).__bytes__() Traceback (most recent call last): File "", line 1, in AttributeError: 'int' object has no attribute '__bytes__' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 11:00:09 2013 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 23 Jan 2013 10:00:09 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358935209.07.0.0149329739995.issue3982@psf.upfronthosting.co.za> Eric V. Smith added the comment: I retract the datetime comment. Given what we're trying to accomplish, I think we only need to support types that are supported by 2.7's %-formatting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 11:03:18 2013 From: report at bugs.python.org (Tim Golden) Date: Wed, 23 Jan 2013 10:03:18 +0000 Subject: [issue14208] No way to recover original argv with python -m In-Reply-To: <1331016803.5.0.715499259579.issue14208@psf.upfronthosting.co.za> Message-ID: <1358935398.6.0.652336047129.issue14208@psf.upfronthosting.co.za> Tim Golden added the comment: My use case is the reloader or restarter. I've initially fallen foul of this when using the cherrypy reloader (which does an execv by building from sys.executable + sys.argv) but I also have web services running which I'd like to restart remotely by forcing them to execv themselves. It's trivial to retrieve the original command line from the Windows API, shlex.split it and pass it along to execv so this is hardly a showstopper. But it would be useful to have something equivalent built-in. ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 12:01:36 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Jan 2013 11:01:36 +0000 Subject: [issue12411] cgi.parse_multipart is broken on 3.x In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za> Message-ID: <3Yrk8H5ygjzSXx@mail.python.org> Roundup Robot added the comment: New changeset a46a0dafcb7a by Senthil Kumaran in branch '3.2': Issue #12411: Fix to cgi.parse_multipart to correctly use bytes boundaries and http://hg.python.org/cpython/rev/a46a0dafcb7a New changeset 59ea872d8b6b by Senthil Kumaran in branch '3.3': merge from 3.2 http://hg.python.org/cpython/rev/59ea872d8b6b New changeset 3d7000549eb1 by Senthil Kumaran in branch 'default': merge from 3.3 http://hg.python.org/cpython/rev/3d7000549eb1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 12:05:33 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 23 Jan 2013 11:05:33 +0000 Subject: [issue12411] cgi.parse_multipart is broken on 3.x In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za> Message-ID: <1358939133.42.0.297967401037.issue12411@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I updated the patch addressing Ezio's comments in the review system and also condensed the tests. This fixes the parse_multipart's byte handling at "some" level. The docstring of parse_multipart say that, this should be deprecated in favor of FieldStorage completely. I will have to trace through the argument and see what should be done here and then I shall close this bug. ---------- assignee: -> orsenthil resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 14:24:49 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Jan 2013 13:24:49 +0000 Subject: [issue17017] email.utils.getaddresses fails for certain addresses In-Reply-To: <1358898702.5.0.0944995793434.issue17017@psf.upfronthosting.co.za> Message-ID: <1358947489.49.0.438194225049.issue17017@psf.upfronthosting.co.za> R. David Murray added the comment: It's sort-of a bug, and sort-of not. getaddresses is expecting to parse an already unfolded header, but the pre-3.3 email package does not unfold headers automatically. See issue 11050 for more information. ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> email.utils.getaddresses behavior contradicts RFC2822 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 14:26:58 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 23 Jan 2013 13:26:58 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358947618.47.0.42198110942.issue16672@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The patch applied to the default branch should be reverted. The 2.7 _hotshot extension module follows the specifications of PyEval_SetTrace: """Set the tracing function to func. This is similar to PyEval_SetProfile(), except the tracing function does receive line-number events.""" ^^^^^^^^^^^^ The 2.7 patch breaks test_hotshot because PyTrace_LINE events are not sent anymore when f_trace is NULL. The first patch (already applied to the default branch), breaks also existing applications that expect to receive line events when they don't care to implement the following semantics defined by sys.settrace: """The trace function is invoked (with event set to 'call') whenever a new local scope is entered; it should return a reference to a local trace function to be used that scope, or None if the scope shouldn?t be traced.""" Those applications want to receive unconditionally line debug events. Attached is a patch that reverts the patch on the default branch. ---------- Added file: http://bugs.python.org/file28806/revert_f_trace_perfs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 14:32:22 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Jan 2013 13:32:22 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358947942.54.0.784184033969.issue16672@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: So, Xavier, are you saying that you are reverting the patch?. Could be possible to provide a "good" patch, with a correct test of the situation you describe? Or are you suggesting just revert this and close this bugentry for good?. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 14:38:55 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Jan 2013 13:38:55 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <3Yrndp4ggyzSZN@mail.python.org> Roundup Robot added the comment: New changeset cd87afe18ff8 by Benjamin Peterson in branch 'default': revert #16672 for incorrect semantics http://hg.python.org/cpython/rev/cd87afe18ff8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 14:49:04 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 23 Jan 2013 13:49:04 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358948944.44.0.422142287475.issue16672@psf.upfronthosting.co.za> Xavier de Gaye added the comment: It is not possible to improve the performances of the trace function set with sys.settrace without breaking backward compatibility for PyEval_SetTrace or without introducing a new PyEval_xxx of some sort. Yes, I suggest to revert this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 14:58:57 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 23 Jan 2013 13:58:57 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358949537.31.0.869241534405.issue16672@psf.upfronthosting.co.za> Xavier de Gaye added the comment: status should be close, I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 15:23:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 14:23:38 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358951018.13.0.436743044404.issue17012@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you, Ned, for information. Here is a patch which remove the first difference (processing an empty path). The second difference is not semantically significant and I'm not sure whether we need to get rid of it. ---------- keywords: +patch Added file: http://bugs.python.org/file28807/shutil_which_empty_path.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 15:24:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 14:24:02 +0000 Subject: [issue17012] Differences between /usr/bin/which and shutil.which() In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za> Message-ID: <1358951042.24.0.409909396325.issue17012@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 16:03:21 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Jan 2013 15:03:21 +0000 Subject: [issue5430] imaplib: must not replace LF or CR by CRLF in literals In-Reply-To: <1236325877.36.0.637700625895.issue5430@psf.upfronthosting.co.za> Message-ID: <1358953401.8.0.947680954451.issue5430@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 16:09:04 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Jan 2013 15:09:04 +0000 Subject: [issue3461] smtplib does not fully support IPv6 in EHLO In-Reply-To: <1217282925.26.0.916204427354.issue3461@psf.upfronthosting.co.za> Message-ID: <1358953744.2.0.785278555502.issue3461@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 16:09:44 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 23 Jan 2013 15:09:44 +0000 Subject: [issue16672] improve tracing performances when f_trace is NULL In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> Message-ID: <1358953784.82.0.855815246157.issue16672@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 16:15:21 2013 From: report at bugs.python.org (Marcin Szewczyk) Date: Wed, 23 Jan 2013 15:15:21 +0000 Subject: [issue17018] Inconsistent behaviour of methods waiting for child process Message-ID: <1358954121.08.0.546295178726.issue17018@psf.upfronthosting.co.za> New submission from Marcin Szewczyk: I've done some experiments with: 1) multiprocessing.Process.join() 2) os.waitpid() 3) subprocess.Popen.wait() These three methods behave completely different when interrupted with a signal which I find disturbing. Reactions are: 1) exit with no exception or special return code 2) OSError exception 3) quiet retry (no exit) The 1) case is very impractical. Is there any movement towards standardization of those 3? Now I know I can loop around Process.join() and check exitcode or is_alive, but it requires more code. It has been pointed out that it changed between 2.6 and 2.7. Associated bug: http://bugs.python.org/issue1731717 Relevant sources: http://svn.python.org/view/python/branches/release26-maint/Lib/multiprocessing/forking.py?revision=84031&view=markup http://hg.python.org/releasing/2.7.3/file/7bb96963d067/Lib/multiprocessing/forking.py http://hg.python.org/cpython/rev/41aef062d529/ I think the behaviour of those three should be at least documented, especially if every one of them behaves differently and it changes between versions. My environment is: $ python --version Python 2.7.3rc2 $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 7.0 (wheezy) Release: 7.0 Codename: wheezy $ uname -a Linux magazyn-ziarno 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux Filing a bug as advised on python-dev mailing list (). ---------- messages: 180465 nosy: wodny priority: normal severity: normal status: open title: Inconsistent behaviour of methods waiting for child process type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 16:26:56 2013 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 23 Jan 2013 15:26:56 +0000 Subject: [issue17018] Inconsistent behaviour of methods waiting for child process In-Reply-To: <1358954121.08.0.546295178726.issue17018@psf.upfronthosting.co.za> Message-ID: <1358954816.97.0.92288054627.issue17018@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 16:48:17 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Jan 2013 15:48:17 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358935090.79.0.979595193234.issue3982@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Remember, the only reason to add this would be to enable writing code that works in both 2.7 and 3.4. So it has to be called .format() and it has to format numbers as decimal strings by default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 16:51:01 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 23 Jan 2013 15:51:01 +0000 Subject: [issue17018] Inconsistent behaviour of methods waiting for child process In-Reply-To: <1358954121.08.0.546295178726.issue17018@psf.upfronthosting.co.za> Message-ID: <1358956261.12.0.434778864491.issue17018@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:13:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 16:13:51 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358957631.44.0.768083002762.issue14771@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Third argument of ioctl should be not " ", but a bytes object with platform dependent length sizeof(pid_t). Beside this, the code at the top of the module checks the same condition and skip the tests if it is wrong. Race condition happened -- the process has been put into the background between executing these two codes. What command line you run the test? ---------- nosy: +serhiy.storchaka status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:25:21 2013 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 23 Jan 2013 16:25:21 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358958321.33.0.252102844414.issue3982@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:26:28 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 16:26:28 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1358957631.44.0.768083002762.issue14771@psf.upfronthosting.co.za> Message-ID: <760034817.416145261.1358958382232.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Beside this, the code at the top of the module checks the same > condition and skip the tests if it is wrong. Race condition happened > -- the process has been put into the background between executing > these two codes. What command line you run the test? It happens (or happened) quite often when using the -j option to regrtest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:44:32 2013 From: report at bugs.python.org (mtb) Date: Wed, 23 Jan 2013 16:44:32 +0000 Subject: [issue17019] Invitation to connect on LinkedIn Message-ID: <321996729.23497561.1358959469883.JavaMail.app@ela4-app2315.prod> New submission from mtb: LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Matthew Matthew Burns unemployed at n/a Greater Los Angeles Area Confirm that you know Matthew Burns: https://www.linkedin.com/e/-3qcne3-hcapdpuw-2h/isd/10664060930/HGLNsmfN/?hs=false&tok=3M68u6D1DIClA1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-3qcne3-hcapdpuw-2h/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I3541514734_1/?hs=false&tok=1flNx1ai_IClA1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ---------- messages: 180469 nosy: zubah priority: normal severity: normal status: open title: Invitation to connect on LinkedIn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:45:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 16:45:40 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358959540.66.0.769854067976.issue14771@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you use -r option? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:46:22 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 23 Jan 2013 16:46:22 +0000 Subject: [issue17019] Invitation to connect on LinkedIn In-Reply-To: <321996729.23497561.1358959469883.JavaMail.app@ela4-app2315.prod> Message-ID: <1358959582.9.0.0893943398885.issue17019@psf.upfronthosting.co.za> Christian Heimes added the comment: Please don't spam the bug tracker! ---------- nosy: +christian.heimes resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:47:11 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 16:47:11 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1358959540.66.0.769854067976.issue14771@psf.upfronthosting.co.za> Message-ID: <1219945340.416204872.1358959624836.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Serhiy Storchaka added the comment: > > Do you use -r option? No. Usually just -j ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:56:35 2013 From: report at bugs.python.org (Nickolai Zeldovich) Date: Wed, 23 Jan 2013 16:56:35 +0000 Subject: [issue17016] _sre: avoid relying on pointer overflow In-Reply-To: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za> Message-ID: <1358960195.58.0.175127037544.issue17016@psf.upfronthosting.co.za> Nickolai Zeldovich added the comment: Lines 2777 and 3111 do indeed look suspect, because gcc can compile (ptr + offset < ptr) into (offset < 0): nickolai at sahara:/tmp$ cat x.c void bar(); void foo(char* ptr, int offset) { if (ptr + offset < ptr) bar(); } nickolai at sahara:/tmp$ gcc x.c -S -o - -O2 ... foo: .LFB0: .cfi_startproc testl %esi, %esi js .L4 rep ret .p2align 4,,10 .p2align 3 .L4: xorl %eax, %eax jmp bar .cfi_endproc ... nickolai at sahara:/tmp$ Lines 658, 678, 1000, 1084 are potentially problematic -- I don't know of current compilers that will do something unexpected, but it might be worth rewriting the code to avoid undefined behavior anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:59:21 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 16:59:21 +0000 Subject: [issue4934] tp_del and tp_version_tag undocumented In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za> Message-ID: <1358960361.04.0.497245393334.issue4934@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > tp_cache and tp_weaklist are also for internal use only, but are > documented. Ok, so I guess tp_version_tag and tp_del should also be documented as "for internal use only". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 17:59:53 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 16:59:53 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358960392.99.0.235531067383.issue14771@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is ? Can you please expose several lines of regrtest output before and after this error? When "/1" appeared? I?suspect test_gdb: $ ./python -m test.regrtest -j 2 test_gdb test_gdb [1]+ Stopped ./python -m test.regrtest -j 2 test_gdb test_gdb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 18:01:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 17:01:14 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358960474.57.0.718195365155.issue14771@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: $ ./python -m test.regrtest -j 2 test_gdb test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl [ 1/10] test_ioctl [ 2/10] test_ioctl [ 3/10] test_ioctl [ 4/10] test_ioctl [ 5/10] test_ioctl [ 6/10] test_ioctl [ 7/10] test_ioctl [ 8/10] test_ioctl test_ioctl skipped -- Neither the process group nor the session are attached to /dev/tty [ 9/10] test_ioctl test_ioctl skipped -- Neither the process group nor the session are attached to /dev/tty [10/10] test_gdb 8 tests OK. 2 tests skipped: test_ioctl test_ioctl ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 18:03:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 17:03:51 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358960631.65.0.823638831017.issue14771@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: $ ./python -m test.regrtest -j 4 test_gdb test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl [ 1/20] test_ioctl [ 2/20] test_ioctl [ 3/20] test_ioctl [ 4/20] test_ioctl [ 5/20] test_ioctl [ 6/20] test_ioctl [ 7/20] test_ioctl [ 8/20] test_ioctl [ 9/20] test_ioctl [10/20] test_ioctl [11/20] test_ioctl [12/20] test_ioctl [13/20] test_ioctl [14/20] test_ioctl [15/20] test_ioctl [16/20] test_ioctl [17/20] test_ioctl [18/20] test_ioctl test_ioctl skipped -- Neither the process group nor the session are attached to /dev/tty [19/20] test_ioctl [20/20/1] test_gdb test test_gdb failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_gdb.py", line 716, in test_threads cmds_after_breakpoint=['thread apply all py-bt']) File "/home/serhiy/py/cpython/Lib/test/test_gdb.py", line 170, in get_stack_trace self.assertEqual(err, '') AssertionError: 'Error occurred in Python command.\n' != '' - Error occurred in Python command. 18 tests OK. 1 test failed: test_gdb 1 test skipped: test_ioctl ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 18:05:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 17:05:44 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358960744.87.0.703800179045.issue14771@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Bingo! $ ./python -m test.regrtest -j 4 test_gdb test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl [ 1/20] test_ioctl [ 2/20] test_ioctl [ 3/20] test_ioctl [ 4/20] test_ioctl [ 5/20] test_ioctl [ 6/20] test_ioctl [ 7/20] test_ioctl [ 8/20] test_ioctl [ 9/20] test_ioctl test_ioctl skipped -- Neither the process group nor the session are attached to /dev/tty [10/20] test_ioctl [11/20/1] test_ioctl test test_ioctl failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_ioctl.py", line 66, in test_ioctl_mutate_2048 self._check_ioctl_mutate_len(2048) File "/home/serhiy/py/cpython/Lib/test/test_ioctl.py", line 54, in _check_ioctl_mutate_len self.assertIn(rpgrp, ids) AssertionError: 14270 not found in (14225, 4030) [12/20/1] test_ioctl test_ioctl skipped -- Neither the process group nor the session are attached to /dev/tty [13/20/1] test_ioctl [14/20/1] test_ioctl [15/20/1] test_ioctl [16/20/1] test_ioctl [17/20/1] test_ioctl test_ioctl skipped -- Neither the process group nor the session are attached to /dev/tty [18/20/1] test_ioctl [19/20/1] test_ioctl [20/20/1] test_gdb 16 tests OK. 1 test failed: test_ioctl 3 tests skipped: test_ioctl test_ioctl test_ioctl ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 18:11:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 17:11:29 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358961089.73.0.695469872077.issue14771@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nice catch, Serhiy. I wouldn't have suspected test_gdb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 18:11:50 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 17:11:50 +0000 Subject: [issue14771] Occasional failure in test_ioctl when run parallel with test_gdb In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358961110.05.0.311380979202.issue14771@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch title: Occasional failure in test_ioctl -> Occasional failure in test_ioctl when run parallel with test_gdb versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 18:32:12 2013 From: report at bugs.python.org (Floris van Manen) Date: Wed, 23 Jan 2013 17:32:12 +0000 Subject: [issue17020] random.random() generating values >= 1.0 Message-ID: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za> New submission from Floris van Manen: I recently noticed that the standard random() function generates values >= 1.0 As processes are called from an event scheduler, each process has its own Random() instance. self.random = random.Random(seed) self.randomState = self.random.getstate() keeping track of multiple objects: self.random.setstate(self.randomState) self.random.jumpahead(1) self.randomState = self.random.getstate() Also gammavariate() generates errors as it too makes use of the _random() call A workaround is to check each response of random() for values >= 1.0 ---------- assignee: ronaldoussoren components: Macintosh messages: 180480 nosy: klankschap, ronaldoussoren priority: normal severity: normal status: open title: random.random() generating values >= 1.0 type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 18:40:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 17:40:46 +0000 Subject: [issue14771] Occasional failure in test_ioctl when run parallel with test_gdb In-Reply-To: <1358961110.07.0.962181367094.issue14771@psf.upfronthosting.co.za> Message-ID: <201301231940.27941.storchaka@gmail.com> Serhiy Storchaka added the comment: Perhaps we need a possibility to mark a test that it can't run in parallel. I suspect some multiprocess tests fail for same reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:00:13 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Jan 2013 18:00:13 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za> Message-ID: <1358964013.8.0.0901772553701.issue17020@psf.upfronthosting.co.za> R. David Murray added the comment: Can you post a small program that demonstrates the problem? I'm certainly not seeing a problem just calling random.random() (and would be very surprised if I did). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:09:49 2013 From: report at bugs.python.org (Peter Otten) Date: Wed, 23 Jan 2013 18:09:49 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za> Message-ID: <1358964589.92.0.778449063543.issue17020@psf.upfronthosting.co.za> Peter Otten added the comment: This could be a duplicate of issue14591. ---------- nosy: +peter.otten _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:13:47 2013 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 23 Jan 2013 18:13:47 +0000 Subject: [issue17016] _sre: avoid relying on pointer overflow In-Reply-To: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za> Message-ID: <1358964827.91.0.726753390195.issue17016@psf.upfronthosting.co.za> Matthew Barnett added the comment: You're checking "int offset", but what happens with "unsigned int offset"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:14:41 2013 From: report at bugs.python.org (Nickolai Zeldovich) Date: Wed, 23 Jan 2013 18:14:41 +0000 Subject: [issue17016] _sre: avoid relying on pointer overflow In-Reply-To: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za> Message-ID: <1358964881.95.0.0912276798365.issue17016@psf.upfronthosting.co.za> Nickolai Zeldovich added the comment: For an unsigned int offset, see my original bug report: gcc eliminates the check altogether, since offset >= 0 by definition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:18:28 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Jan 2013 18:18:28 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za> Message-ID: <1358965108.54.0.0972810302615.issue17020@psf.upfronthosting.co.za> R. David Murray added the comment: That indeed looks likely. Fortunately there will be a new release of 2.7 including that fix soon. Floris, do you have any way to test against 2.7 tip? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:43:34 2013 From: report at bugs.python.org (Floris van Manen) Date: Wed, 23 Jan 2013 18:43:34 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358965108.54.0.0972810302615.issue17020@psf.upfronthosting.co.za> Message-ID: <37516943-A284-463A-B646-FB2185866847@klankschap.nl> Floris van Manen added the comment: On 23 Jan 2013, at 19:18, R. David Murray wrote: > > R. David Murray added the comment: > > That indeed looks likely. Fortunately there will be a new release of 2.7 including that fix soon. > > Floris, do you have any way to test against 2.7 tip? using 2.7.3 as well as pypy (based on 2.7.3) via macport. pypy version suffers from the same issue. i'm not (yet) familiar how to get the tip from 2.7.3 hint? .F ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:46:45 2013 From: report at bugs.python.org (Floris van Manen) Date: Wed, 23 Jan 2013 18:46:45 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358964589.92.0.778449063543.issue17020@psf.upfronthosting.co.za> Message-ID: <1B7F527E-7A78-4492-892C-815404888FFA@klankschap.nl> Floris van Manen added the comment: indeed, looks like the same. .F On 23 Jan 2013, at 19:09, Peter Otten wrote: > > Peter Otten added the comment: > > This could be a duplicate of issue14591. > > ---------- > nosy: +peter.otten > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:57:51 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Wed, 23 Jan 2013 18:57:51 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358925897.3453.14.camel@localhost.localdomain> Message-ID: <1762CE80-BF18-4D0C-8A80-8B666076F0BB@twistedmatrix.com> Glyph Lefkowitz added the comment: On Jan 22, 2013, at 11:27 PM, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > The "ASCII superset commands" part is clearly separated from the "binary > data" part. Your own LineReceiver is able to switch between "raw mode" > and "line mode"; one is text and the other is binary. This is incorrect. "Lines" are just CRLF (0x0D0A) separated chunks of data. For example, SMTP is always in line-mode, but messages ("data lines") may contain arbitrary 8-bit data. > This is a non-sequitur. You can fully well (...) > So, yes, it is reasonably possible, and it even makes sense. I concede it is possible to implement what you're talking about, but it still requires encoding things which are potentially 8-bit data. Yes, there are many corners of protocols where said data looks like text, but it is an optical illusion. >> even disregarding compatibility with a 2.x codebase, b''.join() and >> b'' + b'' and (''.format()).encode('charmap') are all slower _and_ >> more awkward than simply b''.format() or b''%. > > How can existing constructions be slower than non-existing constructions > that don't have performance numbers at all? Sorry, "in 2.x" :). > Besides, if b''.join() is too slow, it deserves to be improved. Or > perhaps you should try bytearray instead, or even io.BytesIO. As others have noted, b''.join is *not* slower than b''.format for simply assembling strings; b''.join is indeed faster at that and I didn't mean to say it wasn't. The performance improvement shows up when you are assembling complex messages that contain a smattering of ints, floats, and other chunks of bytes; mostly in that you can avoid a bunch of python code execution and python function calls when formatting those values. The trouble with cooking up an example of this is that it starts to involve a bunch of additional code complexity and it requires careful framing to make sure the other complexity isn't what's getting in the way. I will try to come up with one, maybe doing so will prove even this contention wrong. But, the main issue here is expressiveness, not performance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 19:58:20 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Wed, 23 Jan 2013 18:58:20 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358926279.28.0.299507836287.issue3982@psf.upfronthosting.co.za> Message-ID: <4228CBE4-155D-4A06-92F8-19726542293B@twistedmatrix.com> Glyph Lefkowitz added the comment: On Jan 22, 2013, at 11:31 PM, Martin v. L?wis wrote: > I admit that it is puzzling that string interpolation is apparently the fastest way to assemble byte strings. It involves parsing the format string, so it ought to be slower than anything that merely concatenates (such as cStringIO). (I do understand why + is inefficient, as it creates temporary objects) You're correct about this; see my previous comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 20:00:46 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Wed, 23 Jan 2013 19:00:46 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358935090.79.0.979595193234.issue3982@psf.upfronthosting.co.za> Message-ID: <45DF3CF9-A60E-4DC3-B961-31DD9753DB73@twistedmatrix.com> Glyph Lefkowitz added the comment: On Jan 23, 2013, at 1:58 AM, Antoine Pitrou wrote: > Numbers currently don't have a __bytes__ method: > >>>> (5).__bytes__() > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'int' object has no attribute '__bytes__' They do have some rather odd behavior when passed to the builtin though: >>> bytes(10) b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' It would be much more convenient for me if bytes(int) returned the ASCIIfication of that int; but honestly, even an error would be better than this behavior. (If I wanted this behavior - which I never have - I'd rather it be a classmethod, invoked like "bytes.zeroes(n)".) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 20:02:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 19:02:44 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <45DF3CF9-A60E-4DC3-B961-31DD9753DB73@twistedmatrix.com> Message-ID: <1358967604.3458.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > They do have some rather odd behavior when passed to the builtin > though: > > >>> bytes(10) > b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' > > It would be much more convenient for me if bytes(int) returned the > ASCIIfication of that int; but honestly, even an error would be better > than this behavior. (If I wanted this behavior - which I never have - > I'd rather it be a classmethod, invoked like "bytes.zeroes(n)".) I would agree with you, but it's probably too late to change... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 20:04:05 2013 From: report at bugs.python.org (Glyph Lefkowitz) Date: Wed, 23 Jan 2013 19:04:05 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1358967604.3458.1.camel@localhost.localdomain> Message-ID: <53DA5D90-95D2-411C-B711-6350707E10CC@twistedmatrix.com> Glyph Lefkowitz added the comment: On Jan 23, 2013, at 11:02 AM, Antoine Pitrou wrote: > I would agree with you, but it's probably too late to change... Understandable, and, in any case, out of scope for this ticket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 20:08:37 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 19:08:37 +0000 Subject: [issue14771] Occasional failure in test_ioctl when run parallel with test_gdb In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358968117.35.0.545766542126.issue14771@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Perhaps we need a possibility to mark a test that it can't run in parallel. > I suspect some multiprocess tests fail for same reason. Well, first I would like to know what the underlying problem is. -j doesn't use multiprocessing, it spawns standalone processes using the subprocess module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 20:17:58 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Jan 2013 19:17:58 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za> Message-ID: <1358968678.53.0.984449250065.issue17020@psf.upfronthosting.co.za> R. David Murray added the comment: hg pull http://hg.python.org/cpython hg up 2.7 There are also git and bzr mirrors, but I don't know their urls or how up to date they are. We could also just close this as a dup if you are pretty sure its the same problem (which it certainly sounds like it is) and you could post to that issue if your problem isn't solved by the RC for 2.7.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 20:20:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 19:20:40 +0000 Subject: [issue14771] Occasional failure in test_ioctl when run parallel with test_gdb In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358968840.19.0.266042716704.issue14771@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, I see, that's because of the "Skip if another process is in foreground" thing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 20:34:46 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 19:34:46 +0000 Subject: [issue14771] Occasional failure in test_ioctl when run parallel with test_gdb In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358969686.93.0.378259601255.issue14771@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Given what _check_ioctl_mutate_len() seems to be designed to check, perhaps we should relax: self.assertIn(rpgrp, ids) into: self.assertNotEqual(rpgrp, fill) or perhaps simply: self.assertGreater(rpgrp, 0) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 20:54:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Jan 2013 19:54:20 +0000 Subject: [issue14771] Occasional failure in test_ioctl when run parallel with test_gdb In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1358970860.19.0.0358086120925.issue14771@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, and the test_ioctl() method needs to be fixed too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 23 21:19:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Jan 2013 20:19:15 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za> Message-ID: <1358972355.21.0.0313686549602.issue13169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now RuntimeError is raised in this case. Here is a patch, which: 1) Increases the limit of repeat numbers to 4G (now SRE_CODE at least 32-bit). 2) Raises re.error exception if this limit is exceeded. 3) Fixes some minor related things. ---------- components: +Extension Modules, Regular Expressions keywords: +patch nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28808/re_maxrepeat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 00:55:20 2013 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 23 Jan 2013 23:55:20 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1358985319.99.0.460696249103.issue3982@psf.upfronthosting.co.za> Eric V. Smith added the comment: So it sounds like the use case is (as Glyph said in msg180432): - Provide a transition for users of 2.7's of str %-formatting into a style that's compatible with both str in 2.7 and bytes in 3.4. In that case the only options I see are to implement __mod__ or .format for bytes in 3.4. I'd of course prefer to use .format, although __mod__ would probably make the transition easier (no need to move to .format first). It would probably also make the implementation easier, since there's so much less code in str.__mod__. But let's assume we're using .format [1]. Given the restricted use case, and assuming we using .format, the implementation would not need to support: - Types other than bytes, int, float. - Subclasses of these types with custom formatting. - !s, !r, or !a (none of the ! conversions). [2] But it would support all of the specifiers for formatting strs (except now for bytes), floats, and ints. I haven't looked through the str.format or {str,int,float}.__format__ code since the PEP 393 work, so I'm not really sure if we could stringlib-ify the code again, or if it would just be easier to reimplement it as separate bytes-only code. [1] It's open for debate whether .format or .__mod__ is preferable. [2] Since %-formatting supports %r and %s, this point is arguable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 02:01:59 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 24 Jan 2013 01:01:59 +0000 Subject: [issue8478] tokenize.untokenize first token missing failure case In-Reply-To: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za> Message-ID: <1358989319.13.0.443954185822.issue8478@psf.upfronthosting.co.za> Changes by Thomas Kluyver : ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 02:27:30 2013 From: report at bugs.python.org (benrg) Date: Thu, 24 Jan 2013 01:27:30 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1358990850.05.0.650056835518.issue16701@psf.upfronthosting.co.za> benrg added the comment: This is bizarre: Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = y = [1, 2] >>> x += [3] >>> y [1, 2, 3] >>> x = y = {1, 2} >>> x -= {2} >>> y {1} >>> Since when has this been standard behavior? The documentation says: "An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a similar, but not exactly equal effect. In the augmented version, x is only evaluated once. Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target, the old object is modified instead." What is "when possible" supposed to mean here? I always thought it meant "when there are known to be no other references to the object". If op= is always destructive on lists and sets, then "where possible" needs to be changed to "always" and a prominent warning added, like "WARNING: X OP= EXPR DOES NOT BEHAVE EVEN REMOTELY LIKE X = X OP EXPR IN PYTHON WHEN X IS A MUTABLE OBJECT, IN STARK CONTRAST TO EVERY OTHER LANGUAGE WITH A SIMILAR SYNTAX." ---------- nosy: +benrg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 03:46:59 2013 From: report at bugs.python.org (Hank Christian) Date: Thu, 24 Jan 2013 02:46:59 +0000 Subject: [issue17021] Invitation to connect on LinkedIn Message-ID: <261743059.559914.1358995617320.JavaMail.app@ela4-app2309.prod> New submission from Hank Christian: LinkedIn ------------ Python, I'd like to add you to my professional network on LinkedIn. - Henry Henry Christian ADJUNCT PROFESSOR at Central Texas College Greater Los Angeles Area Confirm that you know Henry Christian: https://www.linkedin.com/e/-3qcne3-hcbawhei-t/isd/10674146693/f8KKDSuG/?hs=false&tok=1CeofNO2B6D5A1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-3qcne3-hcbawhei-t/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I3544543039_1/?hs=false&tok=2VYf22chR6D5A1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ---------- messages: 180502 nosy: hankchristian priority: normal severity: normal status: open title: Invitation to connect on LinkedIn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 03:50:04 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 02:50:04 +0000 Subject: [issue17021] Invitation to connect on LinkedIn In-Reply-To: <261743059.559914.1358995617320.JavaMail.app@ela4-app2309.prod> Message-ID: <1358995804.72.0.125735221211.issue17021@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 03:50:17 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 02:50:17 +0000 Subject: [issue17021] Invitation to connect on LinkedIn Message-ID: <1358995817.0.0.348409907153.issue17021@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg180502 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 04:06:32 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 03:06:32 +0000 Subject: [issue15919] hg.python.org: log page entries don't always link to revision In-Reply-To: <1347362900.6.0.139284928383.issue15919@psf.upfronthosting.co.za> Message-ID: <1358996792.97.0.537038735397.issue15919@psf.upfronthosting.co.za> Ezio Melotti added the comment: This should now be fixed (http://mail.python.org/pipermail/python-dev/2013-January/123680.html). > This seems to happen whenever the revision description begins with > text that results in a link to something else (e.g. an issue number). To elaborate a bit on what I wrote in the email, I'll provide a few examples. Here is a link to the revision page, to the bug tracker, and the 4 steps shows the original message, the resulting link in the "shortlog" page, the link added by interhg and how the browser interprets the invalid HTML: 1) issue at the beginning: #12345: fix foo <- commit message #12345: fix foo <- normal link #12345 fix foo <- interhg (invalid html) #12345 fix foo <- resulting html 2) issue in the middle: Issue #12345: fix foo <- commit message Issue #12345: fix foo <- normal link Issue #12345 fix foo <- interhg (invalid html) Issue #12345 fix foo <- resulting html In case 1) the revision link ends up being empty, and there's no way to get to the revision page. In case 2) everything before the issue number links to the revision page, the #12345 links to the bug tracker, and everything after that is not a link. > In contrast, the "graph" page seems always to link to the revision This seems to be because that page is not affected by the interhg extension. > the UI doesn't make a distinction between the portion of the > description that links to the revision and the portion that links > to the something else. That's because the link to the revision page ends right where the one for the issue begins. > For example, with description text "Fix for fcc629208842", FWIW all that I said about issues is true for changeset ids. However the fix I added for issue has not been applied for csids (they are not really common in commit messages, and usually they are not at the beginning). > It might be better if the revision link was separate from the > description text. I did the opposite -- I left the revision link there and created a separated link to the issue at the end of the description. I think this issue can be closed now, even if there still some room for improvement. ---------- assignee: -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 04:37:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 03:37:15 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1358998635.73.0.478702263053.issue16701@psf.upfronthosting.co.za> Ezio Melotti added the comment: > What is "when possible" supposed to mean here? Generally it means "when the object is mutable": >>> l = [1,2,3] >>> id(l) 3074713484 >>> l += [4] >>> id(l) 3074713484 >>> t = (1,2,3) >>> id(t) 3074704004 >>> t += (4,) >>> id(t) 3075304860 Tuples are not mutable, so it's not possible to modify them in place, and a new tuple needs to be created. Note that while most mutable objects in the stdlib that support += do indeed modify the object rather than creating a new one, I don't think this is strictly required. IOW that paragraph is already warning you that (with mutable objects) the object might be reused, depending on the implementation. Maybe this should be clarified? (IIRC in CPython it could be possible that in some situations an immutable object still has the same id after an augmented assignment, but, if it really happens, it is an implementation detail and shouldn't affect semantics.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 04:53:01 2013 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 24 Jan 2013 03:53:01 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za> Message-ID: <1358999581.3.0.808903557849.issue13169@psf.upfronthosting.co.za> Matthew Barnett added the comment: IMHO, I don't think that MAXREPEAT should be defined in sre_constants.py _and_ SRE_MAXREPEAT defined in sre_constants.h. (In the latter case, why is it in decimal?) I think that it should be defined in one place, namely sre_constants.h, perhaps as: #define SRE_MAXREPEAT ~(SRE_CODE)0 and then imported into sre_constants.py. That'll reduce the chance of an inadvertent mismatch, and it's the C code that's imposing the limit to the number of repeats, not the Python code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 04:53:52 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 24 Jan 2013 03:53:52 +0000 Subject: [issue15919] hg.python.org: log page entries don't always link to revision In-Reply-To: <1347362900.6.0.139284928383.issue15919@psf.upfronthosting.co.za> Message-ID: <1358999632.23.0.598802611125.issue15919@psf.upfronthosting.co.za> Chris Jerdonek added the comment: >> It might be better if the revision link was separate from the >> description text. > I did the opposite -- I left the revision link there and created a separated link to the issue at the end of the description. Some downsides of the selected approach are that it doesn't work for descriptions referencing more than one issue and/or containing a changeset reference. It also adds clutter by repeating the issue number. I may create a new issue for improving this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 05:10:02 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Jan 2013 04:10:02 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1359000602.86.0.893833148802.issue16701@psf.upfronthosting.co.za> R. David Murray added the comment: If you really want to freak out, try this: >>> x = ([],) >>> x[0] += [1] Traceback (most recent call last): File "", line 1, in TypeError: 'tuple' object does not support item assignment >>> x ([1],) but to answer your question, it has *always* worked that way, from the time augmented assignment was introduced (see, eg, issue 1306777, which was reported against python 2.4). Remember, Python names refer to pointers to objects, they are not variables in the sense that other languages have variables. Guido resisted augmented assignment for a long time. These confusions speak to why. As far as I know Ezio is correct, "when possible" means "when the target is mutable". The documentation should probably be clarified on that point. I'm not sure it is practical to let whether or not the target is mutated be an implementation detail. IMO the behavior must be clearly defined for each type that is built in to Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 05:59:57 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 04:59:57 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1359003597.91.0.0119699438017.issue16701@psf.upfronthosting.co.za> Ezio Melotti added the comment: To clarify, with "depends on the implementation" I meant the way a particular class is implemented (i.e. a class might decide to return a new object even if it's mutable). The behavior of built-in types is well defined and should be the same across all the Python implementations. Regarding the comment about immutable types, it's something specific to CPython (I don't remember the specific details though, so I might be wrong), and somewhat similar to: >>> 'a'*20 is 'a'*20 True >>> 'a'*25 is 'a'*25 False This shouldn't be a problem though, so if you e.g. do "x = y = immutableobj; y += 1", 'x' should never be affected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 06:04:16 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 05:04:16 +0000 Subject: [issue15919] hg.python.org: log page entries don't always link to revision In-Reply-To: <1347362900.6.0.139284928383.issue15919@psf.upfronthosting.co.za> Message-ID: <1359003856.97.0.477003679455.issue15919@psf.upfronthosting.co.za> Ezio Melotti added the comment: True. The fix is far from being ideal, but it's a good compromise given the limitations of interhg IMHO. An RFE for interhg should be created, to allow to specify the pages affected by each regex and/or use different regexs on different pages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 06:18:42 2013 From: report at bugs.python.org (benrg) Date: Thu, 24 Jan 2013 05:18:42 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1359004722.06.0.51526932482.issue16701@psf.upfronthosting.co.za> benrg added the comment: > As far as I know Ezio is correct, "when possible" means "when the target is mutable". The documentation should probably be clarified on that point. Yes, it needs to be made very, very clear in the documentation. As I said, I'm not aware of any other language in which var op= expr does not mean the same thing as var = var op expr. I'm actually amazed that neither of you recognize the weirdness of this behavior (and even more amazed that GvR apparently didn't). I'm an experienced professional programmer, and I dutifully read the official documentation cover to cover when I started programming in Python, and I interpreted this paragraph wrongly, because I interpreted it in the only way that made sense given the meaning of these operators in every other language that has them. Python is designed to be unsurprising; constructs generally mean what it looks like they mean. You need to explain this unique feature of Python in terms so clear that it can't possibly be mistaken for the behavior of all of the other languages. > Remember, Python names refer to pointers to objects, they are not variables in the sense that other languages have variables. That has nothing to do with this. Yes, in Python (and Java and Javascript and many other languages) all objects live on the heap, local variables are not first-class objects, and var = expr is a special form. That doesn't change the fact that in all of those other languages, var += expr means var = var + expr. In C++ local variables are first-class objects and var += expr means var.operator+=(expr) or operator+=(var, expr), and this normally modifies the thing on the left in a way that's visible through references. But in C++, var = var + expr also modifies the thing on the left, in the same way. In Python and Java and Javascript and ..., var = value never visibly mutates any heap object, and neither does var = var + value (in any library that defines a sane + operator), and therefore neither should var += value (again, in any sanely designed library). And it doesn't. Except in Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 07:22:22 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 06:22:22 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1359008542.86.0.495095094533.issue16701@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Python is designed to be unsurprising; constructs generally mean > what it looks like they mean. AFAIK in C "x += 1" is equivalent to "x++", and both are semantically more about incrementing (mutating) the value of x than about creating a new value that gets assigned to x. Likewise it seems to me more natural to interpret "x += y" as "add the value of y to the object x" than "add x and y together and save the result in x". Clearly if you are used to other languages with different semantics you might expect a different behavior, but you could say the same about the fact that int/int gives float on Python 3: it's surprising if you are used to other languages like C, but otherwise it's more natural. > I interpreted this paragraph wrongly, because I interpreted it in the > only way that made sense given the meaning of these operators in > every other language that has them. It seems to me that the documentation doesn't leave much room for interpretation regarding the fact that the object is mutated in place; the only problem is that it doesn't specify clearly what are the objects that do this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 07:40:31 2013 From: report at bugs.python.org (Atsuo Ishimoto) Date: Thu, 24 Jan 2013 06:40:31 +0000 Subject: [issue12782] Multiple context expressions do not support parentheses for continuation across lines In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za> Message-ID: <1359009631.31.0.552744726752.issue12782@psf.upfronthosting.co.za> Atsuo Ishimoto added the comment: In Python 3.3, we have contextlib.ExitStack() for multiple contexts. So, perhaps we can close this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 08:24:14 2013 From: report at bugs.python.org (Eric Snow) Date: Thu, 24 Jan 2013 07:24:14 +0000 Subject: [issue16803] Make test_importlib run tests under both _frozen_importlib and importlib._bootstrap In-Reply-To: <1356718069.62.0.143946538677.issue16803@psf.upfronthosting.co.za> Message-ID: <1359012254.15.0.963515671604.issue16803@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 08:43:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 07:43:51 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1359013431.35.0.665568797843.issue1159051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually previous patch doesn't fix original problem, it only ensure that GzipFile consistent with BZ2File and LZMAFile. To fix original problem we need other patch, and this patch looks as new feature for 3.4. Here is a sample patch for LZMAFile. BZ2File patch will be similar, and GzipFile patch will be more different and complex. Now error doesn't raised immediately when read the file unexpectedly ended if some data can be read. Instead maximal possible part of read data returned and exception raising deferred to next read (see tests). Perhaps we need a new flag for constructor or for read() which enables a new behavior (what will be a good name for this?). Or we can use a special value for size argument which means "read to the end as much as possible" (we can differentiate the behavior for size<0 and size=None). Unconditional enabling a new behavior for size >=0 is safe. ---------- type: behavior -> enhancement versions: -Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file28809/lzma_deferred_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 08:58:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 07:58:36 +0000 Subject: [issue12782] Multiple context expressions do not support parentheses for continuation across lines In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za> Message-ID: <1359014316.26.0.0710157853668.issue12782@psf.upfronthosting.co.za> Ezio Melotti added the comment: If this can't be fixed I think it should be at least documented in the FAQs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 09:01:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 08:01:18 +0000 Subject: [issue12782] Multiple context expressions do not support parentheses for continuation across lines In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za> Message-ID: <1359014478.72.0.522482733724.issue12782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a discussion about this on Python-Ideas: http://comments.gmane.org/gmane.comp.python.ideas/17597 http://mail.python.org/pipermail/python-ideas/2012-October/017610.html ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 09:30:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 08:30:24 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1358999581.3.0.808903557849.issue13169@psf.upfronthosting.co.za> Message-ID: <201301241030.07548.storchaka@gmail.com> Serhiy Storchaka added the comment: > (In the latter case, why is it in decimal?) Because SRE_MAXREPEAT is generated (as all sre_constants.h) from sre_constants.py (note changes at the end of sre_constants.py). I agree, that SRE_MAXREPEAT is imposed by the C code limitation and it will be better to defined it in C. But we can't just import C's define into Python. This requires more code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 09:52:28 2013 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 24 Jan 2013 08:52:28 +0000 Subject: [issue16208] getaddrinfo returns wrong results if IPv6 is disabled In-Reply-To: <1350029317.3.0.399140827664.issue16208@psf.upfronthosting.co.za> Message-ID: <1359017548.21.0.446638063209.issue16208@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Marc, I think you'll have to bring this up on the mailing list if you want to have anything changed. The developers on the nosy list have already closed this as "wont fix". They don't care anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 10:30:55 2013 From: report at bugs.python.org (Gabriel Nistor) Date: Thu, 24 Jan 2013 09:30:55 +0000 Subject: [issue17022] Inline assignation uses the newly created object Message-ID: <1359019855.42.0.818555984965.issue17022@psf.upfronthosting.co.za> New submission from Gabriel Nistor: I am using Lubuntu x64 version and python 3.2.3 I have a tree search method: node = self while xpaths: xpath = xpaths.popleft() for path, child in node.childrens.items(): if path == xpath: node = child break else: node = node.childrens[xpath] = Node(xpath) return node This fails because the node is created and then the node.childrens[xpath] assignation is done on the new created node rather then the old node, I needed to do something like: child = node.childrens[xpath] = Node(xpath) node = child to have the proper behavior. ---------- components: Interpreter Core messages: 180518 nosy: chupym priority: normal severity: normal status: open title: Inline assignation uses the newly created object versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 11:46:51 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 24 Jan 2013 10:46:51 +0000 Subject: [issue17022] Inline assignation uses the newly created object In-Reply-To: <1359019855.42.0.818555984965.issue17022@psf.upfronthosting.co.za> Message-ID: <1359024411.92.0.560077691055.issue17022@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 12:32:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 11:32:05 +0000 Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za> Message-ID: <1359027125.83.0.771716962245.issue9669@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can you please provide the tests? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 14:09:21 2013 From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=) Date: Thu, 24 Jan 2013 13:09:21 +0000 Subject: [issue17023] Subprocess does not find executable on Windows if it is PATH with quotes Message-ID: <1359032961.6.0.0734607018969.issue17023@psf.upfronthosting.co.za> New submission from Pekka Kl?rck: If you add a directory into PATH on Windows so that the directory is in quotes, subprocess does not find executables in it. They are found by the operating system, though, at least when run on the command prompt. To reproduce: C:\>python --version Python 2.7.3 C:\>type test\script.bat @echo off echo hello C:\>set ORIG=%PATH% C:\>set PATH=%ORIG%;test C:\>script.bat hello C:\>python -c "from subprocess import call; call('script.bat')" hello C:\>set PATH=%ORIG%;"test" C:\>script.bat hello C:\>python -c "from subprocess import call; call('script.bat')" Traceback (most recent call last): File "", line 1, in File "C:\Python27\lib\subprocess.py", line 493, in call return Popen(*popenargs, **kwargs).wait() File "C:\Python27\lib\subprocess.py", line 679, in __init__ errread, errwrite) File "C:\Python27\lib\subprocess.py", line 896, in _execute_child startupinfo) WindowsError: [Error 2] The system cannot find the file specified I don't think you ever need those quotes, even if the directory would have spaces, but it is very confusing that the behavior is different on the command prompt and with subprocess. Additionally, Linux does not suffer from this problem: $ python --version Python 2.7.3 $ cat test/script.sh #!/bin/sh echo "hello" $ PATH=$PATH:test script.sh hello $ PATH=$PATH:test python -c "from subprocess import call; call('script.sh')" hello $ PATH=$PATH:"test" script.sh hello $ PATH=$PATH:"test" python -c "from subprocess import call; call('script.sh')" hello ---------- messages: 180520 nosy: pekka.klarck priority: normal severity: normal status: open title: Subprocess does not find executable on Windows if it is PATH with quotes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 14:44:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 13:44:23 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za> Message-ID: <1359035063.9.0.15151843105.issue13169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated for addressing Ezio's and Matthew's comments. MAXREPEAT now defined in the C code. It lowered to 2G on 32-bit platform to fit repetition numbers into Py_ssize_t. The condition for raising of an exception now more complex: if the repetition number overflows Py_ssize_t it means the same as an infinity bound and in this case an exception is not raised (i.e. it never raised on 32-bit platform). Tests added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 14:45:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 13:45:10 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za> Message-ID: <1359035110.8.0.207994650493.issue13169@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file28810/re_maxrepeat2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 14:46:42 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Jan 2013 13:46:42 +0000 Subject: [issue17022] Inline assignment uses the newly created object In-Reply-To: <1359019855.42.0.818555984965.issue17022@psf.upfronthosting.co.za> Message-ID: <1359035202.33.0.571079462263.issue17022@psf.upfronthosting.co.za> R. David Murray added the comment: I agree that this is somewhat surprising, but it is working as intended. a = b = c is equivalent to a = c b = c except that the RHS is evaluated only once, which can be important. You were either expecting it to be equivalent to b = c a = c or expecting all of the LHS expressions to be evaluated before any assignments were done. It could have been implemented any of these ways (though the last one is much more complex to implement). Python chose the first way. There is a specific warning about this in the documentation, at the end of the section on assignment statements: http://docs.python.org/3/reference/simple_stmts.html#assignment-statements ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed title: Inline assignation uses the newly created object -> Inline assignment uses the newly created object type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 15:00:28 2013 From: report at bugs.python.org (Richard Wall) Date: Thu, 24 Jan 2013 14:00:28 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1359036028.54.0.906615491941.issue15340@psf.upfronthosting.co.za> Richard Wall added the comment: This bug also causes problems when you try to install Python in a Linux chroot environment or systemd-nspawn - before mounting devtmpfs. For example, this Redhat bug "yum traceback with python-2.6.6-29.el6_2.2 and higher + missing /dev/urandom" * https://bugzilla.redhat.com/show_bug.cgi?id=893034 ---------- nosy: +richardw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 15:29:41 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Jan 2013 14:29:41 +0000 Subject: [issue12323] ElementPath 1.3 expressions In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za> Message-ID: <3YsQjw354CzRJm@mail.python.org> Roundup Robot added the comment: New changeset 56a4561600ad by Eli Bendersky in branch 'default': Issue #12323: Strengthen error checking of the position XPath selectors http://hg.python.org/cpython/rev/56a4561600ad ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 15:31:10 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 24 Jan 2013 14:31:10 +0000 Subject: [issue12323] ElementPath 1.3 expressions In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za> Message-ID: <1359037870.73.0.62091379947.issue12323@psf.upfronthosting.co.za> Eli Bendersky added the comment: Agreed. I strengthened the error checking when parsing the path, so now hopefully many non-sensical positions will be rejected. Note that this is only for the default branch (the future Python 3.4), because I don't think this is important enough to warrant breaking existing pre-3.4 code. Only true bug fixes should go to released branches. ---------- resolution: rejected -> fixed stage: needs patch -> committed/rejected versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:10:08 2013 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 24 Jan 2013 15:10:08 +0000 Subject: [issue17024] cElementTree calls end() on parser taget even if start() fails Message-ID: <1359040208.76.0.707549580683.issue17024@psf.upfronthosting.co.za> New submission from Stefan Behnel: The following compatibility unit test fails for me in lxml since Py3.3. etree = xml.etree.ElementTree def test_parser_target_error_in_start(self): assertEqual = self.assertEqual events = [] class Target(object): def start(self, tag, attrib): events.append("start") assertEqual("TAG", tag) raise ValueError("TEST") def end(self, tag): events.append("end") assertEqual("TAG", tag) def close(self): return "DONE" parser = self.etree.XMLParser(target=Target()) try: parser.feed("") except ValueError: self.assertTrue('TEST' in str(sys.exc_info()[1])) else: self.assertTrue(False) # ERROR HERE - gives ["start", "end"] in Py3.3 self.assertEqual(["start"], events) It seems like cET doesn't handle exceptions early enough and still calls the end() method. Neither Python ElementTree nor lxml do this. Some more tests are here: https://github.com/lxml/lxml/blob/master/src/lxml/tests/test_elementtree.py#L3446 (all tests in that file are known to work with ET) ---------- components: Library (Lib), XML messages: 180526 nosy: eli.bendersky, scoder priority: normal severity: normal status: open title: cElementTree calls end() on parser taget even if start() fails type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:12:09 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 15:12:09 +0000 Subject: [issue17024] cElementTree calls end() on parser taget even if start() fails In-Reply-To: <1359040208.76.0.707549580683.issue17024@psf.upfronthosting.co.za> Message-ID: <1359040329.72.0.962978294831.issue17024@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:17:44 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Jan 2013 15:17:44 +0000 Subject: [issue9708] cElementTree iterparse does not support "parser" argument In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za> Message-ID: <3YsRnM4cnLzPN9@mail.python.org> Roundup Robot added the comment: New changeset cce526a28f81 by Eli Bendersky in branch '3.3': Issue #9708: Fix support for iterparse(parser=...) argument per documentation. http://hg.python.org/cpython/rev/cce526a28f81 New changeset 0c9268ac3ffa by Eli Bendersky in branch 'default': Issue #9708: Fix support for iterparse(parser=...) argument per documentation. http://hg.python.org/cpython/rev/0c9268ac3ffa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:19:56 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 24 Jan 2013 15:19:56 +0000 Subject: [issue9708] cElementTree iterparse does not support "parser" argument In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za> Message-ID: <1359040796.97.0.0405769254515.issue9708@psf.upfronthosting.co.za> Eli Bendersky added the comment: Support added in 3.3 and default Documentation patches should be done for 2.7 and 3.2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:26:23 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 24 Jan 2013 15:26:23 +0000 Subject: [issue9708] cElementTree iterparse does not support "parser" argument In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za> Message-ID: <1359041183.56.0.167824198956.issue9708@psf.upfronthosting.co.za> Eli Bendersky added the comment: Fix to 3.2 committed in 5b02d622d625 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:27:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 15:27:10 +0000 Subject: [issue14462] In re's named group the name cannot contain unicode characters In-Reply-To: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za> Message-ID: <1359041230.34.0.549714618352.issue14462@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which make re to use for groups the same rule as for Python 3 identifiers. In Python 2 the implementation confirms the documentation. ---------- keywords: +patch nosy: +serhiy.storchaka stage: needs patch -> patch review versions: +Python 3.4 -Python 2.7 Added file: http://bugs.python.org/file28811/re_unicode_identifiers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:28:46 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Jan 2013 15:28:46 +0000 Subject: [issue9708] cElementTree iterparse does not support "parser" argument In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za> Message-ID: <3YsS261nS6zRJm@mail.python.org> Roundup Robot added the comment: New changeset 8f2edea69d5d by Eli Bendersky in branch '2.7': Issue #9708: clarify doc of iterparse - cElementTree doesn't support the parser argument http://hg.python.org/cpython/rev/8f2edea69d5d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:29:16 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 24 Jan 2013 15:29:16 +0000 Subject: [issue9708] cElementTree iterparse does not support "parser" argument In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za> Message-ID: <1359041356.6.0.194652877592.issue9708@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:49:06 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 24 Jan 2013 15:49:06 +0000 Subject: [issue17025] reduce multiprocessing.Queue contention Message-ID: <1359042546.71.0.578815247507.issue17025@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: Here's an implementation of the idea posted on python-ideas (http://mail.python.org/pipermail/python-ideas/2013-January/018846.html). The principle is really simple, we just serialize/unserialize the objects before/after holding the locks. This leads to reduced contention. Here are the results of a benchmark using from 1 reader/1 writer up to 4 readers/4 writers, on a 8-cores box: without patch: $ ./python /tmp/multi_queue.py took 0.8340198993682861 seconds with 1 workers took 1.956531047821045 seconds with 2 workers took 3.175778865814209 seconds with 3 workers took 4.277260780334473 seconds with 4 workers with patch: $ ./python /tmp/multi_queue.py took 0.7945001125335693 seconds with 1 workers took 0.7428359985351562 seconds with 2 workers took 0.7897098064422607 seconds with 3 workers took 1.1860828399658203 seconds with 4 workers I tried Richard's suggestion of serializing the data inside put(), but this reduces performance quite notably: $ ./python /tmp/multi_queue.py took 1.412883996963501 seconds with 1 workers took 1.3212130069732666 seconds with 2 workers took 1.2271699905395508 seconds with 3 workers took 1.4817359447479248 seconds with 4 workers Although I didn't analyse it further, I guess one reason could be that if the serializing is done in put(), the feeder thread has nothing to do but keep waiting for data to be available from the buffer, send it, and block until there's more to do: basically, it almost doesn't use its time-slice, and spends its time blocking and doing context switches. ---------- files: queues_contention.diff keywords: patch messages: 180532 nosy: neologix, pitrou, sbt priority: normal severity: normal status: open title: reduce multiprocessing.Queue contention type: performance Added file: http://bugs.python.org/file28812/queues_contention.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 16:49:20 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 24 Jan 2013 15:49:20 +0000 Subject: [issue17025] reduce multiprocessing.Queue contention In-Reply-To: <1359042546.71.0.578815247507.issue17025@psf.upfronthosting.co.za> Message-ID: <1359042560.27.0.926438419796.issue17025@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file28813/multi_queue.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 17:44:54 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 24 Jan 2013 16:44:54 +0000 Subject: [issue17025] reduce multiprocessing.Queue contention In-Reply-To: <1359042546.71.0.578815247507.issue17025@psf.upfronthosting.co.za> Message-ID: <1161566103.419088047.1359045887257.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Here's an implementation of the idea posted on python-ideas > (http://mail.python.org/pipermail/python-ideas/2013-January/018846.html). > > The principle is really simple, we just serialize/unserialize the > objects before/after holding the locks. This leads to reduced > contention. I would like to suggest again my idea of doing it in Connection instead, with new methods (e.g. locked_send and locked_recv). Especially given it can be useful in user code to have a thread-safe Connection (I'm in this situation currently). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 18:06:14 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 24 Jan 2013 17:06:14 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1359047174.13.0.0571244157222.issue16993@psf.upfronthosting.co.za> Stefan Krah added the comment: Serhiy, test_pathext_checking still fails on many Windows buildbots: http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstable ---------- nosy: +skrah status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 18:18:33 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 24 Jan 2013 17:18:33 +0000 Subject: [issue17026] pdb frames accessible after the termination occurs on uncaught exception Message-ID: <1359047913.36.0.999891280978.issue17026@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The following test illustrates the problem. script.py contains the line "1 / 0". The 'bt' command is also wrong. $ python3 -m pdb script.py > /tmp/script.py(1)() -> 1 / 0 (Pdb) continue Traceback (most recent call last): File "/usr/local/lib/python3.3/pdb.py", line 1651, in main pdb._runscript(mainpyfile) File "/usr/local/lib/python3.3/pdb.py", line 1532, in _runscript self.run(statement) File "/usr/local/lib/python3.3/bdb.py", line 405, in run exec(cmd, globals, locals) File "", line 1, in File "/tmp/script.py", line 1, in 1 / 0 ZeroDivisionError: division by zero Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > /tmp/script.py(1)() -> 1 / 0 (Pdb) up > (1)() (Pdb) up > /usr/local/lib/python3.3/bdb.py(405)run() -> exec(cmd, globals, locals) (Pdb) up > /usr/local/lib/python3.3/pdb.py(1532)_runscript() -> self.run(statement) (Pdb) up > /usr/local/lib/python3.3/pdb.py(1651)main() -> pdb._runscript(mainpyfile) (Pdb) up *** Oldest frame (Pdb) ---------- components: Library (Lib) messages: 180535 nosy: xdegaye priority: normal severity: normal status: open title: pdb frames accessible after the termination occurs on uncaught exception type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 19:02:10 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 18:02:10 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1359050530.62.0.55713537329.issue16954@psf.upfronthosting.co.za> Ezio Melotti added the comment: I would suggest to adapt the comments to follow PEP 257, and in particular: """ The docstring is a phrase ending in a period. It prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ...". """ Currently there are two docstrings, one for write() and one for iterparse() (recently added in #9708). Only the former uses the correct form ("Return" instead of "Returns"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 19:09:22 2013 From: report at bugs.python.org (Sven Brauch) Date: Thu, 24 Jan 2013 18:09:22 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1359050962.17.0.339746968469.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: I have signed the contributor agreement and sent a scan to the specified mail address (received no reply so far, but I guess that's okay). Did anyone happen to find the time to look at the patches yet? Greetings, Sven ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 19:15:11 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 24 Jan 2013 18:15:11 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1359050530.62.0.55713537329.issue16954@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: On Thu, Jan 24, 2013 at 10:02 AM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > I would suggest to adapt the comments to follow PEP 257, and in particular: > """ > The docstring is a phrase ending in a period. It prescribes the function > or method's effect as a command ("Do this", "Return that"), not as a > description; e.g. don't write "Returns the pathname ...". > """ > > Currently there are two docstrings, one for write() and one for > iterparse() (recently added in #9708). Only the former uses the correct > form ("Return" instead of "Returns"). > Actually, the latter was copy-pasted from the ReST docs of the method. Does that PEP 257 suggestion apply to ReST docs as well, or do we have a discrepancy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 19:18:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 18:18:34 +0000 Subject: [issue16993] shutil.which() should preserve path case In-Reply-To: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za> Message-ID: <1359051514.29.0.825909518055.issue16993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you, Stefan. This relates to issue16957. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 19:19:14 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 18:19:14 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1359051554.78.0.285034472666.issue16954@psf.upfronthosting.co.za> Ezio Melotti added the comment: The docs should use "return" too, even though I'm not sure this is enforced. Consistency within the doc page is more important, but I don't think that consistency between comments and docstrings in the code or between docstrings and documentation is so important. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 19:40:16 2013 From: report at bugs.python.org (benrg) Date: Thu, 24 Jan 2013 18:40:16 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1359052816.69.0.160065600674.issue16701@psf.upfronthosting.co.za> benrg added the comment: > AFAIK in C "x += 1" is equivalent to "x++", and both are semantically > more about incrementing (mutating) the value of x than about creating a > new value that gets assigned to x. Likewise it seems to me more natural > to interpret "x += y" as "add the value of y to the object x" than "add > x and y together and save the result in x". Look, it's very simple: in C, ++x and x += 1 and x = x + 1 all mean the same thing. You can argue about how to describe the thing that they do, but there's only one thing to describe. Likewise, in every other language that borrows the op= syntax from C, it is a shorthand for the expanded version with the bare operator. As far as I know, Python is the only exception. If you know of another exception please say so. > >>> x = ([],) > >>> x[0] += [1] > Traceback (most recent call last): > File "", line 1, in > TypeError: 'tuple' object does not support item assignment > >>> x > ([1],) I actually knew about this. It's an understandably difficult corner case, since the exception is raised after __iadd__ returns, so there's no chance for it to roll back its changes. At least, I thought it was a difficult corner case back when I thought the in-place update was a mere optimization. But if += really means .extend() on lists, this should not raise an exception at all. In fact there's no sense in having __iadd__ return a value that gets assigned anywhere, since mutable objects always mutate and return themselves and immutable objects don't define __iadd__. It looks like the interface was designed with the standard semantics in mind but the implementation did something different, leaving a vestigial assignment that's always a no-op. What a disaster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 20:14:18 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 24 Jan 2013 19:14:18 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1359054858.49.0.0738363535804.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for signing the agreement. I'll try to look at the patches by the end of this weekend. Sorry for the delay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 20:20:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 19:20:33 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za> Message-ID: <1359055233.06.0.848866119215.issue13169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated for addressing Ezio's comments. Tests simplified and optimized a little as Ezio suggested. Added a test for implementation dependent behavior (I hope it will gone away at some day). ---------- Added file: http://bugs.python.org/file28814/re_maxrepeat3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 20:39:27 2013 From: report at bugs.python.org (David Lam) Date: Thu, 24 Jan 2013 19:39:27 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1359056367.32.0.437945018876.issue16954@psf.upfronthosting.co.za> David Lam added the comment: I had an innocent question about the format to use when listing function arguments in docstrings. In the PEP 257 doc, there's a single example: def complex(real=0.0, imag=0.0): """Form a complex number. Keyword arguments: real -- the real part (default 0.0) imag -- the imaginary part (default 0.0) I went digging through Lib/ for a good example to follow, but felt a little unsure because the exact format seemed to differ ever so slightly sometimes. Like in ipaddress.py, a colon is used instead of two hyphens, and it's indented: def ip_address(address): """Take an IP string/int and return an object of the correct type. Args: address: A string or integer, the IP address. Either IPv4 or IPv6 addresses may be supplied; integers less than 2**32 will be considered to be IPv4 by default. Is there an "ideal" example in the source to try to copy? (or maybe this is just a use-your-common-sense thing) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 20:43:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Jan 2013 19:43:15 +0000 Subject: [issue16954] Add docstrings for ElementTree module In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za> Message-ID: <1359056595.08.0.194073730764.issue16954@psf.upfronthosting.co.za> Ezio Melotti added the comment: > (or maybe this is just a use-your-common-sense thing) That's probably the best thing. I don't think we follow any specific convention for args in the docstring. Mostly they are just described in the text, without having lists of args. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 21:21:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Jan 2013 20:21:09 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1357772053.04.0.661587544729.issue10156@psf.upfronthosting.co.za> Message-ID: <201301242220.35371.storchaka@gmail.com> Serhiy Storchaka added the comment: There is a set of updated patches. ---------- Added file: http://bugs.python.org/file28815/unicode_globals-2.7_2.patch Added file: http://bugs.python.org/file28816/unicode_globals-3.2_2.patch Added file: http://bugs.python.org/file28817/unicode_globals-3.3_2.patch Added file: http://bugs.python.org/file28818/unicode_globals-3.4_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 8f2edea69d5d Objects/unicodeobject.c --- a/Objects/unicodeobject.c Thu Jan 24 07:28:33 2013 -0800 +++ b/Objects/unicodeobject.c Thu Jan 24 22:14:14 2013 +0200 @@ -93,15 +93,27 @@ #endif /* Free list for Unicode objects */ -static PyUnicodeObject *free_list; -static int numfree; +static PyUnicodeObject *free_list = NULL; +static int numfree = 0; /* The empty Unicode object is shared to improve performance. */ -static PyUnicodeObject *unicode_empty; +static PyUnicodeObject *unicode_empty = NULL; + +#define _Py_RETURN_UNICODE_EMPTY() \ + do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = _PyUnicode_New(0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + return (PyObject *)unicode_empty; \ + } while (0) /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyUnicodeObject *unicode_latin1[256]; +static PyUnicodeObject *unicode_latin1[256] = {NULL}; /* Default encoding to use and assume when NULL is passed as encoding parameter; it is initialized by _PyUnicode_Init(). @@ -110,7 +122,7 @@ PyUnicode_GetDefaultEncoding() APIs to access this global. */ -static char unicode_default_encoding[100]; +static char unicode_default_encoding[100 + 1] = "ascii"; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -204,7 +216,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -448,10 +460,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -497,10 +507,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single characters are shared when using this constructor. Restrict to ASCII, since the input must be UTF-8. */ @@ -1162,13 +1170,10 @@ } /* Convert to Unicode */ - if (len == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *)unicode_empty; - } - else - v = PyUnicode_Decode(s, len, encoding, errors); - + if (len == 0) + _Py_RETURN_UNICODE_EMPTY(); + + v = PyUnicode_Decode(s, len, encoding, errors); return v; onError: @@ -1381,7 +1386,7 @@ Py_DECREF(v); strncpy(unicode_default_encoding, encoding, - sizeof(unicode_default_encoding)); + sizeof(unicode_default_encoding) - 1); return 0; onError: @@ -8850,8 +8855,6 @@ void _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UNICODE linebreak[] = { 0x000A, /* LINE FEED */ @@ -8865,15 +8868,10 @@ }; /* Init the implementation */ - free_list = NULL; - numfree = 0; unicode_empty = _PyUnicode_New(0); if (!unicode_empty) return; - strcpy(unicode_default_encoding, "ascii"); - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -8918,15 +8916,11 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); + (void)PyUnicode_ClearFreeList(); } -------------- next part -------------- diff -r 5b02d622d625 Lib/re.py --- a/Lib/re.py Thu Jan 24 07:23:34 2013 -0800 +++ b/Lib/re.py Thu Jan 24 22:14:22 2013 +0200 @@ -233,7 +233,8 @@ alphanum = _alphanum_str s = list(pattern) for i, c in enumerate(pattern): - if c not in alphanum: + if c not in alphanum and not ('\U00010000'[1:] and + 0xdc00 <= ord(c) < 0xe000): if c == "\000": s[i] = "\\000" else: diff -r 5b02d622d625 Lib/sre_parse.py --- a/Lib/sre_parse.py Thu Jan 24 07:23:34 2013 -0800 +++ b/Lib/sre_parse.py Thu Jan 24 22:14:22 2013 +0200 @@ -177,26 +177,32 @@ class Tokenizer: def __init__(self, string): - self.string = string + if isinstance(string, bytes): + self.string = string.decode('latin1') + else: + self.string = string self.index = 0 self.__next() def __next(self): if self.index >= len(self.string): self.next = None return - char = self.string[self.index:self.index+1] - # Special case for the str8, since indexing returns a integer - # XXX This is only needed for test_bug_926075 in test_re.py - if char and isinstance(char, bytes): - char = chr(char[0]) + char = self.string[self.index] if char == "\\": try: c = self.string[self.index + 1] except IndexError: raise error("bogus escape (end of line)") - if isinstance(self.string, bytes): - c = chr(c) char = char + c + else: + c = char + if '\U00010000'[1:] and 0xd800 <= ord(c) < 0xdc00: + try: + c2 = self.string[self.index + len(char)] + if 0xdc00 <= ord(c2) < 0xe000: + char += c2 + except IndexError: + pass self.index = self.index + len(char) self.next = char def match(self, char, skip=1): @@ -238,7 +244,7 @@ if code and code[0] == IN: return code try: - c = escape[1:2] + c = escape[1:] if c == "x": # hexadecimal escape (exactly two digits) while source.next in HEXDIGITS and len(escape) < 4: @@ -255,8 +261,8 @@ return LITERAL, int(escape, 8) & 0xff elif c in DIGITS: raise error("bogus escape: %s" % repr(escape)) - if len(escape) == 2: - return LITERAL, ord(escape[1]) + if c: + return LITERAL, ord(c) except ValueError: pass raise error("bogus escape: %s" % repr(escape)) @@ -270,7 +276,7 @@ if code: return code try: - c = escape[1:2] + c = escape[1:] if c == "x": # hexadecimal escape while source.next in HEXDIGITS and len(escape) < 4: @@ -299,8 +305,8 @@ raise error("cannot refer to open group") return GROUPREF, group raise ValueError - if len(escape) == 2: - return LITERAL, ord(escape[1]) + if c: + return LITERAL, ord(c) except ValueError: pass raise error("bogus escape: %s" % repr(escape)) @@ -458,7 +464,7 @@ lo = code1[1] hi = code2[1] if hi < lo: - raise error("bad character range") + raise error("bad character range %x %x" % (lo, hi)) setappend((RANGE, (lo, hi))) else: raise error("unexpected end of regular expression") @@ -704,6 +710,7 @@ elif tail: raise error("bogus characters at end of regular expression") + #flags |= SRE_FLAG_DEBUG if flags & SRE_FLAG_DEBUG: p.dump() diff -r 5b02d622d625 Lib/test/test_re.py --- a/Lib/test/test_re.py Thu Jan 24 07:23:34 2013 -0800 +++ b/Lib/test/test_re.py Thu Jan 24 22:14:22 2013 +0200 @@ -522,12 +522,23 @@ self.assertMatch(re.escape(p), p) def test_re_escape_non_ascii(self): - s = 'xxx\u2620\u2620\u2620xxx' + #s = 'xxx\u2620\u2620\u2620xxx' + #s_escaped = re.escape(s) + #self.assertEqual(s_escaped, 'xxx\\\u2620\\\u2620\\\u2620xxx') + #self.assertMatch(s_escaped, s) + #self.assertMatch('.%s+.' % re.escape('\u2620'), s, + #'x\u2620\u2620\u2620x', (2, 7), re.search) + print('*********') + s = 'xxx\U0001d11e\U0001d11e\U0001d11exxx' s_escaped = re.escape(s) - self.assertEqual(s_escaped, 'xxx\\\u2620\\\u2620\\\u2620xxx') + p = re.compile('.%s+.' % re.escape('\U0001d11e'), re.DEBUG) + print(p.code) + m = re.search('.%s+.' % re.escape('\U0001d11e'), s) + self.assertEqual(m.group(), 'x\U0001d11e\U0001d11e\U0001d11ex') + self.assertEqual(s_escaped, 'xxx\\\U0001d11e\\\U0001d11e\\\U0001d11exxx') self.assertMatch(s_escaped, s) - self.assertMatch('.%s+.' % re.escape('\u2620'), s, - 'x\u2620\u2620\u2620x', (2, 7), re.search) + self.assertMatch('.%s+.' % re.escape('\U0001d11e'), s, + 'x\U0001d11e\U0001d11e\U0001d11ex', (2, len(s) - 2), re.search) def test_re_escape_non_ascii_bytes(self): b = 'y\u2620y\u2620y'.encode('utf-8') diff -r 5b02d622d625 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Thu Jan 24 07:23:34 2013 -0800 +++ b/Objects/unicodeobject.c Thu Jan 24 22:14:22 2013 +0200 @@ -98,18 +98,30 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* Free list for Unicode objects */ -static PyUnicodeObject *free_list; -static int numfree; +static PyUnicodeObject *free_list = NULL; +static int numfree = 0; /* The empty Unicode object is shared to improve performance. */ -static PyUnicodeObject *unicode_empty; +static PyUnicodeObject *unicode_empty = NULL; + +#define _Py_RETURN_UNICODE_EMPTY() \ + do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = _PyUnicode_New(0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + return (PyObject *)unicode_empty; \ + } while (0) /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyUnicodeObject *unicode_latin1[256]; +static PyUnicodeObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -214,7 +226,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -479,10 +491,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -528,10 +538,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single characters are shared when using this constructor. Restrict to ASCII, since the input must be UTF-8. */ @@ -1393,15 +1401,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *) unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -1421,12 +1425,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *) unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -8323,10 +8326,8 @@ Py_ssize_t nchars; size_t nbytes; - if (len < 1) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); if (len == 1 && PyUnicode_CheckExact(str)) { /* no repeat, return original string */ @@ -10056,8 +10057,6 @@ void _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UNICODE linebreak[] = { 0x000A, /* LINE FEED */ @@ -10071,14 +10070,10 @@ }; /* Init the implementation */ - free_list = NULL; - numfree = 0; unicode_empty = _PyUnicode_New(0); if (!unicode_empty) return; - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -10123,15 +10118,11 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); + (void)PyUnicode_ClearFreeList(); } @@ -10250,8 +10241,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } -------------- next part -------------- diff -r 99db73ce8374 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Thu Jan 24 20:03:49 2013 +0200 +++ b/Objects/unicodeobject.c Thu Jan 24 22:16:03 2013 +0200 @@ -179,17 +179,34 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* The empty Unicode object is shared to improve performance. */ -static PyObject *unicode_empty; +static PyObject *unicode_empty = NULL; + +#define _Py_INCREF_UNICODE_EMPTY() \ + do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = PyUnicode_New(0, 0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + } while (0) + +#define _Py_RETURN_UNICODE_EMPTY() \ + do { \ + _Py_INCREF_UNICODE_EMPTY(); \ + return unicode_empty; \ + } while (0) /* List of static strings. */ -static _Py_Identifier *static_strings; +static _Py_Identifier *static_strings = NULL; /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyObject *unicode_latin1[256]; +static PyObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -416,9 +433,8 @@ len = _PyUnicode_WSTR_LENGTH(unicode); if (len == 0) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (len == 1) { @@ -450,8 +466,8 @@ length = PyUnicode_GET_LENGTH(unicode); if (length == 0) { if (unicode != unicode_empty) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); + _Py_RETURN_UNICODE_EMPTY(); } return unicode_empty; } @@ -528,7 +544,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -1582,9 +1598,11 @@ return 0; if (length == 0) { + _Py_INCREF_UNICODE_EMPTY(); + if (!unicode_empty) + return -1; Py_DECREF(*p_unicode); *p_unicode = unicode_empty; - Py_INCREF(*p_unicode); return 0; } @@ -1731,10 +1749,8 @@ some optimizations which share commonly used objects. */ /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -1893,10 +1909,8 @@ PyObject *res; unsigned char max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) return get_latin1_char(u[0]); @@ -1916,10 +1930,8 @@ PyObject *res; Py_UCS2 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -1954,10 +1966,8 @@ PyObject *res; Py_UCS4 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -2249,10 +2259,8 @@ PyUnicode_FromWideChar(register const wchar_t *w, Py_ssize_t size) { if (w == NULL) { - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); PyErr_BadInternalCall(); return NULL; } @@ -3007,15 +3015,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -3035,12 +3039,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -4720,8 +4723,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* ASCII is equivalent to the first 128 ordinals in Unicode. */ @@ -5232,8 +5234,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #ifdef BYTEORDER_IS_LITTLE_ENDIAN @@ -6558,10 +6559,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* ASCII is equivalent to the first 128 ordinals in Unicode. */ if (size == 1 && (unsigned char)s[0] < 128) @@ -6940,8 +6939,7 @@ if (chunk_size == 0 && done) { if (v != NULL) break; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } @@ -9503,9 +9501,7 @@ /* If empty sequence, return u"". */ if (seqlen == 0) { Py_DECREF(fseq); - Py_INCREF(unicode_empty); - res = unicode_empty; - return res; + _Py_RETURN_UNICODE_EMPTY(); } /* If singleton sequence with an exact Unicode, return that. */ @@ -10205,7 +10201,9 @@ } new_size = slen + n * (len2 - len1); if (new_size == 0) { - Py_INCREF(unicode_empty); + _Py_INCREF_UNICODE_EMPTY(); + if (!unicode_empty) + goto error; u = unicode_empty; goto done; } @@ -11672,10 +11670,8 @@ PyErr_SetString(PyExc_IndexError, "string index out of range"); return NULL; } - if (start >= length || end < start) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (start >= length || end < start) + _Py_RETURN_UNICODE_EMPTY(); length = end - start; if (PyUnicode_IS_ASCII(self)) { @@ -11802,10 +11798,8 @@ PyObject *u; Py_ssize_t nchars, n; - if (len < 1) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); /* no repeat, return original string */ if (len == 1) @@ -12924,8 +12918,7 @@ { if (writer->pos == 0) { Py_XDECREF(writer->buffer); - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (writer->readonly) { assert(PyUnicode_GET_LENGTH(writer->buffer) == writer->pos); @@ -13143,8 +13136,7 @@ } if (slicelength <= 0) { - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } else if (start == 0 && step == 1 && slicelength == PyUnicode_GET_LENGTH(self)) { return unicode_result_unchanged(self); @@ -13974,10 +13966,8 @@ if (!PyArg_ParseTupleAndKeywords(args, kwds, "|Oss:str", kwlist, &x, &encoding, &errors)) return NULL; - if (x == NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (x == NULL) + _Py_RETURN_UNICODE_EMPTY(); if (encoding == NULL && errors == NULL) return PyObject_Str(x); else @@ -14146,8 +14136,6 @@ int _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UCS2 linebreak[] = { 0x000A, /* LINE FEED */ @@ -14161,13 +14149,13 @@ }; /* Init the implementation */ - unicode_empty = PyUnicode_New(0, 0); - if (!unicode_empty) - Py_FatalError("Can't create empty string"); + if (unicode_empty == NULL) { + unicode_empty = PyUnicode_New(0, 0); + if (!unicode_empty) + Py_FatalError("Can't create empty string"); + } assert(_PyUnicode_CheckConsistency(unicode_empty, 1)); - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -14207,15 +14195,10 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); _PyUnicode_ClearStaticStrings(); (void)PyUnicode_ClearFreeList(); } @@ -14344,8 +14327,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } -------------- next part -------------- diff -r ab0ff935126c Objects/unicodeobject.c --- a/Objects/unicodeobject.c Thu Jan 24 20:04:37 2013 +0200 +++ b/Objects/unicodeobject.c Thu Jan 24 22:16:10 2013 +0200 @@ -171,17 +171,32 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* The empty Unicode object is shared to improve performance. */ -static PyObject *unicode_empty; +static PyObject *unicode_empty = NULL; + +#define _Py_INCREF_UNICODE_EMPTY() do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = PyUnicode_New(0, 0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + } while (0) + +#define _Py_RETURN_UNICODE_EMPTY() do { \ + _Py_INCREF_UNICODE_EMPTY(); \ + return unicode_empty; \ + } while (0) /* List of static strings. */ -static _Py_Identifier *static_strings; +static _Py_Identifier *static_strings = NULL; /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyObject *unicode_latin1[256]; +static PyObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -406,9 +421,8 @@ len = _PyUnicode_WSTR_LENGTH(unicode); if (len == 0) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (len == 1) { @@ -442,8 +456,8 @@ length = PyUnicode_GET_LENGTH(unicode); if (length == 0) { if (unicode != unicode_empty) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); + _Py_RETURN_UNICODE_EMPTY(); } return unicode_empty; } @@ -520,7 +534,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -1602,9 +1616,11 @@ return 0; if (length == 0) { + _Py_INCREF_UNICODE_EMPTY(); + if (!unicode_empty) + return -1; Py_DECREF(*p_unicode); *p_unicode = unicode_empty; - Py_INCREF(*p_unicode); return 0; } @@ -1727,10 +1743,8 @@ some optimizations which share commonly used objects. */ /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -1889,10 +1903,8 @@ PyObject *res; unsigned char max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) return get_latin1_char(u[0]); @@ -1912,10 +1924,8 @@ PyObject *res; Py_UCS2 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -1950,10 +1960,8 @@ PyObject *res; Py_UCS4 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -2245,10 +2253,8 @@ PyUnicode_FromWideChar(register const wchar_t *w, Py_ssize_t size) { if (w == NULL) { - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); PyErr_BadInternalCall(); return NULL; } @@ -2825,15 +2831,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -2853,12 +2855,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -4201,8 +4202,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* Start off assuming it's all ASCII. Widen later as necessary. */ @@ -4609,8 +4609,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* ASCII is equivalent to the first 128 ordinals in Unicode. */ @@ -4868,8 +4867,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #ifdef WORDS_BIGENDIAN @@ -5108,8 +5106,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #if PY_LITTLE_ENDIAN @@ -5386,10 +5383,8 @@ Py_ssize_t len; len = length_of_escaped_ascii_string(s, size); - if (len == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len == 0) + _Py_RETURN_UNICODE_EMPTY(); /* After length_of_escaped_ascii_string() there are two alternatives, either the string is pure ASCII with named escapes like \n, etc. @@ -5781,10 +5776,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Escaped strings will always be longer than the resulting Unicode string, so we start with size here and then reduce the @@ -5988,10 +5981,8 @@ 1)) return NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* XXX overflow detection missing */ _PyUnicodeWriter_Init(&writer, 0); @@ -6439,10 +6430,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* ASCII is equivalent to the first 128 ordinals in Unicode. */ if (size == 1 && (unsigned char)s[0] < 128) @@ -6820,8 +6809,7 @@ if (chunk_size == 0 && done) { if (v != NULL) break; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } @@ -7298,10 +7286,8 @@ if (mapping == NULL) return PyUnicode_DecodeLatin1(s, size, errors); - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); _PyUnicodeWriter_Init(&writer, 0); if (_PyUnicodeWriter_Prepare(&writer, size, 127) == -1) goto onError; @@ -9354,9 +9340,7 @@ /* If empty sequence, return u"". */ if (seqlen == 0) { Py_DECREF(fseq); - Py_INCREF(unicode_empty); - res = unicode_empty; - return res; + _Py_RETURN_UNICODE_EMPTY(); } /* If singleton sequence with an exact Unicode, return that. */ @@ -10056,7 +10040,9 @@ } new_size = slen + n * (len2 - len1); if (new_size == 0) { - Py_INCREF(unicode_empty); + _Py_INCREF_UNICODE_EMPTY(); + if (!unicode_empty) + goto error; u = unicode_empty; goto done; } @@ -11559,10 +11545,8 @@ PyErr_SetString(PyExc_IndexError, "string index out of range"); return NULL; } - if (start >= length || end < start) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (start >= length || end < start) + _Py_RETURN_UNICODE_EMPTY(); length = end - start; if (PyUnicode_IS_ASCII(self)) { @@ -11689,10 +11673,8 @@ PyObject *u; Py_ssize_t nchars, n; - if (len < 1) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); /* no repeat, return original string */ if (len == 1) @@ -12832,8 +12814,7 @@ { if (writer->pos == 0) { Py_XDECREF(writer->buffer); - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (writer->readonly) { assert(PyUnicode_GET_LENGTH(writer->buffer) == writer->pos); @@ -13051,8 +13032,7 @@ } if (slicelength <= 0) { - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } else if (start == 0 && step == 1 && slicelength == PyUnicode_GET_LENGTH(self)) { return unicode_result_unchanged(self); @@ -14056,10 +14036,8 @@ if (!PyArg_ParseTupleAndKeywords(args, kwds, "|Oss:str", kwlist, &x, &encoding, &errors)) return NULL; - if (x == NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (x == NULL) + _Py_RETURN_UNICODE_EMPTY(); if (encoding == NULL && errors == NULL) return PyObject_Str(x); else @@ -14228,8 +14206,6 @@ int _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UCS2 linebreak[] = { 0x000A, /* LINE FEED */ @@ -14243,13 +14219,13 @@ }; /* Init the implementation */ - unicode_empty = PyUnicode_New(0, 0); - if (!unicode_empty) - Py_FatalError("Can't create empty string"); + if (unicode_empty == NULL) { + unicode_empty = PyUnicode_New(0, 0); + if (!unicode_empty) + Py_FatalError("Can't create empty string"); + } assert(_PyUnicode_CheckConsistency(unicode_empty, 1)); - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -14289,15 +14265,10 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); _PyUnicode_ClearStaticStrings(); (void)PyUnicode_ClearFreeList(); } @@ -14426,8 +14397,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } From report at bugs.python.org Thu Jan 24 21:42:09 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 24 Jan 2013 20:42:09 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1359060128.98.0.922534694089.issue10156@psf.upfronthosting.co.za> Nick Coghlan added the comment: Serhiy's general approach here looks good to me (although there seem to be some unrelated changes to the re module in the current 3.2 patch). For PEP 432, I want to try to rearrange things so that _PyUnicode_Init is one of the *first* calls made in Py_BeginInitialization (even before the general call to Py_ReadyTypes), but that still won't invalidate the work done here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 22:17:27 2013 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 24 Jan 2013 21:17:27 +0000 Subject: [issue12323] ElementPath 1.3 expressions In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za> Message-ID: <1359062247.48.0.414734964308.issue12323@psf.upfronthosting.co.za> Stefan Behnel added the comment: I agree that [0] should be treated as a visible error as it's easy to get wrong. It's certainly too late to change this to 0-based indexing and I think it's ok to keep it 1-based for XPath compatibility (or at least similarity) as that's what people will expect it to mimic. I came up with a similar fix for lxml, BTW. Regarding the behaviour of negative indices, it's clearly broken and unexpected and "-1" is definitely not a valid XML tag name (as which it's currently interpreted). That's a change for Py3.4+ only though. Either disable negative indices completely and raise an exception at parse time or read "-X" as "last()-X". I would also be ok with the latter as it feels natural to support this in a Python context. But that's a new feature then, not a bug fix. And the fact that "last()-X" already exists tends to speak against it. It's more of an "if the intention is clear, why raise an exception" kind of thing. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 22:36:16 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 24 Jan 2013 21:36:16 +0000 Subject: [issue12323] ElementPath 1.3 expressions In-Reply-To: <1359062247.48.0.414734964308.issue12323@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: > I agree that [0] should be treated as a visible error as it's easy to get > wrong. It's certainly too late to change this to 0-based indexing and I > think it's ok to keep it 1-based for XPath compatibility (or at least > similarity) as that's what people will expect it to mimic. I came up with a > similar fix for lxml, BTW. > > Regarding the behaviour of negative indices, it's clearly broken and > unexpected and "-1" is definitely not a valid XML tag name (as which it's > currently interpreted). That's a change for Py3.4+ only though. Either > disable negative indices completely and raise an exception at parse time or > read "-X" as "last()-X". I would also be ok with the latter as it feels > natural to support this in a Python context. But that's a new feature then, > not a bug fix. And the fact that "last()-X" already exists tends to speak > against it. It's more of an "if the intention is clear, why raise an > exception" kind of thing. > Stefan, IIUC, my recent commit (mirrored to the issue) is in accord with this comment. Please correct me if I'm wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 22:56:17 2013 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 24 Jan 2013 21:56:17 +0000 Subject: [issue12323] ElementPath 1.3 expressions In-Reply-To: <1307959893.21.0.719611338142.issue12323@psf.upfronthosting.co.za> Message-ID: <1359064577.88.0.266952759622.issue12323@psf.upfronthosting.co.za> Stefan Behnel added the comment: Yes, I think it makes sense to be rigid now and *maybe* add a new feature later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 24 23:30:50 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 24 Jan 2013 22:30:50 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1359066650.55.0.607886301301.issue16968@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm at a loss on this one. I tried a few different methods of wrapping the tests in load_tests(), I tried doing support.threading_setup() in setUpModule and support.threading_cleanup() in tearDownModule, tried the same in each test class (following the example of test_asynchat.TestAsynchat). Every way I've tried, I still get the warning that threading._dangling was modified when running the test as part of regrtest, even though it appears that everything is getting called at the right time with the right arguments. I did just stumble onto something interesting: if you simply remove the decorator and finally clause from test_main and run it (with the initial discovery patch applied), there is no warning at the end. Remove test_main and there's the warning. Add a load_tests that builds a suite in what appears to be the same order as what support.run_unittest does, and the warning is still there. I can't find what makes the difference. The attached diff is the best I've come up with that seems to do the right things with the reap functions, but still causes the warning on my machine. Am I missing something obvious here or what? ---------- Added file: http://bugs.python.org/file28819/test_concurrent_futures_discovery.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 01:14:46 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Jan 2013 00:14:46 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <1359072886.52.0.0420218031351.issue16335@psf.upfronthosting.co.za> Stefan Krah added the comment: I just ran the 2.7 tests while dealing with another issue, and I'm getting a memory error or excessive swapping in test_ucn: The statement x = b'\\N{SPACE' + b'x' * int(_testcapi.UINT_MAX + 1) + b'}' uses over 8GB on my system, so I think that minsize=_testcapi.UINT_MAX + 1 is too low. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 06:24:29 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 25 Jan 2013 05:24:29 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za> Message-ID: <1359091469.63.0.329308431052.issue17020@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Can you show how you determined that you got a value >= 1.0 or provide a seed that reproduces the problem? I'm not seeing an issue on the 2.7.3 64-bit Mac build: >>> from itertools import starmap, repeat >>> from random import random, seed >>> seed(56019413053459019451450201) >>> for i in range(20): print max(starmap(random, repeat((), 10000000))) 0.999999787916 0.999999859769 0.999999809486 0.99999968575 0.999999886565 0.999999991274 0.999999886922 0.999999874948 0.999999987989 0.999999751067 0.999999999353 0.999999935037 0.999999919091 0.999999664265 0.999999951016 0.999999998665 0.999999919618 0.999999786864 0.999999874042 0.999999967453 ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 06:36:07 2013 From: report at bugs.python.org (Sarbjit singh) Date: Fri, 25 Jan 2013 05:36:07 +0000 Subject: [issue17027] support for drag and drop of files to tkinter application Message-ID: <1359092167.25.0.0405358457492.issue17027@psf.upfronthosting.co.za> New submission from Sarbjit singh: It would be nice to have a support to drop the files (files from the file explorer i.e. from outside the application) to the tkinter application which could then set the file path/ directory path depending upon the configuration set in the module. This feature would be very helpful in applications where user need to select some file/directory. ---------- components: Tkinter messages: 180554 nosy: Sarbjit.singh priority: normal severity: normal status: open title: support for drag and drop of files to tkinter application type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 08:17:13 2013 From: report at bugs.python.org (Floris van Manen) Date: Fri, 25 Jan 2013 07:17:13 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1359091469.63.0.329308431052.issue17020@psf.upfronthosting.co.za> Message-ID: Floris van Manen added the comment: It is in the combination with jumpahead(), getstate(), setstate() that you'll experience random() to produce values >= 1.0 .F On 25 Jan 2013, at 06:24, Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > Can you show how you determined that you got a value >= 1.0 or provide a seed that reproduces the problem? > > I'm not seeing an issue on the 2.7.3 64-bit Mac build: > >>>> from itertools import starmap, repeat >>>> from random import random, seed >>>> seed(56019413053459019451450201) >>>> for i in range(20): > print max(starmap(random, repeat((), 10000000))) > > > 0.999999787916 > 0.999999859769 > 0.999999809486 > 0.99999968575 > 0.999999886565 > 0.999999991274 > 0.999999886922 > 0.999999874948 > 0.999999987989 > 0.999999751067 > 0.999999999353 > 0.999999935037 > 0.999999919091 > 0.999999664265 > 0.999999951016 > 0.999999998665 > 0.999999919618 > 0.999999786864 > 0.999999874042 > 0.999999967453 > > ---------- > nosy: +rhettinger > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 09:18:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 08:18:01 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <3YstQc54p3zSHr@mail.python.org> Roundup Robot added the comment: New changeset fc21f8e83062 by Serhiy Storchaka in branch '2.7': Don't run the test for issue #16335 when -M is not specified. http://hg.python.org/cpython/rev/fc21f8e83062 New changeset e3d1b68d34e3 by Serhiy Storchaka in branch '3.2': Increase the memory limit in the test for issue #16335. http://hg.python.org/cpython/rev/e3d1b68d34e3 New changeset 43907b88ce93 by Serhiy Storchaka in branch '3.3': Increase the memory limit in the test for issue #16335. http://hg.python.org/cpython/rev/43907b88ce93 New changeset fcdb35b114ab by Serhiy Storchaka in branch 'default': Increase the memory limit in the test for issue #16335. http://hg.python.org/cpython/rev/fcdb35b114ab ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 09:18:02 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 08:18:02 +0000 Subject: [issue16957] shutil.which() shouldn't look in working directory on unix-y systems In-Reply-To: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za> Message-ID: <3YstQd3c1bzSJB@mail.python.org> Roundup Robot added the comment: New changeset 99db73ce8374 by Serhiy Storchaka in branch '3.3': Fix pathext test for shutil.which() which was http://hg.python.org/cpython/rev/99db73ce8374 New changeset ab0ff935126c by Serhiy Storchaka in branch 'default': Fix pathext test for shutil.which() which was http://hg.python.org/cpython/rev/ab0ff935126c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 09:31:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 08:31:42 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <1359102702.51.0.85507954677.issue16335@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Bigmem test in 2.7 ran even if -M option is not specified and this causes the memory error. But memuse parameter should be increased (I tested with smaller sizes and found that 1 + 4 // len(u'\U00010000') is not enough, but 2 + 4 // len(u'\U00010000') is enough). Let's see if it helps. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 10:00:14 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 25 Jan 2013 09:00:14 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1359102702.51.0.85507954677.issue16335@psf.upfronthosting.co.za> Message-ID: <290231034.420952942.1359104408525.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Bigmem test in 2.7 ran even if -M option is not specified and this > causes the memory error. Ah, yes, that's because you should have used `size` instead of `_testcapi.UINT_MAX` inside the test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 10:43:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 09:43:49 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <290231034.420952942.1359104408525.JavaMail.root@zimbra10-e2.priv.proxad.net> Message-ID: <201301251143.30324.storchaka@gmail.com> Serhiy Storchaka added the comment: > Ah, yes, that's because you should have used `size` instead > of `_testcapi.UINT_MAX` inside the test. This test has sense only if size % (_testcapi.UINT_MAX + 1) == 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 10:55:17 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Jan 2013 09:55:17 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1359102702.51.0.85507954677.issue16335@psf.upfronthosting.co.za> Message-ID: <20130125095519.GA12454@sleipnir.bytereef.org> Stefan Krah added the comment: The test is fixed here, thanks. The limits appear to be different in 2.7 and 3.4: In 2.7 the bigmem tests are executed with -M x > 16G, in 3.4 with -M x >= 12G. I don't know if that's deliberate, just mentioning it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 11:07:46 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Jan 2013 10:07:46 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za> Message-ID: <1359108466.81.0.706104683417.issue17020@psf.upfronthosting.co.za> Stefan Krah added the comment: > It is in the combination with jumpahead(), getstate(), setstate() that you'll experience random() to produce values >= 1.0 Let me reiterate what David said: Can you post a self-contained program that exhibits the issue? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 11:20:52 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 10:20:52 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <1359109252.38.0.833640113253.issue16335@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Due to PEP 393 Python 3.3+ requires less memory for temporary output buffer. As for difference between ">" and ">=", the meaning of -M parameter a little differs in 2.7 and 3.x -- in 2.7 some overhead (5MiB) counted up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 11:31:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 10:31:12 +0000 Subject: [issue16686] audioop overflow issues In-Reply-To: <1355508907.39.0.527029919241.issue16686@psf.upfronthosting.co.za> Message-ID: <1359109872.71.0.609513893283.issue16686@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can anyone look at the patch? I want fix this issue before 2.7.4 RC released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 11:56:24 2013 From: report at bugs.python.org (Thomas Heller) Date: Fri, 25 Jan 2013 10:56:24 +0000 Subject: [issue17028] launcher Message-ID: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za> New submission from Thomas Heller: The python launcher does not parse the shebang if arguments for the Python interpreter are given on the command line. For example: py.exe test.py # uses shebang line py.exe -u test.py # does NOT use shebang line The attached patch fixes this. ---------- components: Windows files: launcher.patch keywords: patch messages: 180565 nosy: theller priority: normal severity: normal stage: patch review status: open title: launcher type: enhancement Added file: http://bugs.python.org/file28820/launcher.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 11:58:10 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 25 Jan 2013 10:58:10 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1359111490.95.0.558972457048.issue16968@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I looked into this a bit. It seems like this is because with the patch, the call to "loader.loadTestsFromModule(the_module)" inside regrtest comes before the try-finally: http://hg.python.org/cpython/file/fcdb35b114ab/Lib/test/regrtest.py#l1277 whereas with the current code, the analogous test-loading code is part of test.support.run_unittest() and so is protected by the try-finally inside test_main(). Apparently, simply discovering/loading tests from test_concurrent_futures.py is enough to modify threading._dangling (e.g. when finding the tests to pass to load_tests). I'm not sure yet what the right solution is, but it doesn't seem like test discovery should have that side effect. It could be because of how test_concurrent_futures is written, or because of certain initialization code in one of the modules it depends on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 12:13:36 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 25 Jan 2013 11:13:36 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1359112416.01.0.705389289502.issue16968@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I confirmed the above by changing regrtest as follows in the patch (moving the decorator from load_tests()), and trying both placements of the loadTestsFromModule() line. One gives the warning and one does not: if test_runner is None: loader = unittest.TestLoader() #tests = loader.loadTestsFromModule(the_module) @support.reap_threads def test_runner(): try: tests = loader.loadTestsFromModule(the_module) support.run_unittest(tests) finally: support.reap_children() test_runner() This is mostly a suggestion though -- not 100%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 12:35:11 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 11:35:11 +0000 Subject: [issue13454] crash when deleting one pair from tee() In-Reply-To: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za> Message-ID: <3Ysyp64CjMzS81@mail.python.org> Roundup Robot added the comment: New changeset f7e14a1af609 by Serhiy Storchaka in branch '3.2': Issue #13454: Fix a crash when deleting an iterator created by itertools.tee() http://hg.python.org/cpython/rev/f7e14a1af609 New changeset eff2a7346243 by Serhiy Storchaka in branch '3.3': Issue #13454: Fix a crash when deleting an iterator created by itertools.tee() http://hg.python.org/cpython/rev/eff2a7346243 New changeset 02d7a127fdfb by Serhiy Storchaka in branch 'default': Issue #13454: Fix a crash when deleting an iterator created by itertools.tee() http://hg.python.org/cpython/rev/02d7a127fdfb New changeset 62f2d3f6015e by Serhiy Storchaka in branch '2.7': Issue #13454: Fix a crash when deleting an iterator created by itertools.tee() http://hg.python.org/cpython/rev/62f2d3f6015e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 12:36:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 11:36:17 +0000 Subject: [issue13454] crash when deleting one pair from tee() In-Reply-To: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za> Message-ID: <1359113777.72.0.887227766458.issue13454@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 12:37:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 25 Jan 2013 11:37:44 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <201301251143.30324.storchaka@gmail.com> Message-ID: <1250396377.421402865.1359113857514.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Serhiy Storchaka added the comment: > > > Ah, yes, that's because you should have used `size` instead > > of `_testcapi.UINT_MAX` inside the test. > > This test has sense only if size % (_testcapi.UINT_MAX + 1) == 0. Why so? Does it fail otherwise? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 12:57:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 11:57:20 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <1359115040.93.0.331379123336.issue16335@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The test passed in any case, but for different size it doesn't check that the bug is fixed. Due to the bug bytes b'\\N{SPACExxxxxxxxxxxx...xxx'}' decoded as b'\\N{SPACE'}' if the number of x-es divisible by (UINT_MAX + 1). In this case unicode-escape decoding doesn't failed when the bug not fixed and failed (as expected) when the bug fixed. For all other numbers (>0) the decoding fails as when the bug fixed so when the bug is not fixed. And for other numbers the test is not relevant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 12:59:29 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 11:59:29 +0000 Subject: [issue17029] h2py.py: search the multiarch include dir if it does exist Message-ID: <1359115169.66.0.228835023529.issue17029@psf.upfronthosting.co.za> New submission from Matthias Klose: On MultiArch systems, header files are split into /usr/include and /usr/include/. Make sure that h2py finds all headers. Currently the build of IN.py is broken, when running on such a system. ---------- components: Build files: ma-h2py.diff keywords: patch messages: 180571 nosy: doko priority: normal severity: normal status: open title: h2py.py: search the multiarch include dir if it does exist versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28821/ma-h2py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 13:21:11 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 12:21:11 +0000 Subject: [issue17029] h2py.py: search the multiarch include dir if it does exist In-Reply-To: <1359115169.66.0.228835023529.issue17029@psf.upfronthosting.co.za> Message-ID: <3YszqC0ZSYzQyb@mail.python.org> Roundup Robot added the comment: New changeset 5981425cc48e by doko in branch '2.7': - Issue #17029: Let h2py search the multiarch system include directory. http://hg.python.org/cpython/rev/5981425cc48e New changeset 039e17133391 by doko in branch '3.2': - Issue #17029: Let h2py search the multiarch system include directory. http://hg.python.org/cpython/rev/039e17133391 New changeset c97447e36665 by doko in branch '3.3': - Issue #17029: Let h2py search the multiarch system include directory. http://hg.python.org/cpython/rev/c97447e36665 New changeset f69eced9ff9d by doko in branch 'default': - Issue #17029: Let h2py search the multiarch system include directory. http://hg.python.org/cpython/rev/f69eced9ff9d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 13:29:15 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Jan 2013 12:29:15 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1359116955.36.0.731401156968.issue10156@psf.upfronthosting.co.za> Stefan Krah added the comment: Since Rietveld didn't mail me this time: I left some comments on the 2.7 patch. ---------- versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 13:57:47 2013 From: report at bugs.python.org (Stephan) Date: Fri, 25 Jan 2013 12:57:47 +0000 Subject: [issue17030] strange import visibility Message-ID: <1359118666.97.0.0299772103321.issue17030@psf.upfronthosting.co.za> New submission from Stephan: $ cat a.py import dbus import b dbus.mainloop.glib.DBusGMainLoop(set_as_default=True) print "Hello, World." $ cat b.py import dbus.mainloop.glib $ python a.py Hello, World. $ If I remove the ?import b? line, the output is: $ python a.py Traceback (most recent call last): File "a.py", line 3, in dbus.mainloop.glib.DBusGMainLoop(set_as_default=True) AttributeError: 'module' object has no attribute 'mainloop' $ In my opinion this is inconsistent. Either both versions should fail with that error, because ?dbus.mainloop.glib? is imported in ?b?, not ?a?; or both should succeed, because ?a? imports dbus. This is Python 2.7.3 and python-dbus 1.0.0 on Ubuntu 12.4.2 ---------- components: Interpreter Core messages: 180574 nosy: geryon priority: normal severity: normal status: open title: strange import visibility type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:17:00 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 13:17:00 +0000 Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za> Message-ID: <1359119820.08.0.335631277465.issue15484@psf.upfronthosting.co.za> Matthias Klose added the comment: > 2-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfig.patch This looks ok to me, just factoring out some code and setting the project base. Even if distutils is frozen, I'll apply this one, based on Eric's comment in http://bugs.python.org/issue14330#msg164406 > 2-CROSS-set-_PYTHON_PROJECT_BASE-to-current-build-dir.patch I'll use abs_builddir instead. ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:21:57 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 25 Jan 2013 13:21:57 +0000 Subject: [issue17030] strange import visibility In-Reply-To: <1359118666.97.0.0299772103321.issue17030@psf.upfronthosting.co.za> Message-ID: <1359120117.15.0.173064785911.issue17030@psf.upfronthosting.co.za> R. David Murray added the comment: I agree that this is not immediately intuitive. What you need to know is that modules are part of the global state. When b imports dbus.mainloop.glib, it affects the global state of the module dbus, causing mainloop.glib to be defined when 'a' references it. The fact that modules are global state is inherent in Python's design, and is the reason that "monkey patching" works. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:22:50 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 13:22:50 +0000 Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za> Message-ID: <1359120170.06.0.0891295708925.issue15484@psf.upfronthosting.co.za> Matthias Klose added the comment: and adding the pybuilddir to PYTHONPATH, so that _sysconfigdata.py is found if it does exist. $(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:36:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 13:36:01 +0000 Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za> Message-ID: <3Yt1TX2dkPzRC0@mail.python.org> Roundup Robot added the comment: New changeset b2e7c85399f5 by doko in branch '3.3': - Issue #15484: Fix _PYTHON_PROJECT_BASE for srcdir != builddir builds; http://hg.python.org/cpython/rev/b2e7c85399f5 New changeset 172fec65c882 by doko in branch 'default': - Issue #15484: Fix _PYTHON_PROJECT_BASE for srcdir != builddir builds; http://hg.python.org/cpython/rev/172fec65c882 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:36:49 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 13:36:49 +0000 Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za> Message-ID: <1359121009.06.0.745660834576.issue15484@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:40:39 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Jan 2013 13:40:39 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1359121239.39.0.893184229389.issue10156@psf.upfronthosting.co.za> Stefan Krah added the comment: The 2.7 comments also apply to the 3.2 patch. Otherwise the 3.2 patch (without the _sre changes :) looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:44:31 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 13:44:31 +0000 Subject: [issue16292] Cross compilation fixes (general) In-Reply-To: <1350774308.18.0.656262327513.issue16292@psf.upfronthosting.co.za> Message-ID: <3Yt1gM0q6WzSJC@mail.python.org> Roundup Robot added the comment: New changeset 4c97d2d464ad by doko in branch '3.3': - Issue #16292: Improve a comment for cross building in configure.ac http://hg.python.org/cpython/rev/4c97d2d464ad New changeset 4feff8c8250b by doko in branch 'default': - Issue #16292: Improve a comment for cross building in configure.ac http://hg.python.org/cpython/rev/4feff8c8250b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:45:13 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 13:45:13 +0000 Subject: [issue16292] Cross compilation fixes (general) In-Reply-To: <1350774308.18.0.656262327513.issue16292@psf.upfronthosting.co.za> Message-ID: <1359121513.76.0.764481351547.issue16292@psf.upfronthosting.co.za> Matthias Klose added the comment: updated the comment, the fixes for the duplicate issues are checked in. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:53:01 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 25 Jan 2013 13:53:01 +0000 Subject: [issue17029] h2py.py: search the multiarch include dir if it does exist In-Reply-To: <1359115169.66.0.228835023529.issue17029@psf.upfronthosting.co.za> Message-ID: <1359121981.49.0.632596894259.issue17029@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 14:54:59 2013 From: report at bugs.python.org (Stephan) Date: Fri, 25 Jan 2013 13:54:59 +0000 Subject: [issue17030] strange import visibility In-Reply-To: <1359118666.97.0.0299772103321.issue17030@psf.upfronthosting.co.za> Message-ID: <1359122099.18.0.942718455979.issue17030@psf.upfronthosting.co.za> Stephan added the comment: Thanks! I was not aware of this yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:00:16 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 14:00:16 +0000 Subject: [issue3718] environment variable MACHDEP and python build system In-Reply-To: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za> Message-ID: <1359122416.22.0.463744804684.issue3718@psf.upfronthosting.co.za> Matthias Klose added the comment: the change to the configure script looks ok. however you could change the README too. It looks like the changes to the Makefile.pre.in are already applied. ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:06:04 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 14:06:04 +0000 Subject: [issue10782] Not possible to cross-compile due to poor detection of %lld support in printf In-Reply-To: <1293473376.4.0.265613686073.issue10782@psf.upfronthosting.co.za> Message-ID: <1359122764.82.0.555440943049.issue10782@psf.upfronthosting.co.za> Matthias Klose added the comment: in 3.3 and later, the test defaults to no when cross-building. If gcc is used for the cross build, then a compile test is used. it is usually needed to provide some values in a CONFIG_SITE file. See autoconf for the details. closing the issue. ---------- nosy: +doko status: languishing -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:14:11 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 14:14:11 +0000 Subject: [issue15483] CROSS: initialise include and library paths in setup.py In-Reply-To: <1343554833.66.0.976178324221.issue15483@psf.upfronthosting.co.za> Message-ID: <1359123251.11.0.249757185301.issue15483@psf.upfronthosting.co.za> Matthias Klose added the comment: I don't think this one is still necessary. can it be closed? ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:15:05 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 14:15:05 +0000 Subject: [issue9290] IDLE and Command line present different behavior for sys.stdin In-Reply-To: <1279417895.54.0.811089047738.issue9290@psf.upfronthosting.co.za> Message-ID: <3Yt2Lc380LzSLw@mail.python.org> Roundup Robot added the comment: New changeset def4cd7e0a9f by Serhiy Storchaka in branch '2.7': Issue #9290: In IDLE the sys.std* streams now implement io.TextIOBase http://hg.python.org/cpython/rev/def4cd7e0a9f New changeset 0d26f3aa7a8f by Serhiy Storchaka in branch '3.2': Issue #9290: In IDLE the sys.std* streams now implement io.TextIOBase http://hg.python.org/cpython/rev/0d26f3aa7a8f New changeset 9dfbd65d5041 by Serhiy Storchaka in branch '3.3': Issue #9290: In IDLE the sys.std* streams now implement io.TextIOBase http://hg.python.org/cpython/rev/9dfbd65d5041 New changeset 458b36fb12bc by Serhiy Storchaka in branch 'default': Issue #9290: In IDLE the sys.std* streams now implement io.TextIOBase http://hg.python.org/cpython/rev/458b36fb12bc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:20:37 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 25 Jan 2013 14:20:37 +0000 Subject: [issue16224] tokenize.untokenize() misbehaves when moved to "compatiblity mode" In-Reply-To: <1350194693.62.0.576275883555.issue16224@psf.upfronthosting.co.za> Message-ID: <1359123637.26.0.683853136933.issue16224@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I think this is a duplicate of #8478. ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:21:30 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 14:21:30 +0000 Subject: [issue17031] fix running regen in cross builds Message-ID: <1359123690.9.0.217015982102.issue17031@psf.upfronthosting.co.za> New submission from Matthias Klose: currently regen calls the python interpreter for the host, not the build machine. You can't directly use BUILD_FOR_PYTHON, because this one uses ./python explicitly, so use BUILDPYTHON instead. I'd like to see this for 3.3 and the trunk. ---------- assignee: doko components: Cross-Build files: regen.diff keywords: needs review, patch messages: 180588 nosy: doko priority: normal severity: normal status: open title: fix running regen in cross builds versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28822/regen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:25:46 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 25 Jan 2013 14:25:46 +0000 Subject: [issue8478] tokenize.untokenize first token missing failure case In-Reply-To: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za> Message-ID: <1359123946.24.0.482438369796.issue8478@psf.upfronthosting.co.za> Thomas Kluyver added the comment: #16224 appears to be a duplicate. There seem to be several quite major issues with untokenize - see also #12691 - with patches made to fix them. Is there anything I can do to help push these forwards? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:35:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 14:35:27 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <3Yt2p70X9JzSLm@mail.python.org> Roundup Robot added the comment: New changeset 11a18263ceb7 by doko in branch '2.7': - Issue #3754: fix typo in pthread AC_CACHE_VAL. http://hg.python.org/cpython/rev/11a18263ceb7 New changeset e28b30e6eee6 by doko in branch '3.2': - Issue #3754: fix typo in pthread AC_CACHE_VAL. http://hg.python.org/cpython/rev/e28b30e6eee6 New changeset 5464a534e7bd by doko in branch '3.3': - Issue #3754: fix typo in pthread AC_CACHE_VAL. http://hg.python.org/cpython/rev/5464a534e7bd New changeset ee48728e3695 by doko in branch 'default': - Issue #3754: fix typo in pthread AC_CACHE_VAL. http://hg.python.org/cpython/rev/ee48728e3695 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:42:54 2013 From: report at bugs.python.org (Ram Rachum) Date: Fri, 25 Jan 2013 14:42:54 +0000 Subject: [issue17032] Misleading error message: global name 'X' is not defined Message-ID: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za> New submission from Ram Rachum: Every single time I see the error message `global name 'X' is not defined` I say to myself, "ah yeah, I mistyped a variable name." But then it occurred to me, why should I have to do this mental translation from "global name not defined" to "I mistyped a variable name"? Now, I'm not asking for the error message to say "You mistyped a variable name", because that goes too much into second-guessing the user. But can we at least drop the reference to a global name? I understand that Python first searches the local namespace, and only then in the global namespace, and if the name isn't found there then an error is raised. But that doesn't mean that the error message should just assume that the variable is supposed to be global. It's misleading to say that a variable is global when it's in fact local. I think that the error message should just say `Variable 'X' not defined`. Maybe add a suggestion `(Typo?)` at the end. Example: >>> def f(): ... meow = 0 ... return meoow ... >>> f() Traceback (most recent call last): File "", line 1, in File "", line 3, in f NameError: global name 'meoow' is not defined I'd make the error message: NameError: Variable 'meoow' is not defined ---------- components: Interpreter Core messages: 180591 nosy: cool-RR priority: normal severity: normal status: open title: Misleading error message: global name 'X' is not defined type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:44:51 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 25 Jan 2013 14:44:51 +0000 Subject: [issue17032] Misleading error message: global name 'X' is not defined In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za> Message-ID: <1359125091.23.0.17100919228.issue17032@psf.upfronthosting.co.za> Ezio Melotti added the comment: Maybe we could just drop the 'global'. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 15:58:19 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 25 Jan 2013 14:58:19 +0000 Subject: [issue17032] Misleading error message: global name 'X' is not defined In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za> Message-ID: <1359125899.91.0.131886926436.issue17032@psf.upfronthosting.co.za> Ramchandra Apte added the comment: +1 on Ezio's idea. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 16:11:16 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 25 Jan 2013 15:11:16 +0000 Subject: [issue16292] Cross compilation fixes (general) In-Reply-To: <1350774308.18.0.656262327513.issue16292@psf.upfronthosting.co.za> Message-ID: <1359126676.22.0.800598055262.issue16292@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> fixed stage: -> committed/rejected versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 16:12:07 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 25 Jan 2013 15:12:07 +0000 Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za> Message-ID: <1359126727.66.0.320994350132.issue15484@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> fixed stage: -> committed/rejected versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 16:17:06 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 15:17:06 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1359127026.27.0.805134882578.issue3754@psf.upfronthosting.co.za> Matthias Klose added the comment: about py3k-20121004-CROSS.tgz: - committed 0001-CROSS-fix-typo-in-thread-AC_CACHE_VAL.patch - 0002-CROSS-restore-graminit.-to-source-directory.patch is this necessary? Assuming that you have correct time stamps, this is something which usually is not built during a cross build. Can we just have a shell script which touches some files so that you can cross-build even from the repository without building pgen? Do the release managers have such a script which is run when building a release? - 0003-CROSS-restore-importlib-header-to-source-directory-a.patch Same as for 0002, using correct timestamps. The EXEEXT is a different issue. However I'm not sure what to use, EXEEXT, or BUILDEXEEXT. - 0004-CROSS-restore-AST-to-source-directory.patch Same as for 0002. Btw, does this fail with a native out-of-tree build too? - 0005-CROSS-revert-issue13150-i.e.-python-solution-with-_s.patch A comment like "The fix for issue #13150 is bogus and break everything" might not the best way to convince maintainers ... This works for me, and IMO should be dropped, or please explain why this doesn't work for you. - 0006-CROSS-initialise-include-and-library-paths.patch Afaics, a similar patch is now applied. Can be dropped. - 0007-CROSS-set-_PYTHON_PROJECT_BASE-to-current-build-dir.patch Applied. - 0008-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfi.patch Applied. - 0009-CROSS-pass-all-top-configure-arguments-to-libffi-con.patch Why is it needed to pass all configure args? - 0010-CROSS-warn-only-if-readelf-is-not-in-host-triplet-fo.patch Why is this needed just for readelf? If you do have a cross toolchain installed, then this should be available with the triplet name, same as for gcc, as, ... - 0011-CROSS-append-gcc-library-search-paths-instead-to-pre.patch Looks ok. Could you mention where this does make a difference, or do you just want to keep the search order as defined by the compiler? - 0012-CROSS-avoid-ncursesw-include-path-hack.patch This would break cross-building in a multiarch environment. Maybe we need a --with-curses-incdir=<> option. - 0013-CROSS-properly-detect-WINDOW-_flags-for-different-nc.patch This should be a separate issue. Not cross specific. - 0014-CROSS-use-build-directory-as-root-for-regression-tes.patch why is this necessary? - 0015-CROSS-test-tools-has-to-depend-only-from-location-of.patch Looks ok, but not cross specific. Could you file a separate issue? - 0016-CROSS-reload-may-fail-with-operation-on-closed-file-.patch Looks like a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 16:44:24 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 15:44:24 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359128664.47.0.801938322492.issue3871@psf.upfronthosting.co.za> Matthias Klose added the comment: some random comments about py3k-20121004-MINGW.patch: - Modules/_ctypes/libffi_msvc/win32.S Please can you get rid of libffi_msvc and use libffi? afaics, libffi has support for mingw32. - there seem to be chunks which are unrelated to mingw, like: @@ -830,15 +926,18 @@ class PyBuildExt(build_ext): if have_usable_openssl: # The _hashlib module wraps optimized implementations # of hash functions from the OpenSSL library. + # NOTE: _hashlib require only OpenSSL crypto library ! exts.append( Extension('_hashlib', ['_hashopenssl.c'], depends = ['hashlib.h'], include_dirs = ssl_incs, library_dirs = ssl_libs, - libraries = ['ssl', 'crypto']) ) + libraries = ['crypto']) ) please file separate issues. - why setup_info.in. looks like something which could be done with get_config_var. - why re-reading files in setup.py, and grepping these for config options? I think the patch would benefit from splitting it up into several self-contained chunks. did you try to do builds for windows and linux after this patch was applied? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 16:53:33 2013 From: report at bugs.python.org (Taavi Burns) Date: Fri, 25 Jan 2013 15:53:33 +0000 Subject: [issue17033] RPM spec file has old config_binsuffix value Message-ID: <1359129213.62.0.851750342405.issue17033@psf.upfronthosting.co.za> New submission from Taavi Burns: Looking at the Misc/RPM/python-X.X.spec files, they seem to be slightly out of date. Near the top of the file is a config_binsuffix configuration setting that is "2.6" for both the 2.7 and 3.3 branches! I suspect that it should be updated with the version and libvers variables a bit later in the file. ---------- components: Build files: python-2.7.spec.diff keywords: patch messages: 180596 nosy: taavi-burns priority: normal severity: normal status: open title: RPM spec file has old config_binsuffix value versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file28823/python-2.7.spec.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 16:53:57 2013 From: report at bugs.python.org (Taavi Burns) Date: Fri, 25 Jan 2013 15:53:57 +0000 Subject: [issue17033] RPM spec file has old config_binsuffix value In-Reply-To: <1359129213.62.0.851750342405.issue17033@psf.upfronthosting.co.za> Message-ID: <1359129237.72.0.562747550236.issue17033@psf.upfronthosting.co.za> Taavi Burns added the comment: The diff against 3.3. ---------- Added file: http://bugs.python.org/file28824/python-3.3.spec.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 18:03:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 17:03:21 +0000 Subject: [issue1602133] non-framework python fails to define os.environ properly Message-ID: <3Yt64m4ZQDzSL0@mail.python.org> Roundup Robot added the comment: New changeset 864b9836dae6 by Ronald Oussoren in branch '2.7': Issue #1602133: 'environ' is not really available with shared libraries on OSX http://hg.python.org/cpython/rev/864b9836dae6 New changeset ea9fd9c9c677 by Ronald Oussoren in branch '3.2': Issue #1602133: 'environ' is not really available with shared libraries on OSX http://hg.python.org/cpython/rev/ea9fd9c9c677 New changeset 106d1d79c853 by Ronald Oussoren in branch '3.3': Issue #1602133: 'environ' is not really available with shared libraries on OSX (merge from 3.2) http://hg.python.org/cpython/rev/106d1d79c853 New changeset b41e3e2bd4cc by Ronald Oussoren in branch 'default': Issue #1602133: 'environ' is not really available with shared libraries on OSX (merge from 3.3) http://hg.python.org/cpython/rev/b41e3e2bd4cc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 18:04:15 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 25 Jan 2013 17:04:15 +0000 Subject: [issue1602133] non-framework python fails to define os.environ properly Message-ID: <1359133455.44.0.323815744951.issue1602133@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- stage: commit review -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 18:18:36 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 25 Jan 2013 17:18:36 +0000 Subject: [issue17031] fix running regen in cross builds In-Reply-To: <1359123690.9.0.217015982102.issue17031@psf.upfronthosting.co.za> Message-ID: <1359134316.92.0.534839514393.issue17031@psf.upfronthosting.co.za> ?ric Araujo added the comment: Not an autotools expert, but patch looks good. Apparently 3.3 is still open to such changes. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 18:20:37 2013 From: report at bugs.python.org (Thomas Heller) Date: Fri, 25 Jan 2013 17:20:37 +0000 Subject: [issue17028] launcher does not read shebang line when arguments are given In-Reply-To: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za> Message-ID: <1359134437.42.0.953810941069.issue17028@psf.upfronthosting.co.za> Changes by Thomas Heller : ---------- title: launcher -> launcher does not read shebang line when arguments are given _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 18:30:37 2013 From: report at bugs.python.org (Ned Deily) Date: Fri, 25 Jan 2013 17:30:37 +0000 Subject: [issue17027] support for drag and drop of files to tkinter application In-Reply-To: <1359092167.25.0.0405358457492.issue17027@psf.upfronthosting.co.za> Message-ID: <1359135037.73.0.481773125279.issue17027@psf.upfronthosting.co.za> Ned Deily added the comment: A feature like drag-and-drop seems like something that needs to be provided at either the application level or within Tk or both. While there is apparently no built-in Tk support for drag-and-drop, it appears to be possible to use a Tk extension that provides that capability and that will work with Tkinter. See, for example, http://stackoverflow.com/questions/14267900/python-drag-and-drop-explorer-files-to-tkinter-entry-widget ---------- nosy: +ned.deily resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 18:45:59 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 17:45:59 +0000 Subject: [issue17031] fix running regen in cross builds In-Reply-To: <1359123690.9.0.217015982102.issue17031@psf.upfronthosting.co.za> Message-ID: <3Yt71y4lBZzSML@mail.python.org> Roundup Robot added the comment: New changeset ff5cf42136b3 by doko in branch '3.3': - Issue #17031: Fix running regen in cross builds. http://hg.python.org/cpython/rev/ff5cf42136b3 New changeset 1942987921e9 by doko in branch 'default': - Issue #17031: Fix running regen in cross builds. http://hg.python.org/cpython/rev/1942987921e9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 18:47:31 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 17:47:31 +0000 Subject: [issue17031] fix running regen in cross builds In-Reply-To: <1359123690.9.0.217015982102.issue17031@psf.upfronthosting.co.za> Message-ID: <1359136051.72.0.917541834864.issue17031@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 19:03:31 2013 From: report at bugs.python.org (Matthias Klose) Date: Fri, 25 Jan 2013 18:03:31 +0000 Subject: [issue16235] Add python-config.sh for use during cross compilation. In-Reply-To: <1350251714.79.0.226527559426.issue16235@psf.upfronthosting.co.za> Message-ID: <1359137011.31.0.0533759325663.issue16235@psf.upfronthosting.co.za> Matthias Klose added the comment: so here is what I intend to commit. - --help now does exit with 0 (same as the python script) - removed the abi safety check (always compares the same two strings) - build the script for the build target, so that it can be checked before installing it. - install the old script in $(LIBPL). Maybe we can remove this later, or add this functionality into sysconfig. ---------- Added file: http://bugs.python.org/file28825/0001-add-python-config-sh.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 19:13:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 18:13:17 +0000 Subject: [issue9290] IDLE and Command line present different behavior for sys.stdin In-Reply-To: <1279417895.54.0.811089047738.issue9290@psf.upfronthosting.co.za> Message-ID: <1359137597.26.0.0813553300266.issue9290@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 19:16:57 2013 From: report at bugs.python.org (Floris van Manen) Date: Fri, 25 Jan 2013 18:16:57 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1359108466.81.0.706104683417.issue17020@psf.upfronthosting.co.za> Message-ID: Floris van Manen added the comment: On 25 Jan 2013, at 11:07, Stefan Krah wrote: > > Stefan Krah added the comment: > >> It is in the combination with jumpahead(), getstate(), setstate() that you'll experience random() to produce values >= 1.0 > > Let me reiterate what David said: Can you post a self-contained program > that exhibits the issue? My program is sort of complex in the meaning of multiple processes interleaving and interacting via a priorityqueue. Each individual steps through multiple classes which all should stay independent. No simple short snippet. >From what i understand is that issue14591 was able to reproduce the same feature as it seems related to the jumpahead() malfunctioning. .F ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 19:35:56 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Jan 2013 18:35:56 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: Message-ID: <20130125183558.GA17308@sleipnir.bytereef.org> Stefan Krah added the comment: Floris van Manen wrote: > From what i understand is that issue14591 was able to reproduce the same feature as it seems related to the jumpahead() malfunctioning. I'm also quite sure that it's the same issue. It would be nice to have confirmation though. If you have the opportunity to compile the tip of the 2.7 branch (where #14591 is fixed), get one of these: http://hg.python.org/cpython/archive/864b9836dae6.tar.gz http://hg.python.org/cpython/archive/864b9836dae6.zip ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 19:50:11 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 18:50:11 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1359139811.32.0.407272287712.issue15031@psf.upfronthosting.co.za> Brett Cannon added the comment: Nick's suggestions done in changeset 792810303239 . ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 19:57:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 18:57:23 +0000 Subject: [issue16972] Useless function call in site.py In-Reply-To: <1358263158.12.0.256435330615.issue16972@psf.upfronthosting.co.za> Message-ID: <3Yt8cL3KHYzSLy@mail.python.org> Roundup Robot added the comment: New changeset 2c0197c95ec6 by Brett Cannon in branch 'default': Issue #16972: Have site.addpackage() consider known paths even when http://hg.python.org/cpython/rev/2c0197c95ec6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 19:57:59 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 18:57:59 +0000 Subject: [issue16972] Useless function call in site.py In-Reply-To: <1358263158.12.0.256435330615.issue16972@psf.upfronthosting.co.za> Message-ID: <1359140279.14.0.360986905729.issue16972@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the bug report, Kirill! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:09:58 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:09:58 +0000 Subject: [issue3099] On windows, "import nul" always succeed In-Reply-To: <1213319928.58.0.193615390811.issue3099@psf.upfronthosting.co.za> Message-ID: <1359140998.71.0.715518116396.issue3099@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:14:08 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:14:08 +0000 Subject: [issue4180] warnings.simplefilter("always") does not make warnings always show up In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za> Message-ID: <1359141248.16.0.692549257185.issue4180@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:14:46 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:14:46 +0000 Subject: [issue762963] timemodule.c: Python loses current timezone Message-ID: <1359141286.82.0.366323598388.issue762963@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:17:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:17:43 +0000 Subject: [issue12583] More detailed ImportError messages In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za> Message-ID: <1359141463.46.0.938662803158.issue12583@psf.upfronthosting.co.za> Brett Cannon added the comment: Closing as circular imports are not as much of a problem in Python 3.3, ImportError now has informational attributes, and namespace packages took care of the usefulness of ImportWarning. ---------- assignee: -> brett.cannon resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:18:16 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:18:16 +0000 Subject: [issue1284670] Allow to restrict ModuleFinder to get "direct" dependencies Message-ID: <1359141496.53.0.652707632005.issue1284670@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:19:22 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:19:22 +0000 Subject: [issue12652] Keep test.support docs out of the global docs index In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za> Message-ID: <1359141562.45.0.753357610003.issue12652@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:20:18 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:20:18 +0000 Subject: [issue12648] Wrong import module search order on Windows In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za> Message-ID: <1359141618.05.0.658981822301.issue12648@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:21:38 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:21:38 +0000 Subject: [issue11049] add tests for test.support In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za> Message-ID: <1359141698.19.0.673164914317.issue11049@psf.upfronthosting.co.za> Brett Cannon added the comment: Can this be closed, David? ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:21:51 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:21:51 +0000 Subject: [issue11049] add tests for test.support In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za> Message-ID: <1359141711.46.0.135913264466.issue11049@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:23:58 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:23:58 +0000 Subject: [issue12701] Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za> Message-ID: <1359141838.31.0.990515308821.issue12701@psf.upfronthosting.co.za> Brett Cannon added the comment: Is this still a problem in clang 3.2? ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:24:10 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:24:10 +0000 Subject: [issue12701] Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za> Message-ID: <1359141850.81.0.918972054422.issue12701@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:25:00 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 25 Jan 2013 19:25:00 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1359141900.51.0.741629070789.issue16795@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I'm not sure how to make hg include a commit message in the patch... See hg help export. (In Mercurial, the only objects are changesets; hg log trawls through commit messages (with options to see short text, full text, diff), hg diff only shows diff, and hg export is the command to output full changesets.) ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:25:33 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:25:33 +0000 Subject: [issue12693] test.support.transient_internet prints to stderr when verbose is false In-Reply-To: <1312521271.03.0.978158187308.issue12693@psf.upfronthosting.co.za> Message-ID: <1359141933.37.0.498652331131.issue12693@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:27:26 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:27:26 +0000 Subject: [issue3329] API for setting the memory allocator used by Python In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za> Message-ID: <1359142046.31.0.279782831608.issue3329@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:30:20 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 25 Jan 2013 19:30:20 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1359142220.78.0.871942922201.issue16795@psf.upfronthosting.co.za> Ezio Melotti added the comment: It's not necessary to include the commit message and/or use "hg export" though, since we don't import patches directly and we write the message ourself when we commit. > (... is there a better way to upload three files?) You need to upload them individually and "submit changes" 3 times, but it's not necessary to write a comment every time. Also, unless the 3 patches are independent, it's usually better to upload a single diff that includes all the necessary changes. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:31:04 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:31:04 +0000 Subject: [issue10588] imp.find_module raises unexpected SyntaxError In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za> Message-ID: <1359142264.05.0.295965178516.issue10588@psf.upfronthosting.co.za> Brett Cannon added the comment: imp.find_module() is now documented as deprecated, so changing the mode that files are opened in would change backwards-compatibility but wouldn't be worth it. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:32:38 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:32:38 +0000 Subject: [issue11676] Improve imp.load_module and submodules doc In-Reply-To: <1301089227.12.0.157951103986.issue11676@psf.upfronthosting.co.za> Message-ID: <1359142358.39.0.102196099283.issue11676@psf.upfronthosting.co.za> Brett Cannon added the comment: imp.find_module() is now deprecated, so not worrying about adding more details to the docs for the function. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:33:15 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:33:15 +0000 Subject: [issue13048] Handling of paths in first argument of imp.find_module() In-Reply-To: <1316984733.77.0.135974751185.issue13048@psf.upfronthosting.co.za> Message-ID: <1359142395.69.0.620724437525.issue13048@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:34:04 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 25 Jan 2013 19:34:04 +0000 Subject: [issue13047] imp.find_module("") and imp.find_module(".") In-Reply-To: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za> Message-ID: <1359142444.63.0.318610476141.issue13047@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:39:55 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 25 Jan 2013 19:39:55 +0000 Subject: [issue17033] RPM spec file has old config_binsuffix value In-Reply-To: <1359129213.62.0.851750342405.issue17033@psf.upfronthosting.co.za> Message-ID: <1359142795.9.0.488049746593.issue17033@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +ncoghlan stage: -> patch review versions: +Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:41:04 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 25 Jan 2013 19:41:04 +0000 Subject: [issue17032] Misleading error message: global name 'X' is not defined In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za> Message-ID: <1359142864.23.0.420802271259.issue17032@psf.upfronthosting.co.za> ?ric Araujo added the comment: Dropping global sounds good. (Let?s not replace name with variable though!) ---------- nosy: +eric.araujo versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:42:39 2013 From: report at bugs.python.org (Floris van Manen) Date: Fri, 25 Jan 2013 19:42:39 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <20130125183558.GA17308@sleipnir.bytereef.org> Message-ID: Floris van Manen added the comment: On 25 Jan 2013, at 19:35, Stefan Krah wrote: > > Stefan Krah added the comment: > > Floris van Manen wrote: >> From what i understand is that issue14591 was able to reproduce the same feature as it seems related to the jumpahead() malfunctioning. > > I'm also quite sure that it's the same issue. It would be nice to have > confirmation though. If you have the opportunity to compile the tip of > the 2.7 branch (where #14591 is fixed), get one of these: > > http://hg.python.org/cpython/archive/864b9836dae6.tar.gz > http://hg.python.org/cpython/archive/864b9836dae6.zip > Did compile that version and it launches. To test with my code i do not want to have it interfere with my current version. I remember it is possible to setup n isolated environment with pip en virtualenv. But i never did this so far. Any hints / links to (simple) script explanation that could do the job? Or is there an even simpler way? .F ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 20:51:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 19:51:33 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1359121239.39.0.893184229389.issue10156@psf.upfronthosting.co.za> Message-ID: <201301252150.58860.storchaka@gmail.com> Serhiy Storchaka added the comment: > The 2.7 comments also apply to the 3.2 patch. Otherwise the 3.2 patch > (without the _sre changes :) looks good to me. Patches updated addressing new Stefan's comments. Unicode globals no longer reinitialized in _PyUnicode_Init(). Note that I have added a consistency check into the macro in 3.3+. I hope Rietveld will accept this set. ---------- Added file: http://bugs.python.org/file28826/unicode_globals-2.7_3.patch Added file: http://bugs.python.org/file28827/unicode_globals-3.2_3.patch Added file: http://bugs.python.org/file28828/unicode_globals-3.3_3.patch Added file: http://bugs.python.org/file28829/unicode_globals-3.4_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 864b9836dae6 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 25 17:55:39 2013 +0100 +++ b/Objects/unicodeobject.c Fri Jan 25 21:34:01 2013 +0200 @@ -82,8 +82,9 @@ /* --- Globals ------------------------------------------------------------ - The globals are initialized by the _PyUnicode_Init() API and should - not be used before calling that API. +NOTE: In the interpreter's initialization phase, some globals are currently + initialized dynamically as needed. In the process Unicode objects may + be created before the Unicode type is ready. */ @@ -93,15 +94,27 @@ #endif /* Free list for Unicode objects */ -static PyUnicodeObject *free_list; -static int numfree; +static PyUnicodeObject *free_list = NULL; +static int numfree = 0; /* The empty Unicode object is shared to improve performance. */ -static PyUnicodeObject *unicode_empty; +static PyUnicodeObject *unicode_empty = NULL; + +#define _Py_RETURN_UNICODE_EMPTY() \ + do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = _PyUnicode_New(0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + return (PyObject *)unicode_empty; \ + } while (0) /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyUnicodeObject *unicode_latin1[256]; +static PyUnicodeObject *unicode_latin1[256] = {NULL}; /* Default encoding to use and assume when NULL is passed as encoding parameter; it is initialized by _PyUnicode_Init(). @@ -110,7 +123,7 @@ PyUnicode_GetDefaultEncoding() APIs to access this global. */ -static char unicode_default_encoding[100]; +static char unicode_default_encoding[100 + 1] = "ascii"; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -204,7 +217,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -448,10 +461,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -497,10 +508,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single characters are shared when using this constructor. Restrict to ASCII, since the input must be UTF-8. */ @@ -1162,13 +1171,10 @@ } /* Convert to Unicode */ - if (len == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *)unicode_empty; - } - else - v = PyUnicode_Decode(s, len, encoding, errors); - + if (len == 0) + _Py_RETURN_UNICODE_EMPTY(); + + v = PyUnicode_Decode(s, len, encoding, errors); return v; onError: @@ -1381,7 +1387,7 @@ Py_DECREF(v); strncpy(unicode_default_encoding, encoding, - sizeof(unicode_default_encoding)); + sizeof(unicode_default_encoding) - 1); return 0; onError: @@ -8850,8 +8856,6 @@ void _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UNICODE linebreak[] = { 0x000A, /* LINE FEED */ @@ -8865,15 +8869,12 @@ }; /* Init the implementation */ - free_list = NULL; - numfree = 0; - unicode_empty = _PyUnicode_New(0); - if (!unicode_empty) - return; - - strcpy(unicode_default_encoding, "ascii"); - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; + if (!unicode_empty) { + unicode_empty = _PyUnicode_New(0); + if (!unicode_empty) + return; + } + if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -8918,15 +8919,11 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); + (void)PyUnicode_ClearFreeList(); } -------------- next part -------------- diff -r ea9fd9c9c677 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 25 17:57:13 2013 +0100 +++ b/Objects/unicodeobject.c Fri Jan 25 21:34:11 2013 +0200 @@ -80,8 +80,9 @@ /* --- Globals ------------------------------------------------------------ - The globals are initialized by the _PyUnicode_Init() API and should - not be used before calling that API. +NOTE: In the interpreter's initialization phase, some globals are currently + initialized dynamically as needed. In the process Unicode objects may + be created before the Unicode type is ready. */ @@ -98,18 +99,30 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* Free list for Unicode objects */ -static PyUnicodeObject *free_list; -static int numfree; +static PyUnicodeObject *free_list = NULL; +static int numfree = 0; /* The empty Unicode object is shared to improve performance. */ -static PyUnicodeObject *unicode_empty; +static PyUnicodeObject *unicode_empty = NULL; + +#define _Py_RETURN_UNICODE_EMPTY() \ + do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = _PyUnicode_New(0); \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + } \ + return (PyObject *)unicode_empty; \ + } while (0) /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyUnicodeObject *unicode_latin1[256]; +static PyUnicodeObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -214,7 +227,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -479,10 +492,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -528,10 +539,8 @@ if (u != NULL) { /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single characters are shared when using this constructor. Restrict to ASCII, since the input must be UTF-8. */ @@ -1393,15 +1402,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *) unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -1421,12 +1426,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = (PyObject *) unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -8323,10 +8327,8 @@ Py_ssize_t nchars; size_t nbytes; - if (len < 1) { - Py_INCREF(unicode_empty); - return (PyObject *)unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); if (len == 1 && PyUnicode_CheckExact(str)) { /* no repeat, return original string */ @@ -10056,8 +10058,6 @@ void _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UNICODE linebreak[] = { 0x000A, /* LINE FEED */ @@ -10071,14 +10071,12 @@ }; /* Init the implementation */ - free_list = NULL; - numfree = 0; - unicode_empty = _PyUnicode_New(0); - if (!unicode_empty) - return; - - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; + if (!unicode_empty) { + unicode_empty = _PyUnicode_New(0); + if (!unicode_empty) + return; + } + if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -10123,15 +10121,11 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); + (void)PyUnicode_ClearFreeList(); } @@ -10250,8 +10244,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } -------------- next part -------------- diff -r ff5cf42136b3 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 25 18:45:12 2013 +0100 +++ b/Objects/unicodeobject.c Fri Jan 25 21:36:29 2013 +0200 @@ -57,8 +57,9 @@ /* --- Globals ------------------------------------------------------------ - The globals are initialized by the _PyUnicode_Init() API and should - not be used before calling that API. +NOTE: In the interpreter's initialization phase, some globals are currently + initialized dynamically as needed. In the process Unicode objects may + be created before the Unicode type is ready. */ @@ -179,17 +180,36 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* The empty Unicode object is shared to improve performance. */ -static PyObject *unicode_empty; +static PyObject *unicode_empty = NULL; + +#define _Py_INCREF_UNICODE_EMPTY() \ + do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = PyUnicode_New(0, 0); \ + if (unicode_empty != NULL) { \ + Py_INCREF(unicode_empty); \ + assert(_PyUnicode_CheckConsistency(unicode_empty, 1)); \ + } \ + } \ + } while (0) + +#define _Py_RETURN_UNICODE_EMPTY() \ + do { \ + _Py_INCREF_UNICODE_EMPTY(); \ + return unicode_empty; \ + } while (0) /* List of static strings. */ -static _Py_Identifier *static_strings; +static _Py_Identifier *static_strings = NULL; /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyObject *unicode_latin1[256]; +static PyObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -416,9 +436,8 @@ len = _PyUnicode_WSTR_LENGTH(unicode); if (len == 0) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (len == 1) { @@ -450,8 +469,8 @@ length = PyUnicode_GET_LENGTH(unicode); if (length == 0) { if (unicode != unicode_empty) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); + _Py_RETURN_UNICODE_EMPTY(); } return unicode_empty; } @@ -528,7 +547,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -1582,9 +1601,11 @@ return 0; if (length == 0) { + _Py_INCREF_UNICODE_EMPTY(); + if (!unicode_empty) + return -1; Py_DECREF(*p_unicode); *p_unicode = unicode_empty; - Py_INCREF(*p_unicode); return 0; } @@ -1731,10 +1752,8 @@ some optimizations which share commonly used objects. */ /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -1893,10 +1912,8 @@ PyObject *res; unsigned char max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) return get_latin1_char(u[0]); @@ -1916,10 +1933,8 @@ PyObject *res; Py_UCS2 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -1954,10 +1969,8 @@ PyObject *res; Py_UCS4 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -2249,10 +2262,8 @@ PyUnicode_FromWideChar(register const wchar_t *w, Py_ssize_t size) { if (w == NULL) { - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); PyErr_BadInternalCall(); return NULL; } @@ -3007,15 +3018,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -3035,12 +3042,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -4720,8 +4726,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* ASCII is equivalent to the first 128 ordinals in Unicode. */ @@ -5232,8 +5237,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #ifdef BYTEORDER_IS_LITTLE_ENDIAN @@ -6558,10 +6562,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* ASCII is equivalent to the first 128 ordinals in Unicode. */ if (size == 1 && (unsigned char)s[0] < 128) @@ -6940,8 +6942,7 @@ if (chunk_size == 0 && done) { if (v != NULL) break; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } @@ -9503,9 +9504,7 @@ /* If empty sequence, return u"". */ if (seqlen == 0) { Py_DECREF(fseq); - Py_INCREF(unicode_empty); - res = unicode_empty; - return res; + _Py_RETURN_UNICODE_EMPTY(); } /* If singleton sequence with an exact Unicode, return that. */ @@ -10205,7 +10204,9 @@ } new_size = slen + n * (len2 - len1); if (new_size == 0) { - Py_INCREF(unicode_empty); + _Py_INCREF_UNICODE_EMPTY(); + if (!unicode_empty) + goto error; u = unicode_empty; goto done; } @@ -11672,10 +11673,8 @@ PyErr_SetString(PyExc_IndexError, "string index out of range"); return NULL; } - if (start >= length || end < start) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (start >= length || end < start) + _Py_RETURN_UNICODE_EMPTY(); length = end - start; if (PyUnicode_IS_ASCII(self)) { @@ -11802,10 +11801,8 @@ PyObject *u; Py_ssize_t nchars, n; - if (len < 1) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); /* no repeat, return original string */ if (len == 1) @@ -12924,8 +12921,7 @@ { if (writer->pos == 0) { Py_XDECREF(writer->buffer); - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (writer->readonly) { assert(PyUnicode_GET_LENGTH(writer->buffer) == writer->pos); @@ -13143,8 +13139,7 @@ } if (slicelength <= 0) { - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } else if (start == 0 && step == 1 && slicelength == PyUnicode_GET_LENGTH(self)) { return unicode_result_unchanged(self); @@ -13974,10 +13969,8 @@ if (!PyArg_ParseTupleAndKeywords(args, kwds, "|Oss:str", kwlist, &x, &encoding, &errors)) return NULL; - if (x == NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (x == NULL) + _Py_RETURN_UNICODE_EMPTY(); if (encoding == NULL && errors == NULL) return PyObject_Str(x); else @@ -14146,8 +14139,6 @@ int _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UCS2 linebreak[] = { 0x000A, /* LINE FEED */ @@ -14161,13 +14152,11 @@ }; /* Init the implementation */ - unicode_empty = PyUnicode_New(0, 0); + _Py_INCREF_UNICODE_EMPTY(); if (!unicode_empty) Py_FatalError("Can't create empty string"); - assert(_PyUnicode_CheckConsistency(unicode_empty, 1)); - - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; + Py_DECREF(unicode_empty); + if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -14207,15 +14196,10 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); _PyUnicode_ClearStaticStrings(); (void)PyUnicode_ClearFreeList(); } @@ -14344,8 +14328,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } -------------- next part -------------- diff -r 1942987921e9 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 25 18:45:41 2013 +0100 +++ b/Objects/unicodeobject.c Fri Jan 25 21:36:35 2013 +0200 @@ -49,8 +49,9 @@ /* --- Globals ------------------------------------------------------------ - The globals are initialized by the _PyUnicode_Init() API and should - not be used before calling that API. +NOTE: In the interpreter's initialization phase, some globals are currently + initialized dynamically as needed. In the process Unicode objects may + be created before the Unicode type is ready. */ @@ -171,17 +172,36 @@ Another way to look at this is that to say that the actual reference count of a string is: s->ob_refcnt + (s->state ? 2 : 0) */ -static PyObject *interned; +static PyObject *interned = NULL; /* The empty Unicode object is shared to improve performance. */ -static PyObject *unicode_empty; +static PyObject *unicode_empty = NULL; + +#define _Py_INCREF_UNICODE_EMPTY() \ + do { \ + if (unicode_empty != NULL) \ + Py_INCREF(unicode_empty); \ + else { \ + unicode_empty = PyUnicode_New(0, 0); \ + if (unicode_empty != NULL) { \ + Py_INCREF(unicode_empty); \ + assert(_PyUnicode_CheckConsistency(unicode_empty, 1)); \ + } \ + } \ + } while (0) + +#define _Py_RETURN_UNICODE_EMPTY() \ + do { \ + _Py_INCREF_UNICODE_EMPTY(); \ + return unicode_empty; \ + } while (0) /* List of static strings. */ -static _Py_Identifier *static_strings; +static _Py_Identifier *static_strings = NULL; /* Single character Unicode strings in the Latin-1 range are being shared as well. */ -static PyObject *unicode_latin1[256]; +static PyObject *unicode_latin1[256] = {NULL}; /* Fast detection of the most frequent whitespace characters */ const unsigned char _Py_ascii_whitespace[] = { @@ -406,9 +426,8 @@ len = _PyUnicode_WSTR_LENGTH(unicode); if (len == 0) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (len == 1) { @@ -442,8 +461,8 @@ length = PyUnicode_GET_LENGTH(unicode); if (length == 0) { if (unicode != unicode_empty) { - Py_INCREF(unicode_empty); Py_DECREF(unicode); + _Py_RETURN_UNICODE_EMPTY(); } return unicode_empty; } @@ -520,7 +539,7 @@ #define BLOOM_MASK unsigned long -static BLOOM_MASK bloom_linebreak; +static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; #define BLOOM_ADD(mask, ch) ((mask |= (1UL << ((ch) & (BLOOM_WIDTH - 1))))) #define BLOOM(mask, ch) ((mask & (1UL << ((ch) & (BLOOM_WIDTH - 1))))) @@ -1602,9 +1621,11 @@ return 0; if (length == 0) { + _Py_INCREF_UNICODE_EMPTY(); + if (!unicode_empty) + return -1; Py_DECREF(*p_unicode); *p_unicode = unicode_empty; - Py_INCREF(*p_unicode); return 0; } @@ -1727,10 +1748,8 @@ some optimizations which share commonly used objects. */ /* Optimization for empty strings */ - if (size == 0 && unicode_empty != NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Single character Unicode objects in the Latin-1 range are shared when using this constructor */ @@ -1889,10 +1908,8 @@ PyObject *res; unsigned char max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) return get_latin1_char(u[0]); @@ -1912,10 +1929,8 @@ PyObject *res; Py_UCS2 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -1950,10 +1965,8 @@ PyObject *res; Py_UCS4 max_char; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); assert(size > 0); if (size == 1) { Py_UCS4 ch = u[0]; @@ -2245,10 +2258,8 @@ PyUnicode_FromWideChar(register const wchar_t *w, Py_ssize_t size) { if (w == NULL) { - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); PyErr_BadInternalCall(); return NULL; } @@ -2825,15 +2836,11 @@ /* Decoding bytes objects is the most common case and should be fast */ if (PyBytes_Check(obj)) { - if (PyBytes_GET_SIZE(obj) == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else { - v = PyUnicode_Decode( - PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), - encoding, errors); - } + if (PyBytes_GET_SIZE(obj) == 0) + _Py_RETURN_UNICODE_EMPTY(); + v = PyUnicode_Decode( + PyBytes_AS_STRING(obj), PyBytes_GET_SIZE(obj), + encoding, errors); return v; } @@ -2853,12 +2860,11 @@ } if (buffer.len == 0) { - Py_INCREF(unicode_empty); - v = unicode_empty; - } - else - v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); - + PyBuffer_Release(&buffer); + _Py_RETURN_UNICODE_EMPTY(); + } + + v = PyUnicode_Decode((char*) buffer.buf, buffer.len, encoding, errors); PyBuffer_Release(&buffer); return v; } @@ -4201,8 +4207,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* Start off assuming it's all ASCII. Widen later as necessary. */ @@ -4609,8 +4614,7 @@ if (size == 0) { if (consumed) *consumed = 0; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } /* ASCII is equivalent to the first 128 ordinals in Unicode. */ @@ -4868,8 +4872,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #ifdef WORDS_BIGENDIAN @@ -5108,8 +5111,7 @@ if (q == e) { if (consumed) *consumed = size; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } #if PY_LITTLE_ENDIAN @@ -5386,10 +5388,8 @@ Py_ssize_t len; len = length_of_escaped_ascii_string(s, size); - if (len == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len == 0) + _Py_RETURN_UNICODE_EMPTY(); /* After length_of_escaped_ascii_string() there are two alternatives, either the string is pure ASCII with named escapes like \n, etc. @@ -5781,10 +5781,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* Escaped strings will always be longer than the resulting Unicode string, so we start with size here and then reduce the @@ -5988,10 +5986,8 @@ 1)) return NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* XXX overflow detection missing */ _PyUnicodeWriter_Init(&writer, 0); @@ -6439,10 +6435,8 @@ PyObject *errorHandler = NULL; PyObject *exc = NULL; - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); /* ASCII is equivalent to the first 128 ordinals in Unicode. */ if (size == 1 && (unsigned char)s[0] < 128) @@ -6820,8 +6814,7 @@ if (chunk_size == 0 && done) { if (v != NULL) break; - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } @@ -7298,10 +7291,8 @@ if (mapping == NULL) return PyUnicode_DecodeLatin1(s, size, errors); - if (size == 0) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (size == 0) + _Py_RETURN_UNICODE_EMPTY(); _PyUnicodeWriter_Init(&writer, 0); if (_PyUnicodeWriter_Prepare(&writer, size, 127) == -1) goto onError; @@ -9354,9 +9345,7 @@ /* If empty sequence, return u"". */ if (seqlen == 0) { Py_DECREF(fseq); - Py_INCREF(unicode_empty); - res = unicode_empty; - return res; + _Py_RETURN_UNICODE_EMPTY(); } /* If singleton sequence with an exact Unicode, return that. */ @@ -10056,7 +10045,9 @@ } new_size = slen + n * (len2 - len1); if (new_size == 0) { - Py_INCREF(unicode_empty); + _Py_INCREF_UNICODE_EMPTY(); + if (!unicode_empty) + goto error; u = unicode_empty; goto done; } @@ -11559,10 +11550,8 @@ PyErr_SetString(PyExc_IndexError, "string index out of range"); return NULL; } - if (start >= length || end < start) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (start >= length || end < start) + _Py_RETURN_UNICODE_EMPTY(); length = end - start; if (PyUnicode_IS_ASCII(self)) { @@ -11689,10 +11678,8 @@ PyObject *u; Py_ssize_t nchars, n; - if (len < 1) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (len < 1) + _Py_RETURN_UNICODE_EMPTY(); /* no repeat, return original string */ if (len == 1) @@ -12832,8 +12819,7 @@ { if (writer->pos == 0) { Py_XDECREF(writer->buffer); - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } if (writer->readonly) { assert(PyUnicode_GET_LENGTH(writer->buffer) == writer->pos); @@ -13051,8 +13037,7 @@ } if (slicelength <= 0) { - Py_INCREF(unicode_empty); - return unicode_empty; + _Py_RETURN_UNICODE_EMPTY(); } else if (start == 0 && step == 1 && slicelength == PyUnicode_GET_LENGTH(self)) { return unicode_result_unchanged(self); @@ -14056,10 +14041,8 @@ if (!PyArg_ParseTupleAndKeywords(args, kwds, "|Oss:str", kwlist, &x, &encoding, &errors)) return NULL; - if (x == NULL) { - Py_INCREF(unicode_empty); - return unicode_empty; - } + if (x == NULL) + _Py_RETURN_UNICODE_EMPTY(); if (encoding == NULL && errors == NULL) return PyObject_Str(x); else @@ -14228,8 +14211,6 @@ int _PyUnicode_Init(void) { - int i; - /* XXX - move this array to unicodectype.c ? */ Py_UCS2 linebreak[] = { 0x000A, /* LINE FEED */ @@ -14243,13 +14224,11 @@ }; /* Init the implementation */ - unicode_empty = PyUnicode_New(0, 0); + _Py_INCREF_UNICODE_EMPTY(); if (!unicode_empty) Py_FatalError("Can't create empty string"); - assert(_PyUnicode_CheckConsistency(unicode_empty, 1)); - - for (i = 0; i < 256; i++) - unicode_latin1[i] = NULL; + Py_DECREF(unicode_empty); + if (PyType_Ready(&PyUnicode_Type) < 0) Py_FatalError("Can't initialize 'unicode'"); @@ -14289,15 +14268,10 @@ { int i; - Py_XDECREF(unicode_empty); - unicode_empty = NULL; - - for (i = 0; i < 256; i++) { - if (unicode_latin1[i]) { - Py_DECREF(unicode_latin1[i]); - unicode_latin1[i] = NULL; - } - } + Py_CLEAR(unicode_empty); + + for (i = 0; i < 256; i++) + Py_CLEAR(unicode_latin1[i]); _PyUnicode_ClearStaticStrings(); (void)PyUnicode_ClearFreeList(); } @@ -14426,8 +14400,7 @@ "mortal/immortal\n", mortal_size, immortal_size); Py_DECREF(keys); PyDict_Clear(interned); - Py_DECREF(interned); - interned = NULL; + Py_CLEAR(interned); } From report at bugs.python.org Fri Jan 25 21:08:02 2013 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 25 Jan 2013 20:08:02 +0000 Subject: [issue12701] Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za> Message-ID: <1359144482.95.0.682590612632.issue12701@psf.upfronthosting.co.za> Mark Dickinson added the comment: I believe the int_pow issue has been resolved, so this bug shouldn't show up in any of the current branches, regardless of which version of Clang is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 21:09:25 2013 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 25 Jan 2013 20:09:25 +0000 Subject: [issue12701] Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za> Message-ID: <1359144565.13.0.177049700108.issue12701@psf.upfronthosting.co.za> Mark Dickinson added the comment: Issue #12973 is the one that led to the eventual fix. Closing this as a duplicate. ---------- resolution: -> duplicate status: open -> closed superseder: -> int_pow() implementation is incorrect _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 21:09:50 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 25 Jan 2013 20:09:50 +0000 Subject: [issue11049] add tests for test.support In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za> Message-ID: <1359144590.27.0.339890793437.issue11049@psf.upfronthosting.co.za> R. David Murray added the comment: Sure. It doesn't seem likely that I'll get back to it any time soon, and if I do I can open a new issue. ---------- stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 21:14:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 20:14:51 +0000 Subject: [issue17034] Initialization of globals in stringobject.c Message-ID: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The patch for stringobject.c is similar to patch for unicodeobject.c in issue10156, but more simpler. ---------- components: Interpreter Core files: string_globals.patch keywords: patch messages: 180621 nosy: serhiy.storchaka, skrah priority: normal severity: normal stage: patch review status: open title: Initialization of globals in stringobject.c type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file28830/string_globals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 21:40:08 2013 From: report at bugs.python.org (Jakub Wilk) Date: Fri, 25 Jan 2013 20:40:08 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1359146408.39.0.819949269476.issue12641@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 21:59:09 2013 From: report at bugs.python.org (Ray Donnelly) Date: Fri, 25 Jan 2013 20:59:09 +0000 Subject: [issue16235] Add python-config.sh for use during cross compilation. In-Reply-To: <1350251714.79.0.226527559426.issue16235@psf.upfronthosting.co.za> Message-ID: <1359147549.85.0.696716510143.issue16235@psf.upfronthosting.co.za> Ray Donnelly added the comment: Great. My only query is whether the changes to sed will work on non-GNU sed. It used to be like: sed < in >out you've now got: sed in >out I'm not saying it won't work, I'm not in a position to check, but I think it's safer to keep it as it was. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 22:12:47 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Jan 2013 21:12:47 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1359148367.47.0.385603236738.issue10156@psf.upfronthosting.co.za> Stefan Krah added the comment: Nice. I think the latest patches are commit-ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 22:13:13 2013 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Jan 2013 21:13:13 +0000 Subject: [issue17035] Use new style classes in {class, static}method examples Message-ID: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za> New submission from Berker Peksag: The examples in the built-in functions documentation[1] should be consistent and use new style classes. [1] http://docs.python.org/2.7/library/functions.html ---------- assignee: docs at python components: Documentation files: new-style-classes.diff keywords: patch messages: 180624 nosy: berker.peksag, docs at python priority: normal severity: normal status: open title: Use new style classes in {class, static}method examples versions: Python 2.7 Added file: http://bugs.python.org/file28831/new-style-classes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 22:18:19 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 25 Jan 2013 21:18:19 +0000 Subject: [issue16651] Find out what stdlib modules lack a pure Python implementation In-Reply-To: <1355078393.91.0.564166411172.issue16651@psf.upfronthosting.co.za> Message-ID: <1359148699.12.0.737135637998.issue16651@psf.upfronthosting.co.za> Eric Snow added the comment: Also missing a pure-Python implementation: collections.defaultdict (relatively trivial) collections.deque In the spirit of what Brett said, I found that PyPy has an implementation already: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/_collections.py Jython and IronPython do not have pure Python implentations: http://hg.python.org/jython/file/default/src/org/python/modules/_collections http://ironpython.codeplex.com/SourceControl/changeset/view/99885#1091023 ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 22:27:52 2013 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Jan 2013 21:27:52 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: Message-ID: <20130125212754.GA18885@sleipnir.bytereef.org> Stefan Krah added the comment: Floris van Manen wrote: > Did compile that version and it launches. > To test with my code i do not want to have it interfere with my current version. > I remember it is possible to setup n isolated environment with pip en virtualenv. > But i never did this so far. > Any hints / links to (simple) script explanation that could do the job? > Or is there an even simpler way? I wouldn't bother with virtualenvs yet. First I'd simply install python into /tmp: mkdir /tmp/usr ./configure --prefix=/tmp/usr/ make make install Then always call python with the full path. If your app is a simple script, then: /tmp/usr/bin/python app.py If you have to install it: /tmp/usr/bin/python setup.py install ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 22:43:55 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 21:43:55 +0000 Subject: [issue16975] Broken error handling in codecs.escape_decode() In-Reply-To: <1358286171.54.0.132780688137.issue16975@psf.upfronthosting.co.za> Message-ID: <3YtDJW0WNCzSNX@mail.python.org> Roundup Robot added the comment: New changeset 5970c90dd8d1 by Serhiy Storchaka in branch '2.7': Issue #16975: Fix error handling bug in the escape-decode decoder. http://hg.python.org/cpython/rev/5970c90dd8d1 New changeset 22594c5060eb by Serhiy Storchaka in branch '3.2': Issue #16975: Fix error handling bug in the escape-decode bytes decoder. http://hg.python.org/cpython/rev/22594c5060eb New changeset 580d536cc910 by Serhiy Storchaka in branch '3.3': Issue #16975: Fix error handling bug in the escape-decode bytes decoder. http://hg.python.org/cpython/rev/580d536cc910 New changeset 513b728695fc by Serhiy Storchaka in branch 'default': Issue #16975: Fix error handling bug in the escape-decode bytes decoder. http://hg.python.org/cpython/rev/513b728695fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 22:51:13 2013 From: report at bugs.python.org (Floris van Manen) Date: Fri, 25 Jan 2013 21:51:13 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <20130125212754.GA18885@sleipnir.bytereef.org> Message-ID: Floris van Manen added the comment: On 25 Jan 2013, at 22:27, Stefan Krah wrote: > Then always call python with the full path. If your app is a simple > script, then: > > /tmp/usr/bin/python app.py ok. and how do i add extra packages to that new python version ? e.g. i need to install pyyam and openpyxll (sorry for the inconvenience) .F ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 22:54:38 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 21:54:38 +0000 Subject: [issue16980] SystemError in codecs.unicode_escape_decode() In-Reply-To: <1358343747.58.0.471745996102.issue16980@psf.upfronthosting.co.za> Message-ID: <3YtDXt07Q1zSND@mail.python.org> Roundup Robot added the comment: New changeset dcbc16afd6bc by Serhiy Storchaka in branch '3.3': Issue #16980: Fix processing of escaped non-ascii bytes in the http://hg.python.org/cpython/rev/dcbc16afd6bc New changeset d8c2ce63f5a4 by Serhiy Storchaka in branch 'default': Issue #16980: Fix processing of escaped non-ascii bytes in the http://hg.python.org/cpython/rev/d8c2ce63f5a4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 23:01:25 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Jan 2013 22:01:25 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance Message-ID: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> New submission from STINNER Victor: I create this issue to review and track the implementation of the PEP 433: "Easier suppression of file descriptor inheritance" http://www.python.org/dev/peps/pep-0433/ ---------- components: Interpreter Core hgrepos: 173 messages: 180630 nosy: haypo priority: normal severity: normal status: open title: Implementation of the PEP 433: Easier suppression of file descriptor inheritance type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 23:02:40 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Jan 2013 22:02:40 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359151360.57.0.782812660076.issue17036@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +patch Added file: http://bugs.python.org/file28832/297b3529876a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 23:06:39 2013 From: report at bugs.python.org (Floris van Manen) Date: Fri, 25 Jan 2013 22:06:39 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <20130125212754.GA18885@sleipnir.bytereef.org> Message-ID: <2F8E93A8-9311-4321-AE4D-93263E734531@klankschap.nl> Floris van Manen added the comment: On 25 Jan 2013, at 22:27, Stefan Krah wrote: > Then always call python with the full path. If your app is a simple > script, t ok, managed to install the extra packages and run the app. Seems to work correctly now, no more random() >= 1.0 (thanks!) .F ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 23:11:35 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 25 Jan 2013 22:11:35 +0000 Subject: [issue17020] random.random() generating values >= 1.0 In-Reply-To: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za> Message-ID: <1359151895.77.0.960382992948.issue17020@psf.upfronthosting.co.za> R. David Murray added the comment: Excellent. Thanks for testing. And thanks for pointing out the duplicate, Peter. ---------- assignee: ronaldoussoren -> resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Value returned by random.random() out of valid range on 64-bit type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 23:21:55 2013 From: report at bugs.python.org (Roumen Petrov) Date: Fri, 25 Jan 2013 22:21:55 +0000 Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig In-Reply-To: <1359119820.08.0.335631277465.issue15484@psf.upfronthosting.co.za> Message-ID: <51030582.5050409@roumenpetrov.info> Roumen Petrov added the comment: Matthias Klose wrote: > 2-CROSS-set-_PYTHON_PROJECT_BASE-to-current-build-dir.patch > I'll use abs_builddir instead. Yes after some fixes related to issue 15819 (msg173144) this is preferred. Roumen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 23:55:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 22:55:26 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() In-Reply-To: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za> Message-ID: <1359154526.94.0.239688107782.issue16979@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28752/unicode_escape_decode_error_handling-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 25 23:58:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Jan 2013 22:58:19 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() In-Reply-To: <1358347805.83.0.744932901412.issue16979@psf.upfronthosting.co.za> Message-ID: <201301260057.45735.storchaka@gmail.com> Serhiy Storchaka added the comment: Here is a set of patches for all versions (patch for 3.4 updated). ---------- Added file: http://bugs.python.org/file28833/unicode_escape_decode_error_handling-2.7.patch Added file: http://bugs.python.org/file28834/unicode_escape_decode_error_handling-3.2.patch Added file: http://bugs.python.org/file28835/unicode_escape_decode_error_handling-3.3.patch Added file: http://bugs.python.org/file28836/unicode_escape_decode_error_handling-3.4.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 5970c90dd8d1 Lib/test/test_codeccallbacks.py --- a/Lib/test/test_codeccallbacks.py Fri Jan 25 23:30:50 2013 +0200 +++ b/Lib/test/test_codeccallbacks.py Sat Jan 26 00:51:30 2013 +0200 @@ -262,12 +262,12 @@ self.assertEqual( "\\u3042\u3xxx".decode("unicode-escape", "test.handler1"), - u"\u3042[<92><117><51><120>]xx" + u"\u3042[<92><117><51>]xxx" ) self.assertEqual( "\\u3042\u3xx".decode("unicode-escape", "test.handler1"), - u"\u3042[<92><117><51><120><120>]" + u"\u3042[<92><117><51>]xx" ) self.assertEqual( diff -r 5970c90dd8d1 Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py Fri Jan 25 23:30:50 2013 +0200 +++ b/Lib/test/test_codecs.py Sat Jan 26 00:51:30 2013 +0200 @@ -1786,6 +1786,84 @@ self.assertEqual(srw.read(), u"\xfc") +class UnicodeEscapeTest(unittest.TestCase): + def test_empty(self): + self.assertEqual(codecs.unicode_escape_encode(u""), ("", 0)) + self.assertEqual(codecs.unicode_escape_decode(""), (u"", 0)) + + def test_raw_encode(self): + encode = codecs.unicode_escape_encode + for b in range(32, 127): + if b != ord('\\'): + self.assertEqual(encode(unichr(b)), (chr(b), 1)) + + def test_raw_decode(self): + decode = codecs.unicode_escape_decode + for b in range(256): + if b != ord('\\'): + self.assertEqual(decode(chr(b) + '0'), (unichr(b) + u'0', 2)) + + def test_escape_encode(self): + encode = codecs.unicode_escape_encode + self.assertEqual(encode(u'\t'), (r'\t', 1)) + self.assertEqual(encode(u'\n'), (r'\n', 1)) + self.assertEqual(encode(u'\r'), (r'\r', 1)) + self.assertEqual(encode(u'\\'), (r'\\', 1)) + for b in range(32): + if chr(b) not in '\t\n\r': + self.assertEqual(encode(unichr(b)), ('\\x%02x' % b, 1)) + for b in range(127, 256): + self.assertEqual(encode(unichr(b)), ('\\x%02x' % b, 1)) + self.assertEqual(encode(u'\u20ac'), (r'\u20ac', 1)) + self.assertEqual(encode(u'\U0001d120'), + (r'\U0001d120', len(u'\U0001d120'))) + + def test_escape_decode(self): + decode = codecs.unicode_escape_decode + self.assertEqual(decode("[\\\n]"), (u"[]", 4)) + self.assertEqual(decode(r'[\"]'), (u'["]', 4)) + self.assertEqual(decode(r"[\']"), (u"[']", 4)) + self.assertEqual(decode(r"[\\]"), (ur"[\]", 4)) + self.assertEqual(decode(r"[\a]"), (u"[\x07]", 4)) + self.assertEqual(decode(r"[\b]"), (u"[\x08]", 4)) + self.assertEqual(decode(r"[\t]"), (u"[\x09]", 4)) + self.assertEqual(decode(r"[\n]"), (u"[\x0a]", 4)) + self.assertEqual(decode(r"[\v]"), (u"[\x0b]", 4)) + self.assertEqual(decode(r"[\f]"), (u"[\x0c]", 4)) + self.assertEqual(decode(r"[\r]"), (u"[\x0d]", 4)) + self.assertEqual(decode(r"[\7]"), (u"[\x07]", 4)) + self.assertEqual(decode(r"[\8]"), (ur"[\8]", 4)) + self.assertEqual(decode(r"[\78]"), (u"[\x078]", 5)) + self.assertEqual(decode(r"[\41]"), (u"[!]", 5)) + self.assertEqual(decode(r"[\418]"), (u"[!8]", 6)) + self.assertEqual(decode(r"[\101]"), (u"[A]", 6)) + self.assertEqual(decode(r"[\1010]"), (u"[A0]", 7)) + self.assertEqual(decode(r"[\x41]"), (u"[A]", 6)) + self.assertEqual(decode(r"[\x410]"), (u"[A0]", 7)) + self.assertEqual(decode(r"\u20ac"), (u"\u20ac", 6)) + self.assertEqual(decode(r"\U0001d120"), (u"\U0001d120", 10)) + for b in range(256): + if chr(b) not in '\n"\'\\abtnvfr01234567xuUN': + self.assertEqual(decode('\\' + chr(b)), + (u'\\' + unichr(b), 2)) + + def test_decode_errors(self): + decode = codecs.unicode_escape_decode + for c, d in ('x', 2), ('u', 4), ('U', 4): + for i in range(d): + self.assertRaises(UnicodeDecodeError, decode, + "\\" + c + "0"*i) + self.assertRaises(UnicodeDecodeError, decode, + "[\\" + c + "0"*i + "]") + data = "[\\" + c + "0"*i + "]\\" + c + "0"*i + self.assertEqual(decode(data, "ignore"), (u"[]", len(data))) + self.assertEqual(decode(data, "replace"), + (u"[\ufffd]\ufffd", len(data))) + self.assertRaises(UnicodeDecodeError, decode, r"\U00110000") + self.assertEqual(decode(r"\U00110000", "ignore"), (u"", 10)) + self.assertEqual(decode(r"\U00110000", "replace"), (u"\ufffd", 10)) + + class BomTest(unittest.TestCase): def test_seek0(self): data = u"1234567890" @@ -1871,6 +1949,7 @@ BasicStrTest, CharmapTest, WithStmtTest, + UnicodeEscapeTest, BomTest, ) diff -r 5970c90dd8d1 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 25 23:30:50 2013 +0200 +++ b/Objects/unicodeobject.c Sat Jan 26 00:51:30 2013 +0200 @@ -2732,7 +2732,6 @@ Py_ssize_t startinpos; Py_ssize_t endinpos; Py_ssize_t outpos; - int i; PyUnicodeObject *v; Py_UNICODE *p; const char *end; @@ -2818,29 +2817,19 @@ message = "truncated \\UXXXXXXXX escape"; hexescape: chr = 0; - outpos = p-PyUnicode_AS_UNICODE(v); - if (s+digits>end) { - endinpos = size; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", "end of string in escape sequence", - starts, size, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; - goto nextByte; + if (end - s < digits) { + /* count only hex digits */ + for (; s < end; ++s) { + c = (unsigned char)*s; + if (!Py_ISXDIGIT(c)) + goto error; + } + goto error; } - for (i = 0; i < digits; ++i) { - c = (unsigned char) s[i]; - if (!isxdigit(c)) { - endinpos = (s+i+1)-starts; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - starts, size, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; - goto nextByte; - } + for (; digits--; ++s) { + c = (unsigned char)*s; + if (!Py_ISXDIGIT(c)) + goto error; chr = (chr<<4) & ~0xF; if (c >= '0' && c <= '9') chr += c - '0'; @@ -2849,7 +2838,6 @@ else chr += 10 + c - 'A'; } - s += i; if (chr == 0xffffffff && PyErr_Occurred()) /* _decoding_error will have already written into the target buffer. */ @@ -2870,14 +2858,8 @@ *p++ = 0xDC00 + (Py_UNICODE) (chr & 0x03FF); #endif } else { - endinpos = s-starts; - outpos = p-PyUnicode_AS_UNICODE(v); - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", "illegal Unicode character", - starts, size, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; + message = "illegal Unicode character"; + goto error; } break; @@ -2904,28 +2886,13 @@ goto store; } } - endinpos = s-starts; - outpos = p-PyUnicode_AS_UNICODE(v); - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - starts, size, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; - break; + goto error; default: if (s > end) { message = "\\ at end of string"; s--; - endinpos = s-starts; - outpos = p-PyUnicode_AS_UNICODE(v); - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - starts, size, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; + goto error; } else { *p++ = '\\'; @@ -2933,8 +2900,18 @@ } break; } - nextByte: - ; + continue; + + error: + endinpos = s-starts; + outpos = p-PyUnicode_AS_UNICODE(v); + if (unicode_decode_call_errorhandler( + errors, &errorHandler, + "unicodeescape", message, + starts, size, &startinpos, &endinpos, &exc, &s, + &v, &outpos, &p)) + goto onError; + continue; } if (_PyUnicode_Resize(&v, p - PyUnicode_AS_UNICODE(v)) < 0) goto onError; -------------- next part -------------- diff -r 22594c5060eb Lib/test/test_codeccallbacks.py --- a/Lib/test/test_codeccallbacks.py Fri Jan 25 23:31:43 2013 +0200 +++ b/Lib/test/test_codeccallbacks.py Sat Jan 26 00:51:39 2013 +0200 @@ -262,12 +262,12 @@ self.assertEqual( b"\\u3042\u3xxx".decode("unicode-escape", "test.handler1"), - "\u3042[<92><117><51><120>]xx" + "\u3042[<92><117><51>]xxx" ) self.assertEqual( b"\\u3042\u3xx".decode("unicode-escape", "test.handler1"), - "\u3042[<92><117><51><120><120>]" + "\u3042[<92><117><51>]xx" ) self.assertEqual( diff -r 22594c5060eb Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py Fri Jan 25 23:31:43 2013 +0200 +++ b/Lib/test/test_codecs.py Sat Jan 26 00:51:39 2013 +0200 @@ -1846,6 +1846,85 @@ self.assertEqual(codecs.raw_unicode_escape_decode(r"\u1234"), ("\u1234", 6)) self.assertEqual(codecs.raw_unicode_escape_decode(br"\u1234"), ("\u1234", 6)) + +class UnicodeEscapeTest(unittest.TestCase): + def test_empty(self): + self.assertEqual(codecs.unicode_escape_encode(""), (b"", 0)) + self.assertEqual(codecs.unicode_escape_decode(b""), ("", 0)) + + def test_raw_encode(self): + encode = codecs.unicode_escape_encode + for b in range(32, 127): + if b != b'\\'[0]: + self.assertEqual(encode(chr(b)), (bytes([b]), 1)) + + def test_raw_decode(self): + decode = codecs.unicode_escape_decode + for b in range(256): + if b != b'\\'[0]: + self.assertEqual(decode(bytes([b]) + b'0'), (chr(b) + '0', 2)) + + def test_escape_encode(self): + encode = codecs.unicode_escape_encode + self.assertEqual(encode('\t'), (br'\t', 1)) + self.assertEqual(encode('\n'), (br'\n', 1)) + self.assertEqual(encode('\r'), (br'\r', 1)) + self.assertEqual(encode('\\'), (br'\\', 1)) + for b in range(32): + if chr(b) not in '\t\n\r': + self.assertEqual(encode(chr(b)), (('\\x%02x' % b).encode(), 1)) + for b in range(127, 256): + self.assertEqual(encode(chr(b)), (('\\x%02x' % b).encode(), 1)) + self.assertEqual(encode('\u20ac'), (br'\u20ac', 1)) + self.assertEqual(encode('\U0001d120'), + (br'\U0001d120', len('\U0001d120'))) + + def test_escape_decode(self): + decode = codecs.unicode_escape_decode + self.assertEqual(decode(b"[\\\n]"), ("[]", 4)) + self.assertEqual(decode(br'[\"]'), ('["]', 4)) + self.assertEqual(decode(br"[\']"), ("[']", 4)) + self.assertEqual(decode(br"[\\]"), (r"[\]", 4)) + self.assertEqual(decode(br"[\a]"), ("[\x07]", 4)) + self.assertEqual(decode(br"[\b]"), ("[\x08]", 4)) + self.assertEqual(decode(br"[\t]"), ("[\x09]", 4)) + self.assertEqual(decode(br"[\n]"), ("[\x0a]", 4)) + self.assertEqual(decode(br"[\v]"), ("[\x0b]", 4)) + self.assertEqual(decode(br"[\f]"), ("[\x0c]", 4)) + self.assertEqual(decode(br"[\r]"), ("[\x0d]", 4)) + self.assertEqual(decode(br"[\7]"), ("[\x07]", 4)) + self.assertEqual(decode(br"[\8]"), (r"[\8]", 4)) + self.assertEqual(decode(br"[\78]"), ("[\x078]", 5)) + self.assertEqual(decode(br"[\41]"), ("[!]", 5)) + self.assertEqual(decode(br"[\418]"), ("[!8]", 6)) + self.assertEqual(decode(br"[\101]"), ("[A]", 6)) + self.assertEqual(decode(br"[\1010]"), ("[A0]", 7)) + self.assertEqual(decode(br"[\x41]"), ("[A]", 6)) + self.assertEqual(decode(br"[\x410]"), ("[A0]", 7)) + self.assertEqual(decode(br"\u20ac"), ("\u20ac", 6)) + self.assertEqual(decode(br"\U0001d120"), ("\U0001d120", 10)) + for b in range(256): + if b not in b'\n"\'\\abtnvfr01234567xuUN': + self.assertEqual(decode(b'\\' + bytes([b])), + ('\\' + chr(b), 2)) + + def test_decode_errors(self): + decode = codecs.unicode_escape_decode + for c, d in (b'x', 2), (b'u', 4), (b'U', 4): + for i in range(d): + self.assertRaises(UnicodeDecodeError, decode, + b"\\" + c + b"0"*i) + self.assertRaises(UnicodeDecodeError, decode, + b"[\\" + c + b"0"*i + b"]") + data = b"[\\" + c + b"0"*i + b"]\\" + c + b"0"*i + self.assertEqual(decode(data, "ignore"), ("[]", len(data))) + self.assertEqual(decode(data, "replace"), + ("[\ufffd]\ufffd", len(data))) + self.assertRaises(UnicodeDecodeError, decode, br"\U00110000") + self.assertEqual(decode(br"\U00110000", "ignore"), ("", 10)) + self.assertEqual(decode(br"\U00110000", "replace"), ("\ufffd", 10)) + + class SurrogateEscapeTest(unittest.TestCase): def test_utf8(self): @@ -2011,6 +2090,7 @@ CharmapTest, WithStmtTest, TypesTest, + UnicodeEscapeTest, SurrogateEscapeTest, BomTest, TransformCodecTest, diff -r 22594c5060eb Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 25 23:31:43 2013 +0200 +++ b/Objects/unicodeobject.c Sat Jan 26 00:51:39 2013 +0200 @@ -3756,7 +3756,6 @@ Py_ssize_t startinpos; Py_ssize_t endinpos; Py_ssize_t outpos; - int i; PyUnicodeObject *v; Py_UNICODE *p; const char *end; @@ -3842,29 +3841,19 @@ message = "truncated \\UXXXXXXXX escape"; hexescape: chr = 0; - outpos = p-PyUnicode_AS_UNICODE(v); - if (s+digits>end) { - endinpos = size; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", "end of string in escape sequence", - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; - goto nextByte; - } - for (i = 0; i < digits; ++i) { - c = (unsigned char) s[i]; - if (!Py_ISXDIGIT(c)) { - endinpos = (s+i+1)-starts; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; - goto nextByte; + if (end - s < digits) { + /* count only hex digits */ + for (; s < end; ++s) { + c = (unsigned char)*s; + if (!Py_ISXDIGIT(c)) + goto error; } + goto error; + } + for (; digits--; ++s) { + c = (unsigned char)*s; + if (!Py_ISXDIGIT(c)) + goto error; chr = (chr<<4) & ~0xF; if (c >= '0' && c <= '9') chr += c - '0'; @@ -3873,7 +3862,6 @@ else chr += 10 + c - 'A'; } - s += i; if (chr == 0xffffffff && PyErr_Occurred()) /* _decoding_error will have already written into the target buffer. */ @@ -3894,14 +3882,8 @@ *p++ = 0xDC00 + (Py_UNICODE) (chr & 0x03FF); #endif } else { - endinpos = s-starts; - outpos = p-PyUnicode_AS_UNICODE(v); - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", "illegal Unicode character", - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; + message = "illegal Unicode character"; + goto error; } break; @@ -3928,28 +3910,13 @@ goto store; } } - endinpos = s-starts; - outpos = p-PyUnicode_AS_UNICODE(v); - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; - break; + goto error; default: if (s > end) { message = "\\ at end of string"; s--; - endinpos = s-starts; - outpos = p-PyUnicode_AS_UNICODE(v); - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) - goto onError; + goto error; } else { *p++ = '\\'; @@ -3957,8 +3924,18 @@ } break; } - nextByte: - ; + continue; + + error: + endinpos = s-starts; + outpos = p-PyUnicode_AS_UNICODE(v); + if (unicode_decode_call_errorhandler( + errors, &errorHandler, + "unicodeescape", message, + &starts, &end, &startinpos, &endinpos, &exc, &s, + &v, &outpos, &p)) + goto onError; + continue; } if (_PyUnicode_Resize(&v, p - PyUnicode_AS_UNICODE(v)) < 0) goto onError; -------------- next part -------------- diff -r dcbc16afd6bc Lib/test/test_codeccallbacks.py --- a/Lib/test/test_codeccallbacks.py Fri Jan 25 23:52:21 2013 +0200 +++ b/Lib/test/test_codeccallbacks.py Sat Jan 26 00:51:50 2013 +0200 @@ -271,12 +271,12 @@ self.assertEqual( b"\\u3042\u3xxx".decode("unicode-escape", "test.handler1"), - "\u3042[<92><117><51><120>]xx" + "\u3042[<92><117><51>]xxx" ) self.assertEqual( b"\\u3042\u3xx".decode("unicode-escape", "test.handler1"), - "\u3042[<92><117><51><120><120>]" + "\u3042[<92><117><51>]xx" ) self.assertEqual( diff -r dcbc16afd6bc Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py Fri Jan 25 23:52:21 2013 +0200 +++ b/Lib/test/test_codecs.py Sat Jan 26 00:51:50 2013 +0200 @@ -2009,6 +2009,84 @@ self.assertRaises(UnicodeDecodeError, codecs.raw_unicode_escape_decode, br"\U00110000") self.assertEqual(codecs.raw_unicode_escape_decode(r"\U00110000", "replace"), ("\ufffd", 10)) + +class UnicodeEscapeTest(unittest.TestCase): + def test_empty(self): + self.assertEqual(codecs.unicode_escape_encode(""), (b"", 0)) + self.assertEqual(codecs.unicode_escape_decode(b""), ("", 0)) + + def test_raw_encode(self): + encode = codecs.unicode_escape_encode + for b in range(32, 127): + if b != b'\\'[0]: + self.assertEqual(encode(chr(b)), (bytes([b]), 1)) + + def test_raw_decode(self): + decode = codecs.unicode_escape_decode + for b in range(256): + if b != b'\\'[0]: + self.assertEqual(decode(bytes([b]) + b'0'), (chr(b) + '0', 2)) + + def test_escape_encode(self): + encode = codecs.unicode_escape_encode + self.assertEqual(encode('\t'), (br'\t', 1)) + self.assertEqual(encode('\n'), (br'\n', 1)) + self.assertEqual(encode('\r'), (br'\r', 1)) + self.assertEqual(encode('\\'), (br'\\', 1)) + for b in range(32): + if chr(b) not in '\t\n\r': + self.assertEqual(encode(chr(b)), (('\\x%02x' % b).encode(), 1)) + for b in range(127, 256): + self.assertEqual(encode(chr(b)), (('\\x%02x' % b).encode(), 1)) + self.assertEqual(encode('\u20ac'), (br'\u20ac', 1)) + self.assertEqual(encode('\U0001d120'), (br'\U0001d120', 1)) + + def test_escape_decode(self): + decode = codecs.unicode_escape_decode + self.assertEqual(decode(b"[\\\n]"), ("[]", 4)) + self.assertEqual(decode(br'[\"]'), ('["]', 4)) + self.assertEqual(decode(br"[\']"), ("[']", 4)) + self.assertEqual(decode(br"[\\]"), (r"[\]", 4)) + self.assertEqual(decode(br"[\a]"), ("[\x07]", 4)) + self.assertEqual(decode(br"[\b]"), ("[\x08]", 4)) + self.assertEqual(decode(br"[\t]"), ("[\x09]", 4)) + self.assertEqual(decode(br"[\n]"), ("[\x0a]", 4)) + self.assertEqual(decode(br"[\v]"), ("[\x0b]", 4)) + self.assertEqual(decode(br"[\f]"), ("[\x0c]", 4)) + self.assertEqual(decode(br"[\r]"), ("[\x0d]", 4)) + self.assertEqual(decode(br"[\7]"), ("[\x07]", 4)) + self.assertEqual(decode(br"[\8]"), (r"[\8]", 4)) + self.assertEqual(decode(br"[\78]"), ("[\x078]", 5)) + self.assertEqual(decode(br"[\41]"), ("[!]", 5)) + self.assertEqual(decode(br"[\418]"), ("[!8]", 6)) + self.assertEqual(decode(br"[\101]"), ("[A]", 6)) + self.assertEqual(decode(br"[\1010]"), ("[A0]", 7)) + self.assertEqual(decode(br"[\x41]"), ("[A]", 6)) + self.assertEqual(decode(br"[\x410]"), ("[A0]", 7)) + self.assertEqual(decode(br"\u20ac"), ("\u20ac", 6)) + self.assertEqual(decode(br"\U0001d120"), ("\U0001d120", 10)) + for b in range(256): + if b not in b'\n"\'\\abtnvfr01234567xuUN': + self.assertEqual(decode(b'\\' + bytes([b])), + ('\\' + chr(b), 2)) + + def test_decode_errors(self): + decode = codecs.unicode_escape_decode + for c, d in (b'x', 2), (b'u', 4), (b'U', 4): + for i in range(d): + self.assertRaises(UnicodeDecodeError, decode, + b"\\" + c + b"0"*i) + self.assertRaises(UnicodeDecodeError, decode, + b"[\\" + c + b"0"*i + b"]") + data = b"[\\" + c + b"0"*i + b"]\\" + c + b"0"*i + self.assertEqual(decode(data, "ignore"), ("[]", len(data))) + self.assertEqual(decode(data, "replace"), + ("[\ufffd]\ufffd", len(data))) + self.assertRaises(UnicodeDecodeError, decode, br"\U00110000") + self.assertEqual(decode(br"\U00110000", "ignore"), ("", 10)) + self.assertEqual(decode(br"\U00110000", "replace"), ("\ufffd", 10)) + + class SurrogateEscapeTest(unittest.TestCase): def test_utf8(self): diff -r dcbc16afd6bc Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 25 23:52:21 2013 +0200 +++ b/Objects/unicodeobject.c Sat Jan 26 00:51:50 2013 +0200 @@ -5504,7 +5504,6 @@ const char *starts = s; Py_ssize_t startinpos; Py_ssize_t endinpos; - int j; PyObject *v; const char *end; char* message; @@ -5626,29 +5625,19 @@ message = "truncated \\UXXXXXXXX escape"; hexescape: chr = 0; - if (s+digits>end) { - endinpos = size; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", "end of string in escape sequence", - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &i)) - goto onError; - goto nextByte; - } - for (j = 0; j < digits; ++j) { - c = (unsigned char) s[j]; - if (!Py_ISXDIGIT(c)) { - endinpos = (s+j+1)-starts; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &i)) - goto onError; - len = PyUnicode_GET_LENGTH(v); - goto nextByte; - } + if (end - s < digits) { + /* count only hex digits */ + for (; s < end; ++s) { + c = (unsigned char)*s; + if (!Py_ISXDIGIT(c)) + goto error; + } + goto error; + } + for (; digits--; ++s) { + c = (unsigned char)*s; + if (!Py_ISXDIGIT(c)) + goto error; chr = (chr<<4) & ~0xF; if (c >= '0' && c <= '9') chr += c - '0'; @@ -5657,24 +5646,16 @@ else chr += 10 + c - 'A'; } - s += j; if (chr == 0xffffffff && PyErr_Occurred()) /* _decoding_error will have already written into the target buffer. */ break; store: /* when we get here, chr is a 32-bit unicode character */ - if (chr <= MAX_UNICODE) { - WRITECHAR(chr); - } else { - endinpos = s-starts; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", "illegal Unicode character", - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &i)) - goto onError; - } + message = "illegal Unicode character"; + if (chr > MAX_UNICODE) + goto error; + WRITECHAR(chr); break; /* \N{name} */ @@ -5702,26 +5683,13 @@ goto store; } } - endinpos = s-starts; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &i)) - goto onError; - break; + goto error; default: if (s > end) { message = "\\ at end of string"; s--; - endinpos = s-starts; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &i)) - goto onError; + goto error; } else { WRITECHAR('\\'); @@ -5729,8 +5697,18 @@ } break; } - nextByte: - ; + continue; + + error: + endinpos = s-starts; + if (unicode_decode_call_errorhandler( + errors, &errorHandler, + "unicodeescape", message, + &starts, &end, &startinpos, &endinpos, &exc, &s, + &v, &i)) + goto onError; + len = PyUnicode_GET_LENGTH(v); + continue; } #undef WRITECHAR -------------- next part -------------- diff -r d8c2ce63f5a4 Lib/test/test_codeccallbacks.py --- a/Lib/test/test_codeccallbacks.py Fri Jan 25 23:53:29 2013 +0200 +++ b/Lib/test/test_codeccallbacks.py Sat Jan 26 00:52:02 2013 +0200 @@ -271,12 +271,12 @@ self.assertEqual( b"\\u3042\u3xxx".decode("unicode-escape", "test.handler1"), - "\u3042[<92><117><51><120>]xx" + "\u3042[<92><117><51>]xxx" ) self.assertEqual( b"\\u3042\u3xx".decode("unicode-escape", "test.handler1"), - "\u3042[<92><117><51><120><120>]" + "\u3042[<92><117><51>]xx" ) self.assertEqual( diff -r d8c2ce63f5a4 Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py Fri Jan 25 23:53:29 2013 +0200 +++ b/Lib/test/test_codecs.py Sat Jan 26 00:52:02 2013 +0200 @@ -2009,6 +2009,84 @@ self.assertRaises(UnicodeDecodeError, codecs.raw_unicode_escape_decode, br"\U00110000") self.assertEqual(codecs.raw_unicode_escape_decode(r"\U00110000", "replace"), ("\ufffd", 10)) + +class UnicodeEscapeTest(unittest.TestCase): + def test_empty(self): + self.assertEqual(codecs.unicode_escape_encode(""), (b"", 0)) + self.assertEqual(codecs.unicode_escape_decode(b""), ("", 0)) + + def test_raw_encode(self): + encode = codecs.unicode_escape_encode + for b in range(32, 127): + if b != b'\\'[0]: + self.assertEqual(encode(chr(b)), (bytes([b]), 1)) + + def test_raw_decode(self): + decode = codecs.unicode_escape_decode + for b in range(256): + if b != b'\\'[0]: + self.assertEqual(decode(bytes([b]) + b'0'), (chr(b) + '0', 2)) + + def test_escape_encode(self): + encode = codecs.unicode_escape_encode + self.assertEqual(encode('\t'), (br'\t', 1)) + self.assertEqual(encode('\n'), (br'\n', 1)) + self.assertEqual(encode('\r'), (br'\r', 1)) + self.assertEqual(encode('\\'), (br'\\', 1)) + for b in range(32): + if chr(b) not in '\t\n\r': + self.assertEqual(encode(chr(b)), (('\\x%02x' % b).encode(), 1)) + for b in range(127, 256): + self.assertEqual(encode(chr(b)), (('\\x%02x' % b).encode(), 1)) + self.assertEqual(encode('\u20ac'), (br'\u20ac', 1)) + self.assertEqual(encode('\U0001d120'), (br'\U0001d120', 1)) + + def test_escape_decode(self): + decode = codecs.unicode_escape_decode + self.assertEqual(decode(b"[\\\n]"), ("[]", 4)) + self.assertEqual(decode(br'[\"]'), ('["]', 4)) + self.assertEqual(decode(br"[\']"), ("[']", 4)) + self.assertEqual(decode(br"[\\]"), (r"[\]", 4)) + self.assertEqual(decode(br"[\a]"), ("[\x07]", 4)) + self.assertEqual(decode(br"[\b]"), ("[\x08]", 4)) + self.assertEqual(decode(br"[\t]"), ("[\x09]", 4)) + self.assertEqual(decode(br"[\n]"), ("[\x0a]", 4)) + self.assertEqual(decode(br"[\v]"), ("[\x0b]", 4)) + self.assertEqual(decode(br"[\f]"), ("[\x0c]", 4)) + self.assertEqual(decode(br"[\r]"), ("[\x0d]", 4)) + self.assertEqual(decode(br"[\7]"), ("[\x07]", 4)) + self.assertEqual(decode(br"[\8]"), (r"[\8]", 4)) + self.assertEqual(decode(br"[\78]"), ("[\x078]", 5)) + self.assertEqual(decode(br"[\41]"), ("[!]", 5)) + self.assertEqual(decode(br"[\418]"), ("[!8]", 6)) + self.assertEqual(decode(br"[\101]"), ("[A]", 6)) + self.assertEqual(decode(br"[\1010]"), ("[A0]", 7)) + self.assertEqual(decode(br"[\x41]"), ("[A]", 6)) + self.assertEqual(decode(br"[\x410]"), ("[A0]", 7)) + self.assertEqual(decode(br"\u20ac"), ("\u20ac", 6)) + self.assertEqual(decode(br"\U0001d120"), ("\U0001d120", 10)) + for b in range(256): + if b not in b'\n"\'\\abtnvfr01234567xuUN': + self.assertEqual(decode(b'\\' + bytes([b])), + ('\\' + chr(b), 2)) + + def test_decode_errors(self): + decode = codecs.unicode_escape_decode + for c, d in (b'x', 2), (b'u', 4), (b'U', 4): + for i in range(d): + self.assertRaises(UnicodeDecodeError, decode, + b"\\" + c + b"0"*i) + self.assertRaises(UnicodeDecodeError, decode, + b"[\\" + c + b"0"*i + b"]") + data = b"[\\" + c + b"0"*i + b"]\\" + c + b"0"*i + self.assertEqual(decode(data, "ignore"), ("[]", len(data))) + self.assertEqual(decode(data, "replace"), + ("[\ufffd]\ufffd", len(data))) + self.assertRaises(UnicodeDecodeError, decode, br"\U00110000") + self.assertEqual(decode(br"\U00110000", "ignore"), ("", 10)) + self.assertEqual(decode(br"\U00110000", "replace"), ("\ufffd", 10)) + + class SurrogateEscapeTest(unittest.TestCase): def test_utf8(self): diff -r d8c2ce63f5a4 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 25 23:53:29 2013 +0200 +++ b/Objects/unicodeobject.c Sat Jan 26 00:52:02 2013 +0200 @@ -5376,7 +5376,6 @@ const char *starts = s; Py_ssize_t startinpos; Py_ssize_t endinpos; - int j; _PyUnicodeWriter writer; const char *end; char* message; @@ -5500,28 +5499,19 @@ message = "truncated \\UXXXXXXXX escape"; hexescape: chr = 0; - if (s+digits>end) { - endinpos = size; - if (unicode_decode_call_errorhandler_writer( - errors, &errorHandler, - "unicodeescape", "end of string in escape sequence", - &starts, &end, &startinpos, &endinpos, &exc, &s, - &writer)) - goto onError; - goto nextByte; - } - for (j = 0; j < digits; ++j) { - c = (unsigned char) s[j]; - if (!Py_ISXDIGIT(c)) { - endinpos = (s+j+1)-starts; - if (unicode_decode_call_errorhandler_writer( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &writer)) - goto onError; - goto nextByte; + if (end - s < digits) { + /* count only hex digits */ + for (; s < end; ++s) { + c = (unsigned char)*s; + if (!Py_ISXDIGIT(c)) + goto error; } + goto error; + } + for (; digits--; ++s) { + c = (unsigned char)*s; + if (!Py_ISXDIGIT(c)) + goto error; chr = (chr<<4) & ~0xF; if (c >= '0' && c <= '9') chr += c - '0'; @@ -5530,24 +5520,16 @@ else chr += 10 + c - 'A'; } - s += j; if (chr == 0xffffffff && PyErr_Occurred()) /* _decoding_error will have already written into the target buffer. */ break; store: /* when we get here, chr is a 32-bit unicode character */ - if (chr <= MAX_UNICODE) { - WRITECHAR(chr); - } else { - endinpos = s-starts; - if (unicode_decode_call_errorhandler_writer( - errors, &errorHandler, - "unicodeescape", "illegal Unicode character", - &starts, &end, &startinpos, &endinpos, &exc, &s, - &writer)) - goto onError; - } + message = "illegal Unicode character"; + if (chr > MAX_UNICODE) + goto error; + WRITECHAR(chr); break; /* \N{name} */ @@ -5575,26 +5557,13 @@ goto store; } } - endinpos = s-starts; - if (unicode_decode_call_errorhandler_writer( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &writer)) - goto onError; - break; + goto error; default: if (s > end) { message = "\\ at end of string"; s--; - endinpos = s-starts; - if (unicode_decode_call_errorhandler_writer( - errors, &errorHandler, - "unicodeescape", message, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &writer)) - goto onError; + goto error; } else { WRITECHAR('\\'); @@ -5602,8 +5571,17 @@ } break; } - nextByte: - ; + continue; + + error: + endinpos = s-starts; + if (unicode_decode_call_errorhandler_writer( + errors, &errorHandler, + "unicodeescape", message, + &starts, &end, &startinpos, &endinpos, &exc, &s, + &writer)) + goto onError; + continue; } #undef WRITECHAR From report at bugs.python.org Sat Jan 26 00:11:45 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Jan 2013 23:11:45 +0000 Subject: [issue16769] Remove some old Visual Studio versions from PC/ directory In-Reply-To: <1356368491.28.0.606279812477.issue16769@psf.upfronthosting.co.za> Message-ID: <3YtGFr2zYkzSM2@mail.python.org> Roundup Robot added the comment: New changeset 01bbac9369e8 by Brian Curtin in branch 'default': Fix #16769. Remove outdated Visual Studio project directories for VC6, VS7.1, and VS8. http://hg.python.org/cpython/rev/01bbac9369e8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 00:12:23 2013 From: report at bugs.python.org (Brian Curtin) Date: Fri, 25 Jan 2013 23:12:23 +0000 Subject: [issue16769] Remove some old Visual Studio versions from PC/ directory In-Reply-To: <1356368491.28.0.606279812477.issue16769@psf.upfronthosting.co.za> Message-ID: <1359155543.32.0.236654218067.issue16769@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 00:13:49 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 25 Jan 2013 23:13:49 +0000 Subject: [issue1674555] sys.path in tests contains system directories Message-ID: <1359155629.6.0.165196507444.issue1674555@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 01:04:07 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 26 Jan 2013 00:04:07 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1359158647.62.0.393454183144.issue17015@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 01:05:16 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 26 Jan 2013 00:05:16 +0000 Subject: [issue17010] Windows launcher ignores active virtual environment In-Reply-To: <1358812657.25.0.839528896034.issue17010@psf.upfronthosting.co.za> Message-ID: <1359158716.17.0.283335752144.issue17010@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- components: +Interpreter Core -Installation nosy: +brian.curtin, tim.golden, vinay.sajip stage: -> needs patch versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 01:26:13 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Jan 2013 00:26:13 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359159973.61.0.770534886965.issue17036@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file28832/297b3529876a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 02:00:46 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 26 Jan 2013 01:00:46 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1359162046.03.0.95269526962.issue9253@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 02:00:51 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Jan 2013 01:00:51 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359162051.03.0.97979887225.issue17036@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch of the latest revision. configure and Python/importlib.h must be regenerated (are not part of the diff). ---------- Added file: http://bugs.python.org/file28837/9bdfa1a3ea8c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 02:51:47 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Jan 2013 01:51:47 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359165107.86.0.0402077874053.issue17036@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested 9bdfa1a3ea8c.patch on Fedora 16 (Linux 3.6, glibc 2.14), Debian Etch (Linux 2.6.19), OpenBSD 5.2, OpenIndiana, FreeBSD 8.2, Windows 7. I tested both cases (works/not supported) for O_CLOEXEC and SOCK_CLOEXEC. For the WSA_FLAG_NO_HANDLE_INHERIT flag, I only tested a Windows version not supporting it (Windows 7 SP1 is required). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 02:52:24 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Jan 2013 01:52:24 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359165144.2.0.425613630663.issue17036@psf.upfronthosting.co.za> STINNER Victor added the comment: The select module may need more work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 03:04:27 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 26 Jan 2013 02:04:27 +0000 Subject: [issue16651] Find out what stdlib modules lack a pure Python implementation In-Reply-To: <1355078393.91.0.564166411172.issue16651@psf.upfronthosting.co.za> Message-ID: <1359165867.15.0.553284601319.issue16651@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- dependencies: +Add OrderedDict written in C nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 04:03:30 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 26 Jan 2013 03:03:30 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359169410.69.0.125536807365.issue17036@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 04:54:59 2013 From: report at bugs.python.org (Irwin Jungreis) Date: Sat, 26 Jan 2013 03:54:59 +0000 Subject: [issue16770] Selection in IDLE often skips first character In-Reply-To: <1356373924.27.0.67520730715.issue16770@psf.upfronthosting.co.za> Message-ID: <1359172499.43.0.651656721641.issue16770@psf.upfronthosting.co.za> Irwin Jungreis added the comment: I have reopened this issue because there are still cases where it does not work. I installed 8.5.13 and the IDLE patch as suggested. That fixed the particular case that I had used to demonstrate the problem (a file containing just two characters M1). However, the problem still occurs in other cases. To reproduce it, in IDLE pick File | New Window. In the new window type the characters '>>>from' (no spaces, and without the quotes). Now, before clicking anywhere else, move the cursor to the left half of the 'r'. Click once, and the insertion point incorrectly goes to the right of the 'r'. Click a second time without moving the cursor and the insertion point goes to the left side of the 'r'. Unlike the previously reported case, repeated clicking does not cause it to alternate -- only the first click is wrong. I have attached a second video (IMG_1219.MOV) that demonstrates this. ---------- status: closed -> open Added file: http://bugs.python.org/file28838/IMG_1219.MOV _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 06:08:17 2013 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 26 Jan 2013 05:08:17 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1359176897.04.0.822421551359.issue16991@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 06:48:25 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 05:48:25 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1359179305.65.0.712776896715.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a cleanup of test.test_collections that helps keep the subsequent patch (still forthcoming) cleaner. ---------- Added file: http://bugs.python.org/file28839/cleanup-test-collections.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 06:48:48 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 05:48:48 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support Message-ID: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> New submission from Eric Snow: Related to issue #16817 and to my efforts on a C OrderedDict, I think it would be nice to have a class decorator that handles most of the PEP 399 requirements for you. The attached patch adds such a decorator to test.support. ---------- assignee: eric.snow components: Library (Lib) files: conforms-to-pep399.diff keywords: patch messages: 180641 nosy: brett.cannon, eric.snow priority: normal severity: normal stage: patch review status: open title: Add conforms_to_pep399() to test.support type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28840/conforms-to-pep399.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 06:51:01 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 05:51:01 +0000 Subject: [issue16817] test___all__ affects other tests by doing too much importing In-Reply-To: <1356828969.86.0.130125185831.issue16817@psf.upfronthosting.co.za> Message-ID: <1359179460.99.0.905201609879.issue16817@psf.upfronthosting.co.za> Eric Snow added the comment: So the current solution is to temporarily put the relevant module in place in sys.modules, right? That seems to be the solution that Stefan recommended and used in the decimal module. Sounds good to me. I'm hitting this while doing the PEP 399 two-step for the collections module. It seems like this will be a problem for testing any module that has had such attention and has __all__. I'd be a fan of a class decorator that would take care of this and the rest of the PEP 399 stuff for you. I've created issue #17037 to cover that (so it doesn't get muddled in with this discussion of test___all__). There's even a proposed patch. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 06:52:47 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 05:52:47 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359179567.1.0.502793792035.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: One lingering doubt I have is about how I throw the two new test case classes into the globals. They're already getting bound, as a pair, to the original test class's name... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 06:56:14 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 05:56:14 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359179774.92.0.511238119161.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: One step I left out is handling the whole pickle/copyreg case outlined by #16817. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 06:56:55 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 05:56:55 +0000 Subject: [issue14715] test.support.DirsOnSysPath should be replaced by importlib.test.util.import_state In-Reply-To: <1336079069.84.0.625762752869.issue14715@psf.upfronthosting.co.za> Message-ID: <1359179815.1.0.332176231051.issue14715@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 07:02:08 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 26 Jan 2013 06:02:08 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359180128.72.0.896129620101.issue17037@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 08:15:32 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 26 Jan 2013 07:15:32 +0000 Subject: [issue17033] RPM spec file has old config_binsuffix value In-Reply-To: <1359129213.62.0.851750342405.issue17033@psf.upfronthosting.co.za> Message-ID: <1359184532.4.0.436601082296.issue17033@psf.upfronthosting.co.za> Nick Coghlan added the comment: Do we even *use* the spec file in Misc/RPM for anything any more? Should we just delete the entire directory? (Added Sean and Dave Malcolm to the nosy list) ---------- nosy: +dmalcolm, jafo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 09:32:53 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 08:32:53 +0000 Subject: [issue16737] Different behaviours in script run directly and via runpy.run_module In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za> Message-ID: <1359189173.26.0.861500496496.issue16737@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 09:37:07 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 08:37:07 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1359189427.12.0.275721453127.issue16748@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 09:44:29 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 08:44:29 +0000 Subject: [issue11995] test_pydoc loads all Python modules In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za> Message-ID: <1359189869.92.0.424009360585.issue11995@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 09:48:50 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 08:48:50 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359190130.9.0.947546619031.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: The decorator also mitigates the problem described in issue #16835. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 10:10:22 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 26 Jan 2013 09:10:22 +0000 Subject: [issue16770] Selection in IDLE often skips first character In-Reply-To: <1356373924.27.0.67520730715.issue16770@psf.upfronthosting.co.za> Message-ID: <1359191422.12.0.0356273864283.issue16770@psf.upfronthosting.co.za> Ned Deily added the comment: Using Cocoa Tk 8.5.13 and IDLE from either 2.7.3 and 3.3.0 on OS X 10.8.2, I can reproduce the behavior you report. However, I do not see the behavior when using Python 2.7.3 linked with the older Carbon Tk 8.4. I tried without success to reproduce the behavior using a stripped down version of one of the Tk Text widget demos in Wish 8.5. To me, the most likely cause is either an issue within Tk itself or a Tk 8.5 difference not handled by Tkinter and/or IDLE. In any case, it seems like a rather minor annoyance compared with most IDLE or Tkinter issues. If someone wants to investigate further, please feel free to do so. ---------- assignee: ned.deily -> priority: normal -> low resolution: out of date -> stage: committed/rejected -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 10:39:23 2013 From: report at bugs.python.org (HadiM) Date: Sat, 26 Jan 2013 09:39:23 +0000 Subject: [issue17038] multiprocessing only use one core when C module are imported Message-ID: <1359193163.5.0.985528068255.issue17038@psf.upfronthosting.co.za> New submission from HadiM: Hi, This is the first time I report a bug so if I did something wrong please let me know. I also tried to ask on #python and #python-fr before posting here to know if it was a bug or a possible multiprocessing limitation on Linux. So I'm sorry if it's not a bug... The problem appears when a module with .c compiled file is imported (sush as numpy, scipy, pandas, tables, skimage, I did not tested with a custom .c module). Multiprocessing and more specifically imap and map method of Pool class did not distribute processes along all the core but only on one core. This problem does not appears when I don't import a module with .c compiled. I know distributing processes along cores is specific to the OS implementation and not related to Python but I said that to illustrate the behaviour. I should notice that I did not see the bug with a Windows 7, 32 bits (Virtualbox). My laptop run with the latest ubuntu 64bits (tested with both kernel 3.5 and 3.8 last rc). It's a classic Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz with 4 cores. You can try to reproduce the bug with the attached file. You can also find the same file here : http://pastebin.com/jqq9G5Ph Thank you for your time ! ---------- components: Library (Lib), ctypes files: bug.py messages: 180648 nosy: hadim priority: normal severity: normal status: open title: multiprocessing only use one core when C module are imported type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file28841/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 10:56:33 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Jan 2013 09:56:33 +0000 Subject: [issue13454] crash when deleting one pair from tee() In-Reply-To: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za> Message-ID: <3YtXYr6q5YzRCZ@mail.python.org> Roundup Robot added the comment: New changeset 4ee8d38398d4 by Serhiy Storchaka in branch '2.7': Optimize the test for issue #13454. http://hg.python.org/cpython/rev/4ee8d38398d4 New changeset d391b2849a51 by Serhiy Storchaka in branch '3.2': Optimize the test for issue #13454. http://hg.python.org/cpython/rev/d391b2849a51 New changeset 2258b4d89c9f by Serhiy Storchaka in branch '3.3': Optimize the test for issue #13454. http://hg.python.org/cpython/rev/2258b4d89c9f New changeset 1f57fb5e1e8e by Serhiy Storchaka in branch 'default': Optimize the test for issue #13454. http://hg.python.org/cpython/rev/1f57fb5e1e8e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 11:03:07 2013 From: report at bugs.python.org (HadiM) Date: Sat, 26 Jan 2013 10:03:07 +0000 Subject: [issue17038] multiprocessing only use one core when C module are imported In-Reply-To: <1359193163.5.0.985528068255.issue17038@psf.upfronthosting.co.za> Message-ID: <1359194587.4.0.337829178293.issue17038@psf.upfronthosting.co.za> HadiM added the comment: I test to launch bug.py with pypy (import numpypy instead of import numpy) and the bug did not appear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 11:11:57 2013 From: report at bugs.python.org (Neil Muller) Date: Sat, 26 Jan 2013 10:11:57 +0000 Subject: [issue1145257] shutil.copystat() may fail... Message-ID: <1359195117.13.0.00686574452793.issue1145257@psf.upfronthosting.co.za> Neil Muller added the comment: I can't reproduce this bug on windows XP or windows 7 with python 2.7 or python 3.3. Is this still an issue? ---------- nosy: +Neil Muller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 11:21:50 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Jan 2013 10:21:50 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <3YtY715gHrzSRl@mail.python.org> Roundup Robot added the comment: New changeset 7c8ad0d02664 by Serhiy Storchaka in branch '2.7': Issue #10156: In the interpreter's initialization phase, unicode globals http://hg.python.org/cpython/rev/7c8ad0d02664 New changeset f7eda8165e6f by Serhiy Storchaka in branch '3.2': Issue #10156: In the interpreter's initialization phase, unicode globals http://hg.python.org/cpython/rev/f7eda8165e6f New changeset 01d4dd412581 by Serhiy Storchaka in branch '3.3': Issue #10156: In the interpreter's initialization phase, unicode globals http://hg.python.org/cpython/rev/01d4dd412581 New changeset cb12d642eed2 by Serhiy Storchaka in branch 'default': Issue #10156: In the interpreter's initialization phase, unicode globals http://hg.python.org/cpython/rev/cb12d642eed2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 11:27:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 10:27:12 +0000 Subject: [issue17034] Initialization of globals in stringobject.c and bytesobject.c In-Reply-To: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za> Message-ID: <1359196032.46.0.856583203952.issue17034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And for bytesobject.c in 3.x. ---------- title: Initialization of globals in stringobject.c -> Initialization of globals in stringobject.c and bytesobject.c versions: +Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28842/bytes_globals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 11:33:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 10:33:56 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1359196436.35.0.358117652154.issue10156@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed. Thank you for review, Stefan. Close this issue if the work is finished. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 11:39:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Jan 2013 10:39:48 +0000 Subject: [issue16235] Add python-config.sh for use during cross compilation. In-Reply-To: <1350251714.79.0.226527559426.issue16235@psf.upfronthosting.co.za> Message-ID: <3YtYWl6dx6zSSw@mail.python.org> Roundup Robot added the comment: New changeset c0370730b364 by doko in branch 'default': - Issue #16235: Implement python-config as a shell script. http://hg.python.org/cpython/rev/c0370730b364 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 11:45:07 2013 From: report at bugs.python.org (Matthias Klose) Date: Sat, 26 Jan 2013 10:45:07 +0000 Subject: [issue16235] Add python-config.sh for use during cross compilation. In-Reply-To: <1350251714.79.0.226527559426.issue16235@psf.upfronthosting.co.za> Message-ID: <1359197107.67.0.889012028146.issue16235@psf.upfronthosting.co.za> Matthias Klose added the comment: now committed, using stdin for sed. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 11:46:34 2013 From: report at bugs.python.org (Ray Donnelly) Date: Sat, 26 Jan 2013 10:46:34 +0000 Subject: [issue16235] Add python-config.sh for use during cross compilation. In-Reply-To: <1350251714.79.0.226527559426.issue16235@psf.upfronthosting.co.za> Message-ID: <1359197194.67.0.295994957912.issue16235@psf.upfronthosting.co.za> Ray Donnelly added the comment: Thank you Matthias! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 12:09:46 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Jan 2013 11:09:46 +0000 Subject: [issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig In-Reply-To: <1343555002.08.0.568710473474.issue15484@psf.upfronthosting.co.za> Message-ID: <3YtZBK5L9vzSRM@mail.python.org> Roundup Robot added the comment: New changeset f0cde9b6830a by doko in branch '3.3': - Follow-up for issue #15484: In PYTHON_FOR_BUILD, use $(PLATDIR) instead http://hg.python.org/cpython/rev/f0cde9b6830a New changeset 938a045cfe7d by doko in branch 'default': - Follow-up for issue #15484: In PYTHON_FOR_BUILD, use $(PLATDIR) instead http://hg.python.org/cpython/rev/938a045cfe7d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 12:28:23 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 26 Jan 2013 11:28:23 +0000 Subject: [issue17038] multiprocessing only use one core when C module are imported In-Reply-To: <1359193163.5.0.985528068255.issue17038@psf.upfronthosting.co.za> Message-ID: <1359199703.12.0.235162253528.issue17038@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Hello, > So I'm sorry if it's not a bug... Don't be afraid, we don't byte :-) Concerning your problem, my guess would be that one of the modules you import sets the process CPU affinity (maybe as a workaround to mitigate the GIL impact in multi-threaded code, or whatever) upon import. And a quick google search returns this: https://github.com/ipython/ipython/issues/840 To confirm this, you can just do: strace -e sched_setaffinity python -c "import numpy" You can also add """ for line in open('/proc/self/status'): if 'Cpu' in line: print(line) """ Right before and after importing the module, and you'll see that the CPU affinity has changed. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 12:30:10 2013 From: report at bugs.python.org (Ronny Pfannschmidt) Date: Sat, 26 Jan 2013 11:30:10 +0000 Subject: [issue17039] socket.SocketIO hides socket timeouts as blocking errors Message-ID: <1359199810.96.0.970549154582.issue17039@psf.upfronthosting.co.za> New submission from Ronny Pfannschmidt: the change to conform with pep 3114 makes socketSocketIO hide Timeouts, since they are also denoted with EAGAIN (which is one of the blocking errors a nonblocking socket will raise) that causes read/readinto return None, when one would expect a Timeout ---------- messages: 180660 nosy: Ronny.Pfannschmidt priority: normal severity: normal status: open title: socket.SocketIO hides socket timeouts as blocking errors versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 12:42:16 2013 From: report at bugs.python.org (HadiM) Date: Sat, 26 Jan 2013 11:42:16 +0000 Subject: [issue17038] multiprocessing only use one core when C module are imported In-Reply-To: <1359193163.5.0.985528068255.issue17038@psf.upfronthosting.co.za> Message-ID: <1359200536.66.0.542697032748.issue17038@psf.upfronthosting.co.za> HadiM added the comment: Indeed some value change when I print "cpu" line from /proc/self/status but I don't really understand what that mean... So there is no solution about that ? We cannot use multiprocessing with these modules under Linux ? Do you think I can manually change the CPU affinity or at least block changes made by other modules (without recompiling them of course) ? I guess if it's possible to modify CPU affinity, numpy and other scientific libraries won't be efficient as before, no ? Because the won't share the same cache or something like that, if I get the wikipedia page about cpu affinity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 12:54:05 2013 From: report at bugs.python.org (Ray Donnelly) Date: Sat, 26 Jan 2013 11:54:05 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359201245.65.0.673480512673.issue3871@psf.upfronthosting.co.za> Ray Donnelly added the comment: When I say ?our patches? I mean mine and Alexey Pavlov?s jointly maintained patch-set. I hope you don?t mind that I find you saying: "I tried some of these patches, but they aren't very organinzed. I really need some docemntaiton to better understand what each patch does and which pairs go together and which don't." ...and then continuing to present a single uber-patch to be mildly funny/ironic? You've already accepted that you should split them up and remove the needless formatting changes to make them more reviewable so I won't labour on this point. "ctypes bz2 multiprocessing sqlite3 ssl pyexpat zlib" Likewise for ours, but also curses, curses_panel, readline, TKinter, IDLE (and probably more besides) for both Win32, Win64, Mac OS X 32bit and 64bit. The main idea behind our patches is (mostly in common with all patches) that they: 1. Are as atomic as possible in their operation (which as few interdependencies as necessary). 2. Are applied in an obvious ordering. 3. Are named sensibly according to what they do. 4. Build upon - and can reuse updates to - Roumen's uber-patch (and also clean it up a bit; let?s face it Roumen did a lot of the hard work and everyone else is trying to finish it off so we can build releases from it). 5. Enable comprehensive cross-compilation. Given the name of each patch and the fact that they do one thing (the novel ones at least) and that by-and-large they fit on a few screens, I had hoped that they were usefully descriptive. To explain which ones go together: The numbering skips 5 each time for each independent bug-fix or feature - to allow space for later, related modifications. Therefore, where the numbering changes monotonically, the patches are related. This only happens twice, once to address the problem caused by Roumen providing an uber-patch and once due to a block of fixes all related to curses (ncurses and PDCurses are both supported). I assume my addressing of Roumen's uber-patch is what led you to write: "However, I'm noticing a ton of descrepancies with these patches. Some are removing pthreads, others are adding them back." There is logic to what you describe as a ton of discrepancies: Roumen's patch is included in it's entirety as 0030-py3k-20121004-MINGW.patch, then I remove one feature of that patch that needed fixing (threading changes) with 0031-py3k-20121004-MINGW-removal-of-pthread-patch.patch, then I add a patch that provides my newer fix, 0032-py3k-20121004-MINGW-ntthreads.patch. The exact same thing happens with the libffi changes. The pthreads stuff needs fixing due to libwinpthread in MinGW-w64 and libffi is broken when targetting a 64bit Windows host. My reason for doing this is so that I can directly drop updated versions from Roumen in over 0030 and it will (in theory at least) still work. He can continue to use a uber-patch if he wishes (though I don't think he does this for "new" patches). Also by taking this approach, my patch for the threading issues has no dependencies at all on Roumen?s patch, since a previous patch ?handled? the dependency by removing that part of it. Everything you said about build environment and the test-suite I agree with. My crucifixion-freedom project includes a .vbs to setup the most basic MSYS and MinGW-w64 environment: https://raw.github.com/mingwandroid/crucifixion-freedom/master/scripts/windows/BootstrapMinGW64.vbs ...this is essential to prevent spending time chasing down issues due to discrepancies between build environments. However, we must go further and add that the patches *cannot* break any other native or cross-compilation, which - as I think Matthias is alluding to - is probably not the case with your patch. This issue is called "cross and native build of python for mingw* hosts", so that your patch possibly breaks builds on build-machine is unfortunate (especially so as a build-machine Python is required to run setup.py as part of the cross-build procedure). Even if it doesn't break building for the build-machine it breaks building the cross-MinGW-w64. Each occurrence of "/mingw" in your patch is probably a part of this problem (you can?t expect cross build systems to be be able to be rooted to /mingw, often you?ll find ~/mingw or /tmp/mingw) You said, "It seems some are also compiling and using the mingw version outside of the msys shell, which I'm not certain of the advantages there when u can just use the mscv version", I?m not entirely sure what you mean here; if compiling MinGW Python on a Windows system with my patches, MSYS is 100% a requirement (cmd.exe will never run the configure script). I can only guess this relates to the mingw_posix2win_path stuff in your patch. Forgive me if I?m wrong, but it seems that you are conflating MSYS and MinGW when they are not related (except by frequent proximity). Without wanting to point out the obvious, MinGW-w64 is a sysroot and compiler toolchain for making native Windows programs and MSYS is a minimal Posix shell capable of running GNU Autotools. I think a result of this conflation is that a Python built using your patch is not properly usable outside of the MSYS shell (i.e. it will incorrectly transform paths), whereas using our patch-set, the built Python is fully compatible with the MSYS shell and cmd.exe (and whatever else; Wine I guess?). You likely already know this, but there are two types programs that run on the MSYS shell, MSYS executables built with msys-gcc that link to the msys dll (which then does file path translation when you call any file IO functions) and native Windows executables (for which, when run under MSYS, MSYS?s bash.exe transforms the input arguments before calling the executable when it detects that msys dll is *not* used by that executable). A MinGW/MSYS environment consists of a mix of both, but programs built *with* it should be native Windows executables only (unless you are involved in hacking on the MSYS/MSYS2 projects that is). Your patch makes something in-between. I think this confusion is the reason why you wrote "u can just use the mscv version", please read again the name of this issue. I fail to see how adding a restriction so that MinGW Python can only work properly under MSYS can be argued as anything other than a bug (if you want to build an MSYS Python then that?s a different issue altogether - you?ll end up wrestling with GCC 3.3). Also, with regards to MSVC, given a choice, for philosophical reasons I'll always use software built predominantly with FLOSS software. For sure, as you say, our patches also allow building MinGW Python outside of the MSYS shell, specifically, you can use a Linux or Mac OS X bourne-compatible shell (good luck trying to get recent MinGW cross-compilers for Darwin though). Again, this is a feature and not a problem. IMHO, updating these patches to track the latest Python is a pointless goal. The only reason I can see to do this would be to make it easy for a reviewer to merge it with the CPython mercurial repository, and realistically, these patches/patch-sets are not going to be merged wholesale. As I said before, the only hope is that bit-by-bit, some small fixes get merged and the patch-set is reduced over time and made more manageable [1]. Instead, I think it makes more sense to target the latest released versions from each branch as that way we?re not chasing a moving target (in particular, we?d only have to update it every-so-often, and if we enforced a disciplined usage of the test-suite then regressions caused by our patches would not be intermixed with ones caused by changes to CPython repository). To recap, the features of our patch-set are: 1. Readable and reviewable. 2. Doesn't break builds for Cygwin or (likely) any other platform. 3. Fixes cross compilation (for me this is hugely important). 4. Can build 64bit MinGW Python. 5. Works outside of MSYS without any path assumptions or hacks. 6. Attempts to minimize impact to distutils (monkey patching instead of direct modification where possible - this is the most contentious part of Python, patches-wise). 7. Can co-exist with Windows Python due to different dll naming. 8. Can be installed to any prefix, using a Posix installation layout rather than the Windows one (?$prefix/bin?, ?$prefix/include?, ?$prefix/lib? and ?$prefix/share?) 9. Can subsequently be relocated to anywhere the user wishes. 10. Is well tested. Python's built with the 2.7.x version of this patch-set have been in use by many people for well over a year now - to provide pretty-printer support for GDB, without any reported issues. 11. As well as cross/MSYS compiling to/on Windows, these patches allow Darwin Python to be cross-compiled. I hope you will consider collaborating. If so then I will set aside some time to add descriptions to each of the patch files; otherwise, if you just split your patches up into a series of atomic fixes instead then I?ll examine those patches to see if there?s anything I can use. As usual, for anyone who wants to get involved in this effort, you can send patches and/or suggestions to me at mingw.android at gmail.com or reply to this issue. [1] http://hg.python.org/cpython/rev/c0370730b364 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 13:01:58 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 26 Jan 2013 12:01:58 +0000 Subject: [issue17038] multiprocessing only use one core when C module are imported In-Reply-To: <1359200536.66.0.542697032748.issue17038@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Indeed some value change when I print "cpu" line from /proc/self/status but I don't really understand what that mean... It means that the CPU affinity is changed, so the scheduler binds your process to a subset of the available CPUs. > So there is no solution about that ? We cannot use multiprocessing with these modules under Linux ? > > Do you think I can manually change the CPU affinity or at least block changes made by other modules (without recompiling them of course) ? If you don't want to recompile the offending module (it seems to be GotoBLAS2), you can change the affinity after importing your modules with something like: """ os.system("taskset -p 0xff %d" % os.getpid()) """ (Python 3.3 exposes the scheduling API natively, see http://docs.python.org/dev/library/os.html#interface-to-the-scheduler) > I guess if it's possible to modify CPU affinity, numpy and other scientific libraries won't be efficient as before, no ? Because the won't share the same cache or something like that, if I get the wikipedia page about cpu affinity. Soft affinity is naturally done by the operating system scheduler, so you don't have to worry about cache line bouncing and the like. Hard affinity is only useful in very specific cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 13:02:26 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 26 Jan 2013 12:02:26 +0000 Subject: [issue17038] multiprocessing only use one core when C module are imported In-Reply-To: <1359193163.5.0.985528068255.issue17038@psf.upfronthosting.co.za> Message-ID: <1359201746.02.0.0903961575612.issue17038@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 13:33:49 2013 From: report at bugs.python.org (HadiM) Date: Sat, 26 Jan 2013 12:33:49 +0000 Subject: [issue17038] multiprocessing only use one core when C module are imported In-Reply-To: <1359193163.5.0.985528068255.issue17038@psf.upfronthosting.co.za> Message-ID: <1359203629.34.0.927097858544.issue17038@psf.upfronthosting.co.za> HadiM added the comment: Your snippet did the trick ! Thank you for your time. Even if it's not very clean, it's working. Thank again ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 13:47:08 2013 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 26 Jan 2013 12:47:08 +0000 Subject: [issue17010] Windows launcher ignores active virtual environment In-Reply-To: <1358812657.25.0.839528896034.issue17010@psf.upfronthosting.co.za> Message-ID: <1359204428.51.0.605504219833.issue17010@psf.upfronthosting.co.za> Vinay Sajip added the comment: When using an activated virtual environment, there is no need to use "py" - just use "python". Primarily, the launcher looks for a shebang line in a script to determine which interpreter to use for the script. If no shebang line can be found, it will launch "the default" Python, which is currently the most recent Python 2.x found in the registry. When invoked via py -3 (or with suitable settings in the configuration), it will use the most recent Python 3.x found in the registry. Since venv interpreters are not in the registry, they will never be invoked as the default Python. However, any scripts installed into venvs will have the correct shebang lines, so they will launch with the venv's interpreter. I don't believe this is a bug, as the system is IMO working as designed and as per PEP 397. If the launcher is asked to launch a script which contains a shebang, while a venv is activated, it will run with the interpreter indicated by the shebang, rather than the venv's interpreter. Perhaps one could consider an enhancement whereby if no shebang is found, a different approach is used to find the interpreter - e.g. looking for "python" on the path before looking in the registry to locate an interpreter. The question arises as to whether this should be tied to a specific condition such as the presence of an environment key PYLAUNCHER_USEPATH. (This is of course orthogonal to whether or not a venv is activated, but would have the desired effect when a venv is activated, without needing to tie the launcher to a virtualenv-specific environment value such as VIRTUAL_ENV.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 13:47:41 2013 From: report at bugs.python.org (Ronny Pfannschmidt) Date: Sat, 26 Jan 2013 12:47:41 +0000 Subject: [issue17039] socket.SocketIO hides socket timeouts as blocking errors In-Reply-To: <1359199810.96.0.970549154582.issue17039@psf.upfronthosting.co.za> Message-ID: <1359204461.63.0.162265239026.issue17039@psf.upfronthosting.co.za> Ronny Pfannschmidt added the comment: noticed an error in my testing, sorry for the noise ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 14:26:51 2013 From: report at bugs.python.org (Berker Peksag) Date: Sat, 26 Jan 2013 13:26:51 +0000 Subject: [issue17040] Document context manager support for shelf objects Message-ID: <1359206810.79.0.264675757917.issue17040@psf.upfronthosting.co.za> New submission from Berker Peksag: Context manager support for shelf objects was added in issue 13896, but not documented. ---------- assignee: docs at python components: Documentation files: shelve-context-manager-doc.diff keywords: patch messages: 180667 nosy: asvetlov, berker.peksag, docs at python priority: normal severity: normal status: open title: Document context manager support for shelf objects versions: Python 3.4 Added file: http://bugs.python.org/file28843/shelve-context-manager-doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 14:35:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 13:35:37 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings Message-ID: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Some tests failed when Python built without docstrings (--without-doc-strings options). Proposed patch fixes most of tests. Only doctests in test_generators and test_genexps don't fixed. I?don't know how to make doctests conditional. [135/372] test_generators ********************************************************************** File "/home/serhiy/py/cpython-without-doc-strings/Lib/test/test_generators.py", line ?, in test.test_generators.__test__.email Failed example: print(i.__next__.__doc__) Expected: x.__next__() <==> next(x) Got: ********************************************************************** 1 items had failures: 1 of 31 in test.test_generators.__test__.email ***Test Failed*** 1 failures. test test_generators failed -- 1 of 287 doctests failed [137/372/1] test_genexps ********************************************************************** File "/home/serhiy/py/cpython-without-doc-strings/Lib/test/test_genexps.py", line ?, in test.test_genexps.__test__.doctests Failed example: print(g.__next__.__doc__) Expected: x.__next__() <==> next(x) Got: ********************************************************************** 1 items had failures: 1 of 75 in test.test_genexps.__test__.doctests ***Test Failed*** 1 failures. test test_genexps failed -- 1 of 75 doctests failed ---------- components: Tests files: tests_without_docstrings.patch keywords: patch messages: 180668 nosy: serhiy.storchaka, skrah priority: normal severity: normal stage: patch review status: open title: Fix tests for build --without-doc-strings type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28844/tests_without_docstrings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 14:36:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 13:36:33 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359207393.26.0.751749668743.issue17041@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, michael.foord, pitrou Added file: http://bugs.python.org/file28845/tests_without_docstrings-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 14:46:48 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 26 Jan 2013 13:46:48 +0000 Subject: [issue16817] test___all__ affects other tests by doing too much importing In-Reply-To: <1356828969.86.0.130125185831.issue16817@psf.upfronthosting.co.za> Message-ID: <1359208008.52.0.922836453849.issue16817@psf.upfronthosting.co.za> Eli Bendersky added the comment: Eric, yes the key code in test_xml_etree that handles this is: def pickleRoundTrip(self, obj, name, dumper, loader): save_m = sys.modules[name] try: sys.modules[name] = dumper temp = pickle.dumps(obj) sys.modules[name] = loader result = pickle.loads(temp) except pickle.PicklingError as pe: # pyET must be second, because pyET may be (equal to) ET. human = dict([(ET, "cET"), (pyET, "pyET")]) raise support.TestFailed("Failed to round-trip %r from %r to %r" % (obj, human.get(dumper, dumper), human.get(loader, loader))) from pe finally: sys.modules[name] = save_m return result Because pickle does its own import of ElementTree. The test___all__ problem should be solved by a patch to issue #1674555, but having a separate mechanism in test.support was discussed. I'll take a look at your decorator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 14:59:14 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 13:59:14 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359208754.62.0.107341659032.issue17041@psf.upfronthosting.co.za> Stefan Krah added the comment: I've already committed a decorator in 5c7f92bfe785, but it isn't quite robust. I think the one in issue17041-decorator.diff should do the trick. Also, we then can use support.HAVE_DOCSTRINGS for some doctests. ---------- Added file: http://bugs.python.org/file28846/issue17041-decorator.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 15:11:31 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 26 Jan 2013 14:11:31 +0000 Subject: [issue15359] Sockets support for CAN_BCM In-Reply-To: <1358915100.92.0.782010614471.issue15359@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I've added (some) docs and added checking of the BCM constants to the test_socket module. This version looks good to me. I'll commit it next week (I currently don't have access to my development machine). > I would guess that checking each broadcast manager function provided by the kernel isn't required? No, the goal is not to test the kernel implementation. That should be enough for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 15:18:53 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 26 Jan 2013 14:18:53 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359209933.55.0.929642736648.issue17037@psf.upfronthosting.co.za> Eli Bendersky added the comment: Nice work, although I worry this is starting to get into "too much magic" territory. Do you have a real use case for the 'names' argument? ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 15:23:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Jan 2013 14:23:30 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359210210.5.0.804198553729.issue17037@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure what the use case for this is. It looks more obfuscating than revealing to me. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 15:28:13 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 14:28:13 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207393.29.0.0898779190321.issue17041@psf.upfronthosting.co.za> Message-ID: <201301261627.47137.storchaka@gmail.com> Serhiy Storchaka added the comment: Oh, I see Stefan already fixed some failures. Here are updated patches. ---------- Added file: http://bugs.python.org/file28847/tests_without_docstrings-2.7_2.patch Added file: http://bugs.python.org/file28848/tests_without_docstrings-3.2_2.patch Added file: http://bugs.python.org/file28849/tests_without_docstrings-3.3_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 523f309cf558 Lib/ctypes/test/test_win32.py --- a/Lib/ctypes/test/test_win32.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/ctypes/test/test_win32.py Sat Jan 26 16:19:23 2013 +0200 @@ -3,6 +3,7 @@ from ctypes import * from ctypes.test import is_resource_enabled import unittest, sys +import sysconfig import _ctypes_test @@ -60,7 +61,9 @@ def test_COMError(self): from _ctypes import COMError - self.assertEqual(COMError.__doc__, "Raised when a COM method call failed.") + if sysconfig.get_config_var('WITH_DOC_STRINGS'): + self.assertEqual(COMError.__doc__, + "Raised when a COM method call failed.") ex = COMError(-1, "text", ("details",)) self.assertEqual(ex.hresult, -1) diff -r 523f309cf558 Lib/distutils/tests/test_build_ext.py --- a/Lib/distutils/tests/test_build_ext.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/distutils/tests/test_build_ext.py Sat Jan 26 16:19:23 2013 +0200 @@ -2,6 +2,7 @@ import os from StringIO import StringIO import textwrap +import sysconfig from distutils.core import Extension, Distribution from distutils.command.build_ext import build_ext @@ -77,8 +78,9 @@ self.assertEqual(xx.foo(2, 5), 7) self.assertEqual(xx.foo(13,15), 28) self.assertEqual(xx.new().demo(), None) - doc = 'This is a template module just for instruction.' - self.assertEqual(xx.__doc__, doc) + if sysconfig.get_config_var('WITH_DOC_STRINGS'): + doc = 'This is a template module just for instruction.' + self.assertEqual(xx.__doc__, doc) self.assertTrue(isinstance(xx.Null(), xx.Null)) self.assertTrue(isinstance(xx.Str(), xx.Str)) diff -r 523f309cf558 Lib/test/test_functools.py --- a/Lib/test/test_functools.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/test/test_functools.py Sat Jan 26 16:19:23 2013 +0200 @@ -196,6 +196,7 @@ self.assertEqual(wrapper.__name__, 'f') self.assertEqual(wrapper.attr, 'This is also a test') + @test_support.requires_docstrings @unittest.skipIf(sys.flags.optimize >= 2, "Docstrings are omitted with -O2 and above") def test_default_update_doc(self): diff -r 523f309cf558 Lib/test/test_pydoc.py --- a/Lib/test/test_pydoc.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/test/test_pydoc.py Sat Jan 26 16:19:23 2013 +0200 @@ -10,12 +10,21 @@ import xml.etree import test.test_support from collections import namedtuple +import sysconfig from test.script_helper import assert_python_ok from test.test_support import ( TESTFN, rmtree, reap_children, captured_stdout) from test import pydoc_mod +if sysconfig.get_config_var('WITH_DOC_STRINGS'): + expected_data_docstrings = ( + 'dictionary for instance variables (if defined)', + 'list of weak references to the object (if defined)', + ) +else: + expected_data_docstrings = ('', '', '', '') + expected_text_pattern = \ """ NAME @@ -40,11 +49,9 @@ class B(__builtin__.object) | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s |\x20\x20 | ---------------------------------------------------------------------- | Data and other attributes defined here: @@ -75,6 +82,9 @@ Nobody """.strip() +expected_text_data_docstrings = tuple('\n | ' + s if s else '' + for s in expected_data_docstrings) + expected_html_pattern = \ """ @@ -121,10 +131,10 @@
     Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s
Data and other attributes defined here:
@@ -168,6 +178,8 @@ 		Nobody
""".strip() +expected_html_data_docstrings = tuple(s.replace(' ', ' ') + for s in expected_data_docstrings) # output pattern for missing module missing_pattern = "no Python documentation found for '%s'" @@ -229,7 +241,9 @@ mod_url = nturl2path.pathname2url(mod_file) else: mod_url = mod_file - expected_html = expected_html_pattern % (mod_url, mod_file, doc_loc) + expected_html = expected_html_pattern % ( + (mod_url, mod_file, doc_loc) + + expected_html_data_docstrings) if result != expected_html: print_diffs(expected_html, result) self.fail("outputs are not equal, see diff above") @@ -238,8 +252,9 @@ "Docstrings are omitted with -O2 and above") def test_text_doc(self): result, doc_loc = get_pydoc_text(pydoc_mod) - expected_text = expected_text_pattern % \ - (inspect.getabsfile(pydoc_mod), doc_loc) + expected_text = expected_text_pattern % ( + (inspect.getabsfile(pydoc_mod), doc_loc) + + expected_text_data_docstrings) if result != expected_text: print_diffs(expected_text, result) self.fail("outputs are not equal, see diff above") -------------- next part -------------- diff -r f7eda8165e6f Lib/ctypes/test/test_win32.py --- a/Lib/ctypes/test/test_win32.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/ctypes/test/test_win32.py Sat Jan 26 16:27:04 2013 +0200 @@ -3,6 +3,7 @@ from ctypes import * from ctypes.test import is_resource_enabled import unittest, sys +import sysconfig import _ctypes_test @@ -60,7 +61,9 @@ def test_COMError(self): from _ctypes import COMError - self.assertEqual(COMError.__doc__, "Raised when a COM method call failed.") + if sysconfig.get_config_var('WITH_DOC_STRINGS'): + self.assertEqual(COMError.__doc__, + "Raised when a COM method call failed.") ex = COMError(-1, "text", ("details",)) self.assertEqual(ex.hresult, -1) diff -r f7eda8165e6f Lib/distutils/tests/test_build_ext.py --- a/Lib/distutils/tests/test_build_ext.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/distutils/tests/test_build_ext.py Sat Jan 26 16:27:04 2013 +0200 @@ -2,6 +2,7 @@ import os from io import StringIO import textwrap +import sysconfig from distutils.core import Distribution from distutils.command.build_ext import build_ext @@ -73,8 +74,9 @@ self.assertEqual(xx.foo(2, 5), 7) self.assertEqual(xx.foo(13,15), 28) self.assertEqual(xx.new().demo(), None) - doc = 'This is a template module just for instruction.' - self.assertEqual(xx.__doc__, doc) + if sysconfig.get_config_var('WITH_DOC_STRINGS'): + doc = 'This is a template module just for instruction.' + self.assertEqual(xx.__doc__, doc) self.assertTrue(isinstance(xx.Null(), xx.Null)) self.assertTrue(isinstance(xx.Str(), xx.Str)) diff -r f7eda8165e6f Lib/test/support.py --- a/Lib/test/support.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/test/support.py Sat Jan 26 16:27:04 2013 +0200 @@ -510,6 +510,10 @@ float.__getformat__("double").startswith("IEEE"), "test requires IEEE 754 doubles") +requires_docstrings = unittest.skipUnless( + sysconfig.get_config_var('WITH_DOC_STRINGS'), + "test requires docstrings") + is_jython = sys.platform.startswith('java') # Filename used for testing diff -r f7eda8165e6f Lib/test/test_bytes.py --- a/Lib/test/test_bytes.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/test/test_bytes.py Sat Jan 26 16:27:04 2013 +0200 @@ -986,6 +986,7 @@ self.assertEqual(bytes(b"abc") < b"ab", False) self.assertEqual(bytes(b"abc") <= b"ab", False) + @test.support.requires_docstrings def test_doc(self): self.assertIsNotNone(bytearray.__doc__) self.assertTrue(bytearray.__doc__.startswith("bytearray("), bytearray.__doc__) diff -r f7eda8165e6f Lib/test/test_functools.py --- a/Lib/test/test_functools.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/test/test_functools.py Sat Jan 26 16:27:04 2013 +0200 @@ -287,6 +287,7 @@ with self.assertRaises(AttributeError): functools.update_wrapper(wrapper, f, assign, update) + @support.requires_docstrings @unittest.skipIf(sys.flags.optimize >= 2, "Docstrings are omitted with -O2 and above") def test_builtin_update(self): diff -r f7eda8165e6f Lib/test/test_pydoc.py --- a/Lib/test/test_pydoc.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/test/test_pydoc.py Sat Jan 26 16:27:04 2013 +0200 @@ -14,6 +14,7 @@ import textwrap from io import StringIO from collections import namedtuple +import sysconfig from test.script_helper import assert_python_ok from test.support import ( TESTFN, rmtree, @@ -30,6 +31,14 @@ if hasattr(pydoc_mod, "__loader__"): del pydoc_mod.__loader__ +if sysconfig.get_config_var('WITH_DOC_STRINGS'): + expected_data_docstrings = ( + 'dictionary for instance variables (if defined)', + 'list of weak references to the object (if defined)', + ) * 2 +else: + expected_data_docstrings = ('', '', '', '') + expected_text_pattern = """ NAME test.pydoc_mod - This is a test module for test_pydoc @@ -50,20 +59,16 @@ | ---------------------------------------------------------------------- | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s \x20\x20\x20\x20 class B(builtins.object) | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s |\x20\x20 | ---------------------------------------------------------------------- | Data and other attributes defined here: @@ -95,6 +100,9 @@ %s """.strip() +expected_text_data_docstrings = tuple('\n | ' + s if s else '' + for s in expected_data_docstrings) + expected_html_pattern = """ @@ -134,10 +142,10 @@
Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s

@@ -148,10 +156,10 @@
     Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s
Data and other attributes defined here:
@@ -193,6 +201,8 @@ 		Nobody
""".strip() # ' <- emacs turd +expected_html_data_docstrings = tuple(s.replace(' ', ' ') + for s in expected_data_docstrings) # output pattern for missing module missing_pattern = "no Python documentation found for '%s'" @@ -262,7 +272,9 @@ mod_url = nturl2path.pathname2url(mod_file) else: mod_url = mod_file - expected_html = expected_html_pattern % (mod_url, mod_file, doc_loc) + expected_html = expected_html_pattern % ( + (mod_url, mod_file, doc_loc) + + expected_html_data_docstrings) if result != expected_html: print_diffs(expected_html, result) self.fail("outputs are not equal, see diff above") @@ -271,8 +283,10 @@ "Docstrings are omitted with -O2 and above") def test_text_doc(self): result, doc_loc = get_pydoc_text(pydoc_mod) - expected_text = expected_text_pattern % \ - (doc_loc, inspect.getabsfile(pydoc_mod)) + expected_text = expected_text_pattern % ( + (doc_loc,) + + expected_text_data_docstrings + + (inspect.getabsfile(pydoc_mod),)) if result != expected_text: print_diffs(expected_text, result) self.fail("outputs are not equal, see diff above") @@ -346,8 +360,10 @@ captured_output('stderr') as err: helper.help(module) result = buf.getvalue().strip() - expected_text = expected_help_pattern % \ - (doc_loc, inspect.getabsfile(pydoc_mod)) + expected_text = expected_help_pattern % ( + (doc_loc,) + + expected_text_data_docstrings + + (inspect.getabsfile(pydoc_mod),)) self.assertEqual('', output.getvalue()) self.assertEqual('', err.getvalue()) self.assertEqual(expected_text, result) -------------- next part -------------- diff -r 0cd5d215179a Lib/ctypes/test/test_win32.py --- a/Lib/ctypes/test/test_win32.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/ctypes/test/test_win32.py Sat Jan 26 16:19:35 2013 +0200 @@ -3,6 +3,7 @@ from ctypes import * from ctypes.test import is_resource_enabled import unittest, sys +import sysconfig import _ctypes_test @@ -60,7 +61,9 @@ def test_COMError(self): from _ctypes import COMError - self.assertEqual(COMError.__doc__, "Raised when a COM method call failed.") + if sysconfig.get_config_var('WITH_DOC_STRINGS'): + self.assertEqual(COMError.__doc__, + "Raised when a COM method call failed.") ex = COMError(-1, "text", ("details",)) self.assertEqual(ex.hresult, -1) diff -r 0cd5d215179a Lib/distutils/tests/test_build_ext.py --- a/Lib/distutils/tests/test_build_ext.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/distutils/tests/test_build_ext.py Sat Jan 26 16:19:35 2013 +0200 @@ -2,6 +2,7 @@ import os from io import StringIO import textwrap +import sysconfig from distutils.core import Distribution from distutils.command.build_ext import build_ext @@ -73,8 +74,9 @@ self.assertEqual(xx.foo(2, 5), 7) self.assertEqual(xx.foo(13,15), 28) self.assertEqual(xx.new().demo(), None) - doc = 'This is a template module just for instruction.' - self.assertEqual(xx.__doc__, doc) + if sysconfig.get_config_var('WITH_DOC_STRINGS'): + doc = 'This is a template module just for instruction.' + self.assertEqual(xx.__doc__, doc) self.assertTrue(isinstance(xx.Null(), xx.Null)) self.assertTrue(isinstance(xx.Str(), xx.Str)) diff -r 0cd5d215179a Lib/test/test_functools.py --- a/Lib/test/test_functools.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/test/test_functools.py Sat Jan 26 16:19:35 2013 +0200 @@ -312,6 +312,7 @@ with self.assertRaises(AttributeError): functools.update_wrapper(wrapper, f, assign, update) + @support.requires_docstrings @unittest.skipIf(sys.flags.optimize >= 2, "Docstrings are omitted with -O2 and above") def test_builtin_update(self): diff -r 0cd5d215179a Lib/test/test_pydoc.py --- a/Lib/test/test_pydoc.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/test/test_pydoc.py Sat Jan 26 16:19:35 2013 +0200 @@ -14,6 +14,7 @@ import textwrap from io import StringIO from collections import namedtuple +import sysconfig from test.script_helper import assert_python_ok from test.support import ( TESTFN, rmtree, @@ -30,6 +31,14 @@ if hasattr(pydoc_mod, "__loader__"): del pydoc_mod.__loader__ +if sysconfig.get_config_var('WITH_DOC_STRINGS'): + expected_data_docstrings = ( + 'dictionary for instance variables (if defined)', + 'list of weak references to the object (if defined)', + ) * 2 +else: + expected_data_docstrings = ('', '', '', '') + expected_text_pattern = """ NAME test.pydoc_mod - This is a test module for test_pydoc @@ -50,20 +59,16 @@ | ---------------------------------------------------------------------- | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s \x20\x20\x20\x20 class B(builtins.object) | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s |\x20\x20 | ---------------------------------------------------------------------- | Data and other attributes defined here: @@ -95,6 +100,9 @@ %s """.strip() +expected_text_data_docstrings = tuple('\n | ' + s if s else '' + for s in expected_data_docstrings) + expected_html_pattern = """ @@ -134,10 +142,10 @@
Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s

@@ -148,10 +156,10 @@
     Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s
Data and other attributes defined here:
@@ -193,6 +201,8 @@ 		Nobody
""".strip() # ' <- emacs turd +expected_html_data_docstrings = tuple(s.replace(' ', ' ') + for s in expected_data_docstrings) # output pattern for missing module missing_pattern = "no Python documentation found for '%s'" @@ -256,7 +266,6 @@ "Docstrings are omitted with -O2 and above") @unittest.skipIf(hasattr(sys, 'gettrace') and sys.gettrace(), 'trace function introduces __locals__ unexpectedly') - @test.support.requires_docstrings def test_html_doc(self): result, doc_loc = get_pydoc_html(pydoc_mod) mod_file = inspect.getabsfile(pydoc_mod) @@ -265,7 +274,9 @@ mod_url = nturl2path.pathname2url(mod_file) else: mod_url = mod_file - expected_html = expected_html_pattern % (mod_url, mod_file, doc_loc) + expected_html = expected_html_pattern % ( + (mod_url, mod_file, doc_loc) + + expected_html_data_docstrings) if result != expected_html: print_diffs(expected_html, result) self.fail("outputs are not equal, see diff above") @@ -274,11 +285,12 @@ "Docstrings are omitted with -O2 and above") @unittest.skipIf(hasattr(sys, 'gettrace') and sys.gettrace(), 'trace function introduces __locals__ unexpectedly') - @test.support.requires_docstrings def test_text_doc(self): result, doc_loc = get_pydoc_text(pydoc_mod) - expected_text = expected_text_pattern % \ - (doc_loc, inspect.getabsfile(pydoc_mod)) + expected_text = expected_text_pattern % ( + (doc_loc,) + + expected_text_data_docstrings + + (inspect.getabsfile(pydoc_mod),)) if result != expected_text: print_diffs(expected_text, result) self.fail("outputs are not equal, see diff above") @@ -329,7 +341,6 @@ 'Docstrings are omitted with -O2 and above') @unittest.skipIf(hasattr(sys, 'gettrace') and sys.gettrace(), 'trace function introduces __locals__ unexpectedly') - @test.support.requires_docstrings def test_help_output_redirect(self): # issue 940286, if output is set in Helper, then all output from # Helper.help should be redirected @@ -355,8 +366,10 @@ captured_output('stderr') as err: helper.help(module) result = buf.getvalue().strip() - expected_text = expected_help_pattern % \ - (doc_loc, inspect.getabsfile(pydoc_mod)) + expected_text = expected_help_pattern % ( + (doc_loc,) + + expected_text_data_docstrings + + (inspect.getabsfile(pydoc_mod),)) self.assertEqual('', output.getvalue()) self.assertEqual('', err.getvalue()) self.assertEqual(expected_text, result) @@ -499,7 +512,6 @@ self.assertRaises(TypeError, f, 'A', '') self.assertRaises(TypeError, f, 'B', 'foobar') - @test.support.requires_docstrings def test_url_requests(self): # Test for the correct title in the html pages returned. # This tests the different parts of the URL handler without From report at bugs.python.org Sat Jan 26 15:31:10 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 26 Jan 2013 14:31:10 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359210670.37.0.20073923132.issue17037@psf.upfronthosting.co.za> Eli Bendersky added the comment: Antoine - I think I can see the use case. ATM, to conform to PEP399, every test _class_ has to be subclassed twice with appropriate assignment to the relevant tested class. This leads to a lot of repetition. As an example, see test_decimal.py, which does this a lot. It would be nice to save programmers from this repetition; however, as I said before, this solution seems very complex. Maybe simpler solutions can be conceived? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 15:44:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Jan 2013 14:44:30 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359211470.28.0.517559142178.issue17037@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure how the "lots of repetition" is a problem. The following: class CCoverage(Coverage): decimal = C class PyCoverage(Coverage): decimal = P is quite trivial compared to the actual base test case (the Coverage class). Not only it is quite trivial to *write*, but it is also very easy to *read*, and quite explicit. Python is not Lisp, and we do not like meta-programming that much, when it tends to obscure the code in the name of not repeating yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 15:48:14 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 26 Jan 2013 14:48:14 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359211694.28.0.74887301352.issue17041@psf.upfronthosting.co.za> R. David Murray added the comment: Once upon a time (two years ago?) we fixed the tests so that they ran successfully (skipped when appropriate) with -OO set, which omits docstrings. We were checking for the optimization level (sys.flags.optimize) then. It seems like it would make more sense to combine both checks into one decorator. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 16:01:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 15:01:26 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207393.29.0.0898779190321.issue17041@psf.upfronthosting.co.za> Message-ID: <201301261701.02028.storchaka@gmail.com> Serhiy Storchaka added the comment: Patches updated incorporating Stefan's patch. ---------- Added file: http://bugs.python.org/file28850/tests_without_docstrings-2.7_3.patch Added file: http://bugs.python.org/file28851/tests_without_docstrings-3.2_3.patch Added file: http://bugs.python.org/file28852/tests_without_docstrings-3.3_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 523f309cf558 Lib/ctypes/test/test_win32.py --- a/Lib/ctypes/test/test_win32.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/ctypes/test/test_win32.py Sat Jan 26 16:59:23 2013 +0200 @@ -3,6 +3,7 @@ from ctypes import * from ctypes.test import is_resource_enabled import unittest, sys +from test import test_support as support import _ctypes_test @@ -60,7 +61,9 @@ def test_COMError(self): from _ctypes import COMError - self.assertEqual(COMError.__doc__, "Raised when a COM method call failed.") + if support.HAVE_DOCSTRINGS: + self.assertEqual(COMError.__doc__, + "Raised when a COM method call failed.") ex = COMError(-1, "text", ("details",)) self.assertEqual(ex.hresult, -1) diff -r 523f309cf558 Lib/distutils/tests/test_build_ext.py --- a/Lib/distutils/tests/test_build_ext.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/distutils/tests/test_build_ext.py Sat Jan 26 16:59:23 2013 +0200 @@ -77,8 +77,9 @@ self.assertEqual(xx.foo(2, 5), 7) self.assertEqual(xx.foo(13,15), 28) self.assertEqual(xx.new().demo(), None) - doc = 'This is a template module just for instruction.' - self.assertEqual(xx.__doc__, doc) + if test_support.HAVE_DOCSTRINGS: + doc = 'This is a template module just for instruction.' + self.assertEqual(xx.__doc__, doc) self.assertTrue(isinstance(xx.Null(), xx.Null)) self.assertTrue(isinstance(xx.Str(), xx.Str)) diff -r 523f309cf558 Lib/test/test_functools.py --- a/Lib/test/test_functools.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/test/test_functools.py Sat Jan 26 16:59:23 2013 +0200 @@ -196,6 +196,7 @@ self.assertEqual(wrapper.__name__, 'f') self.assertEqual(wrapper.attr, 'This is also a test') + @test_support.requires_docstrings @unittest.skipIf(sys.flags.optimize >= 2, "Docstrings are omitted with -O2 and above") def test_default_update_doc(self): diff -r 523f309cf558 Lib/test/test_pydoc.py --- a/Lib/test/test_pydoc.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/test/test_pydoc.py Sat Jan 26 16:59:23 2013 +0200 @@ -10,12 +10,21 @@ import xml.etree import test.test_support from collections import namedtuple +import sysconfig from test.script_helper import assert_python_ok from test.test_support import ( TESTFN, rmtree, reap_children, captured_stdout) from test import pydoc_mod +if test.test_support.HAVE_DOCSTRINGS: + expected_data_docstrings = ( + 'dictionary for instance variables (if defined)', + 'list of weak references to the object (if defined)', + ) +else: + expected_data_docstrings = ('', '', '', '') + expected_text_pattern = \ """ NAME @@ -40,11 +49,9 @@ class B(__builtin__.object) | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s |\x20\x20 | ---------------------------------------------------------------------- | Data and other attributes defined here: @@ -75,6 +82,9 @@ Nobody """.strip() +expected_text_data_docstrings = tuple('\n | ' + s if s else '' + for s in expected_data_docstrings) + expected_html_pattern = \ """ @@ -121,10 +131,10 @@
     Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s
Data and other attributes defined here:
@@ -168,6 +178,8 @@ 		Nobody
""".strip() +expected_html_data_docstrings = tuple(s.replace(' ', ' ') + for s in expected_data_docstrings) # output pattern for missing module missing_pattern = "no Python documentation found for '%s'" @@ -229,7 +241,9 @@ mod_url = nturl2path.pathname2url(mod_file) else: mod_url = mod_file - expected_html = expected_html_pattern % (mod_url, mod_file, doc_loc) + expected_html = expected_html_pattern % ( + (mod_url, mod_file, doc_loc) + + expected_html_data_docstrings) if result != expected_html: print_diffs(expected_html, result) self.fail("outputs are not equal, see diff above") @@ -238,8 +252,9 @@ "Docstrings are omitted with -O2 and above") def test_text_doc(self): result, doc_loc = get_pydoc_text(pydoc_mod) - expected_text = expected_text_pattern % \ - (inspect.getabsfile(pydoc_mod), doc_loc) + expected_text = expected_text_pattern % ( + (inspect.getabsfile(pydoc_mod), doc_loc) + + expected_text_data_docstrings) if result != expected_text: print_diffs(expected_text, result) self.fail("outputs are not equal, see diff above") diff -r 523f309cf558 Lib/test/test_support.py --- a/Lib/test/test_support.py Sat Jan 26 13:31:44 2013 +0100 +++ b/Lib/test/test_support.py Sat Jan 26 16:59:23 2013 +0200 @@ -1112,10 +1112,6 @@ else: return unittest.skip("resource {0!r} is not enabled".format(resource)) -requires_docstrings = unittest.skipUnless( - sysconfig.get_config_var('WITH_DOC_STRINGS'), - "test requires docstrings") - def cpython_only(test): """ Decorator for tests only applicable on CPython. @@ -1193,6 +1189,16 @@ suite.addTest(unittest.makeSuite(cls)) _run_suite(suite) +#======================================================================= +# Check for the presence of docstrings. + +HAVE_DOCSTRINGS = (check_impl_detail(cpython=False) or + sys.platform == 'win32' or + sysconfig.get_config_var('WITH_DOC_STRINGS')) + +requires_docstrings = unittest.skipUnless(HAVE_DOCSTRINGS, + "test requires docstrings") + #======================================================================= # doctest driver. -------------- next part -------------- diff -r f7eda8165e6f Lib/ctypes/test/test_win32.py --- a/Lib/ctypes/test/test_win32.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/ctypes/test/test_win32.py Sat Jan 26 16:59:32 2013 +0200 @@ -3,6 +3,7 @@ from ctypes import * from ctypes.test import is_resource_enabled import unittest, sys +from test import support import _ctypes_test @@ -60,7 +61,9 @@ def test_COMError(self): from _ctypes import COMError - self.assertEqual(COMError.__doc__, "Raised when a COM method call failed.") + if test.support.HAVE_DOCSTRINGS: + self.assertEqual(COMError.__doc__, + "Raised when a COM method call failed.") ex = COMError(-1, "text", ("details",)) self.assertEqual(ex.hresult, -1) diff -r f7eda8165e6f Lib/distutils/tests/test_build_ext.py --- a/Lib/distutils/tests/test_build_ext.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/distutils/tests/test_build_ext.py Sat Jan 26 16:59:32 2013 +0200 @@ -73,8 +73,9 @@ self.assertEqual(xx.foo(2, 5), 7) self.assertEqual(xx.foo(13,15), 28) self.assertEqual(xx.new().demo(), None) - doc = 'This is a template module just for instruction.' - self.assertEqual(xx.__doc__, doc) + if support.HAVE_DOCSTRINGS: + doc = 'This is a template module just for instruction.' + self.assertEqual(xx.__doc__, doc) self.assertTrue(isinstance(xx.Null(), xx.Null)) self.assertTrue(isinstance(xx.Str(), xx.Str)) diff -r f7eda8165e6f Lib/test/support.py --- a/Lib/test/support.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/test/support.py Sat Jan 26 16:59:32 2013 +0200 @@ -1477,6 +1477,16 @@ _filter_suite(suite, case_pred) _run_suite(suite) +#======================================================================= +# Check for the presence of docstrings. + +HAVE_DOCSTRINGS = (check_impl_detail(cpython=False) or + sys.platform == 'win32' or + sysconfig.get_config_var('WITH_DOC_STRINGS')) + +requires_docstrings = unittest.skipUnless(HAVE_DOCSTRINGS, + "test requires docstrings") + #======================================================================= # doctest driver. diff -r f7eda8165e6f Lib/test/test_bytes.py --- a/Lib/test/test_bytes.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/test/test_bytes.py Sat Jan 26 16:59:32 2013 +0200 @@ -986,6 +986,7 @@ self.assertEqual(bytes(b"abc") < b"ab", False) self.assertEqual(bytes(b"abc") <= b"ab", False) + @test.support.requires_docstrings def test_doc(self): self.assertIsNotNone(bytearray.__doc__) self.assertTrue(bytearray.__doc__.startswith("bytearray("), bytearray.__doc__) diff -r f7eda8165e6f Lib/test/test_functools.py --- a/Lib/test/test_functools.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/test/test_functools.py Sat Jan 26 16:59:32 2013 +0200 @@ -287,6 +287,7 @@ with self.assertRaises(AttributeError): functools.update_wrapper(wrapper, f, assign, update) + @support.requires_docstrings @unittest.skipIf(sys.flags.optimize >= 2, "Docstrings are omitted with -O2 and above") def test_builtin_update(self): diff -r f7eda8165e6f Lib/test/test_pydoc.py --- a/Lib/test/test_pydoc.py Sat Jan 26 12:14:02 2013 +0200 +++ b/Lib/test/test_pydoc.py Sat Jan 26 16:59:32 2013 +0200 @@ -14,6 +14,7 @@ import textwrap from io import StringIO from collections import namedtuple +import sysconfig from test.script_helper import assert_python_ok from test.support import ( TESTFN, rmtree, @@ -30,6 +31,14 @@ if hasattr(pydoc_mod, "__loader__"): del pydoc_mod.__loader__ +if test.support.HAVE_DOCSTRINGS: + expected_data_docstrings = ( + 'dictionary for instance variables (if defined)', + 'list of weak references to the object (if defined)', + ) * 2 +else: + expected_data_docstrings = ('', '', '', '') + expected_text_pattern = """ NAME test.pydoc_mod - This is a test module for test_pydoc @@ -50,20 +59,16 @@ | ---------------------------------------------------------------------- | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s \x20\x20\x20\x20 class B(builtins.object) | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s |\x20\x20 | ---------------------------------------------------------------------- | Data and other attributes defined here: @@ -95,6 +100,9 @@ %s """.strip() +expected_text_data_docstrings = tuple('\n | ' + s if s else '' + for s in expected_data_docstrings) + expected_html_pattern = """ @@ -134,10 +142,10 @@
Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s

@@ -148,10 +156,10 @@
     Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s
Data and other attributes defined here:
@@ -193,6 +201,8 @@ 		Nobody
""".strip() # ' <- emacs turd +expected_html_data_docstrings = tuple(s.replace(' ', ' ') + for s in expected_data_docstrings) # output pattern for missing module missing_pattern = "no Python documentation found for '%s'" @@ -262,7 +272,9 @@ mod_url = nturl2path.pathname2url(mod_file) else: mod_url = mod_file - expected_html = expected_html_pattern % (mod_url, mod_file, doc_loc) + expected_html = expected_html_pattern % ( + (mod_url, mod_file, doc_loc) + + expected_html_data_docstrings) if result != expected_html: print_diffs(expected_html, result) self.fail("outputs are not equal, see diff above") @@ -271,8 +283,10 @@ "Docstrings are omitted with -O2 and above") def test_text_doc(self): result, doc_loc = get_pydoc_text(pydoc_mod) - expected_text = expected_text_pattern % \ - (doc_loc, inspect.getabsfile(pydoc_mod)) + expected_text = expected_text_pattern % ( + (doc_loc,) + + expected_text_data_docstrings + + (inspect.getabsfile(pydoc_mod),)) if result != expected_text: print_diffs(expected_text, result) self.fail("outputs are not equal, see diff above") @@ -346,8 +360,10 @@ captured_output('stderr') as err: helper.help(module) result = buf.getvalue().strip() - expected_text = expected_help_pattern % \ - (doc_loc, inspect.getabsfile(pydoc_mod)) + expected_text = expected_help_pattern % ( + (doc_loc,) + + expected_text_data_docstrings + + (inspect.getabsfile(pydoc_mod),)) self.assertEqual('', output.getvalue()) self.assertEqual('', err.getvalue()) self.assertEqual(expected_text, result) -------------- next part -------------- diff -r 0cd5d215179a Lib/ctypes/test/test_win32.py --- a/Lib/ctypes/test/test_win32.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/ctypes/test/test_win32.py Sat Jan 26 16:59:39 2013 +0200 @@ -3,6 +3,7 @@ from ctypes import * from ctypes.test import is_resource_enabled import unittest, sys +from test import support import _ctypes_test @@ -60,7 +61,9 @@ def test_COMError(self): from _ctypes import COMError - self.assertEqual(COMError.__doc__, "Raised when a COM method call failed.") + if support.HAVE_DOCSTRINGS: + self.assertEqual(COMError.__doc__, + "Raised when a COM method call failed.") ex = COMError(-1, "text", ("details",)) self.assertEqual(ex.hresult, -1) diff -r 0cd5d215179a Lib/distutils/tests/test_build_ext.py --- a/Lib/distutils/tests/test_build_ext.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/distutils/tests/test_build_ext.py Sat Jan 26 16:59:39 2013 +0200 @@ -73,8 +73,9 @@ self.assertEqual(xx.foo(2, 5), 7) self.assertEqual(xx.foo(13,15), 28) self.assertEqual(xx.new().demo(), None) - doc = 'This is a template module just for instruction.' - self.assertEqual(xx.__doc__, doc) + if support.HAVE_DOCSTRINGS: + doc = 'This is a template module just for instruction.' + self.assertEqual(xx.__doc__, doc) self.assertTrue(isinstance(xx.Null(), xx.Null)) self.assertTrue(isinstance(xx.Str(), xx.Str)) diff -r 0cd5d215179a Lib/test/support.py --- a/Lib/test/support.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/test/support.py Sat Jan 26 16:59:39 2013 +0200 @@ -597,10 +597,6 @@ requires_lzma = unittest.skipUnless(lzma, 'requires lzma') -requires_docstrings = unittest.skipUnless( - sysconfig.get_config_var('WITH_DOC_STRINGS'), - "test requires docstrings") - is_jython = sys.platform.startswith('java') # Filename used for testing @@ -1599,6 +1595,16 @@ _filter_suite(suite, case_pred) _run_suite(suite) +#======================================================================= +# Check for the presence of docstrings. + +HAVE_DOCSTRINGS = (check_impl_detail(cpython=False) or + sys.platform == 'win32' or + sysconfig.get_config_var('WITH_DOC_STRINGS')) + +requires_docstrings = unittest.skipUnless(HAVE_DOCSTRINGS, + "test requires docstrings") + #======================================================================= # doctest driver. diff -r 0cd5d215179a Lib/test/test_functools.py --- a/Lib/test/test_functools.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/test/test_functools.py Sat Jan 26 16:59:39 2013 +0200 @@ -312,6 +312,7 @@ with self.assertRaises(AttributeError): functools.update_wrapper(wrapper, f, assign, update) + @support.requires_docstrings @unittest.skipIf(sys.flags.optimize >= 2, "Docstrings are omitted with -O2 and above") def test_builtin_update(self): diff -r 0cd5d215179a Lib/test/test_pydoc.py --- a/Lib/test/test_pydoc.py Sat Jan 26 13:58:00 2013 +0100 +++ b/Lib/test/test_pydoc.py Sat Jan 26 16:59:39 2013 +0200 @@ -14,6 +14,7 @@ import textwrap from io import StringIO from collections import namedtuple +import sysconfig from test.script_helper import assert_python_ok from test.support import ( TESTFN, rmtree, @@ -30,6 +31,14 @@ if hasattr(pydoc_mod, "__loader__"): del pydoc_mod.__loader__ +if test.support.HAVE_DOCSTRINGS: + expected_data_docstrings = ( + 'dictionary for instance variables (if defined)', + 'list of weak references to the object (if defined)', + ) * 2 +else: + expected_data_docstrings = ('', '', '', '') + expected_text_pattern = """ NAME test.pydoc_mod - This is a test module for test_pydoc @@ -50,20 +59,16 @@ | ---------------------------------------------------------------------- | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s \x20\x20\x20\x20 class B(builtins.object) | Data descriptors defined here: |\x20\x20 - | __dict__ - | dictionary for instance variables (if defined) + | __dict__%s |\x20\x20 - | __weakref__ - | list of weak references to the object (if defined) + | __weakref__%s |\x20\x20 | ---------------------------------------------------------------------- | Data and other attributes defined here: @@ -95,6 +100,9 @@ %s """.strip() +expected_text_data_docstrings = tuple('\n | ' + s if s else '' + for s in expected_data_docstrings) + expected_html_pattern = """ @@ -134,10 +142,10 @@
Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s

@@ -148,10 +156,10 @@
     Data descriptors defined here:
__dict__
-
dictionary for instance variables (if defined)
+
%s
__weakref__
-
list of weak references to the object (if defined)
+
%s
Data and other attributes defined here:
@@ -193,6 +201,8 @@ 		Nobody
""".strip() # ' <- emacs turd +expected_html_data_docstrings = tuple(s.replace(' ', ' ') + for s in expected_data_docstrings) # output pattern for missing module missing_pattern = "no Python documentation found for '%s'" @@ -256,7 +266,6 @@ "Docstrings are omitted with -O2 and above") @unittest.skipIf(hasattr(sys, 'gettrace') and sys.gettrace(), 'trace function introduces __locals__ unexpectedly') - @test.support.requires_docstrings def test_html_doc(self): result, doc_loc = get_pydoc_html(pydoc_mod) mod_file = inspect.getabsfile(pydoc_mod) @@ -265,7 +274,9 @@ mod_url = nturl2path.pathname2url(mod_file) else: mod_url = mod_file - expected_html = expected_html_pattern % (mod_url, mod_file, doc_loc) + expected_html = expected_html_pattern % ( + (mod_url, mod_file, doc_loc) + + expected_html_data_docstrings) if result != expected_html: print_diffs(expected_html, result) self.fail("outputs are not equal, see diff above") @@ -274,11 +285,12 @@ "Docstrings are omitted with -O2 and above") @unittest.skipIf(hasattr(sys, 'gettrace') and sys.gettrace(), 'trace function introduces __locals__ unexpectedly') - @test.support.requires_docstrings def test_text_doc(self): result, doc_loc = get_pydoc_text(pydoc_mod) - expected_text = expected_text_pattern % \ - (doc_loc, inspect.getabsfile(pydoc_mod)) + expected_text = expected_text_pattern % ( + (doc_loc,) + + expected_text_data_docstrings + + (inspect.getabsfile(pydoc_mod),)) if result != expected_text: print_diffs(expected_text, result) self.fail("outputs are not equal, see diff above") @@ -329,7 +341,6 @@ 'Docstrings are omitted with -O2 and above') @unittest.skipIf(hasattr(sys, 'gettrace') and sys.gettrace(), 'trace function introduces __locals__ unexpectedly') - @test.support.requires_docstrings def test_help_output_redirect(self): # issue 940286, if output is set in Helper, then all output from # Helper.help should be redirected @@ -355,8 +366,10 @@ captured_output('stderr') as err: helper.help(module) result = buf.getvalue().strip() - expected_text = expected_help_pattern % \ - (doc_loc, inspect.getabsfile(pydoc_mod)) + expected_text = expected_help_pattern % ( + (doc_loc,) + + expected_text_data_docstrings + + (inspect.getabsfile(pydoc_mod),)) self.assertEqual('', output.getvalue()) self.assertEqual('', err.getvalue()) self.assertEqual(expected_text, result) @@ -499,7 +512,6 @@ self.assertRaises(TypeError, f, 'A', '') self.assertRaises(TypeError, f, 'B', 'foobar') - @test.support.requires_docstrings def test_url_requests(self): # Test for the correct title in the html pages returned. # This tests the different parts of the URL handler without From report at bugs.python.org Sat Jan 26 16:07:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 15:07:26 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359212846.83.0.75748405145.issue17041@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > It seems like it would make more sense to combine both checks into one decorator. These are different cases. @unittest.skipIf(sys.flags.optimize >= 2) is about docstrings in Python implemented modules, and @support.requires_docstrings is about docstrings in C implemented modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 16:19:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 15:19:45 +0000 Subject: [issue12397] re match object methods have no docstrings In-Reply-To: <1308919603.82.0.975273627438.issue12397@psf.upfronthosting.co.za> Message-ID: <1359213585.38.0.740827604701.issue12397@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in issue16443. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Add docstrings to regular expression match objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 16:20:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 15:20:39 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1359213639.8.0.155114337706.issue15731@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 16:28:19 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 26 Jan 2013 15:28:19 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> Message-ID: <1359214099.09.0.530469269662.issue17009@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 17:22:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 16:22:15 +0000 Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za> Message-ID: <1359217335.66.0.9721484523.issue6972@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can anyone review the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 17:37:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 26 Jan 2013 16:37:58 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1359218278.1.0.276094846783.issue16991@psf.upfronthosting.co.za> Ezio Melotti added the comment: What's the reason for moving the OrderedDict tests in a separate file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 17:55:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 16:55:31 +0000 Subject: [issue4844] ZipFile doesn't range check in _EndRecData() In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za> Message-ID: <1359219331.79.0.99863928324.issue4844@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28178/zipfile_unpack_check.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 17:59:14 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 26 Jan 2013 16:59:14 +0000 Subject: [issue16996] Reuse shutil.which() in webbrowser module In-Reply-To: <1358541875.07.0.897350417662.issue16996@psf.upfronthosting.co.za> Message-ID: <1359219554.61.0.256911887658.issue16996@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:01:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 17:01:20 +0000 Subject: [issue4844] ZipFile doesn't range check in _EndRecData() In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za> Message-ID: <1359219679.99.0.0439310963082.issue4844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated. Now the test use io.BytesIO() for input too. A loop limit changed from len() -2 to len(). If there are no objections I'll commit this patch next week. ---------- assignee: mcherm -> serhiy.storchaka Added file: http://bugs.python.org/file28853/zipfile_unpack_check.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:05:16 2013 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 26 Jan 2013 17:05:16 +0000 Subject: [issue3718] environment variable MACHDEP and python build system In-Reply-To: <1359122416.22.0.463744804684.issue3718@psf.upfronthosting.co.za> Message-ID: <51040CC7.4000507@roumenpetrov.info> Roumen Petrov added the comment: Matthias Klose wrote: > > Matthias Klose added the comment: > > the change to the configure script looks ok. however you could change the README too. This is 5 years old issue. README is not more in repository. As result python lack documentation related to build process. > It looks like the changes to the Makefile.pre.in are already applied. No . But you could ignore this part of issue. Roumen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:10:05 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 17:10:05 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359220205.3.0.68072717026.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: In my case I've been doing PEP 399 for collections.OrderedDict. It struck me that the boilerplate could be stowed away in a decorator. It's more than just adding a couple subclasses. Here's what it covers: * add the test case subclasses, * make sure the original test case does not get used (#16835), * use the relevant names as class attributes rather than globals (e.g. self.OrderedDict vs. OrderedDict), * hack around modules that do their own imports (#16817), * others(?). When adapting existing test cases having a decorator to do this makes the job a snap without having to worry about corner cases. You have to add the decorator and then add the new test names to the test discovery code (at least until we use unittest's test discovery). For new test cases and splitting out test cases it likewise simplifies things. On top of that, if you drop the decorator the test case would still run as-is. Other benefits for both new and existing test cases: * the decorator makes it clear what is going on (or will be made to) via the decorator name, * the requisite boilerplate doesn't have to clutter up the code, * when something like #16817 or #16835 comes up, it's much easier to update the decorator in test.support instead of finding each of the PEP-399-ized tests that is affected and updating them individually. Downsides: * "explicit is better than implicit", * relatedly, the solution is more magic/obfuscated that the current boilerplate. You could argue that the magnitude of the problem doesn't warrant a complex decorator, but it doesn't have to be hard to understand. My patch is something I threw together late last night that could certainly be made more clear. More importantly, as more modules get a dual implementation, the above benefits of the decorator become more pronounced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:13:07 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 17:13:07 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359220387.19.0.532789945582.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: > Do you have a real use case for the 'names' argument? My use case was with the tests for OrderedDict. The existing tests don't refer to collections.OrderedDict, but rather to OrderedDict (looked up from the globals). The names argument facilitates the replacement of OrderedDict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:16:20 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 17:16:20 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359212846.83.0.75748405145.issue17041@psf.upfronthosting.co.za> Message-ID: <20130126171622.GA14625@sleipnir.bytereef.org> Stefan Krah added the comment: Serhiy Storchaka wrote: > > It seems like it would make more sense to combine both checks into one decorator. > > These are different cases. @unittest.skipIf(sys.flags.optimize >= 2) is about docstrings in Python implemented modules, and @support.requires_docstrings is about docstrings in C implemented modules. But they're always used together, aren't they? I kind of like the idea of a single decorator. We could have two different messages "compiled without docstrings" and "docstrings are omitted with -O2 and above", where the first message should get priority if both conditions are true. Given the mood on python-dev concerning --without-doc-strings, I wonder if we should stick to minimal changes and just skip the tests in test_pydoc.py instead of fixing them. Personally I'm happy either way. David, what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:17:06 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 26 Jan 2013 17:17:06 +0000 Subject: =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0and_readline=28?= =?utf-8?q?=29_argument_names?= In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za> Message-ID: <1359220626.33.0.492413457406.issue17003@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:19:19 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 17:19:19 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1359220759.07.0.0917666786009.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: > What's the reason for moving the OrderedDict tests in a separate file? Following the precedent of collections.deque and collections.defaultdict: * a big chunk of code * the default implementation will be coming via _collections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:19:30 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 26 Jan 2013 17:19:30 +0000 Subject: [issue17005] Add a topological sort algorithm In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za> Message-ID: <1359220770.39.0.997783080386.issue17005@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:22:48 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 26 Jan 2013 17:22:48 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1359220968.86.0.354478530217.issue16968@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Okay, I think I understand the issue better now. The threading._dangling warning happens because when leaving the saved_test_environment context manager in regrtest: http://hg.python.org/cpython/file/fcdb35b114ab/Lib/test/regrtest.py#l1271 the context manager finds threads still in threading._dangling that weren't there at the beginning. I think the threads are still in there because the "tests" variable in the code linked to above is holding references to those threads (which isn't surprising given what test_concurrent_futures.py tests). So this is preventing the threads (which are in a WeakSet) from being garbage collected. On my machine, severing those references before leaving the context manager solves the problem. You can do this by adding "test = 0" after the test_runner() line, or defining "tests" inside an inner function as follows: if test_runner is None: def test_runner(): tests = unittest.TestLoader().loadTestsFromModule(the_module) support.run_unittest(tests) test_runner() To be completely sure, we may also need to do something to ensure that the threads are garbage collected before leaving the context manager. Currently, an explicit call to support.gc_collect() happens in threading_cleanup() (which is in turn called by reap_threads(), etc): http://hg.python.org/cpython/file/fcdb35b114ab/Lib/test/support.py#l1665 But I'm not sure if that's late enough in the process to guarantee garbage collection of those threads with the test_runner() change above (since the tests list might still be defined). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:23:14 2013 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 26 Jan 2013 17:23:14 +0000 Subject: [issue3718] environment variable MACHDEP and python build system In-Reply-To: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za> Message-ID: <1359220994.83.0.751323498418.issue3718@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: -gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:27:44 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 26 Jan 2013 17:27:44 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1359221264.04.0.898781140592.issue16991@psf.upfronthosting.co.za> Ezio Melotti added the comment: These are indeed good reasons. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:30:57 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 26 Jan 2013 17:30:57 +0000 Subject: [issue10740] sqlite3 module should allow DDL statements in transactions In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za> Message-ID: <1359221457.29.0.812635116471.issue10740@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 18:44:14 2013 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 26 Jan 2013 17:44:14 +0000 Subject: [issue15483] CROSS: initialise include and library paths in setup.py In-Reply-To: <1359123251.11.0.249757185301.issue15483@psf.upfronthosting.co.za> Message-ID: <510415ED.3010803@roumenpetrov.info> Roumen Petrov added the comment: > Matthias Klose added the comment: > I don't think this one is still necessary. can it be closed? If is difficult to confirm. In scope of issue title initialization is fixed. Another part of proposed path is to insert at first position current directory if cross build. If this is not acceptable in scope of this then someone could open a new issue to set unconditionally in BLDLIBRARY current directory, i.e. to change configure script. I don't like to touch existing native build so in scope of cross build this patch propose libdir to start with current. Roumen ---------- Added file: http://bugs.python.org/file28854/0004-CROSS-initialise-include-and-library-paths.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- >From 9fe8bd2e63ad383c795962cea3aa1ff11b493988 Mon Sep 17 00:00:00 2001 From: Roumen Petrov Date: Mon, 23 Jul 2012 23:31:20 +0300 Subject: [PATCH 04/13] CROSS-initialise include and library paths --- setup.py | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/setup.py b/setup.py index 5d38d29..4a27ba7 100644 --- a/setup.py +++ b/setup.py @@ -500,15 +500,16 @@ class PyBuildExt(build_ext): # lib_dirs and inc_dirs are used to search for files; # if a file is found in one of those directories, it can # be assumed that no additional -I,-L directives are needed. + lib_dirs = self.compiler.library_dirs + inc_dirs = self.compiler.include_dirs if not cross_compiling: - lib_dirs = self.compiler.library_dirs + [ + lib_dirs += [ '/lib64', '/usr/lib64', '/lib', '/usr/lib', ] - inc_dirs = self.compiler.include_dirs + ['/usr/include'] + inc_dirs += ['/usr/include'] else: - lib_dirs = self.compiler.library_dirs[:] - inc_dirs = self.compiler.include_dirs[:] + self.compiler.library_dirs.insert(0, '.') exts = [] missing = [] -- 1.7.12.1 From report at bugs.python.org Sat Jan 26 19:00:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Jan 2013 18:00:34 +0000 Subject: [issue3718] environment variable MACHDEP and python build system In-Reply-To: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za> Message-ID: <3YtlJK60MDzSPL@mail.python.org> Roundup Robot added the comment: New changeset 8c49dd8e4d22 by doko in branch '3.3': - Issue #3718: Use AC_ARG_VAR to set MACHDEP in configure.ac. http://hg.python.org/cpython/rev/8c49dd8e4d22 New changeset 6866384d9ccb by doko in branch 'default': - Issue #3718: Use AC_ARG_VAR to set MACHDEP in configure.ac. http://hg.python.org/cpython/rev/6866384d9ccb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:02:45 2013 From: report at bugs.python.org (Matthias Klose) Date: Sat, 26 Jan 2013 18:02:45 +0000 Subject: [issue3718] environment variable MACHDEP and python build system In-Reply-To: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za> Message-ID: <1359223365.08.0.974516337735.issue3718@psf.upfronthosting.co.za> Matthias Klose added the comment: now checked in the configure change. I think that the cross-build documentation deserves an extra issue. Therefore now closing this issue. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:08:08 2013 From: report at bugs.python.org (Matthias Klose) Date: Sat, 26 Jan 2013 18:08:08 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359223688.31.0.0114219471241.issue3871@psf.upfronthosting.co.za> Matthias Klose added the comment: > IMHO, updating these patches to track the latest Python is a pointless goal. sorry, no. it's the *only* way to get these patches upstream. The mingw patches will never see the light of the 3.3 branch. So the best thing to do is to actively submit the patches for trunk. If you do want to maintain your patches, then split your set of patches into those which are upstream (and then pack-ported), and which are not yet upstream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:11:52 2013 From: report at bugs.python.org (Matthias Klose) Date: Sat, 26 Jan 2013 18:11:52 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359223912.89.0.221007290717.issue3871@psf.upfronthosting.co.za> Matthias Klose added the comment: > However, we must go further and add that the patches *cannot* break any > other native or cross-compilation, which - as I think Matthias is > alluding to - is probably not the case with your patch. This issue is > called "cross and native build of python for mingw* hosts", no, I just didn't check. And I probably won't check. However it's more likely that your patches are accepted if e.g. it doesn't break the normal Windows build and an unrelated build, e.g. for a Linux target. Maybe you could even separate the patches into a patch supporting a native mingw build and a cmingw ross build? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:15:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 18:15:19 +0000 Subject: [issue8865] select.poll is not thread safe In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za> Message-ID: <1359224119.4.0.955028933512.issue8865@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a test made from Charles-Fran?ois's crasher. Let's go. ---------- Added file: http://bugs.python.org/file28855/issue8865_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:16:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 18:16:31 +0000 Subject: [issue10905] zipfile: fix arcname with leading '///' or '..' In-Reply-To: <1295006628.53.0.290414123413.issue10905@psf.upfronthosting.co.za> Message-ID: <1359224191.72.0.392014183658.issue10905@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:17:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 18:17:05 +0000 Subject: [issue8865] select.poll is not thread safe In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za> Message-ID: <1359224225.16.0.323797765289.issue8865@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: test needed -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:20:38 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 18:20:38 +0000 Subject: [issue17042] Example in C-API memory management doc has confusing order Message-ID: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za> New submission from Eric Snow: In http://docs.python.org/dev/c-api/memory.html#examples: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv char *buf1 = PyMem_New(char, BUFSIZ); char *buf2 = (char *) malloc(BUFSIZ); char *buf3 = (char *) PyMem_Malloc(BUFSIZ); ... PyMem_Del(buf3); /* Wrong -- should be PyMem_Free() */ free(buf2); /* Right -- allocated via malloc() */ free(buf1); /* Fatal -- should be PyMem_Del() */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is there a good reason to have the second set of 3 lines in the opposite order as the first three? At first I missed that they were in a different order and thought there was an error in the example. If there's no good reason for the order, it would be worth fixing. If there is a good reason, a comment in the example would help. Either way I'd be glad to patch it (will go ahead with fixing the ordering later today if no one does it first). ---------- assignee: docs at python components: Documentation messages: 180697 nosy: docs at python, eric.snow priority: low severity: normal stage: needs patch status: open title: Example in C-API memory management doc has confusing order versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:36:11 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 18:36:11 +0000 Subject: [issue17042] Example in C-API memory management doc has confusing order In-Reply-To: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za> Message-ID: <1359225371.57.0.0497750080939.issue17042@psf.upfronthosting.co.za> Stefan Krah added the comment: Please don't change this: It's a common pattern in C to undo memory allocations in the opposite order. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:42:00 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 26 Jan 2013 18:42:00 +0000 Subject: [issue17042] Example in C-API memory management doc has confusing order In-Reply-To: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za> Message-ID: <1359225720.72.0.408901131556.issue17042@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> rejected stage: needs patch -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:49:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 18:49:10 +0000 Subject: [issue16802] fileno argument to socket.socket() undocumented In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za> Message-ID: <1359226150.46.0.312270134558.issue16802@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:53:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 18:53:56 +0000 Subject: [issue8821] Range check on unicode repr In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za> Message-ID: <1359226436.54.0.321581040739.issue8821@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 19:56:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 18:56:30 +0000 Subject: [issue16096] Get rid of dangerous integer overflow tricks In-Reply-To: <1349030051.26.0.323672452753.issue16096@psf.upfronthosting.co.za> Message-ID: <1359226590.15.0.819596576875.issue16096@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I withdraw my patches for 2.7 and 3.2 due to the fact that they have no visible effect on supported platforms. Patches for 3.3+ already committed, therefore I?close this issue. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.3, Python 3.4 -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 20:01:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 19:01:21 +0000 Subject: [issue11204] re module: strange behaviour of space inside {m, n} In-Reply-To: <1297552798.48.0.889043344562.issue11204@psf.upfronthosting.co.za> Message-ID: <1359226881.13.0.837400799465.issue11204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Then let's leave all as is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 20:16:43 2013 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 26 Jan 2013 19:16:43 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1359127026.27.0.805134882578.issue3754@psf.upfronthosting.co.za> Message-ID: <51042B98.1070403@roumenpetrov.info> Roumen Petrov added the comment: Matthias Klose wrote: > > Matthias Klose added the comment: > about py3k-20121004-CROSS.tgz: > [SNIP] > - 0002-CROSS-restore-graminit.-to-source-directory.patch > [SNIP] > - 0003-CROSS-restore-importlib-header-to-source-directory-a.patch > [SNIP] > - 0004-CROSS-restore-AST-to-source-directory.patch > [SNIP] All above is related to build out of source tree. Try to keep a build tree for long time. Synchronize source, for instance once in week, and try to rebuild. After updates in those files python (native build) crash. Solutions: a) restore to source tree as before and only for cross build touch files to avoid regeneration. b) after synchronization copy to build tree but now in all cases. Note that a) will allow you to build from readonly source tree . > - 0005-CROSS-revert-issue13150-i.e.-python-solution-with-_s.patch > A comment like "The fix for issue #13150 is bogus and break > everything" might not the best way to convince maintainers ... > > This works for me, and IMO should be dropped, or please explain > why this doesn't work for you. How old is patch ? Before generated "python solution" to be moved from source tree to `cat pybuilddir.txt`. So thanks to all that resolve design failure with commit for issue 13150. It seems to me author is not able to rewrite => issue 13547, issue14774, issue16342(?) . Now obsolete by issue15298 (10x Trent). > - 0006-CROSS-initialise-include-and-library-paths.patch > Afaics, a similar patch is now applied. Can be dropped. > [SNIP] > - 0009-CROSS-pass-all-top-configure-arguments-to-libffi-con.patch > > Why is it needed to pass all configure args? > > - 0010-CROSS-warn-only-if-readelf-is-not-in-host-triplet-fo.patch > > Why is this needed just for readelf? If you do have a cross > toolchain installed, then this should be available with > the triplet name, same as for gcc, as, ... May be I'm wrong to use cross build for multilib , i.e. with gcc -m32. In this case does not exist prefixed readelf. > - 0011-CROSS-append-gcc-library-search-paths-instead-to-pre.patch > > Looks ok. Could you mention where this does make a difference, > or do you just want to keep the search order as defined by > the compiler? issue15485 My multilib compiler list fist paths to 64 libraries the to 32. 64 bit is with all dependent libraries and headers but 32-compatible lack some (tk/tcl for instance). As result 32 bit build find all "required" dependency, try to link all modules and fail on missing. Distutil library search is limited - just search for library name. > - 0012-CROSS-avoid-ncursesw-include-path-hack.patch > > This would break cross-building in a multiarch environment. > Maybe we need a --with-curses-incdir=<> option. May be (issue15268). > - 0013-CROSS-properly-detect-WINDOW-_flags-for-different-nc.patch > This should be a separate issue. Not cross specific. issue14598 and issue15484. > - 0014-CROSS-use-build-directory-as-root-for-regression-tes.patch > why is this necessary? For instance is source tree is readonly . It is important in cross to avoid build defects to update source files. Result is parallel build and test for multiple host. > - 0015-CROSS-test-tools-has-to-depend-only-from-location-of.patch > Looks ok, but not cross specific. Could you file a separate issue? Unfortunately issue is closed. It was fixed perfectly for about 2 hours. I just revert commit. Same as 14 rule apply. > - 0016-CROSS-reload-may-fail-with-operation-on-closed-file-.patch > Looks like a separate issue. May be is not same as issue15833 (fixed+closed). May be case is only for regression test if source tree is readonly. Roumen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 20:20:15 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Jan 2013 19:20:15 +0000 Subject: [issue13896] Make shelf instances work with 'with' as context managers In-Reply-To: <1327749150.13.0.147725255938.issue13896@psf.upfronthosting.co.za> Message-ID: <1359228015.96.0.889388283979.issue13896@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The patch did not update the doc. See #17040, with proposed patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 21:02:35 2013 From: report at bugs.python.org (Ray Donnelly) Date: Sat, 26 Jan 2013 20:02:35 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359230555.0.0.707044770933.issue3871@psf.upfronthosting.co.za> Ray Donnelly added the comment: Re: basing the patches against the latest master branch or targeting released versions, I wasn't clear enough about my thinking. For sure, when trying to get any patches merged, the submitted patch must be re-based (forward ported) and tested against the master branch. But from the perspective of having a project that people can reliably expect to build a working MinGW-w64 Python from (until that elusive fully-merged-day comes), having patches based on the latest released versions seems to me to be the best thing to do (for that goal of course) I'll keep forward porting these patches to each new release, and at those times I'll also submit some of them as issues to bugs.python.org as that's the best way for me to manage my limited spare time. Do you know what the situation is with packaging/distutils2? I think our next good merge opportunity for the bulk of these patches will be when we can target that instead of distutils. > Maybe you could even separate the patches into a patch supporting a native mingw build and a cmingw ross build? I'm already doing that: https://github.com/mingwandroid/crucifixion-freedom/tree/master/patches/python/3.3.0 0000 and 0005 are now merged with upstream. 0000 you merged today, 0005 was merged also (mostly via Roumen's patches which 2/3 of my patch duplicated). At this stage, the framework for cross compiling Python is mostly merged; other than 0065-cross-dont-add-multiarch-paths-if-cross-compiling.patch The stumbling block for me is that there's no working example of cross-compilation in CPython so it will surely rot. This was what I tried to fix with my next patch, 0010-cross-darwin-feature.patch. I went for darwin instead of MinGW as the amount of changes needed is tiny but it was met with some resistance and hasn't seen any activity for 3 months: http://bugs.python.org/issue16291 I should also clarify, by cross compilation I'm specifically excluding GNU-Linux/GNU-Linux combinations such as x86-GNU-Linux/arm-GNU-Linux as they're not as exhaustive a test-case as cross-compiling between different OSes. > Maybe you could even separate the patches into a patch supporting a native mingw build and a cmingw ross build? Not sure if that was directed at me as my set of patches are logically split up I think. Ones with 'mingw' in the name relate to mingw (either cross or native), ones with 'msys' in the name relate to building mingw natively and ones with 'cross' in the name relate to general cross compilation matters; ones with 'hack' in the name generally need improving, rewriting or removing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 21:03:18 2013 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 26 Jan 2013 20:03:18 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1359128664.47.0.801938322492.issue3871@psf.upfronthosting.co.za> Message-ID: <51043684.4070004@roumenpetrov.info> Roumen Petrov added the comment: Matthias Klose wrote: > > Matthias Klose added the comment: > > some random comments about py3k-20121004-MINGW.patch: > > - Modules/_ctypes/libffi_msvc/win32.S > Please can you get rid of libffi_msvc and use libffi? > afaics, libffi has support for mingw32. No python still use custom hack for MSVC. win32.S include this hack and could be compiled with gcc. > - there seem to be chunks which are unrelated to mingw, like: > > @@ -830,15 +926,18 @@ class PyBuildExt(build_ext): > if have_usable_openssl: > # The _hashlib module wraps optimized implementations > # of hash functions from the OpenSSL library. > + # NOTE: _hashlib require only OpenSSL crypto library ! > exts.append( Extension('_hashlib', ['_hashopenssl.c'], > depends = ['hashlib.h'], > include_dirs = ssl_incs, > library_dirs = ssl_libs, > - libraries = ['ssl', 'crypto']) ) > + libraries = ['crypto']) ) > > please file separate issues. > > > - why setup_info.in. looks like something which could be done with get_config_var. Yes and no. get_config_var will use makefile variables (indirectly from sysconfigdata). If you add a make macro(variable) then it will be installed. Setup info is designed to communicate from configure to setup.py without to expose data to installation. > - why re-reading files in setup.py, and grepping these for config options? For historical reasons. Before other commits to start to look info some generated by autotool files. > > I think the patch would benefit from splitting it up into several self-contained chunks. May be. I don't know how to group split. If is based on functionality patch order will be important as more then one patch will update "near lines" - for instance pyport.h is difficult to split :(. cygwinccompiler.py could be rewritten as separate issue, already opened. > did you try to do builds for windows and linux after this patch was applied? Title is correct. Hosts include native linux, cygwin, mingw and cross linux->mingw, linux->android ( not published ). All from one and the same source tree. Roumen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 21:04:52 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 26 Jan 2013 20:04:52 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359230692.35.0.651011861461.issue3871@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: This discussion got very long and it's not clear (to me at least) what the status of the patch is and whether it has been accepted for inclusion. Maybe it makes sense to bring this up to python-dev mailing list instead of keep stressing this thread? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 21:08:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 20:08:42 +0000 Subject: [issue16723] io.TextIOWrapper on urllib.request.urlopen terminates prematurely In-Reply-To: <1355899334.66.0.683261774989.issue16723@psf.upfronthosting.co.za> Message-ID: <1359230921.99.0.0893393016328.issue16723@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which fixes HTTPResponse's end. "closed" property no longer settled automatically, but only after explicit close(). ---------- components: +IO, Library (Lib) keywords: +patch nosy: +orsenthil stage: -> patch review versions: +Python 3.2, Python 3.4 Added file: http://bugs.python.org/file28856/httpresponse_noclosed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 21:11:46 2013 From: report at bugs.python.org (Ray Donnelly) Date: Sat, 26 Jan 2013 20:11:46 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359231106.08.0.920743318329.issue3871@psf.upfronthosting.co.za> Ray Donnelly added the comment: Roumen, I think it would be really great if you could split py3k-20121004-MINGW.patch up into separate bits. The pthread stuff and libffi stuff being two obvious candidates for atomic parts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 21:20:21 2013 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 26 Jan 2013 20:20:21 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359231621.65.0.0718272844941.issue3871@psf.upfronthosting.co.za> Roumen Petrov added the comment: As patch 0005-CROSS-revert-issue13150-i.e.-python-solution-with-_s.patch (CROSS-revert issue13150, i.e. python solution with _sysconfigdata.py instead Makefile) from issue3754 is now obsolete by issue 13547, 14774, 16342, 15298 it is save to switch sysconfigdata with proposed changes in PC/getpathp.c . ---------- Added file: http://bugs.python.org/file28857/0003-MINGW-implement-exec-prefix-i.e.-use-content-of-pybu.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 21:41:15 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 20:41:15 +0000 Subject: [issue17043] Invalid read in test_codecs Message-ID: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za> New submission from Stefan Krah: Found this in test_codecs running under Valgrind (Python 3.3): test_bug1251300 (test.test_codecs.UnicodeInternalTest) ... ==11511== Invalid read of size 1 ==11511== at 0x44AF37: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:6133) ==11511== by 0x4DEB5C: unicode_internal_decode (_codecsmodule.c:251) ==11511== by 0x5093F6: PyObject_Call (abstract.c:2082) ==11511== by 0x47D7F2: PyEval_CallObjectWithKeywords (ceval.c:3942) ==11511== by 0x491C38: PyCodec_Decode (codecs.c:403) ==11511== by 0x459D7D: PyUnicode_Decode (unicodeobject.c:3129) ==11511== by 0x45A287: PyUnicode_FromEncodedObject (unicodeobject.c:3023) ==11511== by 0x519A45: bytes_decode (bytesobject.c:2320) ==11511== by 0x484AB8: PyEval_EvalFrameEx (ceval.c:4374) ==11511== by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11511== by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511== by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11511== Address 0x984a7e2 is 0 bytes after a block of size 34 alloc'd ==11511== at 0x4C27972: realloc (vg_replace_malloc.c:525) ==11511== by 0x51AC34: _PyBytes_Resize (bytesobject.c:2881) ==11511== by 0x51B1FA: PyBytes_FromObject (bytesobject.c:2732) ==11511== by 0x51C134: bytes_new (bytesobject.c:2594) ==11511== by 0x42A4E4: type_call (typeobject.c:723) ==11511== by 0x5093F6: PyObject_Call (abstract.c:2082) ==11511== by 0x4843D5: PyEval_EvalFrameEx (ceval.c:4282) ==11511== by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11511== by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511== by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11511== by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511== by 0x538EF8: function_call (funcobject.c:633) ==11511== _PyUnicode_DecodeUnicodeInternal (s=0x984a7e0 "", size=, errors=0x0) at Objects/unicodeobject.c:6133 6133 ((char *) &uch)[2] = s[2]; ================================================================== ==11511== ==11511== Debugger has detached. Valgrind regains control. We continue. ==11511== Invalid read of size 1 ==11511== at 0x44AF3E: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:6134) ==11511== by 0x4DEB5C: unicode_internal_decode (_codecsmodule.c:251) ==11511== by 0x5093F6: PyObject_Call (abstract.c:2082) ==11511== by 0x47D7F2: PyEval_CallObjectWithKeywords (ceval.c:3942) ==11511== by 0x491C38: PyCodec_Decode (codecs.c:403) ==11511== by 0x459D7D: PyUnicode_Decode (unicodeobject.c:3129) ==11511== by 0x45A287: PyUnicode_FromEncodedObject (unicodeobject.c:3023) ==11511== by 0x519A45: bytes_decode (bytesobject.c:2320) ==11511== by 0x484AB8: PyEval_EvalFrameEx (ceval.c:4374) ==11511== by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11511== by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511== by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11511== Address 0x984a7e3 is 1 bytes after a block of size 34 alloc'd ==11511== at 0x4C27972: realloc (vg_replace_malloc.c:525) ==11511== by 0x51AC34: _PyBytes_Resize (bytesobject.c:2881) ==11511== by 0x51B1FA: PyBytes_FromObject (bytesobject.c:2732) ==11511== by 0x51C134: bytes_new (bytesobject.c:2594) ==11511== by 0x42A4E4: type_call (typeobject.c:723) ==11511== by 0x5093F6: PyObject_Call (abstract.c:2082) ==11511== by 0x4843D5: PyEval_EvalFrameEx (ceval.c:4282) ==11511== by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11511== by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511== by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11511== by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511== by 0x538EF8: function_call (funcobject.c:633) ==11511== Loaded symbols for /usr/lib/gconv/ISO8859-9.so _PyUnicode_DecodeUnicodeInternal (s=0x8295790 "", size=, errors=0x0) at Objects/unicodeobject.c:6134 6134 ((char *) &uch)[3] = s[3]; ---------- messages: 180709 nosy: serhiy.storchaka, skrah priority: normal severity: normal status: open title: Invalid read in test_codecs versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 21:59:52 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Jan 2013 20:59:52 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1359233992.5.0.736609348346.issue16468@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think we have converged on the right solution. The patch looks good as far as it goes, assuming that it passes the current + unwritten new tests. It will also be a good basis for reconsidering what to do with long/infinite iterables in #16418. I think the doc patch should recommend passing a metavar arg with non-iterable choices. With that, using default metavars, whatever they end up being, is fine as long as no exception is raised. So I would make the tests of non-iterable with no metavar passed as general as possible. App writers who do not like the defaults should override them ;-). If I understand correctly, if choices is not iterable and the user enters an invalid choice, the choice part of the error message (passed to ArgumentError) will just be 'invalid choice: '. Minor nit: .join does not need a temporary list as arg and works fine with genexp: choices_str = sep.join(to_str(choice) for choice in choices) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 22:02:36 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 21:02:36 +0000 Subject: [issue17043] Invalid read in test_codecs In-Reply-To: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za> Message-ID: <1359234156.49.0.0578422341127.issue17043@psf.upfronthosting.co.za> Stefan Krah added the comment: Same in test_codeccallbacks: test_badhandlerresults (test.test_codeccallbacks.CodecCallbackTest) ... ==11604== Invalid read of size 1 ==11604== at 0x44AF37: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:6133) ==11604== by 0x4DEB5C: unicode_internal_decode (_codecsmodule.c:251) ==11604== by 0x5093F6: PyObject_Call (abstract.c:2082) ==11604== by 0x47D7F2: PyEval_CallObjectWithKeywords (ceval.c:3942) ==11604== by 0x491C38: PyCodec_Decode (codecs.c:403) ==11604== by 0x459D7D: PyUnicode_Decode (unicodeobject.c:3129) ==11604== by 0x45A287: PyUnicode_FromEncodedObject (unicodeobject.c:3023) ==11604== by 0x519A45: bytes_decode (bytesobject.c:2320) ==11604== by 0x484AB8: PyEval_EvalFrameEx (ceval.c:4374) ==11604== by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11604== by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11604== by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11604== Address 0xfa1f8a2 is 0 bytes after a block of size 34 alloc'd ==11604== at 0x4C27972: realloc (vg_replace_malloc.c:525) ==11604== by 0x51AC34: _PyBytes_Resize (bytesobject.c:2881) ==11604== by 0x51C338: PyBytes_DecodeEscape (bytesobject.c:495) ==11604== by 0x56E871: ast_for_expr (ast.c:3837) ==11604== by 0x570562: ast_for_testlist (ast.c:1106) ==11604== by 0x56E859: ast_for_expr (ast.c:1881) ==11604== by 0x570562: ast_for_testlist (ast.c:1106) ==11604== by 0x56E859: ast_for_expr (ast.c:1881) ==11604== by 0x5715C4: ast_for_stmt (ast.c:3302) ==11604== by 0x5724F8: ast_for_suite (ast.c:3086) ==11604== by 0x5715E3: ast_for_stmt (ast.c:3305) ==11604== by 0x5724F8: ast_for_suite (ast.c:3086) _PyUnicode_DecodeUnicodeInternal (s=0xfa1f8a0 "", size=, errors= 0xf652fa0 "test.badhandler") at Objects/unicodeobject.c:6133 6133 ((char *) &uch)[2] = s[2]; [...] _PyUnicode_DecodeUnicodeInternal (s=0xfa1f8a0 "", size=, errors= 0xf652fa0 "test.badhandler") at Objects/unicodeobject.c:6134 6134 ((char *) &uch)[3] = s[3]; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 22:05:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 21:05:05 +0000 Subject: [issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za> Message-ID: <1359234305.73.0.81067934133.issue16903@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which adds support of strings in communicate(). It also contains a backported test from changeset 4af2c0687970 which tests this behavior. ---------- assignee: -> serhiy.storchaka keywords: +patch nosy: +asvetlov stage: needs patch -> patch review Added file: http://bugs.python.org/file28858/subprocess_communicate_string-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 22:07:48 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 26 Jan 2013 21:07:48 +0000 Subject: [issue16770] Selection in IDLE often skips first character In-Reply-To: <1356373924.27.0.67520730715.issue16770@psf.upfronthosting.co.za> Message-ID: <1359234468.38.0.0710054206438.issue16770@psf.upfronthosting.co.za> Ned Deily added the comment: OK, I *did* spend a little more time on this and am now able to reproduce the behavior solely running the following Tcl code with tclsh: package require Tk set w .text catch {destroy $w} toplevel $w text $w.text -setgrid 1 -height 30 -font "Courier 20" pack $w.text -expand yes -fill both $w.text tag configure color1 -foreground red $w.text insert 0.0 ">>>" $w.text insert end "from" color1 $w.text mark set insert 0.0 Using Cocoa Tk 8.5.13, clicking on the "r" causes the insertion point to move to after the "r" and a second click moves the insertion point to before the "r". Using the Apple-supplied Carbon Tk 8.4, the insertion point stays after the "r" on the second click. I suspect the color tag has something to do with it. I suggest if you want to pursue the issue, you should ask on one of the Tcl mailing lists, like the Mac-specific one (archived here http://dir.gmane.org/gmane.comp.lang.tcl.mac) or open an issue on the Tk tracker: http://sourceforge.net/tracker/?group_id=12997&atid=112997 ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 22:29:18 2013 From: report at bugs.python.org (Daniel Urban) Date: Sat, 26 Jan 2013 21:29:18 +0000 Subject: [issue17044] Implement PEP 422: Simple class initialisation hook Message-ID: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za> New submission from Daniel Urban: The attached patch implements PEP 422 -- Simple class initialisation hook (__init_class__). It includes tests, but it doesn't include documentation yet. ---------- components: Interpreter Core, Library (Lib) files: pep422_1.patch keywords: needs review, patch messages: 180714 nosy: daniel.urban, ncoghlan priority: normal severity: normal stage: patch review status: open title: Implement PEP 422: Simple class initialisation hook type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28859/pep422_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 22:51:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 26 Jan 2013 21:51:36 +0000 Subject: [issue17044] Implement PEP 422: Simple class initialisation hook In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za> Message-ID: <1359237096.08.0.154227447231.issue17044@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 23:05:50 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 26 Jan 2013 22:05:50 +0000 Subject: [issue17037] Add conforms_to_pep399() to test.support In-Reply-To: <1359220205.3.0.68072717026.issue17037@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: On Sat, Jan 26, 2013 at 9:10 AM, Eric Snow wrote: > > Eric Snow added the comment: > > In my case I've been doing PEP 399 for collections.OrderedDict. It struck > me that the boilerplate could be stowed away in a decorator. It's more > than just adding a couple subclasses. Here's what it covers: > > * add the test case subclasses, > * make sure the original test case does not get used (#16835), > PEP 399 dictates that the base class does not inherit from unittest.TestCase, so why would it be used? > * use the relevant names as class attributes rather than globals (e.g. > self.OrderedDict vs. OrderedDict), > Wouldn't it be better to suggest this in PEP 399? Otherwise, the proposed decarator kind-of goes against it. > * hack around modules that do their own imports (#16817), > Can you clarify how this helps? I though the decorator doesn't (yet?) handle the problem with pickle. > * "explicit is better than implicit", > * relatedly, the solution is more magic/obfuscated that the current > boilerplate. > > You could argue that the magnitude of the problem doesn't warrant a > complex decorator, but it doesn't have to be hard to understand. My patch > is something I threw together late last night that could certainly be made > more clear. More importantly, as more modules get a dual implementation, > the above benefits of the decorator become more pronounced. > > I agree that it can be made clearer, but you are unlikely to lose the metaprogramming magic. > My use case was with the tests for OrderedDict. The existing tests don't > refer to > collections.OrderedDict, but rather to OrderedDict (looked up from the globals). > The names argument facilitates the replacement of OrderedDict. Is it possible to just rewrite the tests to use collections.OrderedDict? IMHO this extra 'names' argument adds a lot of magic to the decorator, and if it's just there for a problem that's easy to avoid... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 23:06:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 22:06:44 +0000 Subject: [issue17043] Invalid read in test_codecs In-Reply-To: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za> Message-ID: <201301270006.26207.storchaka@gmail.com> Serhiy Storchaka added the comment: Here are patches for all 4 versions. ---------- keywords: +patch Added file: http://bugs.python.org/file28860/decodeunicodeinternal_overflow-2.7.patch Added file: http://bugs.python.org/file28861/decodeunicodeinternal_overflow-3.2.patch Added file: http://bugs.python.org/file28862/decodeunicodeinternal_overflow-3.3.patch Added file: http://bugs.python.org/file28863/decodeunicodeinternal_overflow-3.4.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 523f309cf558 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sat Jan 26 13:31:44 2013 +0100 +++ b/Objects/unicodeobject.c Sun Jan 27 00:05:19 2013 +0200 @@ -3399,37 +3399,34 @@ end = s + size; while (s < end) { + if (end-s < Py_UNICODE_SIZE) { + endinpos = end-starts; + reason = "truncated input"; + goto error; + } memcpy(p, s, sizeof(Py_UNICODE)); +#ifdef Py_UNICODE_WIDE /* We have to sanity check the raw data, otherwise doom looms for some malformed UCS-4 data. */ - if ( -#ifdef Py_UNICODE_WIDE - *p > unimax || *p < 0 || + if (*p > unimax || *p < 0) { + endinpos = s - starts + Py_UNICODE_SIZE; + reason = "illegal code point (> 0x10FFFF)"; + goto error; + } #endif - end-s < Py_UNICODE_SIZE - ) - { - startinpos = s - starts; - if (end-s < Py_UNICODE_SIZE) { - endinpos = end-starts; - reason = "truncated input"; - } - else { - endinpos = s - starts + Py_UNICODE_SIZE; - reason = "illegal code point (> 0x10FFFF)"; - } - outpos = p - PyUnicode_AS_UNICODE(v); - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicode_internal", reason, - starts, size, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) { - goto onError; - } - } - else { - p++; - s += Py_UNICODE_SIZE; + p++; + s += Py_UNICODE_SIZE; + continue; + + error: + startinpos = s - starts; + outpos = p - PyUnicode_AS_UNICODE(v); + if (unicode_decode_call_errorhandler( + errors, &errorHandler, + "unicode_internal", reason, + starts, size, &startinpos, &endinpos, &exc, &s, + &v, &outpos, &p)) { + goto onError; } } -------------- next part -------------- diff -r f7eda8165e6f Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sat Jan 26 12:14:02 2013 +0200 +++ b/Objects/unicodeobject.c Sat Jan 26 23:55:55 2013 +0200 @@ -4415,37 +4415,34 @@ end = s + size; while (s < end) { + if (end-s < Py_UNICODE_SIZE) { + endinpos = end-starts; + reason = "truncated input"; + goto error; + } memcpy(p, s, sizeof(Py_UNICODE)); +#ifdef Py_UNICODE_WIDE /* We have to sanity check the raw data, otherwise doom looms for some malformed UCS-4 data. */ - if ( -#ifdef Py_UNICODE_WIDE - *p > unimax || *p < 0 || + if (*p > unimax || *p < 0) { + endinpos = s - starts + Py_UNICODE_SIZE; + reason = "illegal code point (> 0x10FFFF)"; + goto error; + } #endif - end-s < Py_UNICODE_SIZE - ) - { - startinpos = s - starts; - if (end-s < Py_UNICODE_SIZE) { - endinpos = end-starts; - reason = "truncated input"; - } - else { - endinpos = s - starts + Py_UNICODE_SIZE; - reason = "illegal code point (> 0x10FFFF)"; - } - outpos = p - PyUnicode_AS_UNICODE(v); - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicode_internal", reason, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &outpos, &p)) { - goto onError; - } - } - else { - p++; - s += Py_UNICODE_SIZE; + p++; + s += Py_UNICODE_SIZE; + continue; + + error: + startinpos = s - starts; + outpos = p - PyUnicode_AS_UNICODE(v); + if (unicode_decode_call_errorhandler( + errors, &errorHandler, + "unicode_internal", reason, + &starts, &end, &startinpos, &endinpos, &exc, &s, + &v, &outpos, &p)) { + goto onError; } } -------------- next part -------------- diff -r 8c49dd8e4d22 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sat Jan 26 18:57:19 2013 +0100 +++ b/Objects/unicodeobject.c Sat Jan 26 23:50:50 2013 +0200 @@ -6125,6 +6125,11 @@ while (s < end) { Py_UNICODE uch; Py_UCS4 ch; + if (end - s < Py_UNICODE_SIZE) { + endinpos = end-starts; + reason = "truncated input"; + goto error; + } /* We copy the raw representation one byte at a time because the pointer may be unaligned (see test_codeccallbacks). */ ((char *) &uch)[0] = s[0]; @@ -6134,37 +6139,18 @@ ((char *) &uch)[3] = s[3]; #endif ch = uch; - +#ifdef Py_UNICODE_WIDE /* We have to sanity check the raw data, otherwise doom looms for some malformed UCS-4 data. */ - if ( -#ifdef Py_UNICODE_WIDE - ch > 0x10ffff || -#endif - end-s < Py_UNICODE_SIZE - ) - { - startinpos = s - starts; - if (end-s < Py_UNICODE_SIZE) { - endinpos = end-starts; - reason = "truncated input"; - } - else { - endinpos = s - starts + Py_UNICODE_SIZE; - reason = "illegal code point (> 0x10FFFF)"; - } - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "unicode_internal", reason, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &v, &outpos)) - goto onError; - continue; - } - + if (ch > 0x10ffff) { + endinpos = s - starts + Py_UNICODE_SIZE; + reason = "illegal code point (> 0x10FFFF)"; + goto error; + } +#endif s += Py_UNICODE_SIZE; #ifndef Py_UNICODE_WIDE - if (Py_UNICODE_IS_HIGH_SURROGATE(ch) && s < end) + if (Py_UNICODE_IS_HIGH_SURROGATE(ch) && end - s >= Py_UNICODE_SIZE) { Py_UNICODE uch2; ((char *) &uch2)[0] = s[0]; @@ -6179,6 +6165,16 @@ if (unicode_putchar(&v, &outpos, ch) < 0) goto onError; + continue; + + error: + startinpos = s - starts; + if (unicode_decode_call_errorhandler( + errors, &errorHandler, + "unicode_internal", reason, + &starts, &end, &startinpos, &endinpos, &exc, &s, + &v, &outpos)) + goto onError; } if (unicode_resize(&v, outpos) < 0) -------------- next part -------------- diff -r 6866384d9ccb Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sat Jan 26 19:00:20 2013 +0100 +++ b/Objects/unicodeobject.c Sat Jan 26 23:50:42 2013 +0200 @@ -5998,6 +5998,11 @@ while (s < end) { Py_UNICODE uch; Py_UCS4 ch; + if (end - s < Py_UNICODE_SIZE) { + endinpos = end-starts; + reason = "truncated input"; + goto error; + } /* We copy the raw representation one byte at a time because the pointer may be unaligned (see test_codeccallbacks). */ ((char *) &uch)[0] = s[0]; @@ -6007,37 +6012,18 @@ ((char *) &uch)[3] = s[3]; #endif ch = uch; - +#ifdef Py_UNICODE_WIDE /* We have to sanity check the raw data, otherwise doom looms for some malformed UCS-4 data. */ - if ( -#ifdef Py_UNICODE_WIDE - ch > 0x10ffff || -#endif - end-s < Py_UNICODE_SIZE - ) - { - startinpos = s - starts; - if (end-s < Py_UNICODE_SIZE) { - endinpos = end-starts; - reason = "truncated input"; - } - else { - endinpos = s - starts + Py_UNICODE_SIZE; - reason = "illegal code point (> 0x10FFFF)"; - } - if (unicode_decode_call_errorhandler_writer( - errors, &errorHandler, - "unicode_internal", reason, - &starts, &end, &startinpos, &endinpos, &exc, &s, - &writer)) - goto onError; - continue; - } - + if (ch > 0x10ffff) { + endinpos = s - starts + Py_UNICODE_SIZE; + reason = "illegal code point (> 0x10FFFF)"; + goto error; + } +#endif s += Py_UNICODE_SIZE; #ifndef Py_UNICODE_WIDE - if (Py_UNICODE_IS_HIGH_SURROGATE(ch) && s < end) + if (Py_UNICODE_IS_HIGH_SURROGATE(ch) && end - s >= Py_UNICODE_SIZE) { Py_UNICODE uch2; ((char *) &uch2)[0] = s[0]; @@ -6054,6 +6040,16 @@ goto onError; PyUnicode_WRITE(writer.kind, writer.data, writer.pos, ch); writer.pos++; + continue; + + error: + startinpos = s - starts; + if (unicode_decode_call_errorhandler_writer( + errors, &errorHandler, + "unicode_internal", reason, + &starts, &end, &startinpos, &endinpos, &exc, &s, + &writer)) + goto onError; } Py_XDECREF(errorHandler); From report at bugs.python.org Sat Jan 26 23:07:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Jan 2013 22:07:47 +0000 Subject: [issue17043] Invalid read in test_codecs In-Reply-To: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za> Message-ID: <1359238067.74.0.824890562592.issue17043@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core, Unicode nosy: +ezio.melotti stage: -> patch review type: -> behavior versions: +Python 2.7, Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 23:46:38 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 22:46:38 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359240398.05.0.250709402263.issue17041@psf.upfronthosting.co.za> Stefan Krah added the comment: The patches are really small, so +1 for committing this before the rc1 for 2.7.4 is released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 23:48:30 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 22:48:30 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359240510.92.0.420528960776.issue17041@psf.upfronthosting.co.za> Stefan Krah added the comment: I left some comments but have no indication that they got mailed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 26 23:58:35 2013 From: report at bugs.python.org (Eric Snow) Date: Sat, 26 Jan 2013 22:58:35 +0000 Subject: [issue17042] Example in C-API memory management doc has confusing order In-Reply-To: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za> Message-ID: <1359241115.15.0.427047283219.issue17042@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for clarifying, Stefan. Are you opposed to a comment in the example? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 00:05:00 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 26 Jan 2013 23:05:00 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1359241500.95.0.499906229698.issue16468@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > the choice part of the error message (passed to ArgumentError) will just be 'invalid choice: '. That's right. With the patch it looks like this: >>> p = argparse.ArgumentParser(prog='test.py') >>> p.add_argument('--foo', choices=c) >>> p.parse_args(['--foo', 'bad']) usage: test.py [-h] [--foo FOO] test.py: error: argument --foo: invalid choice: 'bad' > With that, using default metavars, whatever they end up being argparse's default metavar is just to capitalize the "dest" if the argument is optional, otherwise it is the dest itself (which is always or usually lower-case): def _get_default_metavar_for_optional(self, action): return action.dest.upper() def _get_default_metavar_for_positional(self, action): return action.dest So the patch uses that. You can see the former case in the above usage string. Also, with the patch the current tests pass, btw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 00:21:19 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 23:21:19 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1359242479.2.0.38377642571.issue10156@psf.upfronthosting.co.za> Stefan Krah added the comment: Buildbots etc. look all good. Thanks for fixing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 00:21:26 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 23:21:26 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1359242486.09.0.558615665392.issue10156@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 00:21:43 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 23:21:43 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1359242503.26.0.383608862204.issue10156@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 00:55:23 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Jan 2013 23:55:23 +0000 Subject: [issue17042] Example in C-API memory management doc has confusing order In-Reply-To: <1359241115.15.0.427047283219.issue17042@psf.upfronthosting.co.za> Message-ID: <20130126235525.GA17792@sleipnir.bytereef.org> Stefan Krah added the comment: Moderately opposed, yes. PyMem_Malloc()/PyMem_Free() and PyMem_New()/PyMem_Del() are already explained in depth above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 01:11:25 2013 From: report at bugs.python.org (Eric Snow) Date: Sun, 27 Jan 2013 00:11:25 +0000 Subject: [issue17045] Improve C-API doc for PyTypeObject Message-ID: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za> New submission from Eric Snow: http://docs.python.org/dev/c-api/typeobj.html I found the the documentation for PyTypeObject to be somewhat harder to use than it need be. In the end I distilled the info down for my own use. I'm comfortable with what I came up with, so I'd like to at least add a condensed version of one or two of the tables I made to the top of the doc, with the slot names linking to each description as it currently exists. Attached is a patch. (I also plan on reformatting the doc source so the lines wrap better--70 columns or so.) As well, I have a couple open questions that I'll address separately: * should tp_del be added? * inheritance of tp_flags... ---------- files: typeobj-doc.diff keywords: patch messages: 180723 nosy: eric.snow priority: normal severity: normal status: open title: Improve C-API doc for PyTypeObject Added file: http://bugs.python.org/file28864/typeobj-doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 01:14:02 2013 From: report at bugs.python.org (Eric Snow) Date: Sun, 27 Jan 2013 00:14:02 +0000 Subject: [issue17042] Example in C-API memory management doc has confusing order In-Reply-To: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za> Message-ID: <1359245642.37.0.104025259976.issue17042@psf.upfronthosting.co.za> Eric Snow added the comment: Sorry, I'd meant something like this: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv char *buf1 = PyMem_New(char, BUFSIZ); char *buf2 = (char *) malloc(BUFSIZ); char *buf3 = (char *) PyMem_Malloc(BUFSIZ); ... /* in reverse order */ PyMem_Del(buf3); /* Wrong -- should be PyMem_Free() */ free(buf2); /* Right -- allocated via malloc() */ free(buf1); /* Fatal -- should be PyMem_Del() */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This will help if someone does not know the common pattern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 01:23:38 2013 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 27 Jan 2013 00:23:38 +0000 Subject: [issue5289] ctypes.util.find_library does not work under Solaris In-Reply-To: <1234858635.81.0.426092533899.issue5289@psf.upfronthosting.co.za> Message-ID: <1359246218.31.0.71924015268.issue5289@psf.upfronthosting.co.za> Skip Montanaro added the comment: Is there still time to get this bug fixed in 2.7.3? I patched my 2.7 ctypes/util.py with the latest version (offset a few lines, but no other problems) and verified that it seems to fix the issue. When running util.py as a main program I see this before running patch: % python /opt/TWWfsw/python27/lib/python2.7/ctypes/util.py None None None None After applying the patch: % python /opt/TWWfsw/python27/lib/python2.7/ctypes/util.py libm.so.2 libc.so.1 libbz2.so.1 libcrypt_d.so.1 ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 01:31:19 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 00:31:19 +0000 Subject: [issue17045] Improve C-API doc for PyTypeObject In-Reply-To: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za> Message-ID: <1359246679.86.0.615877751955.issue17045@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, ezio.melotti stage: -> patch review type: -> enhancement versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 01:38:07 2013 From: report at bugs.python.org (Eric Snow) Date: Sun, 27 Jan 2013 00:38:07 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359247087.87.0.792171146001.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: (changing the title to disassociate it from a particular solution) >> * make sure the original test case does not get used (#16835), > > PEP 399 dictates that the base class does not inherit from > unittest.TestCase, so why would it be used? Sorry for any confusion. In this list I was enumerating what you have to do to accommodate PEP 399, rather than any new behavior. Hopefully I wasn't too far off. :) I'd expect that any solution to reduce boilerplate here (like the decorator) would address these responsibilities. >> * use the relevant names as class attributes rather than globals (e.g. >> self.OrderedDict vs. OrderedDict), > > Wouldn't it be better to suggest this in PEP 399? Otherwise, the proposed > decarator kind-of goes against it. PEP 399 already espouses the approach of using a class attribute to hold the module under test, though it doesn't require it. You're right that the decorator obviates the need to make that change when accommodating PEP 399. >> * hack around modules that do their own imports (#16817), > Can you clarify how this helps? I though the decorator doesn't (yet?) > handle the problem with pickle. If a boilerplate solution can make it so that we don't have to hack around these situations whenever they come up, I think it'd be a win. The decorator currently doesn't do this, but I'd expect that any solution we accepted would. That said, if there is a risk of something like the decorator causing other problems then the status quo is certainly better even if it's more work. :) >> * relatedly, the solution is more magic/obfuscated that the current >> boilerplate. >> >> ... > > I agree that it can be made clearer, but you are unlikely to lose the > metaprogramming magic. Yeah, if the right balance can't be struck then I definitely agree that we're better of with the way things are. > Is it possible to just rewrite the tests to use collections.OrderedDict? > IMHO this extra 'names' argument adds a lot of magic to the decorator, and > if it's just there for a problem that's easy to avoid... That's a good idea. Thanks for the feedback, Eli. ---------- title: Add conforms_to_pep399() to test.support -> Use a test.support helper to wrap the PEP 399 boilerplate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 01:57:22 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 00:57:22 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359248242.81.0.298706612397.issue17037@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think something similar has already been proposed and rejected on another issue. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:08:45 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 01:08:45 +0000 Subject: [issue16817] test___all__ affects other tests by doing too much importing In-Reply-To: <1356828969.86.0.130125185831.issue16817@psf.upfronthosting.co.za> Message-ID: <1359248925.26.0.397809178127.issue16817@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:15:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 01:15:58 +0000 Subject: [issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za> Message-ID: <1359249358.92.0.834195796959.issue13997@psf.upfronthosting.co.za> Ezio Melotti added the comment: What's the status of this? Issue #4153 might also be related. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:17:15 2013 From: report at bugs.python.org (Eric Snow) Date: Sun, 27 Jan 2013 01:17:15 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359249435.62.0.240979898449.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: > I think something similar has already been proposed and rejected on another issue. Wouldn't surprise me. I'll look for it. I know there's been a bunch of traffic relative to PEP 399 and to test discovery, so I'm guessing I missed it in there. Thanks for the heads up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:31:11 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 01:31:11 +0000 Subject: [issue4972] context managerment support in imaplib, smtplib, ftplib In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za> Message-ID: <1359250271.81.0.744681337588.issue4972@psf.upfronthosting.co.za> Ezio Melotti added the comment: ftplib.FTP and smtplib.SMTP support the "with" statement since 3.2 and 3.3 respectively. imaplib seems to be the only one left. Can someone review and commit the patch for 3.4? ---------- stage: needs patch -> patch review versions: +Python 3.4 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:32:40 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 01:32:40 +0000 Subject: [issue1479255] Fix building with SWIG's -c++ option set in setup.py Message-ID: <1359250360.41.0.310247139707.issue1479255@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy stage: needs patch -> test needed versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:35:24 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 01:35:24 +0000 Subject: [issue8144] muliprocessing shutdown infinite loop In-Reply-To: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za> Message-ID: <1359250524.83.0.939548975905.issue8144@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can you still reproduce the issue? ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:36:31 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 01:36:31 +0000 Subject: [issue14017] Make it easy to create a new TextIOWrapper based on an existing In-Reply-To: <1329263373.63.0.201487376726.issue14017@psf.upfronthosting.co.za> Message-ID: <1359250591.58.0.385418765002.issue14017@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +pitrou stage: -> needs patch type: -> enhancement versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:41:47 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 27 Jan 2013 01:41:47 +0000 Subject: [issue17005] Add a topological sort algorithm In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za> Message-ID: <1359250907.53.0.115127951276.issue17005@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 02:42:19 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 01:42:19 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <1359250939.08.0.617647505155.issue13886@psf.upfronthosting.co.za> Ezio Melotti added the comment: This problem still exists on 3.4. The attached patch seems to solve it. ---------- nosy: +ezio.melotti versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:02:56 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 27 Jan 2013 02:02:56 +0000 Subject: [issue16488] Add context manager support to epoll object In-Reply-To: <1353078849.09.0.752588026545.issue16488@psf.upfronthosting.co.za> Message-ID: <1359252176.91.0.64025046554.issue16488@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:04:31 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 27 Jan 2013 02:04:31 +0000 Subject: [issue16486] Add context manager support to aifc module In-Reply-To: <1353073163.72.0.969679362142.issue16486@psf.upfronthosting.co.za> Message-ID: <1359252271.06.0.0212471325453.issue16486@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:05:17 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 27 Jan 2013 02:05:17 +0000 Subject: [issue16485] FD leaks in aifc module In-Reply-To: <1353070173.54.0.899587497228.issue16485@psf.upfronthosting.co.za> Message-ID: <1359252317.75.0.553123874989.issue16485@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:06:14 2013 From: report at bugs.python.org (Eric Snow) Date: Sun, 27 Jan 2013 02:06:14 +0000 Subject: [issue17045] Improve C-API doc for PyTypeObject In-Reply-To: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za> Message-ID: <1359252374.62.0.209814806191.issue17045@psf.upfronthosting.co.za> Eric Snow added the comment: Here's an updated patch after feedback. Thanks Ezio! ---------- Added file: http://bugs.python.org/file28865/typeobj-doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:06:30 2013 From: report at bugs.python.org (Eric Snow) Date: Sun, 27 Jan 2013 02:06:30 +0000 Subject: [issue17045] Improve C-API doc for PyTypeObject In-Reply-To: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za> Message-ID: <1359252390.64.0.259964456247.issue17045@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file28864/typeobj-doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:06:51 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 27 Jan 2013 02:06:51 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1359252411.66.0.368485015196.issue16487@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Kristj?n, are you pursuing this yet?. Can we move on? ---------- nosy: +jcea title: Allow ssl certificates to be speficfied from memory rather than files. -> Allow ssl certificates to be specified from memory rather than files. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:12:32 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Jan 2013 02:12:32 +0000 Subject: [issue14018] OS X installer does not detect bad symlinks created by Xcode 3.2.6 In-Reply-To: <1329267688.42.0.5159808393.issue14018@psf.upfronthosting.co.za> Message-ID: <3YtyCz14lhzSLx@mail.python.org> Roundup Robot added the comment: New changeset 49294e55311f by Ned Deily in branch '2.7': Issue #14018: fix merge error http://hg.python.org/cpython/rev/49294e55311f New changeset 58646b0c5226 by Ned Deily in branch '3.2': Issue #14018: fix merge error http://hg.python.org/cpython/rev/58646b0c5226 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:39:05 2013 From: report at bugs.python.org (Chris Rebert) Date: Sun, 27 Jan 2013 02:39:05 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1359254345.34.0.373058678172.issue4153@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:49:41 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 27 Jan 2013 02:49:41 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1359254981.52.0.153636632554.issue16487@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I wasn't pushing it anymore because there seemed to be no interest and Antoine attitude made me lose interest in contributing this. No one liked to comment on my approach except Antoine and I had grown tired of his persistent negativity and aloof manners. I might as well say that here that it is this kind of feedback that has turned me away from contributing to the project on several occations. At CCP we have a heavily patched version of python that we have modified throug time to deal with real world projects. I (and my company) genuinely like to contribute some of those improvements back to the trunk and regularly make efforts to do so (e.g. by taking the time and effort to port to python 3) but often they are met with with almost hostile negativity. I hope, for the sake of Python, that I am the only contributor meeting this kind of attitude. Antoine, please take the time to read what I posted here again. I had a working patch, used in production. I uploaded, it, but when I got back home realized that an unrelated change was part of it. Unable to change it from there I asked politely that you disregard that "unrelated" change while looking at the _substance_ of patch. As you know, I am a committer and will polish things before checking them in, as anyone does. How is that rude? The patch still stands. I on a poor internet in a Chinese hotel and will attempt to download and edit the patch so that the irrelevant change to the PC build solution should no longer need to hinder anyone from reading it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 03:55:27 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 27 Jan 2013 02:55:27 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1359255327.82.0.161153016388.issue16487@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Manually edited the .patch file The build changes are gone but should probably go in separately in some form later. ---------- Added file: http://bugs.python.org/file28866/sslpatch2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 04:27:52 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Jan 2013 03:27:52 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1359257272.14.0.48197557974.issue4153@psf.upfronthosting.co.za> Nick Coghlan added the comment: The section in the HOWTO on Python's unicode support also misses the fact that the easiest way to include a Unicode character in a string literal in Python 3 is to *include that character in the string literal* (since source code is now treated as UTF-8 by default). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 04:41:40 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 03:41:40 +0000 Subject: [issue1681974] mkdtemp fails on Windows if username has non-ASCII character Message-ID: <1359258100.49.0.615357467494.issue1681974@psf.upfronthosting.co.za> Ezio Melotti added the comment: On Win 7 with a non-ASCII username, this seems to work fine on both 2.7 and 3.3. 2.7 returns str or unicode depending on the type of the "prefix=", whereas 3.3 only accepts str (I think this is expected). I'm going to close this as out of date, feel free to reopen if you can reproduce it on some older but still supported system. ---------- nosy: +ezio.melotti resolution: -> out of date stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 04:45:50 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 03:45:50 +0000 Subject: [issue1778410] removeTest() method patch for unittest.TestSuite Message-ID: <1359258350.84.0.800186692481.issue1778410@psf.upfronthosting.co.za> Ezio Melotti added the comment: Michael, what's the situation now? ---------- nosy: +ezio.melotti versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 05:01:16 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 04:01:16 +0000 Subject: [issue1777134] minidom pretty xml output improvement Message-ID: <1359259276.97.0.197007140486.issue1777134@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think this can be closed, since #4147 already improved tpprettyxml(). ---------- nosy: +ezio.melotti resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 05:37:50 2013 From: report at bugs.python.org (Luke Kenneth Casson Leighton) Date: Sun, 27 Jan 2013 04:37:50 +0000 Subject: [issue3871] cross and native build of python for mingw* hosts In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1359261470.6.0.861891411016.issue3871@psf.upfronthosting.co.za> Luke Kenneth Casson Leighton added the comment: the last time this was brought up on python-dev the opinions of the primary python developers was made very very clear: anything that is not written by them is treated with extreme hostile and predudicial contempt. what i mean by that is that the view of the primary python developers is that when they make decisions to decrease their workload, other people are *NOT* welcome to question those decisions. [i questioned their decisions; all bugreports were terminated with excuses without good technical justification, and when i questioned those, access to the bugtracker was terminated]. roumen's work should have been encouraged and welcomed when it was first initiated - FIVE years ago. the best bet therefore is to go over the heads of the primary python developers and to approach the Python Software Foundation's Board of Directors. they are required to enact the PSF Charter in the best interests of the Python Programming Language. what the existing primary python developers can or cannot cope with is of secondary consequence for the Board. the main concern of the primary python developers was that they would be landed with yet another platform to support, and, as they are struggling to cope with the existing ones, they made - and make - absolutely any excuse that they can, regardless of actual merit, to ensure that no other platforms are added. roumen, my opinion is that you have demonstrated over the past five years that you are committed to ensuring that python gets mingw support, and that you yourself are the best person to become the maintainer of python-mingw. you are, already, de-facto, its maintainer. answering some other points: * python-mingw actually requires an entire new platform (built in to sys and os at a fundamental level). neither the platform rules for cygwin, nor the platform rules for gcc, *nor* the platform rules for win32 correctly apply. the MSVC platform rules should also be obviously understood to be useless. mingw uses gcc, but it is gcc for win32: it therefore falls through *all* the existing platforms and requires its own separate class in distutils. * the autoconf-generated pyconfig.h is so insanely slow to generate under mingw (any configure script running under MSYS is insanely slow) that it is virtually impossible to do any development. also, the hard-coded config header file for win32 is also useless: firstly mingw doesn't have all the features of win32 (the headers are reverse-engineered and so are incomplete). secondly, the hard-coded config header file for win32 has MSVC-specific details in it that make it useless. * distutils was frozen because several immature developers made improperly tested commits that caused massive disruption. rather than put in proper review procedures, the primary python developers decided to terminate all possibility of ever adding in a new platform - ever - and began distutils2. this situation has to be reversed. mingw *requires* that distutils have support for the mingw compiler. a way to achieve this is to add separate files into distutils (which cannot be questioned as to their effect on existing files in distutils, because they are separate and therefore have zero effect), and then, once those files have been added and accepted, create a *ONE* line patch to distutils which pulls in the new mingw distutils functionality. a one-line patch cannot really be argued with, esp. if it is only an "include". roumen and others: i recommend that you approach the Python Software Foundation and ask that this project be sponsored for 3 months and/or until it is completed and the patches are in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 06:08:02 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Jan 2013 05:08:02 +0000 Subject: [issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za> Message-ID: <1359263282.18.0.947436932641.issue13997@psf.upfronthosting.co.za> Nick Coghlan added the comment: Current status: #14015 is still valid (i.e. surrogateescape is not well documented) #4153: the Unicode HOWTO still covers more than the bare minimum people need to know Ned Batchelder's "Pragmatic Unicode" is one of the best intros to the topic I have seen: http://nedbatchelder.com/text/unipain.html My full notes on the topic, which I'm still happy with as a "bare minimum Python 3 users should know about Unicode" are available at http://python-notes.boredomandlaziness.org/en/latest/python3/text_file_processing.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 06:36:03 2013 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 27 Jan 2013 05:36:03 +0000 Subject: [issue7576] Avoid warnings in PyModuleDef_HEAD_INIT In-Reply-To: <1261744819.66.0.987087888755.issue7576@psf.upfronthosting.co.za> Message-ID: <1359264963.88.0.287804551566.issue7576@psf.upfronthosting.co.za> Stefan Behnel added the comment: This is a duplicate of issue 9518 (or the other way round) and should be closed as fixed in 3.2. ---------- components: +Extension Modules nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 07:04:13 2013 From: report at bugs.python.org (Ned Deily) Date: Sun, 27 Jan 2013 06:04:13 +0000 Subject: [issue17046] test_subprocess test_executable_without_cwd fails when run with installed python Message-ID: <1359266652.98.0.400492689788.issue17046@psf.upfronthosting.co.za> New submission from Ned Deily: ./configure --enable-shared --with-pydebug --prefix=/py/root && make && make install cd export LD_LIBRARY_PATH=/py/root/lib /py/root/bin/python3.4 -m test -w -uall,-largefile test_subprocess ====================================================================== FAIL: test_executable_without_cwd (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/root/lib/python3.4/test/test_subprocess.py", line 346, in test_executable_without_cwd self._assert_cwd('', "somethingyoudonthave", executable=sys.executable) File "/py/root/lib/python3.4/test/test_subprocess.py", line 274, in _assert_cwd normcase(p.stdout.read().decode("utf-8"))) AssertionError: '' != '/tmp/test_python_22505' + /tmp/test_python_22505 ====================================================================== FAIL: test_executable_without_cwd (test.test_subprocess.ProcessTestCaseNoPoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/root/lib/python3.4/test/test_subprocess.py", line 346, in test_executable_without_cwd self._assert_cwd('', "somethingyoudonthave", executable=sys.executable) File "/py/root/lib/python3.4/test/test_subprocess.py", line 274, in _assert_cwd normcase(p.stdout.read().decode("utf-8"))) AssertionError: '' != '/tmp/test_python_22505' + /tmp/test_python_22505 ---------------------------------------------------------------------- If we don't already have one, it would probably be a good idea to set up at least one buildbot that does a "make install" and runs the tests using the installed Python. ---------- components: Tests messages: 180745 nosy: chris.jerdonek, ned.deily priority: normal severity: normal status: open title: test_subprocess test_executable_without_cwd fails when run with installed python versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 08:15:59 2013 From: report at bugs.python.org (Daniel Urban) Date: Sun, 27 Jan 2013 07:15:59 +0000 Subject: [issue17044] Implement PEP 422: Simple class initialisation hook In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za> Message-ID: <1359270959.18.0.604521626745.issue17044@psf.upfronthosting.co.za> Daniel Urban added the comment: Thanks for the review Ezio! I've fixed the order of the arguments of assertEqual. Regarding your other comment: I agree that your code is shorter and clearer, but it doesn't do exactly the same thing. cls.__init_class__ can be None, and in that case, we should call it (the user should get a TypeError). So the getattr call would need another sentinel object. And with that sentinel, I don't think the code would be shorter and clearer any more. ---------- Added file: http://bugs.python.org/file28867/pep422_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 09:07:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 08:07:10 +0000 Subject: [issue17047] Fix double double words words Message-ID: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In additional to changeset 07488c3c85f1, here are yet some possible word duplications: Lib/_pyio.py:306: Change the stream position to byte offset offset. offset is Lib/concurrent/futures/_base.py:520: fn: A callable that will take take as many arguments as there are Lib/tkinter/__init__.py:3116: have the same start and and end line as the parent widget, but Lib/tkinter/tix.py:149: """Locates a bitmap file of the name name.xpm or name in one of the Lib/tkinter/tix.py:160: """Locates an image file of the name name.xpm, name.xbm or name.ppm Lib/lib2to3/pgen2/grammar.py:23: """Pgen parsing tables tables conversion class. Lib/lib2to3/pgen2/grammar.py:48: states, each state is is a list of arcs, and each Lib/email/_header_value_parser.py:1866: We allow anything except the excluded characters, but but if we find any Lib/email/_encoded_words.py:17:# to to the CTE tables, but YAGNI for now. 'q' is Quoted Printable, 'b' is Lib/email/mime/text.py:29: # If no _charset was specified, check to see see if there are non-ascii Lib/email/policy.py:26: The API extensions enabled by this this policy are currently provisional. Lib/unittest/mock.py:1420: attributes that your production code creates at runtime. It is off by by Lib/test/test_socket.py:845: # Try udp, but don't barf it it doesn't exist Lib/test/test_descrtut.py:322:getx() and and setx(): Lib/test/test_decimal.py:4495: # Do operations and check that it didn't change change internal objects. Lib/distutils/command/install.py:266: raise DistutilsOptionError("can't combine user with with prefix/" Lib/distutils/tests/test_install.py:168: # can't combine user with with prefix/exec_prefix/home or python-gdb.py:1466: '''Is this frame "collect" within the the garbage-collector?''' Include/pyport.h:884: * also also takes care of Apple's universal builds. Modules/_io/iobase.c:79: "Change the stream position to byte offset offset. offset is\n" Modules/_heapqmodule.c:91: /* The leaf at pos is empty now. Put newitem there, and and bubble Modules/_heapqmodule.c:431: /* The leaf at pos is empty now. Put newitem there, and and bubble Modules/socketmodule.c:3547: ensures that that doesn't happen. */ Modules/binascii.c:41:** I have attempted to break with this tradition, but I guess that that Modules/posixmodule.c:9747:Return the value of extended attribute attribute on path.\n\ Modules/posixmodule.c:9825:Set extended attribute attribute on path to value.\n\ Modules/posixmodule.c:9890:Remove extended attribute attribute on path.\n\ PC/msvcrtmodule.c:133:Create a C runtime file descriptor from the file handle handle. The\n\ Doc/c-api/intro.rst:436::c:func:`sum_sequence` example above. It so happens that that example doesn't Doc/c-api/long.rst:206: Return a C :c:type:`size_t` representation of of *pylong*. *pylong* must be Doc/c-api/long.rst:218: Return a C :c:type:`unsigned PY_LONG_LONG` representation of of *pylong*. Doc/library/stdtypes.rst:2640: Cast 1D/unsigned char to to 2D/unsigned long:: Doc/library/email.policy.rst:330: line breaks and and any (RFC invalid) binary data it may contain. Doc/library/unittest.mock.rst:991: attributes that your production code creates at runtime. It is off by by Doc/whatsnew/3.3.rst:1539:New attribute attribute :data:`multiprocessing.Process.sentinel` allows a Lib/idlelib/extend.txt:57:Here is a complete example example: Lib/idlelib/extend.txt:75:used to to configure the loading of extensions and to establish key (or, more ---------- assignee: docs at python components: Documentation keywords: easy messages: 180747 nosy: docs at python, ezio.melotti, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Fix double double words words type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 09:38:10 2013 From: report at bugs.python.org (Robert Xiao) Date: Sun, 27 Jan 2013 08:38:10 +0000 Subject: [issue17048] calendar should understand full- vs. half-width characters Message-ID: <1359275890.12.0.683153995486.issue17048@psf.upfronthosting.co.za> New submission from Robert Xiao: Try this at your command-prompt (requires utf8 support in the terminal emulator): $ python3 -m calendar -L zh_CN -e utf8 The result is a mess like this: 2013 ?? ?? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 2 3 4 5 6 1 2 3 1 2 3 7 8 9 10 11 12 13 4 5 6 7 8 9 10 4 5 6 7 8 9 10 14 15 16 17 18 19 20 11 12 13 14 15 16 17 11 12 13 14 15 16 17 21 22 23 24 25 26 27 18 19 20 21 22 23 24 18 19 20 21 22 23 24 28 29 30 31 25 26 27 28 25 26 27 28 29 30 31 Note the irregular spacing. The calendar module assumes that the characters are half-width, when in reality they are full-width characters. calendar should use unicodedata.east_asian_width to determine if a character is full- or half-width, and adjust the spacing accordingly. ---------- components: Library (Lib) messages: 180748 nosy: nneonneo priority: normal severity: normal status: open title: calendar should understand full- vs. half-width characters versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 09:47:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 08:47:24 +0000 Subject: [issue17047] Fix double double words words In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za> Message-ID: <1359276444.97.0.31319331223.issue17047@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And yet some: Mac/README:40: Create a universal binary build of of Python. This can be used with both Misc/HISTORY:781: some also support accepting an open file descriptor in place of of a path Misc/HISTORY:1415: trying to set a non-binary value as a comment is now now raised at the time Misc/HISTORY:3055: environment after Distutils set it. Instead, have Distutils set the the Tools/pybench/README:6: Extendable suite of of low-level benchmarks for measuring ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 09:48:46 2013 From: report at bugs.python.org (Robert Xiao) Date: Sun, 27 Jan 2013 08:48:46 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified Message-ID: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> New submission from Robert Xiao: Try this at a command-prompt: $ python -m calendar -L ja_JP --encoding utf8 The result is a crash: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/calendar.py", line 708, in main(sys.argv) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/calendar.py", line 703, in main result = result.encode(options.encoding) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 49: ordinal not in range(128) The reason is because the TimeEncoding class doesn't properly return the encoding it should use, so 'encoding' ends up being None in "with TimeEncoding(self.locale) as encoding:" lines. Trivial patch: --- calendar.py 2013-01-27 03:48:08.000000000 -0500 +++ calendar.py 2013-01-27 03:48:08.000000000 -0500 @@ -488,6 +488,7 @@ def __enter__(self): self.oldlocale = _locale.getlocale(_locale.LC_TIME) _locale.setlocale(_locale.LC_TIME, self.locale) + return self.locale[1] def __exit__(self, *args): _locale.setlocale(_locale.LC_TIME, self.oldlocale) ---------- components: Library (Lib) messages: 180750 nosy: nneonneo priority: normal severity: normal status: open title: calendar throws UnicodeEncodeError when locale is specified versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 09:50:03 2013 From: report at bugs.python.org (Robert Xiao) Date: Sun, 27 Jan 2013 08:50:03 +0000 Subject: [issue17048] calendar should understand full- vs. half-width characters In-Reply-To: <1359275890.12.0.683153995486.issue17048@psf.upfronthosting.co.za> Message-ID: <1359276603.17.0.312762783562.issue17048@psf.upfronthosting.co.za> Robert Xiao added the comment: This is also a problem in Python 2.7 after the patch in issue17049 is applied. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 09:51:01 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 27 Jan 2013 08:51:01 +0000 Subject: [issue17050] argparse.REMAINDER doesn't work as first argument Message-ID: <1359276661.57.0.274871702559.issue17050@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Works: >>> p = ArgumentParser(prog='test.py') >>> p.add_argument('pos') >>> p.add_argument('remainder', nargs=argparse.REMAINDER) >>> p.parse_args(['abc', '--def']) Namespace(pos='abc', remainder=['--def']) Doesn't work: >>> p = ArgumentParser(prog='test.py') >>> p.add_argument('remainder', nargs=argparse.REMAINDER) >>> p.parse_args(['--def']) usage: test.py [-h] ... test.py: error: unrecognized arguments: --def This use case comes up, for example, if you would like to extract all the arguments passed to a subparser in order to pass to a different program. ---------- components: Library (Lib) messages: 180752 nosy: bethard, chris.jerdonek priority: normal severity: normal stage: test needed status: open title: argparse.REMAINDER doesn't work as first argument type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 09:52:55 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 27 Jan 2013 08:52:55 +0000 Subject: [issue14174] argparse.REMAINDER fails to parse remainder correctly In-Reply-To: <1330690090.15.0.511487898244.issue14174@psf.upfronthosting.co.za> Message-ID: <1359276775.9.0.949110108705.issue14174@psf.upfronthosting.co.za> Chris Jerdonek added the comment: See also issue 17050 for a reduced/simple case where argparse.REMAINDER doesn't work (the case of the first argument being argparse.REMAINDER). ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 10:01:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 09:01:24 +0000 Subject: [issue17048] calendar should understand full- vs. half-width characters In-Reply-To: <1359275890.12.0.683153995486.issue17048@psf.upfronthosting.co.za> Message-ID: <1359277284.23.0.148768858088.issue17048@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Add functions to get the width in columns of a character _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 10:10:56 2013 From: report at bugs.python.org (Robert Xiao) Date: Sun, 27 Jan 2013 09:10:56 +0000 Subject: [issue17051] Memory leak in os.path.isdir under Windows Message-ID: <1359277856.16.0.886323650341.issue17051@psf.upfronthosting.co.za> New submission from Robert Xiao: [From http://stackoverflow.com/questions/12648737/huge-memory-leak-in-repeated-os-path-isdir-calls] os.path.isdir() leaks memory under Windows in Python 2.7. The core cause is this snippet: Modules/posixmodule.c:4226: if (!PyArg_ParseTuple(args, "et:_isdir", Py_FileSystemDefaultEncoding, &path)) return NULL; attributes = GetFileAttributesA(path); if (attributes == INVALID_FILE_ATTRIBUTES) Py_RETURN_FALSE; check: if (attributes & FILE_ATTRIBUTE_DIRECTORY) Py_RETURN_TRUE; else Py_RETURN_FALSE; The buffer returned by the "et" ParseTuple format must be freed after use. Since it isn't freed, we get a memory leak here. Patch: --- a/Modules/posixmodule.c Mon Apr 09 19:04:04 2012 -0400 +++ b/Modules/posixmodule.c Sun Jan 27 04:10:34 2013 -0500 @@ -4226,6 +4226,7 @@ return NULL; attributes = GetFileAttributesA(path); + PyMem_Free(path); if (attributes == INVALID_FILE_ATTRIBUTES) Py_RETURN_FALSE; ---------- components: Library (Lib) messages: 180754 nosy: nneonneo priority: normal severity: normal status: open title: Memory leak in os.path.isdir under Windows type: resource usage versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:11:51 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 27 Jan 2013 10:11:51 +0000 Subject: [issue17052] unittest discovery should use self.testLoader Message-ID: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The _do_discovery() method of unittest.TestProgram: def _do_discovery(self, argv, Loader=loader.TestLoader): (from http://hg.python.org/cpython/file/2cf89e2e6247/Lib/unittest/main.py#l222 ) should be using self.testLoader instead of loader.TestLoader. It's not consistent for some parts of TestProgram to use loader.TestLoader and other parts to use the testLoader passed in via the constructor. ---------- components: Library (Lib) messages: 180755 nosy: chris.jerdonek, ezio.melotti, michael.foord priority: normal severity: normal stage: test needed status: open title: unittest discovery should use self.testLoader type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:13:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 10:13:43 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified In-Reply-To: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> Message-ID: <1359281623.53.0.919449160047.issue17049@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for report and suggestion, Robert Xiao. The patch should be a little more complex however. ---------- keywords: +patch nosy: +rhettinger, serhiy.storchaka stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file28868/calendar_locale-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:14:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 10:14:45 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified In-Reply-To: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> Message-ID: <1359281685.63.0.921853317382.issue17049@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is an updated test for 3.x. ---------- versions: +Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28869/calendar_locale-3.x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:18:05 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Jan 2013 10:18:05 +0000 Subject: [issue16772] int() accepts float number base In-Reply-To: <1356379816.55.0.394159621293.issue16772@psf.upfronthosting.co.za> Message-ID: <3Yv90D3yKdzSRZ@mail.python.org> Roundup Robot added the comment: New changeset 79db70bd3188 by Mark Dickinson in branch 'default': Issue #16772: in int(x, base), non-integer bases must have an __index__ method. http://hg.python.org/cpython/rev/79db70bd3188 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:20:30 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 27 Jan 2013 10:20:30 +0000 Subject: [issue16772] int() accepts float number base In-Reply-To: <1356379816.55.0.394159621293.issue16772@psf.upfronthosting.co.za> Message-ID: <1359282030.42.0.316044946401.issue16772@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:20:44 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 27 Jan 2013 10:20:44 +0000 Subject: [issue16772] int() accepts float number base In-Reply-To: <1356379816.55.0.394159621293.issue16772@psf.upfronthosting.co.za> Message-ID: <1359282044.78.0.579462078557.issue16772@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:40:26 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 27 Jan 2013 10:40:26 +0000 Subject: [issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex In-Reply-To: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za> Message-ID: <1359283226.41.0.802384970546.issue16899@psf.upfronthosting.co.za> Mark Dickinson added the comment: Postponing as suggested. ---------- resolution: -> postponed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:48:36 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 27 Jan 2013 10:48:36 +0000 Subject: [issue15438] document that math.pow is inappropriate for integers In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za> Message-ID: <1359283716.28.0.245916269118.issue15438@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Anyone wants to suggest a specific wording? How about the attached patch? ---------- keywords: +patch Added file: http://bugs.python.org/file28870/issue15438.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:52:50 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 10:52:50 +0000 Subject: [issue4972] context managerment support in imaplib, smtplib, ftplib In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za> Message-ID: <1359283970.79.0.60541580149.issue4972@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Imaplib tests was changed a lot since 3.2. Here is an updated patch. ---------- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file28871/imaplib_with_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 11:57:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 10:57:19 +0000 Subject: [issue7576] Avoid warnings in PyModuleDef_HEAD_INIT In-Reply-To: <1261744819.66.0.987087888755.issue7576@psf.upfronthosting.co.za> Message-ID: <1359284239.34.0.274157486838.issue7576@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate stage: patch review -> committed/rejected status: open -> closed superseder: -> PyModuleDef_HEAD_INIT does not explicitly initialize all fields of m_base _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 12:59:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 11:59:20 +0000 Subject: [issue17051] Memory leak in os.path.isdir under Windows In-Reply-To: <1359277856.16.0.886323650341.issue17051@psf.upfronthosting.co.za> Message-ID: <1359287960.91.0.0812225103371.issue17051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch. Thank you, Robert Xiao. Can you please submit a contributor form? http://python.org/psf/contrib/contrib-form/ http://python.org/psf/contrib/ ---------- assignee: -> serhiy.storchaka components: +Extension Modules, Windows -Library (Lib) nosy: +serhiy.storchaka stage: -> commit review versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 13:04:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 12:04:01 +0000 Subject: [issue16445] SEGFAULT when deleting Exception.message In-Reply-To: <1352415910.77.0.640632287013.issue16445@psf.upfronthosting.co.za> Message-ID: <1359288241.2.0.590051697714.issue16445@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 13:26:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 12:26:23 +0000 Subject: [issue16447] SEGFAULT when setting type.__name__ In-Reply-To: <1352419760.39.0.728241030951.issue16447@psf.upfronthosting.co.za> Message-ID: <1359289583.95.0.0909162644718.issue16447@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 13:32:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 12:32:38 +0000 Subject: [issue13555] cPickle MemoryError when loading large file (while pickle works) In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za> Message-ID: <1359289958.41.0.940255533135.issue13555@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Charles-Fran?ois, are you going to finish this before 2.7.4 RC released? The patch should be updated to address Antoine's comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 13:37:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 12:37:05 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1359290225.6.0.788410993574.issue15809@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 13:38:03 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 12:38:03 +0000 Subject: [issue16137] Using time.asctime() with an array with negative tm_hour causes Python Crash. In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za> Message-ID: <1359290283.62.0.982090475453.issue16137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Any news? ---------- priority: normal -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 13:44:22 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 12:44:22 +0000 Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for %s, %S, %R, %V, %U, %A In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za> Message-ID: <1359290662.39.0.0965202364855.issue7330@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: crash -> enhancement versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 13:47:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 12:47:44 +0000 Subject: [issue16743] mmap on Windows can mishandle files larger than sys.maxsize In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za> Message-ID: <1359290864.67.0.96159917933.issue16743@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Let's go ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 14:05:00 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Jan 2013 13:05:00 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <3YvDhr1svbzSDM@mail.python.org> Roundup Robot added the comment: New changeset cf0f450b3299 by Nadeem Vawda in branch '3.2': Issue #13886: Fix input() to not strip out supposedly-invalid input bytes. http://hg.python.org/cpython/rev/cf0f450b3299 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 14:13:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Jan 2013 13:13:35 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <3YvDtl061rzSLn@mail.python.org> Roundup Robot added the comment: New changeset 5c8732049dd5 by Nadeem Vawda in branch '3.3': Issue #13886: Fix input() to not strip out supposedly-invalid input bytes. http://hg.python.org/cpython/rev/5c8732049dd5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 14:17:12 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 27 Jan 2013 13:17:12 +0000 Subject: [issue17053] pydoc should use inspect.signature instead of inspect.getfullargspec Message-ID: <1359292632.3.0.760417514127.issue17053@psf.upfronthosting.co.za> New submission from Ronald Oussoren: pydoc currently uses inspect.getfullargspec to determine the signature of a callable when rendering its documentation. It should use inspect.signature instead because that function can work with callables that aren't python functions or methods. Changing pydoc to use inspect.signature would make it possible to render more useful documentation for callables implemented in C, when those callables also implement the "__signature__" special method. ---------- components: Library (Lib) messages: 180768 nosy: ronaldoussoren priority: low severity: normal stage: needs patch status: open title: pydoc should use inspect.signature instead of inspect.getfullargspec type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 14:17:30 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Jan 2013 13:17:30 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <3YvDzF4z9WzSLp@mail.python.org> Roundup Robot added the comment: New changeset 9774721bfc32 by Nadeem Vawda in branch 'default': Issue #13886: Fix input() to not strip out supposedly-invalid input bytes. http://hg.python.org/cpython/rev/9774721bfc32 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 14:21:36 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Jan 2013 13:21:36 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <3YvF4014K7zSMK@mail.python.org> Roundup Robot added the comment: New changeset 12223782031f by Nadeem Vawda in branch '2.7': Issue #13886: Fix input() to not strip out supposedly-invalid input bytes. http://hg.python.org/cpython/rev/12223782031f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 14:24:31 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 27 Jan 2013 13:24:31 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <1359293071.01.0.901590855459.issue13886@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- assignee: -> nadeem.vawda resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 16:15:43 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 27 Jan 2013 15:15:43 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <1359299743.87.0.869272916938.issue11729@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Okay with me to backport. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 16:33:30 2013 From: report at bugs.python.org (Robert Xiao) Date: Sun, 27 Jan 2013 15:33:30 +0000 Subject: [issue17051] Memory leak in os.path.isdir under Windows In-Reply-To: <1359277856.16.0.886323650341.issue17051@psf.upfronthosting.co.za> Message-ID: <1359300810.74.0.81824386842.issue17051@psf.upfronthosting.co.za> Robert Xiao added the comment: The PSF form really needs a PDF version. Anyway, 'tis duly submitted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 16:34:55 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 27 Jan 2013 15:34:55 +0000 Subject: [issue15438] document that math.pow is inappropriate for integers In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za> Message-ID: <1359300895.79.0.745404793898.issue15438@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think it should be .. note, but otherwise it looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 16:38:14 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 27 Jan 2013 15:38:14 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359301094.12.0.332006890522.issue17041@psf.upfronthosting.co.za> R. David Murray added the comment: Stefan: as Serhiy pointed out, the two parameters control different things. While it may be true that it is *likely* that someone would use both if they use one, it is not guaranteed. I think it is better to keep them separate, since while they are related operationally they are otherwise orthogonal, so linking them in the test code just seems wrong :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 17:48:13 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 16:48:13 +0000 Subject: [issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za> Message-ID: <1359305293.68.0.0677563146352.issue13997@psf.upfronthosting.co.za> Ezio Melotti added the comment: Maybe the Unicode HOWTO could be reorganized so that it first introduces the bare minimum and then expands the concepts for whoever wants to know more? Or should we have a "basic" and an "advanced" Unicode HOWTO? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 17:50:54 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 16:50:54 +0000 Subject: [issue16772] int() accepts float number base In-Reply-To: <1356379816.55.0.394159621293.issue16772@psf.upfronthosting.co.za> Message-ID: <1359305454.0.0.532955876988.issue16772@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 18:01:56 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Jan 2013 17:01:56 +0000 Subject: [issue11729] libffi assembler relocation check is not robust, fails with clang In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za> Message-ID: <3YvKyD0Yq0zSCp@mail.python.org> Roundup Robot added the comment: New changeset b9792b27d410 by Stefan Krah in branch '2.7': Issue #11729: Backport commit bff052d9 from libffi upstream in order to fix http://hg.python.org/cpython/rev/b9792b27d410 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 18:41:53 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Jan 2013 17:41:53 +0000 Subject: [issue13555] cPickle MemoryError when loading large file (while pickle works) In-Reply-To: <1359289958.41.0.940255533135.issue13555@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Charles-Fran?ois, are you going to finish this before 2.7.4 RC released? The patch should be updated to address Antoine's comments. No. I don't have access to a 64-bit box, which makes it difficult to write (I don't get compiler warnings) and test. Feel free to pick up the patch and update it! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 19:00:25 2013 From: report at bugs.python.org (Stefan Krah) Date: Sun, 27 Jan 2013 18:00:25 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359301094.12.0.332006890522.issue17041@psf.upfronthosting.co.za> Message-ID: <20130127180027.GA26964@sleipnir.bytereef.org> Stefan Krah added the comment: Right, keeping the cases separate is indeed clearer. Serhiy, in case you are waiting for my "stick to minimal changes" comment to be resolved: People apparently *do* use --without-doc-strings, so the additional code in test_pydoc.py is really fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 19:07:45 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Jan 2013 18:07:45 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <3YvMQ83jzBzSKD@mail.python.org> Roundup Robot added the comment: New changeset 6c0d9d1ce63e by Serhiy Storchaka in branch '2.7': - Issue #17041: Fix testing when Python is configured with the http://hg.python.org/cpython/rev/6c0d9d1ce63e New changeset 241b655c23b6 by Serhiy Storchaka in branch '3.2': Issue #17041: Fix testing when Python is configured with the http://hg.python.org/cpython/rev/241b655c23b6 New changeset b2fa459d95d6 by Serhiy Storchaka in branch '3.3': Issue #17041: Fix testing when Python is configured with the http://hg.python.org/cpython/rev/b2fa459d95d6 New changeset 754112dc3bbb by Serhiy Storchaka in branch 'default': Issue #17041: Fix testing when Python is configured with the http://hg.python.org/cpython/rev/754112dc3bbb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 19:23:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 18:23:43 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359311023.06.0.0616356596822.issue17041@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you, Stefan. I got notification about your comments on email and fixed patches. Here is a patch which fixes doctests (for 2.7 only need replace test.support by test.test_support). I'm not sure this is a right way to do conditional doctests. ---------- Added file: http://bugs.python.org/file28872/doctests_without_docstrings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 19:29:39 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Jan 2013 18:29:39 +0000 Subject: [issue17025] reduce multiprocessing.Queue contention In-Reply-To: <1161566103.419088047.1359045887257.JavaMail.root@zimbra10-e2.priv.proxad.net> Message-ID: Charles-Fran?ois Natali added the comment: > I would like to suggest again my idea of doing it in Connection instead, > with new methods (e.g. locked_send and locked_recv). Especially given > it can be useful in user code to have a thread-safe Connection (I'm in > this situation currently). I intended to do this initially, but then it turned out to be much more intrusive than what I initially thought, and opted for a simpler approach. While it's probably a good idea to implement it in Connection, I don't really like the idea of adding new distinct methods: - this would require allocating locks for every connection, which wouldn't be used most of the time - since locks are implemented atop POSIX semaphores and some platforms only support a handful of them, it could trigger some failure - it's not really just adding locked_send() and locked_recv(): you must implemented locked send_bytes/send/recv_bytes/recv_bytes_into/recv: also, if we want to implement timed and non blocking receive (which is supported by Queue.get), it should probably be handled here So basically, I think the right way to do it would be to define an abstract ConcurrentConnection, or AtomicConnection which would override Connection methods making them thread/process safe. We'd also need exposing AtomicPipe... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 19:41:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Jan 2013 18:41:32 +0000 Subject: [issue17025] reduce multiprocessing.Queue contention In-Reply-To: <1359042546.71.0.578815247507.issue17025@psf.upfronthosting.co.za> Message-ID: <1359312092.44.0.172489308809.issue17025@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For the record, I tried the Connection approach and here is what I ended up with. ---------- Added file: http://bugs.python.org/file28873/locked_send_recv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 20:09:33 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 27 Jan 2013 19:09:33 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359313773.56.0.425694552304.issue17037@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, let's take a step back here and look at what exactly we are trying to simplify (which is now the updated example in PEP 399):: from test.support import import_fresh_module import unittest c_heapq = import_fresh_module('heapq', fresh=['_heapq']) py_heapq = import_fresh_module('heapq', blocked=['_heapq']) class ExampleTest: def test_example(self): self.assertTrue(hasattr(self.module, 'heapify')) class PyExampleTest(ExampleTest, unittest.TestCase): module = py_heapq @unittest.skipUnless(c_heapq, 'requires the C _heapq module') class CExampleTest(ExampleTest, unittest.TestCase): module = c_heapq if __name__ == '__main__': unittest.main() Ignoring the unittest.main() boilerplate, we have two import_fresh_module() calls and the creation of two subclasses of ExampleTest, both of which inherit from unittest.TestCase and one of which is skipped if the acceleration code is lacking. So there is some boilerplate. The question is whether a solution be made that isn't too magical to minimize this code. In my head I see this becoming something more like:: from test.support import PEP399Tests pep399_tests = PEP399Tests('heapq', '_heapq') class ExampleTest: def test_example(self): self.assertTrue(hasattr(self.heapq, 'heapify')) PyExampleTest, CExampleTest = pep399_tests.create_test_cases(ExampleTest) if __name__ == '__main__': unittest.main() This would cut out the import_fresh_module() calls (which don't need to be injected globally as you should be accessing the code through the test class' attribute storing the module and if you don't care what version you get you just do a standard imoprt), remembering to subclass unittest.TestCase, and to skip the accelerated version of the tests if it isn't needed. Basically it goes from 7 lines to 2 with not repetitious lines. You could make this a decorator, but honestly it's the same number of lines without the magic of mucking with a module's globals by getting at them through sys.modules (the decorator really only saves you from typing the variable names to hold the new test classes and the test class argument to begin with). And the implementation should be relatively straight-forward (thanks to Eric having done most of the thinking on what needs to happen):: class PEP399Tests: # Using keyword-only arguments you could go as far as allowing for # customizing the attribute name to set, class name prefixes, etc. def __init__(module_name, *accelerated_names): self.module_name = module_name self.py_module = import_fresh_module(module_name, fresh=accelerated_names) self.accelerated_module = import_fresh_module(module_name, block=accelerated_names) def create_test_cases(self, test_class): class PyTestCase(test_class, unittest.TestCase): pass PyTestCase.__name__ = 'Py' + test_class.__name__ setattr(PyTestCase, self.module_name, self.py_module) if self.accelerated_module is None: AcceleratedTestCase = None else: class AcceleratedTestCase(test_class, unittest.TestCase): pass AcceleratedTestCase.__name__ = 'Accelerated' + test_class.__name__ setattr(AcceleratedTestCase, self.module_name, self.accelerated_module) return PyTestCase, AcceleratedTestCase Does this approach seem more reasonable to people in terms of cutting down boilerplate without being too magical? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 20:23:33 2013 From: report at bugs.python.org (Stefan Krah) Date: Sun, 27 Jan 2013 19:23:33 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359314613.58.0.160498189486.issue17041@psf.upfronthosting.co.za> Stefan Krah added the comment: doctests_without_docstrings.patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 20:42:42 2013 From: report at bugs.python.org (Berker Peksag) Date: Sun, 27 Jan 2013 19:42:42 +0000 Subject: [issue4972] context management support in imaplib, smtplib, ftplib In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za> Message-ID: <1359315762.08.0.294190276002.issue4972@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch lacks documentation updates. ---------- nosy: +berker.peksag title: context managerment support in imaplib, smtplib, ftplib -> context management support in imaplib, smtplib, ftplib _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:11:11 2013 From: report at bugs.python.org (Ned Deily) Date: Sun, 27 Jan 2013 20:11:11 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified In-Reply-To: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> Message-ID: <1359317471.09.0.486285056663.issue17049@psf.upfronthosting.co.za> Ned Deily added the comment: See also Issue13539. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:13:03 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 20:13:03 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359317583.69.0.923617772511.issue17037@psf.upfronthosting.co.za> Ezio Melotti added the comment: Note that while this works for the simple case, it doesn't work whenever you need additional tests or attributes that are specific for one of the two classes, or when you have additional base classes. This is also not so uncommon. I think the skip on the accelerated version might not be necessary in some situations. IOW we have to trade between compactness, flexibility, and readability, and trying to improve one side will likely make other aspects worse. I don't think there would be any problem at grouping the two import_fresh_module() in a single call that returns the two modules though. (I would also avoid the use of pep399 in the names -- it's not really readable unless you can map pep numbers with their titles.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:27:51 2013 From: report at bugs.python.org (Matthias Klose) Date: Sun, 27 Jan 2013 20:27:51 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1359318471.86.0.111371099591.issue15819@psf.upfronthosting.co.za> Matthias Klose added the comment: just saw the comment about .hgtouch in http://bugs.python.org/issue15819#msg169484 attaching a patch for it here (as proposed on python-committers). ---------- nosy: +doko Added file: http://bugs.python.org/file28874/hgtouch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:27:57 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 27 Jan 2013 20:27:57 +0000 Subject: [issue16743] mmap on Windows can mishandle files larger than sys.maxsize In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za> Message-ID: <1359318477.47.0.805246672259.issue16743@psf.upfronthosting.co.za> Terry J. Reedy added the comment: > As Richard explained, this will not break working code, this will break only broken code If code is both working and broken, for some reasonable meaning of 'working' and 'broken', breaking such broken code *will* break working code. I understood Richard as saying that code that 'works by dumb luck' is *also* broken. I agree we do not need to retain unpredictable 'dumb luck' -- in future versions. But in the absence of a clear discrepancy between doc and behavior (the definition of a bug) I believe breaking such code in a bugfix release would be contrary to current policy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:33:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 20:33:45 +0000 Subject: [issue17054] cStringIO.StringIO aborted when more then INT_MAX bytes written Message-ID: <1359318825.63.0.912749070119.issue17054@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Reproduced on x8 snakebite. % ./python.exe Python 2.7.3+ (2.7:38a10d0778d2+, Jan 27 2013, 20:05:15) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin Type "help", "copyright", "credits" or "license" for more information. Could not open PYTHONSTARTUP IOError: [Errno 2] No such file or directory: '/Users/cpython/.pythonrc' >>> from cStringIO import StringIO [38179 refs] >>> f = StringIO() [38181 refs] >>> s = 'x' * 2**30 [38183 refs] >>> f.write(s) [38183 refs] >>> f.write(s) Assertion failed: (oself->pos + l < INT_MAX), function O_cwrite, file /Users/cpython/hg/storchaka/Modules/cStringIO.c, line 421. zsh: abort ./python.exe ---------- components: IO messages: 180790 nosy: serhiy.storchaka priority: high severity: normal stage: needs patch status: open title: cStringIO.StringIO aborted when more then INT_MAX bytes written type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:48:27 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Jan 2013 20:48:27 +0000 Subject: [issue17054] cStringIO.StringIO aborted when more then INT_MAX bytes written In-Reply-To: <1359318825.63.0.912749070119.issue17054@psf.upfronthosting.co.za> Message-ID: <1359319707.23.0.704471581718.issue17054@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Isn't is the same as issue7358? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:49:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 20:49:24 +0000 Subject: [issue13555] cPickle MemoryError when loading large file (while pickle works) In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za> Message-ID: <1359319764.45.0.528107042605.issue13555@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have picked up it. Actually BINSTRING format supports only strings less 2GiB, so test should be changed. But there are other bugs which prohibit pickling a lot of data. For one I open issue17054. ---------- dependencies: +cStringIO.StringIO aborted when more then INT_MAX bytes written _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:49:40 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 27 Jan 2013 20:49:40 +0000 Subject: [issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za> Message-ID: <1359319780.04.0.132184059215.issue13997@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I basically agree with Ezio. The doc currently starts with Introduction to Unicode History of Character Codes ... It ends with Tips for Writing Unicode-aware Programs. ... The most important tip is: Software should only work with Unicode strings internally, decoding the input data as soon as possible and encoding the output only at the end. I think the how-to should *start* with that general principle and continue with the specific task-based how-tos from the thread. This will tell people who at least vaguely know the following material how to get going in a practical manner. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:54:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 20:54:39 +0000 Subject: [issue13539] Return value missing in calendar.TimeEncoding.__enter__ In-Reply-To: <1323176871.81.0.567417111906.issue13539@psf.upfronthosting.co.za> Message-ID: <1359320079.66.0.101995992812.issue13539@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue17049. This is not a theoretical bug. ---------- nosy: +serhiy.storchaka versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 21:54:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 20:54:43 +0000 Subject: [issue1764286] inspect.getsource does not work with decorated functions Message-ID: <1359320083.93.0.901716132339.issue1764286@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 22:00:29 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 21:00:29 +0000 Subject: [issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za> Message-ID: <1359320429.65.0.294960603039.issue13997@psf.upfronthosting.co.za> Ezio Melotti added the comment: If we agree on this, I can propose a patch in #4153 and this issue can be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 22:00:33 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 27 Jan 2013 21:00:33 +0000 Subject: [issue13539] Return value missing in calendar.TimeEncoding.__enter__ In-Reply-To: <1323176871.81.0.567417111906.issue13539@psf.upfronthosting.co.za> Message-ID: <1359320433.54.0.0441816715212.issue13539@psf.upfronthosting.co.za> ?ric Araujo added the comment: Then you can close one bug as duplicate and commit a fix for the other :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 22:06:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Jan 2013 21:06:24 +0000 Subject: [issue16743] mmap on Windows can mishandle files larger than sys.maxsize In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za> Message-ID: <1359320784.56.0.432918283375.issue16743@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Every bugfix breaks some code. As a compromise I propose set m_obj->size = PY_SSIZE_T_MAX in case of overflow and emit a warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:06:13 2013 From: report at bugs.python.org (Trent Nelson) Date: Sun, 27 Jan 2013 22:06:13 +0000 Subject: [issue1298835] Add a vendor-packages directory for system-supplied modules Message-ID: <1359324373.41.0.0276932165715.issue1298835@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +brian-cameron-oracle, trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:26:46 2013 From: report at bugs.python.org (Petr Prikryl) Date: Sun, 27 Jan 2013 22:26:46 +0000 Subject: [issue1145257] shutil.copystat() may fail... Message-ID: <1359325606.55.0.398689448905.issue1145257@psf.upfronthosting.co.za> Petr Prikryl added the comment: Well, it is quite an old event. Anyway, I have fixed the simple example, and launched it on Python 2.6, 2.7, 3.2, 3.3. It does not fail now. But I did not tested it heavily. >From my point of view, it was probably fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:29:09 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 27 Jan 2013 22:29:09 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359325748.99.0.13662649769.issue17037@psf.upfronthosting.co.za> Eli Bendersky added the comment: Brett - you approach is certainly less magical. While you're at it, how about PEP 399 recommending the import_fresh_modules calls not being in the global context, but rather class/instance attributes of the test cases? This is what both yours and Eric's decorator do, and it's better common sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:33:07 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 22:33:07 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359325987.4.0.621474789383.issue17037@psf.upfronthosting.co.za> Ezio Melotti added the comment: That wouldn't work if there is a skip decorator that checks that the C module is available :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:45:37 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Jan 2013 22:45:37 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359326737.92.0.481619731922.issue17037@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, I like Brett's approach much better. Also, I agree with Ezio that "pep399" shouldn't be in the name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:48:28 2013 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=) Date: Sun, 27 Jan 2013 22:48:28 +0000 Subject: [issue17055] ftplib.ftpcp test Message-ID: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za> New submission from Micha? Jastrz?bski: Test for ftplib.ftpcp. ---------- components: Tests files: ftpcp_test.patch keywords: patch messages: 180802 nosy: inc0 priority: normal severity: normal status: open title: ftplib.ftpcp test type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28875/ftpcp_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:49:04 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 22:49:04 +0000 Subject: [issue17055] ftplib.ftpcp test In-Reply-To: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za> Message-ID: <1359326944.76.0.930665921953.issue17055@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, giampaolo.rodola stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:52:10 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 27 Jan 2013 22:52:10 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359325987.4.0.621474789383.issue17037@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: > That wouldn't work if there is a skip decorator that checks that the C module is available :) Yes, but that's easily amended with just raising SkipTest in the setUp instead. Not polluting the global namespace has its merits, especially when the import sequence is so funky you want to clearly separate testing of the two modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 27 23:52:52 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 27 Jan 2013 22:52:52 +0000 Subject: [issue17055] ftplib.ftpcp test In-Reply-To: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za> Message-ID: <1359327172.32.0.216634134364.issue17055@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: ftplib.ftpcp? What is that? I do not understand what you're trying to test. ftplib test suite is already pretty extended. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 00:12:02 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 23:12:02 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359328322.51.0.191309824998.issue17037@psf.upfronthosting.co.za> Ezio Melotti added the comment: That would work if we use something Brett's proposal, so that we can create a default setUp that raises SkipTest. My comment was about using module = import_fresh_module() directly in the class body of the subclasses as they are currently documented in PEP 399. The point is that, while Brett's proposal doesn't look too bad, I'm not sure it's flexible enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 00:13:39 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 27 Jan 2013 23:13:39 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359317583.69.0.923617772511.issue17037@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Sun, Jan 27, 2013 at 3:13 PM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > Note that while this works for the simple case, it doesn't work whenever > you need additional tests or attributes that are specific for one of the > two classes, Sure it does. The modules are simply attributes on the PEP399Test instance, so you can still access the modules just as easily in test classes that don't need to be tested with both possible modules. or when you have additional base classes. That can easily be solved with the argument to create_test_cases(), e.g. ``def create_test_cases(*bases_classes): ... class PyTest(*(base_classes + [unittest.TestCase])): pass``. > This is also not so uncommon. I think the skip on the accelerated > version might not be necessary in some situations. > Then don't use this approach. It doesn't have to apply to every single test class in a module. It just needs to help in the simple case. > > IOW we have to trade between compactness, flexibility, and readability, > and trying to improve one side will likely make other aspects worse. > There is no trade-off. Either you can use this approach or you simply don't and use the slightly longer form. This doesn't mean the current approach we use can't continued to be used, just that the simple case can be made really simple. > I don't think there would be any problem at grouping the two > import_fresh_module() in a single call that returns the two modules though. And that can still be a useful thing for the class; for test modules whose needs are simply too complicated then the instantiated instance can be nothing more than a streamlined way of getting at both modules. > (I would also avoid the use of pep399 in the names -- it's not really > readable unless you can map pep numbers with their titles.) I came up with the name on the fly when I could think of anything better in 5 seconds. =) I assumed a different name would be used if this approached was decided upon and went into test.support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 00:19:38 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 23:19:38 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359328778.56.0.811398519782.issue17037@psf.upfronthosting.co.za> Ezio Melotti added the comment: >> This is also not so uncommon. I think the skip on the accelerated >> version might not be necessary in some situations. > >Then don't use this approach. It doesn't have to apply to every single >test class in a module. It just needs to help in the simple case. What I was trying to say is that since the special cases are not so uncommon, we might not have many simple cases where this idiom could be used to save a few lines, and we will end up with two different idioms for the same thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 00:52:19 2013 From: report at bugs.python.org (Gili T.) Date: Sun, 27 Jan 2013 23:52:19 +0000 Subject: [issue17056] Support Visual Studio 2012 Message-ID: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za> New submission from Gili T.: msvc9compiler needs to check for the VS110COMNTOOLS environment variable in order to support Visual Studio 2012. Currently it complains "cannot find vcvarsall.bat". The following workaround works for now: SET VS90COMNTOOLS=%VS110COMNTOOLS% ---------- components: Build messages: 180808 nosy: cowwoc priority: normal severity: normal status: open title: Support Visual Studio 2012 type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 00:54:34 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 27 Jan 2013 23:54:34 +0000 Subject: [issue17056] Support Visual Studio 2012 In-Reply-To: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za> Message-ID: <1359330874.95.0.0634887948048.issue17056@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Windows nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 00:59:54 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 27 Jan 2013 23:59:54 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359331194.09.0.490530692775.issue17037@psf.upfronthosting.co.za> Brett Cannon added the comment: To prevent speculation, the files that mention import_fresh_module are: # Without changes to test classes Lib/test/test_bisect.py: would work if you made the attribute configurable (e.g. self.module instead of self.bisect Lib/test/test_heapq.py: would work Lib/test/test_warnings.py: would work if you made the attribute configurable # With minor changes to test classes Lib/test/json_tests/__init__.py: would work if you took out the function accessing shortcuts (e.g. self.json.loads instead of self.loads) Lib/test/test_functools.py: would work if you took out the function accessing shortcuts # Won't work Lib/test/test_datetime.py: has its own crazy version of this approach (although it sounds like part of it is because of problem with import_fresh_module and other things that might need to be fixed) Lib/test/test_decimal.py: won't work because of fractions modules Lib/test/test_xml_etree.py: doctest-based Lib/test/test_xml_etree_c.py: specific to accelerated version # Doesn't apply Lib/test/support.py: because it defines it =) Lib/test/test_bz2.py: used in a single test method Lib/test/test_importlib/test_api.py: used in a single test Lib/test/test_support.py: obvious =) So out of 9 test modules it will work with 5 of them (2 with either search-and-replace changes to the test code or making the proposed solution more flexible) and not w/ 4 (or 3 if you don't count the etree tests as separate, and the test_datetime seems weird as to why it's so complicated based on the comments in the code). So overall it still seems like a win to me, especially if we keep adding more test modules that need this approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 01:08:29 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 00:08:29 +0000 Subject: [issue17056] Support Visual Studio 2012 In-Reply-To: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za> Message-ID: <1359331709.16.0.968787781548.issue17056@psf.upfronthosting.co.za> Brian Curtin added the comment: This change can only happen on 3.4. ---------- versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 01:10:41 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 28 Jan 2013 00:10:41 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359331841.35.0.12751088186.issue17037@psf.upfronthosting.co.za> Brett Cannon added the comment: I took a closer look at test_datetime and it probably should be using this approach, but because the tests seemed to have been copied from Zope the tests were left as-is and instead the testing approach we have been using was actually forced upon the test module instead of datetime. So it would probably work with some work to refactor the code to use it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 01:24:17 2013 From: report at bugs.python.org (Hobs) Date: Mon, 28 Jan 2013 00:24:17 +0000 Subject: [issue17057] Data model documentation grammar Message-ID: <1359332657.03.0.048046509713.issue17057@psf.upfronthosting.co.za> New submission from Hobs: New-style and old-style class expalanation in the datamodel section has minor grammatical errors and one minor ambiguity that could be improved. http://docs.python.org/2/reference/datamodel.html#new-style-and-classic-classes * "independently of" should always be "indepenent of" * single hyphens (-) should be double-hyphens (--) for an m-dash * "flavour" should be "flavor" (used 100x more often in docs.python) * "only the symantics of..." is ambiguous. can't tell if 'only' modifies 'symantics' or 'new-style classes'? ---------- assignee: docs at python components: Documentation files: datamodel-reference-docs.patch keywords: patch messages: 180812 nosy: Hobson.Lane, docs at python priority: normal severity: normal status: open title: Data model documentation grammar type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file28876/datamodel-reference-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 01:29:18 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 28 Jan 2013 00:29:18 +0000 Subject: [issue16743] mmap on Windows can mishandle files larger than sys.maxsize In-Reply-To: <1359318477.47.0.805246672259.issue16743@psf.upfronthosting.co.za> Message-ID: <5105C64C.7090706@gmail.com> Richard Oudkerk added the comment: On 27/01/2013 8:27pm, Terry J. Reedy wrote: > I agree we do not need to retain unpredictable 'dumb luck' -- in > future versions. But in the absence of a clear discrepancy > between doc and behavior (the definition of a bug) I believe > breaking such code in a bugfix release would be contrary to > current policy. Currently if you mmap a file with length 4GB+1, then you get an mmap of length 1. Surely that is a *huge* discrepancy between docs and behaviour. BTW, on 32 bit Windows it looks like the maximum size one can mmap in practice is about 1.1GB: PS> python -c "import mmap; m = mmap.mmap(-1, int(1.1*1024**3))" PS> python -c "import mmap; m = mmap.mmap(-1, int(1.2*1024**3))" Traceback (most recent call last): File "", line 1, in WindowsError: [Error 8] Not enough storage is available to process this command ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 01:33:05 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 28 Jan 2013 00:33:05 +0000 Subject: [issue16743] mmap on Windows can mishandle files larger than sys.maxsize In-Reply-To: <1359320784.56.0.432918283375.issue16743@psf.upfronthosting.co.za> Message-ID: <5105C730.30809@gmail.com> Richard Oudkerk added the comment: On 27/01/2013 9:06pm, Serhiy Storchaka wrote: > Every bugfix breaks some code. As a compromise I propose set > m_obj->size = PY_SSIZE_T_MAX in case of overflow and emit a warning. Trying to allocate PY_SSIZE_T_MAX bytes always seems to fail with WindowsError: [Error 8] Not enough storage is available to process this command ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 01:50:13 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 28 Jan 2013 00:50:13 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359334213.94.0.784320444688.issue17037@psf.upfronthosting.co.za> Ezio Melotti added the comment: Some of the exceptions among the modules you listed are: Lib/test/test_warnings.py:420 has a class specific for the C module. Lib/test/json_tests/test_dump.py:34 has an additional test specific for the C module. Lib/test/json_tests/test_speedups.py is specific for the C module. Lib/test/test_functools.py:199 is specific to the Python module. Lib/test/test_functools.py:207 different tests depending on the version. Unless these additional methods are defined separately and somehow added to the two classes returned by pep399_tests.create_test_cases(ExampleTest), it would be necessary to create additional classes using the current idiom and then get the modules from pep399_tests.cmodule/pep399_tests.pycmodule, e.g.: # the two "normal" tests TestPyDump, TestCDump = pep399_tests.create_test_cases(DumpTest) # the additional test for the C module @unittest.skipUnless(pep399_tests.cmodule, 'requires _json') class TestCDump2(unittest.TestCase) module = pep399_tests.cmodule @bigmemtest(size=_1G, memuse=1) def test_large_list(self, size): ... FWIW I won't change the json tests, because I already wrote them in a way that most of the code is defined in __init__.py and shared in all the other test files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 02:00:14 2013 From: report at bugs.python.org (Gili T.) Date: Mon, 28 Jan 2013 01:00:14 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 Message-ID: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> New submission from Gili T.: Python keeps on crashing with error: The following repro steps are a slight variation of http://packages.python.org/RhodeCode/setup.html. My installation environment is Windows 7, 64-bit, Visual Studio 2012. I doubt the bug is specific to this environment but I'm providing it as a point of reference. This issue is 100% reproducible for me: 1. Install Python 2.7.3, 64-bit 2. Download https://raw.github.com/pypa/virtualenv/master/virtualenv.py 3. From a VS2012 64-bit command-prompt, run "python virtualenv c:\users\\documents\rhodecode" 4. "cd \users\\documents\rhodecode" 5. "scripts\activate" 6. "pip install rhodecode" 7. "paster make-config RhodeCode production.ini" 8. "paster setup-rhodecode production.ini" 9. You need to point at a directory that contains at least one Mercurial repository. Code will output: [...] 2013-01-27 19:51:05,855 INFO sqlalchemy.engine.base.Engine () 2013-01-27 19:51:05.861 INFO [rhodecode.model.scm] scanning for repositories in C:\Users\Gili\Documents\MercurialRepositories The thread 0x3b4 has exited with code -1073740777 (0xc0000417). The thread 0x1bfc has exited with code -1073740777 (0xc0000417). The thread 0x39c has exited with code -1073740777 (0xc0000417). The thread 0x1fcc has exited with code -1073740777 (0xc0000417). The program '[1260] python.exe' has exited with code -1073740777 (0xc0000417). and crash. The stack-trace is: > msvcr90.dll!0000000071059f64() Unknown msvcr90.dll!00000000710551ec() Unknown msvcr90.dll!00000000710552d4() Unknown msvcr90.dll!000000007104f335() Unknown python27.dll!000000001e0a89f9() Unknown python27.dll!000000001e0a8c0e() Unknown python27.dll!000000001e0a9379() Unknown osutil.pyd!000007fefc62176f() Unknown python27.dll!000000001e0c0966() Unknown python27.dll!000000001e110484() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e10eba9() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e0b2553() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e099211() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e0e02be() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e10fc7b() Unknown python27.dll!000000001e11052a() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e0b2553() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e099211() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e0e086e() Unknown python27.dll!000000001e0dd5e6() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e10fc7b() Unknown python27.dll!000000001e11052a() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e10eba9() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e0b2553() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e099211() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e0e086e() Unknown python27.dll!000000001e0dd5e6() Unknown python27.dll!000000001e08adf5() Unknown python27.dll!000000001e10fc7b() Unknown python27.dll!000000001e11052a() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e10eba9() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e10eba9() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e10eb38() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e10eba9() Unknown python27.dll!000000001e110514() Unknown python27.dll!000000001e113c34() Unknown python27.dll!000000001e115439() Unknown python27.dll!000000001e1154d9() Unknown python27.dll!000000001e14166a() Unknown python27.dll!000000001e14295a() Unknown python27.dll!000000001e142f9a() Unknown python27.dll!000000001e1439c3() Unknown python27.dll!000000001e0443c0() Unknown python.exe!000000001d00119e() Unknown kernel32.dll!000000007746652d() Unknown ntdll.dll!0000000077a5c521() Unknown There is no known workaround. ---------- components: Windows messages: 180816 nosy: cowwoc priority: normal severity: normal status: open title: Python crashes with error 0xc0000417 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 02:00:16 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 28 Jan 2013 01:00:16 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359334816.34.0.344705318949.issue17037@psf.upfronthosting.co.za> Eli Bendersky added the comment: etree's doctest tests are a painful relic of the past, which will hopefully go away one day (issue #15083), at which point conformance to PEP 399 shouldn't be an issue. More generally, and this applies to etree's test too, a lot of trouble is being caused by pickle (see etree's tests and decimals's tests). If we're on a way to actually commit a decorator for PEP 399, perhaps this issue can somehow be addressed in a generic manner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 02:31:49 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 28 Jan 2013 01:31:49 +0000 Subject: [issue16743] mmap on Windows can mishandle files larger than sys.maxsize In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za> Message-ID: <1359336709.69.0.879421987526.issue16743@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I missed the Ngb+1 case in your previous answer and agree that this is a bug issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 02:50:02 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 28 Jan 2013 01:50:02 +0000 Subject: [issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za> Message-ID: <1359337802.02.0.514190642243.issue13997@psf.upfronthosting.co.za> Nick Coghlan added the comment: Include a couple of "See Also" links out to my essay and Ned's article and that sounds good to me. (Assuming I've adjusted the DNS settings correctly, this alternate URL for my essay should start working soon: http://python-notes.curiousefficiency.org/en/latest/python3/text_file_processing.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 03:16:25 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 28 Jan 2013 02:16:25 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1359339385.07.0.352074316334.issue4153@psf.upfronthosting.co.za> Ezio Melotti added the comment: As discussed in #13997, the HOWTO should be reorganized to start with a basic introduction and then expand on more advanced topic. See also msg180743 for a couple of essays that could be linked as "see also" or integrated in the HOWTO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 03:20:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 28 Jan 2013 02:20:15 +0000 Subject: [issue13997] Clearly explain the bare minimum Python 3 users should know about Unicode In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za> Message-ID: <1359339615.47.0.255399981167.issue13997@psf.upfronthosting.co.za> Ezio Melotti added the comment: OK, I'm going to close this then. I'll take a look at the links and see if what they say can be included in the HOWTO. As I mentioned in an earlier post I made a few talks about Unicode and encodings, so I will take some material from there too. Depending on the final result we can then decide if and what additional links are necessary. ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> Unicode HOWTO up to date? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 04:06:08 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 28 Jan 2013 03:06:08 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359342368.84.0.183508012602.issue16997@psf.upfronthosting.co.za> Chris Jerdonek added the comment: After thinking about this more, it seems this lets you do two orthogonal things: 1. Easily append data to failure messages coming from a block of asserts 2. Continue running a test case after a failure from a block of asserts Both of these seem independently useful and more generally applicable, so it seems worth discussing them in isolation before exposing them only together. Maybe there is a nice API or combination of API's that lets you do one or the other or both. Also, for (1) above, I'm wondering about the choice to put the extra data in the id/shortDescription of a pseudo-TestCase instead of just adding it to the exception message, for example. Adding it to the message seems more consistent with unittest's current API. Including the info in a new name/id seems potentially to be misusing the concept of TestCase because the test names created from this API need not be unique, and the resulting tests are not addressable/runnable. Incidentally, I noticed that the runnability of TestCases was removed from the documentation in an unreviewed change shortly after the last patch was posted: -An instance of a :class:`TestCase`\ -derived class is an object that can -completely run a single test method, together with optional set-up and tidy-up -code. (from http://hg.python.org/cpython/rev/d1e6a48dfb0d#l1.111 ) whereas subtest TestCases from the last patch are not runnable: +class _SubTest(TestCase): + ... + def runTest(self): + raise NotImplementedError("subtests cannot be run directly") A way around these issues would be to pass the original, runnable TestCase object to TestResult.errors, etc. instead of a pseudo-TestCase. Alternatively, subtests could be made independently addressable and runnable, but that route seems more challenging and less certain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 04:16:35 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 28 Jan 2013 03:16:35 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359342995.46.0.617052757181.issue17058@psf.upfronthosting.co.za> R. David Murray added the comment: Is VS2012 actually involved in anything here? Does something get compiled when you install rhodecode? Since it is a third party package, it may be that no one here will volunteer to reproduce this (though it is possible). If you can isolate the failure more, that would be a big help. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 04:50:01 2013 From: report at bugs.python.org (Damian) Date: Mon, 28 Jan 2013 03:50:01 +0000 Subject: [issue17059] tarfile.is_tarfile without read permissions raises AttributeError Message-ID: <1359345001.7.0.483862840582.issue17059@psf.upfronthosting.co.za> New submission from Damian: Hi. While porting a library of mine from python 2.7 to 3.2 I noticed that tarfile.is_tarfile() now raises an AttributeError rather than IOError when it lacks read permissions... atagar at morrigan:~$ touch dummy_file.tar atagar at morrigan:~$ chmod 000 dummy_file.tar atagar at morrigan:~$ pwd /home/atagar atagar at morrigan:~$ python Python 2.7.1+ (r271:86832, Sep 27 2012, 21:16:52) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import tarfile >>> tarfile.is_tarfile("/home/atagar/dummy_file.tar") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/tarfile.py", line 2583, in is_tarfile t = open(name) File "/usr/lib/python2.7/tarfile.py", line 1658, in open return func(name, "r", fileobj, **kwargs) File "/usr/lib/python2.7/tarfile.py", line 1720, in gzopen fileobj = bltn_open(name, mode + "b") IOError: [Errno 13] Permission denied: '/home/atagar/dummy_file.tar' atagar at morrigan:~$ python3 Python 3.2 (r32:88445, Oct 20 2012, 14:09:50) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import tarfile >>> tarfile.is_tarfile("/home/atagar/dummy_file.tar") Traceback (most recent call last): File "/usr/lib/python3.2/tarfile.py", line 1805, in gzopen fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj) File "/usr/lib/python3.2/gzip.py", line 157, in __init__ fileobj = self.myfileobj = builtins.open(filename, mode or 'rb') IOError: [Errno 13] Permission denied: '/home/atagar/dummy_file.tar' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.2/tarfile.py", line 2593, in is_tarfile t = open(name) File "/usr/lib/python3.2/tarfile.py", line 1739, in open return func(name, "r", fileobj, **kwargs) File "/usr/lib/python3.2/tarfile.py", line 1809, in gzopen fileobj.close() AttributeError: 'NoneType' object has no attribute 'close' >>> try: ... tarfile.is_tarfile("/home/atagar/dummy_file.tar") ... except IOError: ... print("caught an IOError") ... except AttributeError: ... print("caught an AttributeError") ... caught an AttributeError ... easy to work around, but I suspect this wasn't intentional. :) ---------- components: None messages: 180824 nosy: atagar priority: normal severity: normal status: open title: tarfile.is_tarfile without read permissions raises AttributeError type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 05:28:16 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 28 Jan 2013 04:28:16 +0000 Subject: [issue17047] Fix double double words words In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za> Message-ID: <1359347296.59.0.705404095727.issue17047@psf.upfronthosting.co.za> ?ric Araujo added the comment: Note that sometimes duplicates are actually typos: in http://hg.python.org/cpython/rev/07488c3c85f1/#l4.1 for exemple I think the intent was to write ?that the? instead of ?the the?. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 06:52:35 2013 From: report at bugs.python.org (Gili T.) Date: Mon, 28 Jan 2013 05:52:35 +0000 Subject: [issue17056] Support Visual Studio 2012 In-Reply-To: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za> Message-ID: <1359352355.45.0.424855732278.issue17056@psf.upfronthosting.co.za> Gili T. added the comment: Why? :) I ask because all the application I depend upon only run against Python 2.x (Rhodecode, Mercurial, etc). I'd love for them to upgrade but it's not really in my control. Has there been some sort of policy change within Python to stop supporting 2.x? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 06:55:24 2013 From: report at bugs.python.org (Gili T.) Date: Mon, 28 Jan 2013 05:55:24 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359352524.85.0.510825538679.issue17058@psf.upfronthosting.co.za> Gili T. added the comment: Yes, Visual Studio 2012 is used when installing Rhodecode. I'd love to isolate this further but I don't know anything about Python. I'm just an end-user of Rhodecode. I filed a bug report with the Rhodecode author (asking for help) but I think we can both agree this is actually a Python bug (python.exe is the one crashing). I try to reproduce this with Visual Studio 2010 if you are more comfortable with that environment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 06:55:46 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 05:55:46 +0000 Subject: [issue17056] Support Visual Studio 2012 In-Reply-To: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za> Message-ID: <1359352546.67.0.448446024343.issue17056@psf.upfronthosting.co.za> Brian Curtin added the comment: This is a feature request and new features are only being added on the 3.x line. The next feature release will be 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 07:06:33 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 06:06:33 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359353193.83.0.398159768407.issue17058@psf.upfronthosting.co.za> Brian Curtin added the comment: You need to compile rhodecode with VS2008 to match Python 2.7. You'd have this same problem mixing runtimes regardless of rhodecode or Python being involved. ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 07:18:55 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 06:18:55 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359353935.14.0.166313476107.issue17058@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 07:22:59 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 06:22:59 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359354179.5.0.770089085853.issue17058@psf.upfronthosting.co.za> Brian Curtin added the comment: A more correct way to say my last message is that you'd need to have Python and rhodecode linked to the same runtime, by compiling with the same Visual Studio. If you require VS2012 with Python 2.7, you'll need to port Python on your own and then your setup would work. We can't accept your patch on #17056, so you'd have to do the work to make 2.7 work with 2012 and maintain the patch yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 07:24:15 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 06:24:15 +0000 Subject: [issue17047] Fix double double words words In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za> Message-ID: <1359354255.86.0.522212685179.issue17047@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 07:33:06 2013 From: report at bugs.python.org (Gili T.) Date: Mon, 28 Jan 2013 06:33:06 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359354786.25.0.307134630767.issue17058@psf.upfronthosting.co.za> Gili T. added the comment: Hey Brian, I'm curious why mixing different versions of Visual Studio runtimes would result in a problem. I thought you can mix different runtimes so long as: 1. You link against a DLL (as opposed to static linking). 2. You use the same kind of library (debug vs release, 32-bit vs 64-bit). Meaning, if one project links against a 64-bit Release DLL from 2008 I expect it to interoperate fine with a 64-bit Release DLL from 2010. The DLL is supposed to be backwards compatible, is it not? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 07:39:29 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 06:39:29 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359355169.85.0.634204308542.issue17058@psf.upfronthosting.co.za> Brian Curtin added the comment: Passing CRT objects (like a file handle) across runtime boundaries results in unexpected behavior, which is probably what's happening here. In the past people have mentioned porting 2.7 to VS2010 which would encounter the same issues you're seeing here. Here's a link to that discussion: http://mail.python.org/pipermail/python-dev/2012-August/121406.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 07:53:47 2013 From: report at bugs.python.org (Gili T.) Date: Mon, 28 Jan 2013 06:53:47 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359356027.43.0.714476711247.issue17058@psf.upfronthosting.co.za> Gili T. added the comment: I read http://mail.python.org/pipermail/python-dev/2012-August/121460.html and I believe they are wrong. I have personally run into these problems (each library maintaining its own CRT with separate heaps, file handles, etc) when static linking was used, but when dynamic linking is used there is only one CRT instance and therefore you only end up with one heap, set of file handles, etc. I've never seen the kind of problems you're referring to if dynamic linking is used. My guess is that someone (Python or an extension) is using static linking which is causing these problems. Is that a reasonable assumption? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 08:01:45 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 07:01:45 +0000 Subject: [issue17058] Python crashes with error 0xc0000417 In-Reply-To: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za> Message-ID: <1359356505.78.0.770638238146.issue17058@psf.upfronthosting.co.za> Brian Curtin added the comment: Maybe you should email python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 08:36:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jan 2013 07:36:10 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359358570.93.0.363924806792.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > 1. Easily append data to failure messages coming from a block of asserts > 2. Continue running a test case after a failure from a block of asserts > Both of these seem independently useful and more generally applicable, I don't understand what you mean. 1 is pointless without 2 (if you let the exception bubble up, unittest already deals with it). 2 without 1 doesn't make much sense either (if you only want to silence an exception, a simple try...except will suffice). > I'm wondering about the choice to put the extra data in the > id/shortDescription of a pseudo-TestCase instead of just adding it to the > exception message, for example. Adding it to the message seems more > consistent with unittest's current API. If e.g. someone lists all failed tests without detailing the exception messages, it's better if subtests are disambiguished in that list. Also, changing the exception message might be confusing as readers expect the displayed message to be exactly str(exc). > Incidentally, I noticed that the runnability of TestCases was removed from > the documentation in an unreviewed change shortly after the last patch was > posted: runTest() is still mentioned in the TestCase constructor: http://docs.python.org/dev/library/unittest.html#unittest.TestCase but indeed it was removed from the module overview, because it doesn't correspond to modern unit testing practices. I guess it could still be covered in the API docs. > Alternatively, subtests could be made independently addressable and > runnable, but that route seems more challenging and less certain. I would say impossible, unless you know a way to run a `with` block in isolation ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 08:45:06 2013 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=) Date: Mon, 28 Jan 2013 07:45:06 +0000 Subject: [issue17055] ftplib.ftpcp test In-Reply-To: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za> Message-ID: <1359359106.44.0.407181130084.issue17055@psf.upfronthosting.co.za> Micha? Jastrz?bski added the comment: Hello, Well, I ran coverage.py over this module and it turns out that this method, ftpcp has neighter tests nor docs. Most of ftplib is tested, but this one function was not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 08:45:38 2013 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 28 Jan 2013 07:45:38 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <1359359138.55.0.412726567931.issue13886@psf.upfronthosting.co.za> Petri Lehtinen added the comment: - setlocale(LC_CTYPE, ""); + setlocale(LC_CTYPE, "C"); This looks dangerous to me. Are you sure readline's behavior doesn't change because of this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 09:06:12 2013 From: report at bugs.python.org (Daniel Cioata) Date: Mon, 28 Jan 2013 08:06:12 +0000 Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za> Message-ID: <1359360372.2.0.567765170546.issue15273@psf.upfronthosting.co.za> Daniel Cioata added the comment: a solution for this issue ---------- nosy: +Daniel.Cioata Added file: http://bugs.python.org/file28877/submitted_patch_Issue15273 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 09:47:07 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 28 Jan 2013 08:47:07 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359362827.9.0.743077181396.issue16997@psf.upfronthosting.co.za> Nick Coghlan added the comment: Right, if you want independently addressable/runnable, then you're back to parameterised tests as discussed in issue7897. What I like about Antoine's subtest idea is that I think it can be used to split the execution/reporting part of parameterised testing from the addressing/selection part. That is, while *this* patch doesn't make subtests addressable, a future enhancement or third party test runner could likely do so. (It wouldn't work with arbitrary subtests, it would only be for data driven variants like those described in issue7897) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 10:03:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 09:03:45 +0000 Subject: [issue17054] cStringIO.StringIO aborted when more then INT_MAX bytes written In-Reply-To: <1359318825.63.0.912749070119.issue17054@psf.upfronthosting.co.za> Message-ID: <1359363825.2.0.0368140620651.issue17054@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed. ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> cStringIO not 64-bit safe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 10:04:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 09:04:30 +0000 Subject: [issue13555] cPickle MemoryError when loading large file (while pickle works) In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za> Message-ID: <1359363870.12.0.67668800283.issue13555@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +cStringIO not 64-bit safe -cStringIO.StringIO aborted when more then INT_MAX bytes written _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 10:06:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 09:06:45 +0000 Subject: [issue7358] cStringIO not 64-bit safe In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za> Message-ID: <1359364005.12.0.290613962572.issue7358@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka components: +Extension Modules, IO -Library (Lib) nosy: +serhiy.storchaka stage: -> needs patch versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 10:17:44 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 28 Jan 2013 09:17:44 +0000 Subject: [issue17060] IDLE -- jump to home should not go past the PS1 and PS2 prompts Message-ID: <1359364664.26.0.133025400757.issue17060@psf.upfronthosting.co.za> New submission from Raymond Hettinger: In IDLE's shell, pressing or currently jumps to the beginning of a line. Instead it should stop *after* the ">>> " prompt. ---------- components: IDLE messages: 180841 nosy: rhettinger priority: normal severity: normal status: open title: IDLE -- jump to home should not go past the PS1 and PS2 prompts type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 10:18:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 09:18:09 +0000 Subject: [issue17059] tarfile.is_tarfile without read permissions raises AttributeError In-Reply-To: <1359345001.7.0.483862840582.issue17059@psf.upfronthosting.co.za> Message-ID: <1359364689.19.0.0654856858718.issue17059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for the report, Damian. This was fixed in issue11513. ---------- assignee: -> serhiy.storchaka components: +Library (Lib) -None nosy: +serhiy.storchaka resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 10:39:32 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 28 Jan 2013 09:39:32 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1359365972.3.0.387921483111.issue13590@psf.upfronthosting.co.za> Ned Deily added the comment: Attached are the back ports to 2.7.x and 3.2.x of the Xcode 4 support changes as released in 3.3.0. I've built and tested both with various configurations on a variety of systems, both Intel and PPC, and various OS X versions (10.4, 10.5, 10.6, 10.7, and 10.8), including all of the standard installer configurations. I also tested with just the standalone Command Line Tools package (for 10.7 and 10.8). With these back ports, extension module builds should once again work out of the box on all supported systems with their most recent versions of Xcode or Command Line Tools. Unless there are objections, I'll commit these in the next day or two for 2.7.4 and 3.2.4. ---------- stage: needs patch -> commit review Added file: http://bugs.python.org/file28878/issue13590_backport_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 10:39:56 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 28 Jan 2013 09:39:56 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1359365996.21.0.460989639575.issue13590@psf.upfronthosting.co.za> Changes by Ned Deily : Added file: http://bugs.python.org/file28879/issue13590_backport_32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 11:54:14 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 28 Jan 2013 10:54:14 +0000 Subject: [issue12691] tokenize.untokenize is broken In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za> Message-ID: <1359370454.01.0.964824587448.issue12691@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Is there anything I can do to push this forwards? I'm trying to use tokenize and untokenize in IPython, and for now I'm going to have to maintain our own copies of it (for Python 2 and 3), because I keep running into problems with the standard library module. ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:11:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 11:11:35 +0000 Subject: [issue7358] cStringIO not 64-bit safe In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za> Message-ID: <1359371495.02.0.703394726081.issue7358@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file28880/cStringIO64.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:14:28 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 28 Jan 2013 11:14:28 +0000 Subject: [issue17061] tokenize unconditionally emits NL after comment lines & blank lines Message-ID: <1359371668.59.0.445577508897.issue17061@psf.upfronthosting.co.za> New submission from Thomas Kluyver: The docs describe the NL token as "Token value used to indicate a non-terminating newline. The NEWLINE token indicates the end of a logical line of Python code; NL tokens are generated when a logical line of code is continued over multiple physical lines." However, after a comment or a blank line, tokenize emits NL, even when it's not inside a multi-line statement. For example: In [15]: for tok in tokenize.generate_tokens(StringIO('#comment\n').readline): print(tok) TokenInfo(type=54 (COMMENT), string='#comment', start=(1, 0), end=(1, 8), line='#comment\n') TokenInfo(type=55 (NL), string='\n', start=(1, 8), end=(1, 9), line='#comment\n') TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='') This makes it difficult to use tokenize to detect multi-line statements, as we want to do in IPython. In my tests so far, changing two instances of NL to NEWLINE in this block (lines 530 & 533) makes it behave as I expect: http://hg.python.org/cpython/file/a375c3d88c7e/Lib/tokenize.py#l524 ---------- messages: 180846 nosy: takluyver priority: normal severity: normal status: open title: tokenize unconditionally emits NL after comment lines & blank lines versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:17:08 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 28 Jan 2013 11:17:08 +0000 Subject: [issue17062] An os.walk inspired replacement for pkgutil.walk_packages Message-ID: <1359371828.89.0.768628623008.issue17062@psf.upfronthosting.co.za> New submission from Nick Coghlan: I recently had occasion to use pkgutil.walk_packages, and my immediate thought was that it would have been a lot easier for me to use if it worked more like os.walk with topdown=True, producing tuples of (pkg, subpackages, modules) "pkg" would be the package object at the current level (None for the top level) "packages" would be a dictionary mapping fully qualified module names to loader objects for the subpackages (i.e. subdirectories) "modules" would be a dictionary mapping fully qualified module names to loader objects for every submodule that wasn't a subpackage As with editing the "subdirs" list with os.walk, editing the "packages" dictionary with this new API would keep the iterator from loading that subpackage and avoid recursing into it (this is the part I wanted in my current use case). (This may even be PEP material, guiding some additions to the importer/finder API) ---------- components: Library (Lib) messages: 180847 nosy: ncoghlan priority: normal severity: normal status: open title: An os.walk inspired replacement for pkgutil.walk_packages versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:30:01 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 28 Jan 2013 11:30:01 +0000 Subject: [issue17062] An os.walk inspired replacement for pkgutil.walk_packages In-Reply-To: <1359371828.89.0.768628623008.issue17062@psf.upfronthosting.co.za> Message-ID: <1359372601.0.0.540434667301.issue17062@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, forgot the proposed call signature: def walk_path(path=None, *, pkg=None): """Walk a package hierarchy, starting with the given path Iterator producing (package, subpackages, submodules) triples. The first entry is the package currently being walked, or None for the top level path. The subpackages and submodules entries are dictionaries mapping from fully qualified module names to the appropriate module loaders. Entries may be removed from the subpackages dictionary to avoid loading those packages and recursing into them. If both pkg and path are None, walks sys.path If path is not None, walks the specified path. If pkg is not None, walks pkg.__path__ Providing both path and pkg results in ValueError """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:34:18 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 28 Jan 2013 11:34:18 +0000 Subject: [issue17062] An os.walk inspired replacement for pkgutil.walk_packages In-Reply-To: <1359371828.89.0.768628623008.issue17062@psf.upfronthosting.co.za> Message-ID: <1359372858.24.0.307119178153.issue17062@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regarding the PEP comment - the piece that would be missing is the "iter_modules" functionality. Currently pkgutil provides the support for standard filesystem imports and zipimports directly - the generic function based extension mechanism is undocumented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:36:24 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 28 Jan 2013 11:36:24 +0000 Subject: [issue14302] Rename Scripts directory to bin and move python.exe to bin In-Reply-To: <1331742575.57.0.919941207524.issue14302@psf.upfronthosting.co.za> Message-ID: <1359372984.4.0.960554062919.issue14302@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:38:10 2013 From: report at bugs.python.org (Michael Foord) Date: Mon, 28 Jan 2013 11:38:10 +0000 Subject: [issue17052] unittest discovery should use self.testLoader In-Reply-To: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za> Message-ID: <1359373090.63.0.798278803638.issue17052@psf.upfronthosting.co.za> Michael Foord added the comment: I think you're correct - although I wonder if *anyone*, *ever* will be helped by the change. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:40:05 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 28 Jan 2013 11:40:05 +0000 Subject: [issue12520] spurious output in test_warnings In-Reply-To: <1310162087.96.0.0645657657853.issue12520@psf.upfronthosting.co.za> Message-ID: <1359373205.93.0.832502994305.issue12520@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:42:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 11:42:17 +0000 Subject: [issue17062] An os.walk inspired replacement for pkgutil.walk_packages In-Reply-To: <1359371828.89.0.768628623008.issue17062@psf.upfronthosting.co.za> Message-ID: <1359373337.51.0.449442753514.issue17062@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:47:28 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 28 Jan 2013 11:47:28 +0000 Subject: [issue17052] unittest discovery should use self.testLoader In-Reply-To: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za> Message-ID: <1359373648.05.0.289982805505.issue17052@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I will at least! :) I noticed the issue after trying to use unittest test discovery with a custom loader. Fortunately, there is at least this work-around (though it relies on an implementation detail): class MyTestProgram(unittest.TestProgram): # Override because of issue #17052. def _do_discovery(self, argv, Loader=None): if Loader is None: Loader = lambda: self.testLoader super(TestPizza, self)._do_discovery(argv, Loader=Loader) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:50:36 2013 From: report at bugs.python.org (Trent Nelson) Date: Mon, 28 Jan 2013 11:50:36 +0000 Subject: [issue5289] ctypes.util.find_library does not work under Solaris In-Reply-To: <1234858635.81.0.426092533899.issue5289@psf.upfronthosting.co.za> Message-ID: <1359373836.37.0.0890571011464.issue5289@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 12:51:54 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 28 Jan 2013 11:51:54 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1359373914.51.0.772217587077.issue15933@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 13:50:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jan 2013 12:50:20 +0000 Subject: [issue17063] assert_called_with could be more powerful if it allowed placeholders Message-ID: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za> New submission from Antoine Pitrou: assert_called_with currently compares every argument for equality, which is not very practical when one of the arguments is a complex object, of which you only want to check certain properties. It could be very nice if you could write e.g.: from mock import Mock, PLACEHOLDER ... my_mock(1, someobj(), bar=someotherobj()): foo, bar = my_mock.assert_called_with( 1, PLACEHOLDER, bar=PLACEHOLDER) self.assertIsInstance(bar, someobj) self.assertIsInstance(foo, someotherobj) (another name for PLACEHOLDER could be CAPTURE, regex-style :-)) ---------- messages: 180852 nosy: michael.foord, pitrou priority: normal severity: normal status: open title: assert_called_with could be more powerful if it allowed placeholders type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 14:19:41 2013 From: report at bugs.python.org (Michael Foord) Date: Mon, 28 Jan 2013 13:19:41 +0000 Subject: [issue17063] assert_called_with could be more powerful if it allowed placeholders In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za> Message-ID: <1359379181.17.0.380018542743.issue17063@psf.upfronthosting.co.za> Michael Foord added the comment: You mean like mock.ANY ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 14:21:14 2013 From: report at bugs.python.org (Michael Foord) Date: Mon, 28 Jan 2013 13:21:14 +0000 Subject: [issue17063] assert_called_with could be more powerful if it allowed placeholders In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za> Message-ID: <1359379274.48.0.366854241287.issue17063@psf.upfronthosting.co.za> Michael Foord added the comment: Oh, you want the assert_called_with call to *return* the objects compared with the placeholder? Well, mock.ANY already exists and you can pull the arguments out for individual assertions using some_mock.call_args. args, kwargs = some_mock.call_args ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 14:29:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 13:29:44 +0000 Subject: [issue16335] Integer overflow in unicode-escape decoder In-Reply-To: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za> Message-ID: <1359379784.36.0.87726449307.issue16335@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 14:57:34 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jan 2013 13:57:34 +0000 Subject: [issue17063] assert_called_with could be more powerful if it allowed placeholders In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za> Message-ID: <1359381454.03.0.497658830515.issue17063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, well... I agree mock.ANY sounds cool :-) Perhaps it could be mentioned in the docs for assert_etc.? Otherwise you only learn about it if you are masochistic enough to read the doc till the end :-) > you can pull the arguments out for individual assertions using > some_mock.call_args. Yeah, but it's cumbersome and it boils down to doing the matching by hand, while assert_called_something already does it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 15:03:14 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jan 2013 14:03:14 +0000 Subject: [issue17063] assert_called_with could be more powerful if it allowed placeholders In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za> Message-ID: <1359381794.24.0.35466581477.issue17063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm noticing that with multiple ANY keyword arguments, the order in the result tuple is undefined. So perhaps ANY could be instantiable in those cases where disambiguation is required: foo, bar = my_mock.assert_called_with(1, foo=ANY(0), bar=ANY(1)) self.assertIsInstance(bar, someobj) self.assertIsInstance(foo, someotherobj) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 15:20:52 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 14:20:52 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() In-Reply-To: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za> Message-ID: <1359382852.61.0.210728828907.issue16979@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ezio, is it a good factorization? def check(self, coder): def checker(input, expect): self.assertEqual(coder(input), (expect, len(input))) return checker def test_escape_decode(self): decode = codecs.unicode_escape_decode check = self.check(decode) check(b"[\\\n]", "[]") check(br'[\"]', '["]') check(br"[\']", "[']") #?other 20 checks ... And same for test_escape_encode and for bytes escape decoder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 15:46:56 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 28 Jan 2013 14:46:56 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1359384416.84.0.0908158531302.issue13994@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Does this still need to block 2.7.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 15:51:51 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 28 Jan 2013 14:51:51 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359384711.26.0.999962935747.issue17037@psf.upfronthosting.co.za> Brett Cannon added the comment: True, the current idiom needs to still be used in those cases, although we could introduce another method to help with this situation as well: # Could also be named use_accelerator to be less hostile-sounding. def requires_accelerator(self, cls): if self.accelerated_module is None: raise SkipTest # With proper message else: setattr(cls, self.module_name, self.accelerated_module) return cls Then the idiom becomes: @pep399_tests.requires_accelerator class AcceleratorSpecificTests(unittest.TestCase): pass This then extends out to also the current idiom if you don't want to have any "magical" classes: @pep399_tests.requires_accelerator class AcceleratedExampleTests(unittest.TestCase): pass # Can add another decorator for this if desired. class PyExampleTests(unittest.TestCase): module = pep399_tests.py_module This also has the benefit of extracting out the module attribute name to minimize messing even that up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 16:29:40 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 28 Jan 2013 15:29:40 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1359386980.88.0.032556908403.issue16968@psf.upfronthosting.co.za> Zachary Ware added the comment: Thank you, Chris. I'm rather ashamed of how long I've spent beating my head on this issue and missed the spare tests reference in runtest_inner. Simply removing the "tests" name entirely clears things up, if this isn't too ugly: diff -r 5f655369ef06 Lib/test/regrtest.py --- a/Lib/test/regrtest.py Mon Jan 28 13:27:02 2013 +0200 +++ b/Lib/test/regrtest.py Mon Jan 28 08:50:59 2013 -0600 @@ -1275,8 +1275,8 @@ # tests. If not, use normal unittest test loading. test_runner = getattr(the_module, "test_main", None) if test_runner is None: - tests = unittest.TestLoader().loadTestsFromModule(the_module) - test_runner = lambda: support.run_unittest(tests) + test_runner = lambda: support.run_unittest( + unittest.TestLoader().loadTestsFromModule(the_module)) test_runner() if huntrleaks: refleak = dash_R(the_module, test, test_runner, As far as the reap_threads wrapper and reap_children follow-up, I think the TestSuite subclass and load_tests function in the last patch I uploaded may be about the simplest way to keep them for this test without adding them to all tests (by adding it to regrtest.runtest_inner). If anyone thinks the 'ReapedSuite' class (or a better named copy) could be useful elsewhere, it might could go in test.support which would make test_concurrent_futures look a little cleaner. Patch v3 is v2 plus the regrtest change inline above. ---------- Added file: http://bugs.python.org/file28881/test_concurrent_futures_discovery.v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 17:31:25 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 28 Jan 2013 16:31:25 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1359390685.36.0.223447546157.issue13994@psf.upfronthosting.co.za> ?ric Araujo added the comment: 2.7.3 broke some setup scripts, it wouldn?t be bad to fix this in 2.7.4. I?ll make time before RC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 18:10:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 17:10:14 +0000 Subject: [issue13539] Return value missing in calendar.TimeEncoding.__enter__ In-Reply-To: <1323176871.81.0.567417111906.issue13539@psf.upfronthosting.co.za> Message-ID: <1359393014.14.0.353323733951.issue13539@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate stage: test needed -> committed/rejected status: open -> closed superseder: -> calendar throws UnicodeEncodeError when locale is specified _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 18:11:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 17:11:18 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified In-Reply-To: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> Message-ID: <1359393078.55.0.662407043105.issue17049@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +JJeffries, Retro, christian.heimes, eric.araujo, georg.brandl, haypo, ixokai, psam, r.david.murray, tim.golden, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 18:14:19 2013 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 28 Jan 2013 17:14:19 +0000 Subject: [issue17064] Fix sporadic buildbot failures for test_mailbox Message-ID: <1359393259.56.0.519558675211.issue17064@psf.upfronthosting.co.za> New submission from Jeremy Kloth: Attached is an attempt at fixing the sporadic failures of test_mailbox on the AMD64 Windows buildbot. It fails due to access errors on some directories which leads me to believe the helper functions in test.support should fix the problem. ---------- components: Tests files: test_mailbox.diff keywords: patch messages: 180862 nosy: jkloth priority: normal severity: normal status: open title: Fix sporadic buildbot failures for test_mailbox versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file28882/test_mailbox.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 18:19:06 2013 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 28 Jan 2013 17:19:06 +0000 Subject: [issue17065] Fix sporadic buildbot failures for test_winreg Message-ID: <1359393546.73.0.336232098313.issue17065@psf.upfronthosting.co.za> New submission from Jeremy Kloth: test_winreg fails sporadically on the AMD64 Windows buildbot. Looking at the test, it appears that concurrent runs of the test would fail if different processes attempted to modify the test key at the same time. The attached patch resolves this by using a per-process unique test key name using the process ID. ---------- components: Tests files: test_winreg.diff keywords: patch messages: 180863 nosy: jkloth priority: normal severity: normal status: open title: Fix sporadic buildbot failures for test_winreg versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file28883/test_winreg.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 18:27:09 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 28 Jan 2013 17:27:09 +0000 Subject: [issue17064] Fix sporadic buildbot failures for test_mailbox In-Reply-To: <1359393259.56.0.519558675211.issue17064@psf.upfronthosting.co.za> Message-ID: <1359394029.5.0.236900437439.issue17064@psf.upfronthosting.co.za> R. David Murray added the comment: I think the support functions just ignore errors. Isn't this going to continue to leave garbage on the buildbot filesystem without fixing the underlying problem? I wonder if this is a variation on the usual Windows access errors, in which case perhaps that is the best we can do... ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 18:42:24 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 28 Jan 2013 17:42:24 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified In-Reply-To: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> Message-ID: <1359394944.72.0.538678295048.issue17049@psf.upfronthosting.co.za> Georg Brandl added the comment: Serhiy: not sure why all those people belong in the nosy list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 18:46:56 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 17:46:56 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified In-Reply-To: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> Message-ID: <1359395216.97.0.426189904462.issue17049@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: They moved from issue13539 which I?have closed as a duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 18:51:11 2013 From: report at bugs.python.org (Michael Foord) Date: Mon, 28 Jan 2013 17:51:11 +0000 Subject: [issue17063] assert_called_with could be more powerful if it allowed placeholders In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za> Message-ID: <1359395471.14.0.859198297399.issue17063@psf.upfronthosting.co.za> Michael Foord added the comment: Yes there are definitely room for documentation improvements. And, yes - pulling the args out from some_mock.call_args "boils down to doing the matching by hand". You only do it when you *want* to do the matching by hand. Your use case I would write: from mock import Mock, ANY ... my_mock(1, someobj(), bar=someotherobj()) my_mock.assert_called_with(1, ANY, bar=ANY) args, kwargs = my_mock.call_args foo = args[1] bar = kwargs['bar'] self.assertIsInstance(bar, someobj) self.assertIsInstance(foo, someotherobj) It's a *little* cumbersome, but not something I do very often and not much extra code. I'm not sure that having "assert_called_with" return objects is an intuitive API either. (And having to specify tuple indices in a call to ANY is a bit odd too.) Custom matchers that do the comparison in their __eq__ method would be another possibility: class IsInstance(object): def __init__(self, Type): self.Type = Type def __eq__(self, other): return isinstance(other, self.Type) my_mock.assert_called_with(1, IsInstance(someobj), bar=IsInstance(someotherobj)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:00:24 2013 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 28 Jan 2013 18:00:24 +0000 Subject: [issue17064] Fix sporadic buildbot failures for test_mailbox In-Reply-To: <1359393259.56.0.519558675211.issue17064@psf.upfronthosting.co.za> Message-ID: <1359396024.88.0.151688960702.issue17064@psf.upfronthosting.co.za> Jeremy Kloth added the comment: Actually, the support functions (as of 3.3) attempt to work around the access errors. They attempt to wait (to a point) for a successful operation before returning to the caller. See issue15496 for details. It is usually the case that the previous operation has not yet finished as to the cause of the access error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:22:50 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Jan 2013 18:22:50 +0000 Subject: [issue17051] Memory leak in os.path.isdir under Windows In-Reply-To: <1359277856.16.0.886323650341.issue17051@psf.upfronthosting.co.za> Message-ID: <3Yvzj51RjrzSN1@mail.python.org> Roundup Robot added the comment: New changeset 4deb294ff567 by Serhiy Storchaka in branch '2.7': Issue #17051: Fix a memory leak in os.path.isdir()?on Windows. Patch by Robert Xiao. http://hg.python.org/cpython/rev/4deb294ff567 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:25:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 18:25:27 +0000 Subject: [issue17051] Memory leak in os.path.isdir under Windows In-Reply-To: <1359277856.16.0.886323650341.issue17051@psf.upfronthosting.co.za> Message-ID: <1359397527.68.0.959879341202.issue17051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed. Thank you for patch. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:26:45 2013 From: report at bugs.python.org (Zack Weinberg) Date: Mon, 28 Jan 2013 18:26:45 +0000 Subject: [issue16624] subprocess.check_output should allow specifying stdin as a string In-Reply-To: <1354748057.02.0.623269532787.issue16624@psf.upfronthosting.co.za> Message-ID: <1359397605.96.0.739993642931.issue16624@psf.upfronthosting.co.za> Zack Weinberg added the comment: Contributor agreement resent by email. Sorry for the delay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:29:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Jan 2013 18:29:21 +0000 Subject: [issue17051] Memory leak in os.path.isdir under Windows In-Reply-To: <1359277856.16.0.886323650341.issue17051@psf.upfronthosting.co.za> Message-ID: <3Yvzrc3dyTzRMh@mail.python.org> Roundup Robot added the comment: New changeset 51173aba06eb by Serhiy Storchaka in branch '2.7': Add Robert Xiao to Misc/ACKS for issue17051. http://hg.python.org/cpython/rev/51173aba06eb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:29:55 2013 From: report at bugs.python.org (=?utf-8?b?RsOhYmlvIE0uIENvc3Rh?=) Date: Mon, 28 Jan 2013 18:29:55 +0000 Subject: [issue4590] 2to3 strips trailing L for long iterals in two fixers In-Reply-To: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za> Message-ID: <1359397795.64.0.0411920735819.issue4590@psf.upfronthosting.co.za> F?bio M. Costa added the comment: I believe that since this change the 2to3 documentation is outdated. http://docs.python.org/2/library/2to3.html#2to3fixer-long http://docs.python.org/2/library/2to3.html#2to3fixer-numliterals http://docs.python.org/3/library/2to3.html#2to3fixer-long http://docs.python.org/3/library/2to3.html#2to3fixer-numliterals They could be updated to something like this: long Renames long to int. Check `numliterals` if you want to strip the L suffix on long literals. numliterals Converts octal and long literals into the new syntax. Sorry if this is not the right channel to send documentation bug reports. ---------- nosy: +fabiomcosta versions: +Python 2.7 -3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:41:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 18:41:17 +0000 Subject: [issue17065] Fix sporadic buildbot failures for test_winreg In-Reply-To: <1359393546.73.0.336232098313.issue17065@psf.upfronthosting.co.za> Message-ID: <1359398477.15.0.544897383227.issue17065@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Windows nosy: +brian.curtin, stutzbach stage: -> patch review type: -> behavior versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:43:07 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 18:43:07 +0000 Subject: [issue17065] Fix sporadic buildbot failures for test_winreg In-Reply-To: <1359393546.73.0.336232098313.issue17065@psf.upfronthosting.co.za> Message-ID: <1359398587.39.0.73639729328.issue17065@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- assignee: -> brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 19:43:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Jan 2013 18:43:48 +0000 Subject: [issue16971] Refleaks in charmap decoder In-Reply-To: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za> Message-ID: <1359398628.36.0.26012634169.issue16971@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 20:30:36 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 28 Jan 2013 19:30:36 +0000 Subject: [issue17051] Memory leak in os.path.isdir under Windows In-Reply-To: <1359277856.16.0.886323650341.issue17051@psf.upfronthosting.co.za> Message-ID: <1359401436.33.0.969267092988.issue17051@psf.upfronthosting.co.za> Brian Curtin added the comment: Robert, thanks a lot for this fix and your contributor agreement. We're currently working on making it easier to submit the contributor agreement so you won't have to print it out and mail/fax/scan it...even though you already did it and you're now covered :) ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 20:34:29 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 28 Jan 2013 19:34:29 +0000 Subject: [issue17064] Fix sporadic buildbot failures for test_mailbox In-Reply-To: <1359393259.56.0.519558675211.issue17064@psf.upfronthosting.co.za> Message-ID: <1359401669.29.0.678643612077.issue17064@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, excellent. I had missed that change. This looks good then. Hopefully it will work :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 20:37:24 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 28 Jan 2013 19:37:24 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1359401844.48.0.31379314868.issue16968@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Whichever solution you pick for the "test" issue, I would at least add a code comment explaining that the test return value needs to be garbage collected and why, etc. and probably reference this issue. > If anyone thinks the 'ReapedSuite' class (or a better named copy) could be useful elsewhere, Can you look at some of the other test modules' test_main() functions to see if the same pattern is used there (or look at other uses of reap_children(), etc)? Then we would know what would be useful elsewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 20:48:07 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 28 Jan 2013 19:48:07 +0000 Subject: [issue16935] unittest should understand SkipTest at import time during test discovery In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za> Message-ID: <1359402487.19.0.847089122119.issue16935@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a patch that I believe nicely handles the raising of unittest.SkipTest at module level while doing test discovery. It adds a _make_skipped_test function to unittest.loader, and an ``except case.SkipTest`` clause to TestLoader._find_tests. For our own test package, this covers non-enabled resources as well. Here's some example output: """ P:\cpython>python -m unittest discover -v Lib/test/ "test_curs*" test_curses (unittest.loader.ModuleSkipped) ... skipped "Use of the 'curses' res ource not enabled" ---------------------------------------------------------------------- Ran 1 test in 0.001s OK (skipped=1) [102289 refs, 38970 blocks] """ ---------- keywords: +patch Added file: http://bugs.python.org/file28884/issue16935.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 21:32:51 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 28 Jan 2013 20:32:51 +0000 Subject: [issue17066] Fix test discovery for test_robotparser.py Message-ID: <1359405171.11.0.463426342019.issue17066@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's a fix for test_robotparser.py. With this patch, the command 'python -m unittest discover Lib/test/ "test_*.py"' can actually be run--before the patch, test_robotparser's unique TestCase subclass causes unexpected errors for discovery. ---------- components: Tests files: test_robotparser_discovery.diff keywords: patch messages: 180878 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_robotparser.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28885/test_robotparser_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 21:46:25 2013 From: report at bugs.python.org (Eric Snow) Date: Mon, 28 Jan 2013 20:46:25 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359405985.08.0.998509788926.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: +1 to where Brett's taking this. I really like having the PEP399Tests class encapsulating the various boilerplate parts, with some of them as methods, rather than trying to pack them all into one all-powerful decorator. It would be worth raising an exception in ``pep399_tests.create_test_cases(ExampleTest)`` if ExampleTest inherits from unittest.TestCase. This is a simple thing that would help people get it right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 21:50:11 2013 From: report at bugs.python.org (Eric Snow) Date: Mon, 28 Jan 2013 20:50:11 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359406211.85.0.445413297744.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: FWIW, here's a little more explanation on my original thoughts, none of which I'm married to. Most of the magic in my patch came messing with the globals (swap out the module and module attrs; add in the two new classes; ditch the original class). That was a consequence of my remaining objectives. I was also following the lead of decorators by having the the boilerplate before the test case definition rather than split up before and after. Finally, I was trying to do it in a way that existing test cases, like TestOrderedDict, would need as little changes as possible. This leads to one bit of boilerplate that I'm not a fan of: the whole self. thing. For TestOrderedDict, it meant changing all uses of an OrderedDict global to self.collections.OrderedDict. In fact, that was essentially the biggest motivation for the "magic" in the decorator. However, I can live with the boilerplate--I'll just deal with the search-and-replace (not the end of the world). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 21:55:32 2013 From: report at bugs.python.org (Eric Snow) Date: Mon, 28 Jan 2013 20:55:32 +0000 Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za> Message-ID: <1359406532.42.0.668462987598.issue17037@psf.upfronthosting.co.za> Eric Snow added the comment: +1 on requires_accelerator(). It could also be used for individual test methods. Similar decorators-as-methods could be added later, where appropriate, for other special cases, like handling the pickle situation described in #16817. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 22:15:46 2013 From: report at bugs.python.org (Carsten Klein) Date: Mon, 28 Jan 2013 21:15:46 +0000 Subject: [issue17067] Examples in documentation for 3.x in 23.1.3.4. Deferred translations are rather weak Message-ID: <1359407746.0.0.0107296426233.issue17067@psf.upfronthosting.co.za> New submission from Carsten Klein: The examples for the topic presented are rather weak. In fact, they merely present do nothing replacements for an actually working, deferred localization mechanism or some sort of prototypical implementation thereof. As such I propose that they be replaced with something more meaningful, for example such as class DeferredTranslation(object): def __init__(self, message, ...): self.message = message def __str__(self): return gettext.translation(...).lgettext(self.message) def _(message, ...): return DeferredTranslation(message, ...) MSG = _('localized message') Or something else along that way other than the currently presented examples :D ---------- assignee: docs at python components: Documentation messages: 180882 nosy: carsten.klein at axn-software.de, docs at python priority: normal severity: normal status: open title: Examples in documentation for 3.x in 23.1.3.4. Deferred translations are rather weak type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 22:22:28 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 28 Jan 2013 21:22:28 +0000 Subject: [issue17063] assert_called_with could be more powerful if it allowed placeholders In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za> Message-ID: <1359408148.32.0.921570671349.issue17063@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 23:00:14 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 28 Jan 2013 22:00:14 +0000 Subject: [issue17067] Examples in documentation for 3.x in 23.1.3.4. Deferred translations are rather weak In-Reply-To: <1359407746.0.0.0107296426233.issue17067@psf.upfronthosting.co.za> Message-ID: <1359410414.84.0.129664893665.issue17067@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for your suggestion, but... The example currently in the docs is exactly how we do deferred translation in the project I am currently working on. Your example is much more complex, and I don't see the benefit of it. Specifically, using the example in the docs you can easily mix deferred translations with non-deferred translations, which what you generally end up wanting to do in real code. (You use deferred translation with strings that are defined at import time, as in the example, and non-deferred with strings that are computed at runtime.) Perhaps there is a need for additional text about how this works in practice, including an example of switching the language dynamically during runtime. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 23:01:28 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 28 Jan 2013 22:01:28 +0000 Subject: [issue17067] Examples in documentation for 3.x in 23.1.3.4. Deferred translations are rather weak In-Reply-To: <1359407746.0.0.0107296426233.issue17067@psf.upfronthosting.co.za> Message-ID: <1359410488.48.0.0227126596872.issue17067@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I didn't mean "computed at runtime", I meant defined in code where the _ call is *executed* at runtime, rather than at import time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 23:19:04 2013 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 28 Jan 2013 22:19:04 +0000 Subject: [issue17068] peephole optimization for constant strings Message-ID: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za> New submission from Neal Norwitz: I was looking through code like this: foo = '%s%s%s' % ('https://', host, uri) and realized this could be rewritten by the interpreter as: foo = 'https://%s%s' % (host, uri) I tried to determine how much code this might affect, but it was pretty hard for me to come up with a decent regex to filter out all the false positives. There were too many hits to determine if this would be used often. ---------- components: Interpreter Core messages: 180885 nosy: nnorwitz priority: normal severity: normal status: open title: peephole optimization for constant strings type: performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 23:28:52 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jan 2013 22:28:52 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1359412132.69.0.0216663337414.issue17015@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Proof-of-concept patch. mock is ugly! ---------- keywords: +patch Added file: http://bugs.python.org/file28886/issue17015.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 28 23:39:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jan 2013 22:39:40 +0000 Subject: [issue17068] peephole optimization for constant strings In-Reply-To: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za> Message-ID: <1359412780.63.0.678099983851.issue17068@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 00:15:50 2013 From: report at bugs.python.org (Sandro Mani) Date: Mon, 28 Jan 2013 23:15:50 +0000 Subject: [issue16754] Incorrect shared library extension on linux In-Reply-To: <1356266166.76.0.178044154393.issue16754@psf.upfronthosting.co.za> Message-ID: <1359414950.29.0.779076388305.issue16754@psf.upfronthosting.co.za> Sandro Mani added the comment: So, from what I can see, historically the SO extension was taken from sysconfig.py, see [1] lines 24 and 60. Then, the CCompiler class got overhauled, and the value was hardcoded to ".so", see [2], but the "compiler.shared_lib_extension = SO" statement remained, presumably oversight. So technically, this is also affecting python 2.x, though in that case it does not make any difference, since python2 does not use versioned so-names for binary modules. [1] http://hg.python.org/cpython/file/2802fb52e99b/Lib/distutils/unixccompiler.py [2] http://hg.python.org/cpython/rev/7922d08426ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 00:30:10 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Jan 2013 23:30:10 +0000 Subject: [issue4590] 2to3 strips trailing L for long iterals in two fixers In-Reply-To: <1228734557.43.0.0269801825175.issue4590@psf.upfronthosting.co.za> Message-ID: <3Yw6Wj18xFzSKX@mail.python.org> Roundup Robot added the comment: New changeset d5ee6d13af18 by Benjamin Peterson in branch '3.3': fix long fixer docs (#4590) http://hg.python.org/cpython/rev/d5ee6d13af18 New changeset 8b9910d8d27f by Benjamin Peterson in branch 'default': merge 3.3 (#4590) http://hg.python.org/cpython/rev/8b9910d8d27f New changeset 6904e229833d by Benjamin Peterson in branch '2.7': fix long fixer docs (#4590) http://hg.python.org/cpython/rev/6904e229833d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 00:36:37 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 28 Jan 2013 23:36:37 +0000 Subject: [issue16509] sqlite3 docs do not explain check_same_thread In-Reply-To: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za> Message-ID: <1359416197.88.0.376711854533.issue16509@psf.upfronthosting.co.za> Changes by Thomas Kluyver : ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 01:09:11 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 00:09:11 +0000 Subject: [issue17068] peephole optimization for constant strings In-Reply-To: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za> Message-ID: <1359418151.88.0.124646642163.issue17068@psf.upfronthosting.co.za> STINNER Victor added the comment: > and realized this could be rewritten by the interpreter as: Yeah, it could but it's tricky to implement it. The current peephole is implemented in C. You may first try to implement it using my astoptimizer project which is implemented in Python. At least to check if it's possible or not :-) https://bitbucket.org/haypo/astoptimizer astoptimizer only optimizes str%args if it succeed at compile time, so if all arguments are constant and no error is raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 01:33:37 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 29 Jan 2013 00:33:37 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() In-Reply-To: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za> Message-ID: <1359419617.97.0.847285146571.issue16979@psf.upfronthosting.co.za> Ezio Melotti added the comment: LGTM. If you want to push it even further you could make a list of (input, expected) and call the check() in a loop. That way it will also be easier to refactor if/when we add subtests (#16997). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 02:47:58 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 29 Jan 2013 01:47:58 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359424078.82.0.423308773055.issue16997@psf.upfronthosting.co.za> Chris Jerdonek added the comment: >> 1. Easily append data to failure messages coming from a block of asserts >> 2. Continue running a test case after a failure from a block of asserts > >> Both of these seem independently useful and more generally applicable, > > I don't understand what you mean. 1 is pointless without 2 (if you let the exception bubble up, unittest already deals with it). 2 without 1 doesn't make much sense either (if you only want to silence an exception, a simple try...except will suffice). I'll explain. (1) is useful without (2) because it lets you add information to the failure data for a group of asserts without having to use the "msg" parameter in every call to assert(). This is useful, for example, if you're testing a number of cases in a loop (with the current behavior of ending the test on first failure), and it's not clear from the default exception message which iteration of the loop failed. Your original example is such a case (minus the part about continuing in case of failure). This use case is basically the one addressed by Serhiy's suggestion in this message: http://bugs.python.org/issue16997#msg180225 (2) is useful without (1) if you'd like to get information about more than one assertion failure in a TestCase (just as in your proposal), but the assertions aren't necessarily coming from a "parametrization" or different iterations of a loop. With the proposed API, you'd do something like: with self.subTest(): # First assertion ... with self.subTest(): # Second assertion ... The difference here is that I wouldn't call these "subtests," and you don't need parameter data to know which assertion is at fault. The meaning here is more like "with self.continueTesting()". > Also, changing the exception message might be confusing as readers expect the displayed message to be exactly str(exc). If the API is more like self.assert*()'s "msg" parameter which appends data to the usual exception, then it will be the same as what people are already used to. Also see the "longMessage" attribute (which defaults to True), which separates the extra message data from the default exception message: http://docs.python.org/dev/library/unittest.html#unittest.TestCase.longMessage >> Alternatively, subtests could be made independently addressable and >> runnable, but that route seems more challenging and less certain. > > I would say impossible, unless you know a way to run a `with` block in isolation ;-) I'm not advocating independent addressability/runnability of subtests or the following approach, but a naive way to do this would be to run the TestCase as usual, but skip over any subTest blocks if the parameter data isn't an exact match. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 06:34:27 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 29 Jan 2013 05:34:27 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1359437667.77.0.155243400378.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: I now divided and regrouped the FAQs in two sections, one "for everyone" and one "for core developers". I'm not sure what to do with the "long-term development of features" section. One one hand I would prefer to move it away from committing.rst, but on the other hand it's a bit too long to be a single FAQ. For now I left it there, but it could also be moved to the faq.rst page and possibly be broken in different subsections or separate FAQs. I think what I have done so far can be committed, even though there are more improvements to do -- but those can be done later, so they shouldn't block this. Please review the commits on bitbucket, and if they are OK I will collapse them and apply the resulting patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 08:20:56 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 07:20:56 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359444056.72.0.753810384808.issue16997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > If the API is more like self.assert*()'s "msg" parameter which appends > data to the usual exception, then it will be the same as what people > are already used to. It might be a good idea to allow both this and the arbitrary parameter kwargs, then. > I'm not advocating independent addressability/runnability of subtests > or the following approach, but a naive way to do this would be to run > the TestCase as usual, but skip over any subTest blocks if the > parameter data isn't an exact match. Well, I still don't know how to skip a `with` block (short of raising an exception that will terminate the entire test). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 09:19:51 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Jan 2013 08:19:51 +0000 Subject: [issue14018] OS X installer does not detect bad symlinks created by Xcode 3.2.6 In-Reply-To: <1329267688.42.0.5159808393.issue14018@psf.upfronthosting.co.za> Message-ID: <3YwLGt6xXhzS7J@mail.python.org> Roundup Robot added the comment: New changeset c2830debb15a by Ned Deily in branch '2.7': Issue #14018: Backport OS X installer updates from 3.3. http://hg.python.org/cpython/rev/c2830debb15a New changeset d54330c8daaa by Ned Deily in branch '3.2': Issue #14018: Backport OS X installer updates from 3.3. http://hg.python.org/cpython/rev/d54330c8daaa New changeset 6e6a76166c47 by Ned Deily in branch '3.3': Issue #14018: merge to 3.3 http://hg.python.org/cpython/rev/6e6a76166c47 New changeset 888590641c49 by Ned Deily in branch 'default': Issue #14018: merge to default http://hg.python.org/cpython/rev/888590641c49 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 09:40:24 2013 From: report at bugs.python.org (Thomas Heller) Date: Tue, 29 Jan 2013 08:40:24 +0000 Subject: [issue17028] launcher does not read shebang line when arguments are given In-Reply-To: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za> Message-ID: <1359448824.91.0.927200222455.issue17028@psf.upfronthosting.co.za> Thomas Heller added the comment: Hope it is ok to assign this to you, vinay. ---------- assignee: -> vinay.sajip nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 09:53:08 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Jan 2013 08:53:08 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() In-Reply-To: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za> Message-ID: <3YwM1H3hMyzSL5@mail.python.org> Roundup Robot added the comment: New changeset a242ac99161f by Serhiy Storchaka in branch '2.7': Issue #16979: Fix error handling bugs in the unicode-escape-decode decoder. http://hg.python.org/cpython/rev/a242ac99161f New changeset 084bec5443d6 by Serhiy Storchaka in branch '3.2': Issue #16979: Fix error handling bugs in the unicode-escape-decode decoder. http://hg.python.org/cpython/rev/084bec5443d6 New changeset 086defaf16fe by Serhiy Storchaka in branch '3.3': Issue #16979: Fix error handling bugs in the unicode-escape-decode decoder. http://hg.python.org/cpython/rev/086defaf16fe New changeset 218da678bb8b by Serhiy Storchaka in branch 'default': Issue #16979: Fix error handling bugs in the unicode-escape-decode decoder. http://hg.python.org/cpython/rev/218da678bb8b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 10:48:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 09:48:12 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() In-Reply-To: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za> Message-ID: <1359452892.42.0.0429237137639.issue16979@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Until subtests added an explicit call looks better to me. And when subtests will be added we will just add subtest inside the helper function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 10:49:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 09:49:57 +0000 Subject: [issue16980] SystemError in codecs.unicode_escape_decode() In-Reply-To: <1358343747.58.0.471745996102.issue16980@psf.upfronthosting.co.za> Message-ID: <1359452997.47.0.363017641702.issue16980@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 10:50:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 09:50:51 +0000 Subject: [issue16979] Broken error handling in codecs.unicode_escape_decode() In-Reply-To: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za> Message-ID: <1359453051.63.0.846610113572.issue16979@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 10:53:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 09:53:49 +0000 Subject: [issue16975] Broken error handling in codecs.escape_decode() In-Reply-To: <1358286171.54.0.132780688137.issue16975@psf.upfronthosting.co.za> Message-ID: <1359453229.26.0.512419332149.issue16975@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 11:17:54 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Jan 2013 10:17:54 +0000 Subject: [issue16971] Refleaks in charmap decoder In-Reply-To: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za> Message-ID: <3YwNv60TPRzNrc@mail.python.org> Roundup Robot added the comment: New changeset 625c397a7283 by Serhiy Storchaka in branch '3.3': Issue #16971: Fix a refleak in the charmap decoder. http://hg.python.org/cpython/rev/625c397a7283 New changeset 02c4ecc87f74 by Serhiy Storchaka in branch 'default': Issue #16971: Fix a refleak in the charmap decoder. http://hg.python.org/cpython/rev/02c4ecc87f74 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 11:18:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 10:18:47 +0000 Subject: [issue16971] Refleaks in charmap decoder In-Reply-To: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za> Message-ID: <1359454727.92.0.922916505006.issue16971@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 11:54:02 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Jan 2013 10:54:02 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359456842.18.0.31006974491.issue16997@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like the idea of the subTest API being something like: def subTest(self, _id, *, **params): However, I'd still factor that in to the reported test ID, not into the exception message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 12:29:17 2013 From: report at bugs.python.org (Tuure Laurinolli) Date: Tue, 29 Jan 2013 11:29:17 +0000 Subject: [issue17069] HTTP result code in urllib2.urlopen() file object undocumented Message-ID: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za> New submission from Tuure Laurinolli: As per documentation at http://docs.python.org/2/library/urllib2.html the file-like object returned by urllib2.urlopen() should have methods geturl() and info(). It actually also has getcode(), which appears to do the same as getcode() on urllib.urlopen() responses. This should be a documented feature of urllib2. ---------- components: Library (Lib) messages: 180900 nosy: tazle priority: normal severity: normal status: open title: HTTP result code in urllib2.urlopen() file object undocumented versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 12:31:35 2013 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 29 Jan 2013 11:31:35 +0000 Subject: [issue12707] Deprecate addinfourl getters In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za> Message-ID: <1359459095.68.0.598075674476.issue12707@psf.upfronthosting.co.za> Petri Lehtinen added the comment: +1 for the documentation changes, which should be applied to 2.7 as well. The deprecation is the only thing to go to 3.4 only, if it's done at all. ---------- nosy: +petri.lehtinen versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 12:43:40 2013 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 29 Jan 2013 11:43:40 +0000 Subject: [issue12707] Deprecate addinfourl getters In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za> Message-ID: <1359459820.85.0.766146290718.issue12707@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Also note that getcode() is already documented in urllib (not urllib2) documentation: http://docs.python.org/2/library/urllib.html#urllib.urlopen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 13:54:36 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 12:54:36 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359464076.87.0.916380468214.issue17036@psf.upfronthosting.co.za> STINNER Victor added the comment: New patch: - sys.setdefaultcloexec() takes again an argument, so sys.setdefaultcloexec(False) is allowed - add cloexec parameter to select.devpoll(), select.kqueue() and select.epoll() - when a function accepts a file name and a file descriptor: the cloexec parameter is ignored if the argument is a file descriptor (it was already done for open(), but not for socket.socket on Windows) - revert enhancements using cloexec=True to simplify the patch: will be done in another issue - fix various bugs in error handling (close newly created file descriptors on error) - release the GIL when calling the os: os.urandom(), os.pipe(), os.dup(), etc. ---------- Added file: http://bugs.python.org/file28887/bc88690df059.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 13:56:35 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 12:56:35 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359464195.85.0.211385489409.issue17036@psf.upfronthosting.co.za> STINNER Victor added the comment: My TODO list is almost empty: the implementation is done. I just see possible enhancement on Windows: socket.socket() and os.dup() can use an atomic flag to set close-on-exec if native functions are used (WSASocket, DuplicateHandle) instead of the POSIX API. But it can be done later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:09:17 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:09:17 +0000 Subject: [issue17070] Use the new cloexec to improve security and avoid bugs Message-ID: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patches use the new cloexec parameter added by the PEP 433 (see issue #17036). cloexec_fs_walk.patch: [security] don't leak a file descriptors of directories to a child processes cloexec_listening_socket.patch: [security] don't leak a listening socket to child processes, see also #12107 cloexec_log_file.patch: [security] don't leak the file descriptor of a log file to child processes cloexec_subprocess.patch: [security/bugs] don't leak file descriptors to child processes cloexec_misc.patch: misc mmodules "security" is a strong word: if subprocess is called with close_fds=True, there is no such problem at all. It's more a theorical problem if a process is created in another thread without using the subprocess module (but directly low level functions). ---------- components: Library (Lib) files: cloexec_fs_walk.patch keywords: patch messages: 180905 nosy: haypo, neologix priority: normal severity: normal status: open title: Use the new cloexec to improve security and avoid bugs versions: Python 3.4 Added file: http://bugs.python.org/file28888/cloexec_fs_walk.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:09:23 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:09:23 +0000 Subject: [issue17070] Use the new cloexec to improve security and avoid bugs In-Reply-To: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za> Message-ID: <1359464963.82.0.932785727409.issue17070@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file28889/cloexec_listening_socket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:09:29 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:09:29 +0000 Subject: [issue17070] Use the new cloexec to improve security and avoid bugs In-Reply-To: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za> Message-ID: <1359464969.78.0.521793755068.issue17070@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file28890/cloexec_log_file.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:09:36 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:09:36 +0000 Subject: [issue17070] Use the new cloexec to improve security and avoid bugs In-Reply-To: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za> Message-ID: <1359464976.39.0.455199525104.issue17070@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file28891/cloexec_misc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:09:43 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:09:43 +0000 Subject: [issue17070] Use the new cloexec to improve security and avoid bugs In-Reply-To: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za> Message-ID: <1359464983.81.0.790151174655.issue17070@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file28892/cloexec_subprocess.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:10:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 13:10:10 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" Message-ID: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> New submission from Antoine Pitrou: >>> def f(a, self): pass ... >>> sig = inspect.signature(f) >>> sig.bind(1, 2) >>> sig.bind(a=1, self=2) Traceback (most recent call last): File "", line 1, in TypeError: bind() got multiple values for argument 'self' ---------- components: Library (Lib) messages: 180906 nosy: larry, pitrou, yselivanov priority: normal severity: normal status: open title: Signature.bind() fails with a keyword argument named "self" type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:10:26 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:10:26 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359465026.49.0.694725713173.issue17036@psf.upfronthosting.co.za> STINNER Victor added the comment: "revert enhancements using cloexec=True to simplify the patch: will be done in another issue" I just created the issue #17070 to track this task. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:10:35 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 13:10:35 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1359465035.92.0.00243617249375.issue17015@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- dependencies: +Signature.bind() fails with a keyword argument named "self" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:11:04 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:11:04 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" In-Reply-To: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> Message-ID: <1359465064.6.0.779969282874.issue17071@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:16:17 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:16:17 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359465026.49.0.694725713173.issue17036@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > My TODO list is almost empty Oh, I forgot one point: I stil don't know if the close-on-exec flag of file descriptors of pass_fds argument of subprocess.Popen should be set. If close-on-exec flag is set globally, it's not convinient to have to clear the flag manually on each file descriptor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:24:40 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:24:40 +0000 Subject: [issue17070] PEP 433: Use the new cloexec to improve security and avoid bugs In-Reply-To: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za> Message-ID: <1359465880.46.0.916163575686.issue17070@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Use the new cloexec to improve security and avoid bugs -> PEP 433: Use the new cloexec to improve security and avoid bugs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 14:26:50 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 13:26:50 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359466010.08.0.373065229796.issue17036@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file28837/9bdfa1a3ea8c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 16:08:38 2013 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 29 Jan 2013 15:08:38 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" In-Reply-To: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> Message-ID: <1359472118.82.0.00333919653314.issue17071@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'll take a look later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 16:17:03 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 15:17:03 +0000 Subject: [issue16946] subprocess: _close_open_fd_range_safe() does not set close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined In-Reply-To: <1358002453.56.0.227593845503.issue16946@psf.upfronthosting.co.za> Message-ID: <1359472623.57.0.87783565948.issue16946@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is fixed in my implementation of the PEP 433: see #17036. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 17:14:16 2013 From: report at bugs.python.org (Hakim Taklanti) Date: Tue, 29 Jan 2013 16:14:16 +0000 Subject: [issue17072] Decimal, quantize, round and negative value Message-ID: <1359476056.94.0.303954404669.issue17072@psf.upfronthosting.co.za> New submission from Hakim Taklanti: >>> from decimal import Decimal >>> from decimal import ROUND_UP, ROUND_DOWN >>> a = Decimal("-3.86") >>> b = Decimal("5.73") >>> a_up = a.quantize(Decimal(".1"), ROUND_UP) >>> a.quantize(Decimal(".1"), ROUND_UP) # -3.8 expected Decimal('-3.9') >>> a.quantize(Decimal(".1"), ROUND_DOWN) # -3.9 expected Decimal('-3.8') >>> b.quantize(Decimal(".1"), ROUND_UP) # Ok Decimal('5.8') >>> b.quantize(Decimal(".1"), ROUND_DOWN) # Ok Decimal('5.7') ---------- components: Library (Lib) messages: 180911 nosy: Hakim.Taklanti priority: normal severity: normal status: open title: Decimal, quantize, round and negative value versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 17:15:34 2013 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 29 Jan 2013 16:15:34 +0000 Subject: [issue17072] Decimal, quantize, round and negative value In-Reply-To: <1359476056.94.0.303954404669.issue17072@psf.upfronthosting.co.za> Message-ID: <1359476134.24.0.266239157867.issue17072@psf.upfronthosting.co.za> Mark Dickinson added the comment: Indeed, that looks wrong. I'll take a look. ---------- assignee: -> mark.dickinson nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 17:18:38 2013 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 29 Jan 2013 16:18:38 +0000 Subject: [issue17072] Decimal, quantize, round and negative value In-Reply-To: <1359476056.94.0.303954404669.issue17072@psf.upfronthosting.co.za> Message-ID: <1359476318.48.0.167982889405.issue17072@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sorry, I take that back. The behaviour is correct: ROUND_UP rounds away from zero; ROUND_DOWN towards zero. For rounding towards +/- infinity, you want ROUND_CEILING and ROUND_FLOOR: Python 2.7.3 |EPD 7.3-1 (32-bit)| (default, Apr 12 2012, 11:28:34) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "credits", "demo" or "enthought" for more information. >>> from decimal import * >>> a = Decimal("-3.86") >>> a.quantize(Decimal(".1"), ROUND_CEILING) Decimal('-3.8') >>> a.quantize(Decimal(".1"), ROUND_FLOOR) Decimal('-3.9') Closing as invalid. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 17:36:50 2013 From: report at bugs.python.org (Hakim Taklanti) Date: Tue, 29 Jan 2013 16:36:50 +0000 Subject: [issue17072] Decimal, quantize, round and negative value In-Reply-To: <1359476056.94.0.303954404669.issue17072@psf.upfronthosting.co.za> Message-ID: <1359477410.37.0.197437301219.issue17072@psf.upfronthosting.co.za> Hakim Taklanti added the comment: Indeed, perhaps to enhance the documentation. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 18:01:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 17:01:48 +0000 Subject: [issue17073] Integer overflow in sqlite module Message-ID: <1359478908.69.0.671503350697.issue17073@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The proposed patch fixes an integer overflow in such cases: 1. When an authorizer callback (registered with set_authorizer()) returns an integer which doesn't fit into C?int. Now integers out of C?int range interpreted as SQLITE_DENY (as any non-integer values). 2. When a callable used in create_collation() returns an integer which doesn't fit into C?int. Now all Python integers work. 3. When Python integer doesn't fit into SQLite INTEGER. Now overflow detected and an exception raised. 4. Now sqlite module built even when HAVE_LONG_LONG is not defined. ---------- components: Extension Modules messages: 180915 nosy: ghaering, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Integer overflow in sqlite module type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 18:06:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 17:06:31 +0000 Subject: [issue17073] Integer overflow in sqlite module In-Reply-To: <1359478908.69.0.671503350697.issue17073@psf.upfronthosting.co.za> Message-ID: <1359479191.94.0.388376307189.issue17073@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file28893/sqlite_int_overflow-2.7.patch Added file: http://bugs.python.org/file28894/sqlite_int_overflow-3.2.patch Added file: http://bugs.python.org/file28895/sqlite_int_overflow-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 18:16:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 17:16:54 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1359479814.65.0.405138063977.issue15989@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sqlite module part extracted to issue17073. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 18:50:11 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 29 Jan 2013 17:50:11 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1359481811.94.0.214494559845.issue16968@psf.upfronthosting.co.za> Zachary Ware added the comment: Right you are, Chris. v4 has a comment added to regrtest.runtest_inner pointing back to this issue. Also in v4, ReapedSuite has been moved to test.support. At least one other test module (test_pydoc) uses the same idiom as test_concurrent_futures, and so could use this suite for the same effect. Several others use at least one of reap_threads (or its component pieces) or reap_children in test_main, and I believe those could also use ReapedSuite for simplicity's sake. Used in its current form, it shouldn't cause any issues other than perhaps an extra couple of function calls. ---------- Added file: http://bugs.python.org/file28896/test_concurrent_futures_discovery.v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 18:57:50 2013 From: report at bugs.python.org (Zearin) Date: Tue, 29 Jan 2013 17:57:50 +0000 Subject: [issue17074] (docs) Consistent formatting of constants Message-ID: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za> New submission from Zearin: When reading the docs, I noticed that the capitalization and formatting of the Python constants ``True``, ``False``, and ``None`` were inconsistent. The attached patch contains a fix for all such occurrences under ``/Doc/library/``. (I **think** I correctly made the patch. I hardly ever make patches, so if I screwed up, let me know and I?ll see if I can get it right. ?) Parent commit: 9137e2d1c00c6906af206d1c9d217b15613bb1ed ---------- assignee: docs at python components: Documentation files: python_docs_constants.diff keywords: patch messages: 180918 nosy: docs at python, zearin priority: normal severity: normal status: open title: (docs) Consistent formatting of constants versions: Python 2.7 Added file: http://bugs.python.org/file28897/python_docs_constants.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 18:58:57 2013 From: report at bugs.python.org (Zearin) Date: Tue, 29 Jan 2013 17:58:57 +0000 Subject: [issue17074] (docs) Consistent formatting of constants In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za> Message-ID: <1359482337.47.0.21976302624.issue17074@psf.upfronthosting.co.za> Changes by Zearin : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:05:06 2013 From: report at bugs.python.org (Aaron Sherman) Date: Tue, 29 Jan 2013 18:05:06 +0000 Subject: [issue17075] logging documentation for library cleanup Message-ID: <1359482706.26.0.367132377172.issue17075@psf.upfronthosting.co.za> New submission from Aaron Sherman: This documentation states that libraries can turn off logging by adding a NullHandler: http://docs.python.org/2/howto/logging.html#configuring-logging-for-a-library This is not entirely true. It only holds true if the application which calls the library has not called basicConfig on the root logger. If it has, you get logs to both the root logger and the NullLogger, defeating the point of having added a NullLogger in the first place. The correct way for a library to silence log messages is to both set a NullHandler and set propagate to false. For an example of the behavior on the current docs, see: import logging import sys # Application configures its root logger logging.basicConfig(level=logging.DEBUG) # Library configures a NullLogger: logger = logging.getLogger('foo') logger.setLevel(logging.DEBUG) handler = logging.NullHandler() handler.setLevel(logging.DEBUG) logger.addHandler(handler) # Library then logs: logger.warning("BLAH") This example is not terribly interesting, but the more interesting example is when the library configures a real log handler (e.g. in order to create a separate security log in an authorization module). In this case, the log messages will be sent to both the file log and the root logger by default, as long as any part of the application has configured the root logger. IMHO, propagate should always be False for all new loggers, but at the very least the fact that it is True should be documented in the section on library logging... ---------- assignee: docs at python components: Documentation messages: 180919 nosy: ajs, docs at python priority: normal severity: normal status: open title: logging documentation for library cleanup type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:18:12 2013 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 29 Jan 2013 18:18:12 +0000 Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like NFS) Message-ID: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za> New submission from Thomas Wouters: The new xattr support in shutil causes shutil.copytree and shutil.copy2 to fail inelegantly on (source) filesystems that do not support xattrs (like NFS): # /home/twouters does not support xattrs >>> os.listxattr("/home/twouters/foo") Traceback (most recent call last): File "", line 1, in OSError: [Errno 95] Operation not supported: '/home/twouters/foo' >>> shutil.copytree("/home/twouters/spam", "/tmp/spam") Traceback (most recent call last): File "", line 1, in File "/home/twouters/gvs-pristine/python/Python-3.3.0/Lib/shutil.py", line 345, in copytree raise Error(errors) shutil.Error: [('/home/twouters/spam/ham', '/tmp/spam/ham', "[Errno 95] Operation not supported: '/home/twouters/spam/ham'"), ('/home/twouters/spam/eggs', '/tmp/spam/eggs', "[Errno 95] Operation not supported: '/home/twouters/spam/eggs'"), ('/home/twouters/spam', '/tmp/spam', "[Errno 95] Operation not supported: '/home/twouters/spam'")] (The actual files will have been copied, since xattr copies are done after everything else.) Interestingly shutil._copyxattr does try to cope with unsupported xattrs on the *target* filesystem (which seems like it might be a mistake to do, since it loses data), just not the original filesystem (which seems like a sensible thing instead): # /tmp does support xattrs >>> os.listxattr("/tmp/spam") [] >>> shutil.copytree("/tmp/spam", "/home/twouters/spam-new") '/home/twouters/spam-new' The attached patch fixes shutil._copyxattr to also ignore unsupported/empty xattrs (but not permission errors) on the source. (I'm not certain if errno.ENODATA can be expected from os.listxattr(), but internet searches suggest that some people think so, and I don't know what other meaning it could have.) ---------- files: shutil.patch keywords: needs review, patch messages: 180920 nosy: twouters priority: high severity: normal stage: patch review status: open title: shutil.copytree failing on xattr-less filesystems (like NFS) type: crash versions: Python 3.3 Added file: http://bugs.python.org/file28898/shutil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:22:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Jan 2013 18:22:39 +0000 Subject: [issue12004] PyZipFile.writepy gives internal error on syntax errors In-Reply-To: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za> Message-ID: <3YwbfQ4DT8zSXF@mail.python.org> Roundup Robot added the comment: New changeset 3a1ac42435f9 by Serhiy Storchaka in branch '3.2': Issue #12004: Fix an internal error in PyZipFile when writing an invalid http://hg.python.org/cpython/rev/3a1ac42435f9 New changeset 678320c7f63d by Serhiy Storchaka in branch '3.3': Issue #12004: Fix an internal error in PyZipFile when writing an invalid http://hg.python.org/cpython/rev/678320c7f63d New changeset e24fd2c35d27 by Serhiy Storchaka in branch 'default': Issue #12004: Fix an internal error in PyZipFile when writing an invalid http://hg.python.org/cpython/rev/e24fd2c35d27 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:27:56 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 29 Jan 2013 18:27:56 +0000 Subject: [issue17074] (docs) Consistent formatting of constants In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za> Message-ID: <1359484076.89.0.904596531521.issue17074@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This has already been proposed in issue 15580. By the way, you don't always want to replace "true" with ``True``. The former has a different connotation/meaning which is boolean true rather than the object True. ---------- nosy: +chris.jerdonek resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> fix True/False/None reST markup _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:28:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Jan 2013 18:28:31 +0000 Subject: [issue12004] PyZipFile.writepy gives internal error on syntax errors In-Reply-To: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za> Message-ID: <1359484111.1.0.0706990216942.issue12004@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for the patch. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:34:53 2013 From: report at bugs.python.org (Zearin) Date: Tue, 29 Jan 2013 18:34:53 +0000 Subject: [issue17074] (docs) Consistent formatting of constants In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za> Message-ID: <1359484493.52.0.591112119429.issue17074@psf.upfronthosting.co.za> Zearin added the comment: Ah; I did look for dupes, but didn?t find it. (So many issues?!) Thanks for pointing me in the right direction. > By the way, you don't always want to replace "true" with ``True``. The former has a different connotation/meaning which is boolean true = rather than the object True. Yes, I know. I went through all the occurrences one by one, and I tried to take that into account. *sigh* I guess it?s a moot point, now? ---- Got more to say on this subject, but I?ll do it in other issue. Take care! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:39:37 2013 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 29 Jan 2013 18:39:37 +0000 Subject: [issue17077] Fix test_tools hangs Message-ID: <1359484777.42.0.023750065374.issue17077@psf.upfronthosting.co.za> New submission from Jeremy Kloth: Attached is a patch to test_tools that gets it back to a run-able state. ---------- components: Tests files: test_tools.diff keywords: patch messages: 180925 nosy: jkloth, serhiy.storchaka priority: normal severity: normal status: open title: Fix test_tools hangs versions: Python 3.2 Added file: http://bugs.python.org/file28899/test_tools.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:43:55 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 18:43:55 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" In-Reply-To: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> Message-ID: <1359485035.45.0.00155959610072.issue17071@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file28900/sig_bind_self.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:45:01 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 29 Jan 2013 18:45:01 +0000 Subject: [issue17075] logging documentation for library cleanup In-Reply-To: <1359482706.26.0.367132377172.issue17075@psf.upfronthosting.co.za> Message-ID: <1359485101.24.0.00307093721047.issue17075@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > This documentation states that libraries can turn off logging by adding a NullHandler: I don't think that's what the documentation says. It says, "If for some reason you don?t want these messages printed *in the absence of any logging configuration* [my emphasis].... If the library user configures logging for application use, presumably that configuration will add some handlers, and if levels are suitably configured then logging calls made in library code will send output to those handlers, as normal." In other words, the documentation is acknowledging that logging won't get turned off if something else configures it. This is the same as what you say further on: > It only holds true if the application which calls the library has not called basicConfig on the root logger. If there's some other part of the documentation that says otherwise, can you include a direct quote in the comment so we know what words you are referencing? > The correct way for a library to silence log messages is to both set a NullHandler and set propagate to false. This doesn't sound like good practice to me and isn't what the current docs were trying to say. ---------- nosy: +chris.jerdonek, vinay.sajip status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:48:07 2013 From: report at bugs.python.org (Zearin) Date: Tue, 29 Jan 2013 18:48:07 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1359485287.28.0.154835908536.issue15580@psf.upfronthosting.co.za> Zearin added the comment: I recently attempted to enhance the documentation in #17074. While I wasn?t linking all occurrences of True/False/None, I did mark them up as ``True``/``False``/``None``. Additionally, I made sure that these were (when appropriate) capitalized. I really disagree with the refusal to accept this issue. Python is represented to the outside world through its documentation. As it is, there are inconsistencies in the capitalization and markup of constants. CONSTANTS! This isn?t exactly a nuanced part of the language. Constants are dead-easy to spot, and they?re dead-easy to fix. This issue is **low-hanging fruit**. **Consistency** is also one of Python?s core values. This is built right into the language itself --- as indentation-based scope. The patch by chris.jerdonek helps make the documentation more consistent. I could understand if this isn?t the type of work you like doing. If the inconsistency was identified, but no one was willing to do the work, **then** this might be considered an issue which ?cost[...] developer time that can better be spent elsewhere.? But that?s not the case. Chris has already done the work. It?s low-hanging fruit, it improves Python?s image to the outside world, and it noticeably improves the readability (and usability) of the documentation. **Please** reconsider accepting this patch. ---------- nosy: +zearin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:54:39 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 29 Jan 2013 18:54:39 +0000 Subject: [issue17074] (docs) Consistent formatting of constants In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za> Message-ID: <1359485679.07.0.368898881647.issue17074@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Yes, I know. I went through all the occurrences one by one, and I tried to take that into account. See issue 4945 for a discussion like this. Might be relevant to what you have in mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:57:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 18:57:02 +0000 Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like NFS) In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za> Message-ID: <1359485822.34.0.485183956396.issue17076@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 19:59:25 2013 From: report at bugs.python.org (Zearin) Date: Tue, 29 Jan 2013 18:59:25 +0000 Subject: [issue4945] json checks True/False by identity, not boolean value In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za> Message-ID: <1359485965.89.0.917838651582.issue4945@psf.upfronthosting.co.za> Zearin added the comment: Note: Javascript has something analogous to Python?s ``==`` and ``is``. In JS: > 0 == false true > 0 === false false > 1 == true true > 1 === true false Perhaps this discrepancy could be fixed in the JSON processing? ---------- nosy: +zearin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:02:29 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 29 Jan 2013 19:02:29 +0000 Subject: [issue17074] (docs) Consistent formatting of constants In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za> Message-ID: <1359486149.46.0.423463859946.issue17074@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > This has already been proposed in issue 15580. By the way, I should have said "something along the same lines." Issue 15580 is about eliminating uses of :const:`None`, etc, whereas this targets a different case. But it is similar in scope so the same discussion/reasons apply. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:04:21 2013 From: report at bugs.python.org (Zearin) Date: Tue, 29 Jan 2013 19:04:21 +0000 Subject: [issue17074] (docs) Consistent formatting of constants In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za> Message-ID: <1359486261.35.0.388228873634.issue17074@psf.upfronthosting.co.za> Zearin added the comment: > By the way, I should have said "something along the same lines." Issue 15580 is about eliminating uses of :const:`None`, etc, whereas this targets a different case. But it is similar in scope so the same discussion/reasons apply. Yep! I read, and understood the difference. I still had 2? to add. I?m kind of a nut for good documentation. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:14:16 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 29 Jan 2013 19:14:16 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1359486856.41.0.596553517631.issue15580@psf.upfronthosting.co.za> R. David Murray added the comment: I prefer to have some of them be links and some of them be code markup. That is, I think there is value in having some of them be links. As Georg said, the devguide rule is more about it not being *necessary* to waste time marking them *all* up as constants. Having some of them marked up as constants will be enough to lead a newbie to the documentation for them. When writing new docs, I will typically mark them up as constants once or twice in the new docs, and make the remainder code markup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:17:24 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 29 Jan 2013 19:17:24 +0000 Subject: [issue17055] ftplib.ftpcp test In-Reply-To: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za> Message-ID: <1359487044.09.0.506297264014.issue17055@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thanks for your patch. A couple of remarks: - try to adhere to PEP 8 in your patches (most notably here: 80 characters per line, please). The rest of test_ftplib.py is also somewhat guilty in that regard but that shouldn't discourage you to do the right thing. - you'll notice the rest of test_ftplib.py avoids vertical whitespace within methods. This is by design. - maintain alphabetic order in Misc/ACKS ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:17:39 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 29 Jan 2013 19:17:39 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1359487059.53.0.905189670157.issue15580@psf.upfronthosting.co.za> R. David Murray added the comment: Note, by the way, that I apply the same rule to most link markup. If I refer to, say, a module name in a paragraph or set of related paragraphs multiple times, I will typically only mark up the first occurrence as a :mod: link. It's not a hard and fast rule, though: I go by feel as to what level of link markup seems appropriate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:26:23 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 29 Jan 2013 19:26:23 +0000 Subject: [issue4945] json checks True/False by identity, not boolean value In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za> Message-ID: <1359487583.46.0.6244639959.issue4945@psf.upfronthosting.co.za> R. David Murray added the comment: I would be very careful trying to reason by analogy there. ==, is, and javascripts === are rather different in detail, from what I understand. Nor do I see what javascript has to do with this issue :) As far as the remaining documentation issue here, IMO to follow the convention used most often in the docs (and docstrings), the text in Chris' example should read: If *allow_nan* is true That is, drop the code markup and capitalization to indicate that any true value is accepted. A naive user will use True, a non-naive user will understand the implication. I know Ezio doesn't think this is worthwhile, but I disagree :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:28:36 2013 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 29 Jan 2013 19:28:36 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" In-Reply-To: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> Message-ID: <1359487716.43.0.352693051043.issue17071@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks Antoine, the patch looks good to me. The only thing I would have done differently myself is to name "self" as "__bind_self__" (with two underscores at the end). Could you please apply the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:30:43 2013 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=) Date: Tue, 29 Jan 2013 19:30:43 +0000 Subject: [issue17055] ftplib.ftpcp test In-Reply-To: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za> Message-ID: <1359487843.04.0.282660170292.issue17055@psf.upfronthosting.co.za> Micha? Jastrz?bski added the comment: Hello, Thanks for tips. How about now? ---------- Added file: http://bugs.python.org/file28901/ftpcp_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:33:05 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 29 Jan 2013 19:33:05 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1359487985.26.0.549996546703.issue15580@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It might be worth clarifying in the devguide then if True/False/etc shouldn't be treated differently from other things. The current wording suggests that links shouldn't be used at all in those cases (e.g. "given that they?re fundamental to the language and should be known to any programmer"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:33:57 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 29 Jan 2013 19:33:57 +0000 Subject: [issue17075] logging documentation for library cleanup In-Reply-To: <1359482706.26.0.367132377172.issue17075@psf.upfronthosting.co.za> Message-ID: <1359488037.16.0.414873633339.issue17075@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed. The whole point of that section is to explain how the library can refrain from spewing unwanted logging *if the application doesn't care about logging*. If the application does care (has configured logging), it would be wrong to block the logging. I believe there is now a NullHandler or something similar set up by default, so I don't think this issue arises in Python3. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:34:21 2013 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=) Date: Tue, 29 Jan 2013 19:34:21 +0000 Subject: [issue17055] ftplib.ftpcp test In-Reply-To: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za> Message-ID: <1359488061.65.0.788386661474.issue17055@psf.upfronthosting.co.za> Micha? Jastrz?bski added the comment: My mistake, this one is better. ---------- Added file: http://bugs.python.org/file28902/ftpcp_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:36:41 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 29 Jan 2013 19:36:41 +0000 Subject: [issue17074] (docs) Consistent formatting of constants In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za> Message-ID: <1359488201.61.0.48311938328.issue17074@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:37:18 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 29 Jan 2013 19:37:18 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1359488238.42.0.728169994793.issue15580@psf.upfronthosting.co.za> R. David Murray added the comment: True. I disagree with the existing language, as I've indicated, but I'll leave it up to Georg as doc master. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 20:38:58 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 29 Jan 2013 19:38:58 +0000 Subject: [issue15580] fix True/False/None reST markup In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za> Message-ID: <1359488338.33.0.0306507604312.issue15580@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 21:24:54 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Jan 2013 20:24:54 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" In-Reply-To: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> Message-ID: <3YwfMT4tM8zPRZ@mail.python.org> Roundup Robot added the comment: New changeset 49fd1c8aeca5 by Antoine Pitrou in branch '3.3': Issue #17071: Signature.bind() now works when one of the keyword arguments is named ``self``. http://hg.python.org/cpython/rev/49fd1c8aeca5 New changeset 4ff1dc8c0a3c by Antoine Pitrou in branch 'default': Issue #17071: Signature.bind() now works when one of the keyword arguments is named self. http://hg.python.org/cpython/rev/4ff1dc8c0a3c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 21:26:09 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 20:26:09 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" In-Reply-To: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> Message-ID: <1359491169.44.0.734254560462.issue17071@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed to 3.3 and default! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 21:27:21 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 20:27:21 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1359491241.5.0.528273573875.issue17015@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a new patch, making all assert_*_call methods work as well as autospeccing, and adding tests. Not sure I'm forgetting something else. ---------- Added file: http://bugs.python.org/file28903/issue17015-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 21:43:56 2013 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 29 Jan 2013 20:43:56 +0000 Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT handler is set. In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za> Message-ID: <1359492236.03.0.419108875111.issue15505@psf.upfronthosting.co.za> Thomas Wouters added the comment: ping (you know why :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 21:45:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 20:45:05 +0000 Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT handler is set. In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za> Message-ID: <1359492305.76.0.629676782664.issue15505@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 22:01:20 2013 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 29 Jan 2013 21:01:20 +0000 Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like NFS) In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za> Message-ID: <1359493280.46.0.17917452148.issue17076@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Could you add regression tests to your patch please? ---------- assignee: -> hynek priority: high -> normal type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 22:30:32 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 29 Jan 2013 21:30:32 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <1359495032.15.0.408793929995.issue16694@psf.upfronthosting.co.za> Zachary Ware added the comment: Since the older Windows project files were removed, v10 removes the patches to them. Everything else still applies cleanly. Also, in the spirit of what Brett said in 16651 about not re-implementing blindly, I did just look up what Jython, IronPython, and PyPy do for the operator module. The first two implement it in their VM language, and PyPy uses a very specialized version that didn't look easy to adapt to CPython, at least at a glance. It was fun for me to write any way about it, though :) ---------- Added file: http://bugs.python.org/file28904/py_operator.v10.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 22:30:46 2013 From: report at bugs.python.org (Adam Kellas) Date: Tue, 29 Jan 2013 21:30:46 +0000 Subject: [issue17078] string.Template.safe_substitute hard-wires "braces" as {} Message-ID: <1359495046.85.0.635388190725.issue17078@psf.upfronthosting.co.za> New submission from Adam Kellas: If you use safe_substitute and try to use a variable reference style other than ${foo}, you will find that it assumes ${foo} style. In particular, when evaluating $[foo] (square braces) and 'foo' is not defined, safe_substitute will put the string back together using ${foo} (curly braces). See for details and test case. ---------- components: Library (Lib) messages: 180949 nosy: Adam.Kellas priority: normal severity: normal status: open title: string.Template.safe_substitute hard-wires "braces" as {} type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 22:33:29 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 29 Jan 2013 21:33:29 +0000 Subject: [issue16968] Fix test discovery for test_concurrent_futures.py In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za> Message-ID: <1359495209.82.0.805671056664.issue16968@psf.upfronthosting.co.za> Zachary Ware added the comment: I failed to mention; v4 also removes setUpModule() which was present in the first 3 patches. With 16935 fixed, setUpModule would be unnecessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 22:38:38 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 21:38:38 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" In-Reply-To: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> Message-ID: <1359495518.82.0.0897569957205.issue17071@psf.upfronthosting.co.za> STINNER Victor added the comment: self doesn't need to have a name, you can use: def bind(*args, **kw): self = args[0] args = args[1:] To accept any name ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 22:40:36 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Jan 2013 21:40:36 +0000 Subject: [issue17071] Signature.bind() fails with a keyword argument named "self" In-Reply-To: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za> Message-ID: <1359495636.4.0.349273433322.issue17071@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, there were several solutions to this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 23:07:27 2013 From: report at bugs.python.org (Sven Brauch) Date: Tue, 29 Jan 2013 22:07:27 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1359497247.66.0.636674965896.issue16795@psf.upfronthosting.co.za> Sven Brauch added the comment: Hm, I'm still getting the same error messages from the review tool which I described earlier; I can neither comment nor add patches. So, I'll have to abuse the bug report again: Thanks for the review. Is it possible you selected the wrong patch file for the second patch (Patch Set 5)? It seems to include all changes instead of just those from the second of the three patches I submitted. Also I had already removed the traceback.print_stack() call. I fixed the other two issues and I will attach a corrected version of the second patch for review. I hope I got everything right ;) Please have an extra close look at the changes to symtable.c and compile.c (since I'm not very familiar with that code), in order to avoid that we break stuff with this. Cheers, Sven ---------- Added file: http://bugs.python.org/file28905/81300-change-var-kwargs-new.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 23:15:25 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 29 Jan 2013 22:15:25 +0000 Subject: [issue17078] string.Template.safe_substitute hard-wires "braces" as {} In-Reply-To: <1359495046.85.0.635388190725.issue17078@psf.upfronthosting.co.za> Message-ID: <1359497725.75.0.0497411660828.issue17078@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 23:20:46 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 29 Jan 2013 22:20:46 +0000 Subject: [issue17079] Fix test discovery for test_ctypes.py Message-ID: <1359498046.65.0.0354719315528.issue17079@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: Tests files: test_ctypes_discovery.diff keywords: patch nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_ctypes.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28906/test_ctypes_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 23:29:38 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Jan 2013 22:29:38 +0000 Subject: [issue17028] launcher does not read shebang line when arguments are given In-Reply-To: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za> Message-ID: <3Ywj7Q1Kb8zSLQ@mail.python.org> Roundup Robot added the comment: New changeset 0880e0f859e0 by Vinay Sajip in branch 'default': Closes #17028: Allowed Python arguments to be supplied to launcher. http://hg.python.org/cpython/rev/0880e0f859e0 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 29 23:59:06 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Jan 2013 22:59:06 +0000 Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT handler is set. In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za> Message-ID: <3YwjnP633jzRBj@mail.python.org> Roundup Robot added the comment: New changeset 7e4c5914ba76 by Michael Foord in branch '2.7': Issue 15505. unittest.installHandler and non callable signal handlers http://hg.python.org/cpython/rev/7e4c5914ba76 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 00:08:14 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Jan 2013 23:08:14 +0000 Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT handler is set. In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za> Message-ID: <3Ywjzy1YbCzPHp@mail.python.org> Roundup Robot added the comment: New changeset 48c5c632d212 by Michael Foord in branch '3.2': Closes issue 15505. unittest.installHandler and non-callable signal handlers. http://hg.python.org/cpython/rev/48c5c632d212 ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 00:10:50 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Jan 2013 23:10:50 +0000 Subject: [issue17036] Implementation of the PEP 433: Easier suppression of file descriptor inheritance In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za> Message-ID: <1359501050.13.0.524628089171.issue17036@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested bc88690df059.patch on Solaris 9: test_os failed on openpty(cloexec=True). It looks like setting close-on-exec on master_fd must be done after grantpt(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 00:12:26 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 29 Jan 2013 23:12:26 +0000 Subject: [issue17078] string.Template.safe_substitute hard-wires "braces" as {} In-Reply-To: <1359495046.85.0.635388190725.issue17078@psf.upfronthosting.co.za> Message-ID: <1359501146.52.0.646208015621.issue17078@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: See PEP 292 and the section titled "Why `$' and Braces?" http://www.python.org/dev/peps/pep-0292/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 01:27:19 2013 From: report at bugs.python.org (Bartosz S) Date: Wed, 30 Jan 2013 00:27:19 +0000 Subject: [issue14037] Allow grouping of argparse subparser commands in help output In-Reply-To: <1329436005.81.0.273577688528.issue14037@psf.upfronthosting.co.za> Message-ID: <1359505639.3.0.1858982011.issue14037@psf.upfronthosting.co.za> Changes by Bartosz S : ---------- nosy: +toszter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 02:27:56 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 01:27:56 +0000 Subject: [issue14037] Allow grouping of argparse subparser commands in help output In-Reply-To: <1329436005.81.0.273577688528.issue14037@psf.upfronthosting.co.za> Message-ID: <1359509276.25.0.976176252932.issue14037@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 02:28:53 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 01:28:53 +0000 Subject: [issue14039] Add "metavar" argument to add_subparsers() in argparse In-Reply-To: <1329436304.54.0.709137632289.issue14039@psf.upfronthosting.co.za> Message-ID: <1359509333.94.0.824496266272.issue14039@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 02:37:06 2013 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 30 Jan 2013 01:37:06 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> Message-ID: <1359509826.64.0.573962471956.issue15633@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Alright, it *finally* happened again. Attributes of the response object are: ._method: GET, .chunked: 0, .length: 9369540 .chunk_left: UNKNOWN, .status: 200 .reason "OK", .version: 11, .will_close: False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 02:52:31 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 01:52:31 +0000 Subject: [issue14039] Add "metavar" argument to add_subparsers() in argparse In-Reply-To: <1329436304.54.0.709137632289.issue14039@psf.upfronthosting.co.za> Message-ID: <1359510751.71.0.00133666879516.issue14039@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Have you tried setting the metavar property on the return value of add_subparsers()? I tried this, and it seems to work. It looks like the logic for _metavar_formatter() is the same no matter what the action type (specifically _SubParsersAction in this case): http://hg.python.org/cpython/file/e81cad0c722a/Lib/argparse.py#l554 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 02:59:41 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 01:59:41 +0000 Subject: [issue14039] Add "metavar" argument to add_subparsers() in argparse In-Reply-To: <1329436304.54.0.709137632289.issue14039@psf.upfronthosting.co.za> Message-ID: <1359511181.9.0.956176921251.issue14039@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Actually, it looks like add_subparsers() may already support passing a metavar argument, but it's just not documented? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 03:34:12 2013 From: report at bugs.python.org (Mitchell Model) Date: Wed, 30 Jan 2013 02:34:12 +0000 Subject: [issue8491] Need readline command and keybinding information In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za> Message-ID: <1359513252.14.0.0110766633569.issue8491@psf.upfronthosting.co.za> Mitchell Model added the comment: Ping. I just noticed that this is still unresolved in the Python 3.3 docs. This should be closed, with or without my suggested change. ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 03:44:59 2013 From: report at bugs.python.org (Mitchell Model) Date: Wed, 30 Jan 2013 02:44:59 +0000 Subject: [issue6057] sqlite3 error classes should be documented In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za> Message-ID: <1359513899.42.0.465745452754.issue6057@psf.upfronthosting.co.za> Mitchell Model added the comment: I still think the Exception class hierarchy should be described in the sqlite3 module documentation. Someone should decide one way or another and close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 06:31:10 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 30 Jan 2013 05:31:10 +0000 Subject: [issue12883] xml.sax.xmlreader.AttributesImpl allows empty string as attribute names In-Reply-To: <1314957842.78.0.391568748992.issue12883@psf.upfronthosting.co.za> Message-ID: <1359523870.82.0.0524942386888.issue12883@psf.upfronthosting.co.za> Ramchandra Apte added the comment: bump... ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 07:37:07 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 30 Jan 2013 06:37:07 +0000 Subject: [issue17077] Fix test_tools hangs In-Reply-To: <1359484777.42.0.023750065374.issue17077@psf.upfronthosting.co.za> Message-ID: <201301300836.49199.storchaka@gmail.com> Serhiy Storchaka added the comment: On what platform it hangs? Note that communicate() currently works only with bytes on 3.2 (issue16903). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 07:39:29 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 30 Jan 2013 06:39:29 +0000 Subject: [issue9536] defaultdict doc makes incorrect reference to __missing__ method In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> Message-ID: <1359527969.35.0.281965045034.issue9536@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 08:23:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2013 07:23:44 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> Message-ID: <1359530624.91.0.425033560143.issue15633@psf.upfronthosting.co.za> Antoine Pitrou added the comment: "length: 9369540" indicates you haven't read the whole advertised Content-Length. Is it possible the server shuts down the TCP connection even before the whole Content-Length has been sent? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 09:33:13 2013 From: report at bugs.python.org (Jonathan Livni) Date: Wed, 30 Jan 2013 08:33:13 +0000 Subject: [issue17080] A better error message for float() Message-ID: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za> New submission from Jonathan Livni: These lines of Python (2.7): y = float(x) gives the error: TypeError: float() argument must be a string or a number. In various cases such as: x = [0] x = None x = SomeClass() In addition to the information given in the error message, it could help, for debugging purposes, to state the type of the object given. ---------- components: Interpreter Core messages: 180967 nosy: Jonathan.Livni priority: normal severity: normal status: open title: A better error message for float() type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 09:35:56 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 30 Jan 2013 08:35:56 +0000 Subject: [issue17080] A better error message for float() In-Reply-To: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za> Message-ID: <1359534956.42.0.980241423965.issue17080@psf.upfronthosting.co.za> Ezio Melotti added the comment: Sounds reasonable to me. ---------- nosy: +ezio.melotti stage: -> needs patch versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 09:41:26 2013 From: report at bugs.python.org (Kushal Das) Date: Wed, 30 Jan 2013 08:41:26 +0000 Subject: [issue17080] A better error message for float() In-Reply-To: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za> Message-ID: <1359535286.28.0.937892740174.issue17080@psf.upfronthosting.co.za> Changes by Kushal Das : ---------- nosy: +kushaldas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 09:47:54 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 30 Jan 2013 08:47:54 +0000 Subject: [issue17080] A better error message for float() In-Reply-To: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za> Message-ID: <1359535674.65.0.822569064675.issue17080@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's an initial patch, still needs tests. The same should be done for complex() too. Maybe it could be applied to older branches too. ---------- assignee: -> ezio.melotti keywords: +patch Added file: http://bugs.python.org/file28907/issue17080.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 09:55:00 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 08:55:00 +0000 Subject: [issue16989] allow distutils debug mode to be enabled more easily In-Reply-To: <1358466115.01.0.322407717365.issue16989@psf.upfronthosting.co.za> Message-ID: <1359536100.26.0.185673189549.issue16989@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I meant to comment on the patch earlier. The fix here isn't as simple as I had originally suggested. The patch has to be constructed more carefully to be more fully backwards compatible. For example, it shouldn't break code that imports DEBUG from modules, or that sets DEBUG on other modules. The test case you found is an example of the former. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 09:55:37 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 08:55:37 +0000 Subject: [issue16989] allow distutils debug mode to be enabled more easily In-Reply-To: <1358466115.01.0.322407717365.issue16989@psf.upfronthosting.co.za> Message-ID: <1359536137.46.0.701710444968.issue16989@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 10:05:10 2013 From: report at bugs.python.org (wohugb) Date: Wed, 30 Jan 2013 09:05:10 +0000 Subject: [issue17081] documentation Message-ID: <1359536710.83.0.297139982136.issue17081@psf.upfronthosting.co.za> Changes by wohugb : ---------- assignee: docs at python components: Documentation nosy: docs at python, wohugb priority: normal severity: normal status: open title: documentation versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 10:49:35 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2013 09:49:35 +0000 Subject: [issue17080] A better error message for float() In-Reply-To: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za> Message-ID: <1359539375.48.0.755250526574.issue17080@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You should put single quotes around the type name, i.e.: "float() argument must be a string or a number, not '%.200s'" ---------- nosy: +pitrou stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 10:59:01 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 30 Jan 2013 09:59:01 +0000 Subject: [issue17080] A better error message for float() In-Reply-To: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za> Message-ID: <1359539941.79.0.6837083948.issue17080@psf.upfronthosting.co.za> Ezio Melotti added the comment: I was thinking about that but in other places they are not used. Adding them is OK though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 11:00:08 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 10:00:08 +0000 Subject: [issue17081] documentation Message-ID: <1359540008.4.0.923924120451.issue17081@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 11:18:49 2013 From: report at bugs.python.org (Trent Nelson) Date: Wed, 30 Jan 2013 10:18:49 +0000 Subject: [issue17056] Support Visual Studio 2012 In-Reply-To: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za> Message-ID: <1359541129.86.0.762409494873.issue17056@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 11:21:59 2013 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 30 Jan 2013 10:21:59 +0000 Subject: [issue17077] Fix test_tools hangs In-Reply-To: <1359484777.42.0.023750065374.issue17077@psf.upfronthosting.co.za> Message-ID: <1359541319.62.0.337350186561.issue17077@psf.upfronthosting.co.za> Jeremy Kloth added the comment: It hangs on both my Windows buildbot and development machine. The patch is tested and works correctly on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 12:03:12 2013 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 30 Jan 2013 11:03:12 +0000 Subject: [issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za> Message-ID: <1359543792.15.0.00221098342091.issue16903@psf.upfronthosting.co.za> Jeremy Kloth added the comment: I would suggest that this be bumped to release blocker as currently passing bytes to communicate with universal_newlines=True on Windows causes the process to hang (see issue17077). The backported test case passes on Windows without any changes to subprocess.py so this is a POSIX-only bug. ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 13:28:24 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Jan 2013 12:28:24 +0000 Subject: [issue17077] Fix test_tools hangs In-Reply-To: <1359484777.42.0.023750065374.issue17077@psf.upfronthosting.co.za> Message-ID: <1359548904.19.0.734267582101.issue17077@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 13:28:28 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Jan 2013 12:28:28 +0000 Subject: [issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za> Message-ID: <1359548908.53.0.668861076381.issue16903@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 14:31:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 30 Jan 2013 13:31:46 +0000 Subject: [issue17077] Fix test_tools hangs In-Reply-To: <1359484777.42.0.023750065374.issue17077@psf.upfronthosting.co.za> Message-ID: <1359552706.93.0.0879392319473.issue17077@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka dependencies: +subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 15:06:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 30 Jan 2013 14:06:58 +0000 Subject: [issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za> Message-ID: <1359554818.32.0.0378914665429.issue16903@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed, Popen.communicate() is incompatible not only between 3.2 and 3.3, but between Windows and POSIX too. Documentation says the input argument should be a bytes string and 3.2 on POSIX?works only with bytes strings. 3.2 on Windows and 3.3 on both platforms require an unicode string, as 3.3 documentation says. 3.2 on Windows hangs with a bytes string. Patch updated with the documentation change (copied from 3.3). ---------- priority: normal -> critical Added file: http://bugs.python.org/file28908/subprocess_communicate_string-3.2_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 18:49:14 2013 From: report at bugs.python.org (Michael Foord) Date: Wed, 30 Jan 2013 17:49:14 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1359568154.21.0.441103489242.issue17015@psf.upfronthosting.co.za> Michael Foord added the comment: Wow, impressive work Antoine - thanks. I am a little concerned that this relies on Python 3 only features of inspect, and *in fact* relies on bug fixes in Python 3.4 to work. That means it would be hard / impossible for the backport "mock" to have the new feature. That may be solveable (there is a backport of function signatures which mock could use for example). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 18:52:21 2013 From: report at bugs.python.org (Michael Foord) Date: Wed, 30 Jan 2013 17:52:21 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359568341.21.0.0857106048955.issue16997@psf.upfronthosting.co.za> Michael Foord added the comment: I am concerned that this feature changes the TestResult API in a backwards incompatible way. There are (quite a few) custom TestResult objects that just implement the API and don't inherit from TestResult. I'd like to try this new code with (for example) the test result provided by the junitxml project and see what happens. I have a broader concern too. I have seen lots of requests for "test parameterization" and none *specifically* for sub tests. They are very similar mechanisms (with key differences), so I don't think we want *both* in unittest. If test parameterization is more powerful / flexible then I would rather see that *instead*. On the other hand if subtests are *better* then lets have them instead - but I'd like to see that discussion happen before we just jump into subtests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 18:54:36 2013 From: report at bugs.python.org (Michael Foord) Date: Wed, 30 Jan 2013 17:54:36 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359568476.07.0.679017924598.issue16997@psf.upfronthosting.co.za> Michael Foord added the comment: Note, some brief discussion on the "testing in python" mailing list: http://lists.idyll.org/pipermail/testing-in-python/2013-January/005356.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 18:57:57 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 30 Jan 2013 17:57:57 +0000 Subject: [issue17082] Fix test discovery for test_dbm*.py Message-ID: <1359568677.42.0.42152696128.issue17082@psf.upfronthosting.co.za> New submission from Zachary Ware: This patch fixes discovery for test_dbm.py and removes test_main() from test_dbm, test_dbm_dumb, test_dbm_gnu, and test_dbm_ndbm. It also removes unnecessary __init__ methods from DumbDBMTestCase and WhichDBTestCase, which only called unittest.TestCase.__init__ with all supplied arguments. ---------- components: Tests files: test_dbm-s_discovery.diff keywords: patch messages: 180979 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_dbm*.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28909/test_dbm-s_discovery.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 19:11:17 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2013 18:11:17 +0000 Subject: [issue16997] subtests In-Reply-To: <1359568341.21.0.0857106048955.issue16997@psf.upfronthosting.co.za> Message-ID: <1359569305.3490.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > I am concerned that this feature changes the TestResult API in a > backwards incompatible way. There are (quite a few) custom TestResult > objects that just implement the API and don't inherit from TestResult. > I'd like to try this new code with (for example) the test result > provided by the junitxml project and see what happens. Feel free to do it, of course :-) In any case, we can add a hook to the TestCase subclass so that specialized reporters can get at the parent TestCase. (and I'm not sure how it's backwards incompatible: as long as you don't use subtests, nothing should break - so existing software shouldn't be affected) > I have a broader concern too. I have seen lots of requests for "test > parameterization" and none *specifically* for sub tests. They are very > similar mechanisms (with key differences), so I don't think we want > *both* in unittest. If test parameterization is more powerful / > flexible then I would rather see that *instead*. The underlying idea of subtests is "if you want to parameterize a test, here is a useful building block". Generic parameterization APIs are cumbersome and actually *harder* to write (and read!) than the corresponding `for` loop. With subtests, you just write your `for` loop and use a subtest to isolate each iteration's failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 19:13:36 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2013 18:13:36 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1359569616.3.0.503858858082.issue17015@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I am a little concerned that this relies on Python 3 only features of > inspect, and *in fact* relies on bug fixes in Python 3.4 to work. The bug fix has landed in 3.3 as well ;-) (see 49fd1c8aeca5) I guess a backport of inspect.signature() would allow it to work on previous Pythons, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 19:15:49 2013 From: report at bugs.python.org (Michael Foord) Date: Wed, 30 Jan 2013 18:15:49 +0000 Subject: [issue17015] mock could be smarter and inspect the spec's signature In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za> Message-ID: <1359569749.12.0.0196431564799.issue17015@psf.upfronthosting.co.za> Michael Foord added the comment: Ah, well if the bugfix exists everywhere that function signatures exist then it shouldn't be a problem. (I think there is already a backport of inspect.signature() by Nick Coghlan.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 19:25:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 30 Jan 2013 18:25:14 +0000 Subject: [issue1783] nonexistent data items declared as exports in sysmodule.h In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za> Message-ID: <1359570314.41.0.559328494259.issue1783@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file28910/sysmodule_h_cleanup-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 19:27:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 30 Jan 2013 18:27:48 +0000 Subject: [issue1783] nonexistent data items declared as exports in sysmodule.h In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za> Message-ID: <1359570468.48.0.791773370425.issue1783@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are patches. ---------- assignee: -> serhiy.storchaka keywords: +easy nosy: +serhiy.storchaka stage: needs patch -> patch review versions: +Python 3.2, Python 3.3, Python 3.4 -Python 3.1 Added file: http://bugs.python.org/file28911/sysmodule_h_cleanup-3.x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 19:32:05 2013 From: report at bugs.python.org (Bryant) Date: Wed, 30 Jan 2013 18:32:05 +0000 Subject: [issue17083] can't specify newline string for readline for binary files Message-ID: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za> New submission from Bryant: When opening binary files in Python 3, the newline parameter cannot be set. While this kind of makes sense, readline() can still be used on binary files. This is great for my usage, but it is doing universal newline mode, I believe, so that any \r, \n, or \r\n triggers an EOL. The data I'm working with is mixed ASCII/binary, with line termination specified by \r\n. I can't read a line (even though that concept occurs in my file) because some of the binary data includes \r or \n even though they aren't newlines in this context. The issue here is that if the newline string can't be specified, readline() is useless on binary data, which often uses custom EOL strings. So would it be reasonable to add the newline parameter support to binary files? If not, then shouldn't readline() throw an exception when used on binary files? I don't know if it's helpful here, but I've written a binary_readline() function supporting arbitrary EOL strings: def binary_readline(file, newline=b'\r\n'): line = bytearray() newlineIndex = 0 while True: x = file.read(1) if x: line += x else: if len(line) == 0: return None else: return line # If this character starts to match the newline string, start that comparison til it matches or doesn't. while line[-1] == newline[newlineIndex]: x = file.read(1) if x: line += x else: return line newlineIndex += 1 if newlineIndex == len(newline): return line # We failed checking for the newline string, so reset the checking index newlineIndex = 0 ---------- components: Library (Lib) messages: 180984 nosy: susurrus priority: normal severity: normal status: open title: can't specify newline string for readline for binary files type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 19:56:42 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 18:56:42 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359572202.29.0.208947599102.issue16997@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I am concerned that this feature changes the TestResult API in a backwards incompatible way. My suggestion to add the original TestCase object to TestResult.errors, etc. instead and add the extra failure data to the longDescription would address this concern, which is why I suggested it. The former is what currently happens with multiple failures per TestCase (e.g. in runTest() and tearDown()). > The underlying idea of subtests is "if you want to parameterize a test, here is a useful building block". The current API doesn't seem like a good building block because it bundles orthogonal features (i.e. to add loop failure data to a block of asserts you have to use the continuance feature). Why not expose *those* as the building blocks? The API can be something like-- with self.addMessage(msg): # Add msg to the longDescription of any assertion failure within. with self.continueTest(msg=''): # Keep running the TestCase on any assertion failure within. (The current subTest() is basically equivalent to continueTest() with a specialized message. It could be added, too, if desired.) Accepting a string message is more basic and flexible than allowing only a **kwargs dict, which seems a bit "cute" and specialized to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 20:04:46 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2013 19:04:46 +0000 Subject: [issue16997] subtests In-Reply-To: <1359572202.29.0.208947599102.issue16997@psf.upfronthosting.co.za> Message-ID: <1359572514.3422.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > The current API doesn't seem like a good building block because it > bundles orthogonal features (i.e. to add loop failure data to a block > of asserts you have to use the continuance feature). Why not expose > *those* as the building blocks? The API can be something like-- > > with self.addMessage(msg): > # Add msg to the longDescription of any assertion failure > within. > > with self.continueTest(msg=''): > # Keep running the TestCase on any assertion failure within. > > (The current subTest() is basically equivalent to continueTest() with > a specialized message. It could be added, too, if desired.) > Accepting a string message is more basic and flexible than allowing > only a **kwargs dict, which seems a bit "cute" and specialized to me. I've already replied to all this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 20:16:53 2013 From: report at bugs.python.org (David Holm) Date: Wed, 30 Jan 2013 19:16:53 +0000 Subject: [issue17084] nntplib.NNTP.xover does not always return results as documented Message-ID: <1359573413.45.0.835923158727.issue17084@psf.upfronthosting.co.za> New submission from David Holm: The response from NNTP.xover doesn't always match the format described in the documentation. It is supposed to return a (result, list) where the list contains entries of the format (article number, subject, poster, date, id, references, size, lines). However, I have found it to sometimes split the subject into two entries or only one of multiple references being in a list (see example below). I am attempting to interpret the data using an enum-like structure to match the indices to the values but it fails very often because the date field contains part of the subject or the size field contains a cross reference entry. Example using Python 2.7: >>> import nntplib >>> c = nntplib.NNTP(..) >>> c.group('alt.binaries.linux') ('211 317334 3 317336 alt.binaries.linux', '317334', '3', '317336', 'alt.binaries.linux') >>> resp, lst = c.xover('114179', '114179') >>> print resp 224 data follows >>> print lst [('114179', 'Re: Newsposter - The Linux Binary Posting Script Version 7.2', 'Patriot ', 'Mon, 04 Jan 2010 17:36:44 -0600', '', ['<5aydnT9obM20bKrWnZ2dnUVZ_v2dnZ2d at giganews.com>'], '', '1443')] In the example above '' can be found at index 6 where the size is supposed to be. ---------- components: Library (Lib) messages: 180987 nosy: dholm priority: normal severity: normal status: open title: nntplib.NNTP.xover does not always return results as documented type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 20:18:58 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 30 Jan 2013 19:18:58 +0000 Subject: [issue17083] can't specify newline string for readline for binary files In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za> Message-ID: <1359573538.17.0.175591200821.issue17083@psf.upfronthosting.co.za> R. David Murray added the comment: If you are reading in binary mode, then all readline does is get you the next \n terminated chunk of data, which is a convenience in some circumstances. You have to do all the newline handling yourself. Otherwise it isn't a binary read. I think the "right way" to do what you want is to write a custom subclass of one of the IO classes. Should such a subclass be added to Python? That's an interesting question. A first step toward an answer might be to post it as a recipe on the ActiveState site and see how many people find it useful. ---------- nosy: +r.david.murray type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 21:00:39 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 30 Jan 2013 20:00:39 +0000 Subject: [issue16997] subtests In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za> Message-ID: <1359576039.97.0.904659998915.issue16997@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I've already replied to all this. You didn't respond to the idea of exposing both features separately after saying you didn't understand what I meant and saying that they were pointless and didn't make sense. So I explained and also proposed a specific API to make the suggestion clearer and more concrete. These don't seem pointless to me at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 21:14:57 2013 From: report at bugs.python.org (Daniel Urban) Date: Wed, 30 Jan 2013 20:14:57 +0000 Subject: [issue17044] Implement PEP 422: Simple class initialisation hook In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za> Message-ID: <1359576897.2.0.986680636257.issue17044@psf.upfronthosting.co.za> Daniel Urban added the comment: I'm attaching a new patch with some documentation and one additional test. ---------- Added file: http://bugs.python.org/file28912/pep422_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 21:22:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2013 20:22:29 +0000 Subject: [issue16997] subtests In-Reply-To: <1359576039.97.0.904659998915.issue16997@psf.upfronthosting.co.za> Message-ID: <1359577177.3422.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > You didn't respond to the idea of exposing both features separately > after saying you didn't understand what I meant and saying that they > were pointless and didn't make sense. So I explained and also > proposed a specific API to make the suggestion clearer and more > concrete. Well, suffice to say that I wasn't convinced at all. There are multiple use cases for subtests in the Python test suite, but I can't think of any for your proposed API separation. That's why I find it uninteresting. I'm making this proposal to solve a concrete issue, not in the interest of minimalism. "Building block" was to be understood in that sense. Unit testing is one of those areas where purity is a secondary concern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 21:57:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Jan 2013 20:57:44 +0000 Subject: [issue15633] httplib.response is not closed after all data has been read In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za> Message-ID: <1359579464.12.0.888089999172.issue15633@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch for 2.7. Ideally, we would raise IncompleteRead in this situation, but this would break existing programs. ---------- keywords: +patch stage: -> patch review versions: +Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28913/http_truncated_body.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 22:17:08 2013 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 30 Jan 2013 21:17:08 +0000 Subject: [issue17085] test_socket crashes the whole test suite Message-ID: <1359580628.83.0.173179383331.issue17085@psf.upfronthosting.co.za> New submission from ddvento at ucar.edu: While running "make test" on my build of python 2.7.3 the suite aborts with [..omiss..] test_socket make: *** [test] Alarm clock Trying to run individually the offending test reveals a little more $ ./python Lib/test/regrtest.py -v test_socket == CPython 2.7.3 (default, Jan 29 2013, 11:23:48) [GCC 4.7.2] == Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian == /glade/scratch/ddvento/build/Python-2.7.3-westmere/build/test_python_12171 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) test_socket TIPC module is not loaded, please 'sudo modprobe tipc' testCrucialConstants (test.test_socket.GeneralModuleTests) ... ok testDefaultTimeout (test.test_socket.GeneralModuleTests) ... ok testGetServBy (test.test_socket.GeneralModuleTests) ... ok testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok testGetaddrinfo (test.test_socket.GeneralModuleTests) ... ok testHostnameRes (test.test_socket.GeneralModuleTests) ... ok testIPv4_inet_aton_fourbytes (test.test_socket.GeneralModuleTests) ... ok testIPv4toString (test.test_socket.GeneralModuleTests) ... ok testIPv6toString (test.test_socket.GeneralModuleTests) ... ok testInterpreterCrash (test.test_socket.GeneralModuleTests) ... ok testListenBacklog0 (test.test_socket.GeneralModuleTests) ... ok testNewAttributes (test.test_socket.GeneralModuleTests) ... ok testNtoH (test.test_socket.GeneralModuleTests) ... ok testNtoHErrors (test.test_socket.GeneralModuleTests) ... ok testRefCountGetNameInfo (test.test_socket.GeneralModuleTests) ... ok testSendAfterClose (test.test_socket.GeneralModuleTests) ... ok testSendtoErrors (test.test_socket.GeneralModuleTests) ... ok testSetSockOpt (test.test_socket.GeneralModuleTests) ... ok testSockName (test.test_socket.GeneralModuleTests) ... ok testSocketError (test.test_socket.GeneralModuleTests) ... ok testStringToIPv4 (test.test_socket.GeneralModuleTests) ... ok testStringToIPv6 (test.test_socket.GeneralModuleTests) ... ok test_flowinfo (test.test_socket.GeneralModuleTests) ... ok test_getsockaddrarg (test.test_socket.GeneralModuleTests) ... ok test_sendall_interrupted (test.test_socket.GeneralModuleTests) ... FAIL test_sendall_interrupted_with_timeout (test.test_socket.GeneralModuleTests) ... FAIL test_sock_ioctl (test.test_socket.GeneralModuleTests) ... skipped 'Windows specific' test_weakref (test.test_socket.GeneralModuleTests) ... ok testDup (test.test_socket.BasicTCPTest) ... ok testFromFd (test.test_socket.BasicTCPTest) ... ok testOverFlowRecv (test.test_socket.BasicTCPTest) ... ok testOverFlowRecvFrom (test.test_socket.BasicTCPTest) ... ok testRecv (test.test_socket.BasicTCPTest) ... ok testRecvFrom (test.test_socket.BasicTCPTest) ... ok testSendAll (test.test_socket.BasicTCPTest) ... ok testShutdown (test.test_socket.BasicTCPTest) ... ok testClose (test.test_socket.TCPCloserTest) ... Alarm clock $ echo $? 142 Of course my installation has an issue (which I'm trying to identify), but the test suite should not crash on a failure of individual test. I believe this is related to Issue1326841 in that the test author forgot to install the signal handler, or maybe was expecting the behavior Paul Rubin suggested in said bug. ---------- components: Tests messages: 180993 nosy: ddvento at ucar.edu priority: normal severity: normal status: open title: test_socket crashes the whole test suite versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 22:42:42 2013 From: report at bugs.python.org (Bryant) Date: Wed, 30 Jan 2013 21:42:42 +0000 Subject: [issue17083] can't specify newline string for readline for binary files In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za> Message-ID: <1359582162.47.0.260089116066.issue17083@psf.upfronthosting.co.za> Bryant added the comment: I'm not terribly worried about the "right" way for me to deal with my code, but that Python, in this instance, is inconsistent. While it doesn't want you to apply the concept of a "line" to a binary file in that it prevents you from specifying an EOL string, it does allow you to read that file as lines. So my question is why shouldn't I be able to specify a newline of b"\r\n" and then use readline() on my binary file? I don't see why that concept shouldn't be applied here when it's definitely applicable in a lot of cases (any binary log format). To resolve this I really think there're two options to maintain the consistency of Python's approach: 1) Have readline() error out for binary-mode files. 2) Allow specifying a byte-string as the newline string for binary files that readline() would then use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 22:59:02 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 30 Jan 2013 21:59:02 +0000 Subject: [issue17028] launcher does not read shebang line when arguments are given In-Reply-To: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za> Message-ID: <1359583142.51.0.364673503488.issue17028@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: An entry in Misc/NEWS would be nice. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 23:19:06 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Jan 2013 22:19:06 +0000 Subject: [issue17028] launcher does not read shebang line when arguments are given In-Reply-To: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za> Message-ID: <1359584346.74.0.810559618142.issue17028@psf.upfronthosting.co.za> STINNER Victor added the comment: A test would also be nice :-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 30 23:26:58 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 30 Jan 2013 22:26:58 +0000 Subject: [issue17028] launcher does not read shebang line when arguments are given In-Reply-To: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za> Message-ID: <3YxK1t002YzPj1@mail.python.org> Roundup Robot added the comment: New changeset 58e72cb89848 by Vinay Sajip in branch 'default': Updated NEWS with fix for #17028. http://hg.python.org/cpython/rev/58e72cb89848 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 00:10:21 2013 From: report at bugs.python.org (Matthias Klose) Date: Wed, 30 Jan 2013 23:10:21 +0000 Subject: [issue17086] backport cross-build patches to the 2.7 branch Message-ID: <1359587420.86.0.11365762234.issue17086@psf.upfronthosting.co.za> New submission from Matthias Klose: I would like to check in a backport of the cross build patches on Thu or Fri, so that these can be checked for the upcoming 2.7.4 release. The backport was made using the current state of the cross build support on the 3.3 branch. The patch is tested with native builds on linux, and a cross build targeting arm-linux-gnueabihf. ---------- assignee: doko files: cross-2.7.diff keywords: patch messages: 180998 nosy: benjamin.peterson, doko priority: normal severity: normal status: open title: backport cross-build patches to the 2.7 branch versions: Python 2.7 Added file: http://bugs.python.org/file28914/cross-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 00:53:02 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 30 Jan 2013 23:53:02 +0000 Subject: [issue17087] Improve the repr for regular expression match objects Message-ID: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Experience teaching Python has shown that people have a hard time learning to work with match objects. A contributing cause is the opaque repr: >>> import re >>> s = 'On 3/14/2013, Python celebrate Pi day.' >>> mo = re.search(r'\d+/\d+/\d+', s) >>> mo <_sre.SRE_Match object at 0x100456100> They could explore the match object with dir() and help() and the matchobject methods and attributes: >>> dir(mo) ['__class__', '__copy__', '__deepcopy__', ... 'end', 'endpos', 'expand', 'group', ... ] >>> mo.start() 3 >>> mo.end() 12 >>> mo.group(0) '3/14/2013' However, this gets old when experimenting with alternative regular expressions. A better solution is to improve the repr: >>> re.search(r'\d+/\d+/\d+', s) This would make the regular expression module much easier to work with. ---------- components: Library (Lib) messages: 180999 nosy: rhettinger priority: normal severity: normal status: open title: Improve the repr for regular expression match objects type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 00:58:13 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 30 Jan 2013 23:58:13 +0000 Subject: [issue17086] backport cross-build patches to the 2.7 branch In-Reply-To: <1359587420.86.0.11365762234.issue17086@psf.upfronthosting.co.za> Message-ID: <1359590293.03.0.0752361573934.issue17086@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Did you mean to add that config.guess file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 01:07:35 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 31 Jan 2013 00:07:35 +0000 Subject: [issue17087] Improve the repr for regular expression match objects In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za> Message-ID: <1359590855.44.0.510672071976.issue17087@psf.upfronthosting.co.za> Ezio Melotti added the comment: Showing start and stop would be OK, but there might be many groups and they might contain lot of text, so they can't simply be included in the repr as they are. FWIW there was another issue about changing _sre.SRE_Match to something better, but I can't find it right now. ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 01:59:43 2013 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 31 Jan 2013 00:59:43 +0000 Subject: [issue17087] Improve the repr for regular expression match objects In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za> Message-ID: <1359593983.98.0.379820619766.issue17087@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Is this a duplicate of issue 13592? ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 02:07:56 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 31 Jan 2013 01:07:56 +0000 Subject: [issue16997] subtests In-Reply-To: <1359577177.3422.8.camel@localhost.localdomain> Message-ID: Nick Coghlan added the comment: Right. I have *heaps* of tests that would be very easy to migrate to Antoine's subtest API. A separate "addMessage" API could conceivably be helpful for debugging, but it's not the obvious improvement to my existing looping tests that subtests would be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 03:05:11 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 31 Jan 2013 02:05:11 +0000 Subject: [issue17087] Improve the repr for regular expression match objects In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za> Message-ID: <1359597911.1.0.119206620558.issue17087@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Just showing group(0) should be helpful. And perhaps the number of groups. If a string is really long, we can truncate it like reprlib does. The main goal is to make it easier to work with match objects at the interactive prompt. They are currently too opaque. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 03:15:34 2013 From: report at bugs.python.org (Silverback Networks) Date: Thu, 31 Jan 2013 02:15:34 +0000 Subject: [issue17011] ElementPath ignores different namespace mappings for the same path expression In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za> Message-ID: <1359598534.79.0.0845638012216.issue17011@psf.upfronthosting.co.za> Changes by Silverback Networks : ---------- nosy: +silverbacknet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 03:35:07 2013 From: report at bugs.python.org (Silverback Networks) Date: Thu, 31 Jan 2013 02:35:07 +0000 Subject: [issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used Message-ID: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za> New submission from Silverback Networks: ET reads a default-namespaced (xmnls="whatever") file correctly but won't write it back out. The error given is: ValueError: cannot use non-qualified names with default_namespace option The XML reference is reasonably clear on this: http://www.w3.org/TR/REC-xml-names/#defaulting "Default namespace declarations do not apply directly to attribute names;" "The namespace name for an unprefixed attribute name always has no value." Therefore, it is not an error to write non-qualified _attribute_ names with a default namespace; they're just considered un-namespaced anyway. The trivial case where a file is read in with a default namespace and written out with the same one should make it obvious: from xml.etree.ElementTree import * register_namespace('svg', 'http://www.w3.org/2000/svg') svg = ElementTree(XML(""" """)) svg.write('simple_new.svg',encoding='UTF-8',default_namespace='svg') Yet this will fail with the error above. By leaving off default_namespace, every element is pointlessly prefixed by 'svg:' in the resulting file, but it does work. ---------- components: XML messages: 181005 nosy: silverbacknet priority: normal severity: normal status: open title: ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 04:36:42 2013 From: report at bugs.python.org (Ben Hoyt) Date: Thu, 31 Jan 2013 03:36:42 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> Message-ID: <1359603402.24.0.899716317495.issue15207@psf.upfronthosting.co.za> Ben Hoyt added the comment: Any update on this, Tim or other Windows developers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 04:45:51 2013 From: report at bugs.python.org (Brian Curtin) Date: Thu, 31 Jan 2013 03:45:51 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> Message-ID: <1359603951.31.0.0953654690826.issue15207@psf.upfronthosting.co.za> Brian Curtin added the comment: I can't comment on what the change should be or how it should be done as I don't do anything with mimetypes, but nothing about how the patch was written jumps out at me for being incorrect (except I would not include ishimoto's name changes). If there's a consensus that this is the appropriate change to be made, the patch still needs tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 08:44:27 2013 From: report at bugs.python.org (Chenguang Wang) Date: Thu, 31 Jan 2013 07:44:27 +0000 Subject: [issue12883] xml.sax.xmlreader.AttributesImpl allows empty string as attribute names In-Reply-To: <1314957842.78.0.391568748992.issue12883@psf.upfronthosting.co.za> Message-ID: <1359618267.37.0.544038477327.issue12883@psf.upfronthosting.co.za> Chenguang Wang added the comment: I found this problem is still not fixed in the lastest hg version. Seriously? This patch is for the latest v3.4.0a0. ---------- keywords: +patch nosy: +Chenguang.Wang Added file: http://bugs.python.org/file28915/w.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 09:26:07 2013 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 31 Jan 2013 08:26:07 +0000 Subject: [issue17028] launcher does not read shebang line when arguments are given In-Reply-To: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za> Message-ID: <1359620767.57.0.581931356189.issue17028@psf.upfronthosting.co.za> Vinay Sajip added the comment: > A test would also be nice :-) I do test the launcher in a standalone environment, but it's not straightforward to test in a standard build or buildbot environment. For example, it needs 4 sets of Python (Python 2.x and 3.x, 32-bit and 64-bit builds for each) setup in the Windows registry. The test script I use is at https://bitbucket.org/vinay.sajip/pylauncher/src/tip/tests.py ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 10:34:19 2013 From: report at bugs.python.org (Jeroen Demeyer) Date: Thu, 31 Jan 2013 09:34:19 +0000 Subject: [issue15182] find_library_file() should try to link In-Reply-To: <1340631736.41.0.714328941122.issue15182@psf.upfronthosting.co.za> Message-ID: <1359624859.07.0.800851010801.issue15182@psf.upfronthosting.co.za> Jeroen Demeyer added the comment: Sorry for the late answer, but yes: I found this out using an actual compilation. I must admit it was in a bit of an usual situation (32-bit userspace on a mixed 32/64-bit mutilib installation), but most other software packages have no problems configuring correctly in such a situation. I can imagine that it's not a trivial change and would require some redesign. Some more context: this was discovered when building Python as part of Sage, see http://trac.sagemath.org/sage_trac/ticket/12725 for the downstream bug report. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 10:37:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 31 Jan 2013 09:37:48 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <3Yxbvv4mdrzPSR@mail.python.org> Roundup Robot added the comment: New changeset 1d061f83a6bf by Ned Deily in branch '2.7': Issue #13590: OS X Xcode 4 - improve support for universal extension modules http://hg.python.org/cpython/rev/1d061f83a6bf New changeset 502b139b3b19 by Ned Deily in branch '3.2': Issue #13590: OS X Xcode 4 - improve support for universal extension modules http://hg.python.org/cpython/rev/502b139b3b19 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 10:47:16 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 31 Jan 2013 09:47:16 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1359625636.62.0.992984056618.issue13590@psf.upfronthosting.co.za> Ned Deily added the comment: Backports committed for 2.7 (2.7.4) and 3.2 (3.2.4). Note that, although the uploaded review patches also included backported changes to ./configure to improve defaults for building Python itself under Xcode 4, I decided not to commit them here as they might introduce a small incompatibility and are more directly associated with Issue11485. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 11:00:38 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 31 Jan 2013 10:00:38 +0000 Subject: [issue17063] assert_called_with could be more powerful if it allowed placeholders In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za> Message-ID: <1359626438.2.0.0560526034606.issue17063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think a better possibility would be to return an indexable "match" object (as bit like re match objects): my_mock(1, someobj(), bar=someotherobj()): match = my_mock.assert_called_with( 1, ANY, bar=ANY) self.assertIsInstance(match[0], someobj) self.assertIsInstance(match['bar'], someotherobj) > It's a *little* cumbersome, but not something I do very often and not > much extra code. I'm not sure that having "assert_called_with" return > objects is an intuitive API either. It has happened to me quite a bit in the latest days :-) "assert_called_with" returning something may fall in the "not very pure" category, but we already have "assertRaises" and friends returning a context manager, and it has proved quite practical. Also, your proposed workaround wouldn't work for assert_any_call(). Perhaps we should wait for other people to chime in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 11:01:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 10:01:19 +0000 Subject: [issue17089] Expat parser parses strings only when XML encoding is UTF-8 Message-ID: <1359626479.25.0.87229024986.issue17089@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: xmlparser.Parse() works with string data only if XML encoding is utf-8 (or ascii). Examples: >>> import xml.parsers.expat >>> parser = xml.parsers.expat.ParserCreate() >>> content = [] >>> parser.CharacterDataHandler = content.append >>> parser.Parse("\xb5") 1 >>> content ['?'] >>> parser = xml.parsers.expat.ParserCreate() >>> content = [] >>> parser.CharacterDataHandler = content.append >>> parser.Parse("\xb5") 1 >>> content ['??'] >>> parser = xml.parsers.expat.ParserCreate() >>> content = [] >>> parser.CharacterDataHandler = content.append >>> parser.Parse("\xb5") Traceback (most recent call last): File "", line 1, in xml.parsers.expat.ExpatError: encoding specified in XML declaration is incorrect: line 1, column 30 This affects all other modules which works with XML: xml.sax, xml.dom.minidom, xml.dom.pulldom, xml.etree.ElementTree. Here is a patch which fixes parsing string data with non-UTF-8 XML. ---------- assignee: serhiy.storchaka components: Extension Modules, Unicode, XML files: pyexpat_parse_str.patch keywords: patch messages: 181014 nosy: ezio.melotti, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Expat parser parses strings only when XML encoding is UTF-8 type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28916/pyexpat_parse_str.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 11:02:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 10:02:25 +0000 Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za> Message-ID: <1359626545.07.0.266875859372.issue2175@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Expat parser parses strings only when XML encoding is UTF-8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 11:02:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 10:02:57 +0000 Subject: [issue2174] xml.sax.xmlreader does not support the InputSource protocol In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za> Message-ID: <1359626577.86.0.823690614725.issue2174@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Expat parser parses strings only when XML encoding is UTF-8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 11:03:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 10:03:47 +0000 Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za> Message-ID: <1359626627.0.0.137669517688.issue1483@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Expat parser parses strings only when XML encoding is UTF-8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 11:05:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 10:05:47 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1359626747.11.0.889921892837.issue10590@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Expat parser parses strings only when XML encoding is UTF-8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 11:52:11 2013 From: report at bugs.python.org (Adam Collard) Date: Thu, 31 Jan 2013 10:52:11 +0000 Subject: [issue12681] unittest expectedFailure could take a message argument like skip does In-Reply-To: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za> Message-ID: <1359629531.59.0.113151293392.issue12681@psf.upfronthosting.co.za> Changes by Adam Collard : ---------- nosy: +adam-collard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 11:52:28 2013 From: report at bugs.python.org (Adam Collard) Date: Thu, 31 Jan 2013 10:52:28 +0000 Subject: [issue9495] argparse unittest tracebacks are confusing if an error is raised when not expected In-Reply-To: <1280852518.56.0.709280463518.issue9495@psf.upfronthosting.co.za> Message-ID: <1359629548.25.0.926280036721.issue9495@psf.upfronthosting.co.za> Changes by Adam Collard : ---------- nosy: +adam-collard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 13:02:12 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 31 Jan 2013 12:02:12 +0000 Subject: [issue11485] Default SDK value on MacOSX needs changing In-Reply-To: <1300051696.43.0.599185291628.issue11485@psf.upfronthosting.co.za> Message-ID: <1359633732.97.0.0281058608387.issue11485@psf.upfronthosting.co.za> Ned Deily added the comment: For 3.3.0, ./configure (configure.ac) was modified in 688d48e434e4 for Issue13590 to use more appropriate defaults for universal builds on newer releases. In particular, --enable-universalsdk=yes uses the Xcode default SDK (as returned by xcodebuild) instead of the 10.4u SDK (not included with Xcode 4), --with-universal-archs now defaults to "intel" if ppc support is not available, and MACOSX_DEPLOYMENT_TARGET defaults to the OS level for 10.6 and newer systems (rather than using 10.4 or 10.3 by default). It also attempts to avoid building Python with deprecated and problematic Apple llvm-gcc compiler, using clang instead. The defaults can be overridden by providing explicit arguments and/or environment variables to ./configure (--enable-universalsdk, --with-universal-archs, CC, MACOSX_DEPLOYMENT_TARGET). While not 100% perfect, the 3.3 changes give good defaults for nearly all common universal build configurations on 10.4 through 10.8. 2.7.x and 3.2.x have the same problems; attached are patches that backport the 3.3 configure changes to them. However, they do introduce a potential incompatibility. Currently, 2.7 and 3.2 initial configures set MACOSX_DEPLOYMENT_TARGET by default to 10.4 (10.3 on a PPC system) for non-universal builds or 32-bit universal builds and to 10.5 for other universal builds. For 3.3, those values are still used for 10.4 and 10.5 systems; for 10.6 and later systems, the default deployment target is now the OS level itself (10.6 for builds on 10.6, etc). Changing the default deployment target for more recent systems has some benefits: the most obvious is that readline support linking with the system BSD libedit is now enabled by default. The potential incompatibility is that the deployment target value is used by distutils.util.get_platform() to form the platform name which is used for bdist names (like eggs) and the lib build directory for the standard library build. While I haven't verified that this is the case, if you've built Python 2.7.2, say, from source on 10.6+ and installed some extension modules with Distutils, then would build from a new release with the proposed patches and install to the existing install location without reinstalling the extension modules, there might be a chance of unexpected incompatibilities between the old extension module (built to an older deployment target) and the upgraded interpreter. Perhaps somewhat more likely is that an extension module binary distribution available on PyPI was available for the old deployment target (10.4) but not for the new target (10.6). Also, it is possible that differences in behavior might be introduced by a change in default compiler. All of these potential incompatibilities can be avoided by overriding the changed defaults, either at Python build time with arguments to ./configure or at extension module build time with environment variables or Distutils config files. Introducing such changes is clearly acceptable with a new release, such as 3.3. For existing releases, it can be argued that the newer, more appropriate settings can also be obtained by just overriding the old defaults ("Explicit is better than implicit."). The question then is, when the old default behavior no longer makes sense due to changes outside of our control, do the benefits of changing them in a maintenance release outweigh the risk of introducing an incompatibility? If they are applied, some or all of the changes to the Mac/README file should be backported as well. Also, while working on this, I did find one edge case where the ./configure defaults do not produce a buildable configuration. The case is on 10.6 with (the optional) Xcode 4. For universal builds, the test added early in ./configure to determine if ppc is supported doesn't work. Since the correct compiler hasn't been determined yet, the test looks at the architectures in /usr/lib/libSystem.dylib. On 10.6, unfortunately, that (and other libs) is a 3-way universal files (i386, x86_64, and ppc) even in the 10.6 SDK supplied with Xcode 4.2 for 10.6 despite the fact that the compilers provided with 4.x do not support building ppc binaries. The problem shows up right away as the "make" dies quickly and it is easily fixed by specifying --with-universal-archs=intel. Still, it would be nice to fix that. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 2.7, Python 3.2 Added file: http://bugs.python.org/file28917/issue11485_backport_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 13:02:27 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 31 Jan 2013 12:02:27 +0000 Subject: [issue11485] Default SDK value on MacOSX needs changing In-Reply-To: <1300051696.43.0.599185291628.issue11485@psf.upfronthosting.co.za> Message-ID: <1359633747.7.0.661731764905.issue11485@psf.upfronthosting.co.za> Changes by Ned Deily : Added file: http://bugs.python.org/file28918/issue11485_backport_32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 13:30:45 2013 From: report at bugs.python.org (Matthias Klose) Date: Thu, 31 Jan 2013 12:30:45 +0000 Subject: [issue17086] backport cross-build patches to the 2.7 branch In-Reply-To: <1359587420.86.0.11365762234.issue17086@psf.upfronthosting.co.za> Message-ID: <1359635445.42.0.377686887463.issue17086@psf.upfronthosting.co.za> Matthias Klose added the comment: config.add and config.sub are needed for the AC_CANONICAL_HOST macro. the patch includes these and the regenerated configure script. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 14:03:23 2013 From: report at bugs.python.org (Attila Gerendi) Date: Thu, 31 Jan 2013 13:03:23 +0000 Subject: [issue16904] http.client.HTTPConnection.send double send data In-Reply-To: <1357727307.69.0.69749124261.issue16904@psf.upfronthosting.co.za> Message-ID: <1359637403.2.0.0380268630746.issue16904@psf.upfronthosting.co.za> Attila Gerendi added the comment: Renamed the report since it's unsafe for sure. This problem was previously called: Avoid unnecessary and possibly unsafe code from http.client.HTTPConnection.send. Imagine that the data parameter from HTTPConnection it's a file like object but it's not iterable, maybe some custom data wrapper. the if hasattr(data, "read"): True branch will correctly send out the response then unnecessary continue to: try: self.sock.sendall(data) except TypeError: if isinstance(data, collections.Iterable): for d in data: self.sock.sendall(d) else: raise TypeError("data should be a bytes-like object " "or an iterable, got %r" % type(data)) and crash! ---------- resolution: -> remind title: Avoid unnecessary and possibly unsafe code from http.client.HTTPConnection.send -> http.client.HTTPConnection.send double send data type: performance -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 14:30:21 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 31 Jan 2013 13:30:21 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359639021.47.0.521753246763.issue17041@psf.upfronthosting.co.za> Stefan Krah added the comment: Serhiy, if you have time, I think it would be nice to get the remaining fix into the upcoming release candidates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 14:33:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 31 Jan 2013 13:33:39 +0000 Subject: [issue4844] ZipFile doesn't range check in _EndRecData() In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za> Message-ID: <3Yxj82398PzP7C@mail.python.org> Roundup Robot added the comment: New changeset 32de35f0f877 by Serhiy Storchaka in branch '2.7': Issue #4844: ZipFile now raises BadZipfile when opens a ZIP file with an http://hg.python.org/cpython/rev/32de35f0f877 New changeset 01147e468c8c by Serhiy Storchaka in branch '3.2': Issue #4844: ZipFile now raises BadZipFile when opens a ZIP file with an http://hg.python.org/cpython/rev/01147e468c8c New changeset 46f24a18a4ab by Serhiy Storchaka in branch '3.3': Issue #4844: ZipFile now raises BadZipFile when opens a ZIP file with an http://hg.python.org/cpython/rev/46f24a18a4ab New changeset e406b8bd7b38 by Serhiy Storchaka in branch 'default': Issue #4844: ZipFile now raises BadZipFile when opens a ZIP file with an http://hg.python.org/cpython/rev/e406b8bd7b38 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 14:38:41 2013 From: report at bugs.python.org (Michael Foord) Date: Thu, 31 Jan 2013 13:38:41 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359639521.46.0.929233026658.issue17041@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- nosy: -michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 14:58:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 31 Jan 2013 13:58:35 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified In-Reply-To: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> Message-ID: <3Yxjhp54yDzNx3@mail.python.org> Roundup Robot added the comment: New changeset af41eca1959e by Serhiy Storchaka in branch '2.7': Issue #17049: Localized calendar methods now return unicode if a locale http://hg.python.org/cpython/rev/af41eca1959e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:13:54 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 31 Jan 2013 14:13:54 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <3Yxk2V1HpnzNwg@mail.python.org> Roundup Robot added the comment: New changeset df9f8feb7444 by Serhiy Storchaka in branch '2.7': Issue #17041: Fix doctesting when Python is configured with the http://hg.python.org/cpython/rev/df9f8feb7444 New changeset 9c0cd608464e by Serhiy Storchaka in branch '3.2': Issue #17041: Fix doctesting when Python is configured with the http://hg.python.org/cpython/rev/9c0cd608464e New changeset 886f48754f7e by Serhiy Storchaka in branch '3.3': Issue #17041: Fix doctesting when Python is configured with the http://hg.python.org/cpython/rev/886f48754f7e New changeset e6cc582cafce by Serhiy Storchaka in branch 'default': Issue #17041: Fix doctesting when Python is configured with the http://hg.python.org/cpython/rev/e6cc582cafce ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:15:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:15:48 +0000 Subject: [issue4844] ZipFile doesn't range check in _EndRecData() In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za> Message-ID: <1359641748.85.0.224699535667.issue4844@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:17:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:17:36 +0000 Subject: [issue17049] calendar throws UnicodeEncodeError when locale is specified In-Reply-To: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za> Message-ID: <1359641856.29.0.32638988288.issue17049@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed. Thank you for reports, Robert Xiao and psam. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:19:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:19:36 +0000 Subject: [issue17041] Fix tests for build --without-doc-strings In-Reply-To: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za> Message-ID: <1359641976.56.0.00884431177455.issue17041@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for review, Stefan Krah. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:28:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:28:36 +0000 Subject: [issue12983] byte string literals with invalid hex escape codes raise ValueError instead of SyntaxError In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za> Message-ID: <1359642516.24.0.247955146266.issue12983@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:32:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:32:20 +0000 Subject: [issue14462] In re's named group the name cannot contain unicode characters In-Reply-To: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za> Message-ID: <1359642740.46.0.974897296747.issue14462@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:35:57 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 31 Jan 2013 14:35:57 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1359642957.91.0.680876170219.issue15881@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Philip, if you could backport, that'd be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:37:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:37:54 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za> Message-ID: <1359643074.14.0.584415256306.issue13169@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:38:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:38:11 +0000 Subject: [issue17034] Initialization of globals in stringobject.c and bytesobject.c In-Reply-To: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za> Message-ID: <1359643091.65.0.217611029141.issue17034@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:38:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:38:36 +0000 Subject: [issue16723] io.TextIOWrapper on urllib.request.urlopen terminates prematurely In-Reply-To: <1355899334.66.0.683261774989.issue16723@psf.upfronthosting.co.za> Message-ID: <1359643116.76.0.947913513515.issue16723@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:38:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 14:38:51 +0000 Subject: [issue17043] Invalid read in test_codecs In-Reply-To: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za> Message-ID: <1359643131.36.0.769219154169.issue17043@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:42:52 2013 From: report at bugs.python.org (Brian Curtin) Date: Thu, 31 Jan 2013 14:42:52 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za> Message-ID: <1359643372.19.0.56744047283.issue13169@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 15:45:51 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 31 Jan 2013 14:45:51 +0000 Subject: [issue17034] Initialization of globals in stringobject.c and bytesobject.c In-Reply-To: <1359643091.69.0.587961368484.issue17034@psf.upfronthosting.co.za> Message-ID: <20130131144553.GA11796@sleipnir.bytereef.org> Stefan Krah added the comment: This is mainly about Py_CLEAR(), right? The initializations to NULL should be guaranteed by the C standard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 16:23:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 15:23:27 +0000 Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError In-Reply-To: <1359643074.19.0.657863786892.issue13169@psf.upfronthosting.co.za> Message-ID: <201301311722.59541.storchaka@gmail.com> Serhiy Storchaka added the comment: Here are patches for 2.7, 3.2 and updated patch for 3.3+ (test_repeat_minmax_overflow_maxrepeat is changed). ---------- Added file: http://bugs.python.org/file28919/re_maxrepeat4-2.7.patch Added file: http://bugs.python.org/file28920/re_maxrepeat4-3.2.patch Added file: http://bugs.python.org/file28921/re_maxrepeat4.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r df9f8feb7444 Lib/sre_compile.py --- a/Lib/sre_compile.py Thu Jan 31 16:10:15 2013 +0200 +++ b/Lib/sre_compile.py Thu Jan 31 17:18:46 2013 +0200 @@ -13,6 +13,7 @@ import _sre, sys import sre_parse from sre_constants import * +from _sre import MAXREPEAT assert _sre.MAGIC == MAGIC, "SRE module mismatch" diff -r df9f8feb7444 Lib/sre_constants.py --- a/Lib/sre_constants.py Thu Jan 31 16:10:15 2013 +0200 +++ b/Lib/sre_constants.py Thu Jan 31 17:18:46 2013 +0200 @@ -15,10 +15,6 @@ MAGIC = 20031017 -# max code word in this release - -MAXREPEAT = 65535 - # SRE standard exception (access as sre.error) # should this really be here? diff -r df9f8feb7444 Lib/sre_parse.py --- a/Lib/sre_parse.py Thu Jan 31 16:10:15 2013 +0200 +++ b/Lib/sre_parse.py Thu Jan 31 17:18:46 2013 +0200 @@ -15,6 +15,7 @@ import sys from sre_constants import * +from _sre import MAXREPEAT SPECIAL_CHARS = ".\\[{()*+?^$|" REPEAT_CHARS = "*+?{" @@ -498,10 +499,18 @@ continue if lo: min = int(lo) + if MAXREPEAT <= min <= sys.maxsize: + raise error("the repetition number is too large") if hi: max = int(hi) - if max < min: - raise error, "bad repeat interval" + if max < min: + raise error("bad repeat interval") + if max >= MAXREPEAT: + if max <= sys.maxsize: + raise error("the repetition number is too large") + max = MAXREPEAT + if min > MAXREPEAT: + min = MAXREPEAT else: raise error, "not supported" # figure out which item to repeat diff -r df9f8feb7444 Lib/test/test_re.py --- a/Lib/test/test_re.py Thu Jan 31 16:10:15 2013 +0200 +++ b/Lib/test/test_re.py Thu Jan 31 17:18:46 2013 +0200 @@ -1,5 +1,5 @@ from test.test_support import verbose, run_unittest, import_module -from test.test_support import precisionbigmemtest, _2G +from test.test_support import precisionbigmemtest, _2G, cpython_only import re from re import Scanner import sys @@ -847,6 +847,39 @@ self.assertEqual(n, size + 1) + def test_repeat_minmax_overflow(self): + # Issue #13169 + string = "x" * 100000 + self.assertEqual(re.match(r".{65535}", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{,65535}", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{65535,}?", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{65536}", string).span(), (0, 65536)) + self.assertEqual(re.match(r".{,65536}", string).span(), (0, 65536)) + self.assertEqual(re.match(r".{65536,}?", string).span(), (0, 65536)) + # 2**128 should be big enough to overflow both SRE_CODE and Py_ssize_t. + self.assertIsNone(re.match(r".{%d}" % 2**128, string)) + self.assertEqual(re.match(r".{,%d}" % 2**128, string).span(), + (0, 100000)) + self.assertIsNone(re.match(r".{%d,}?" % 2**128, string)) + self.assertRaises(re.error, re.compile, r".{%d,%d}" % (2**129, 2**128)) + + @cpython_only + def test_repeat_minmax_overflow_maxrepeat(self): + try: + from _sre import MAXREPEAT + except ImportError: + self.skipTest('requires _sre.MAXREPEAT constant') + if MAXREPEAT > sys.maxsize: + self.skipTest('requires _sre.MAXREPEAT <= sys.maxsize') + self.assertIsNone(re.match(r".{%d}" % (MAXREPEAT - 1), string)) + self.assertEqual(re.match(r".{,%d}" % (MAXREPEAT - 1), string).span(), + (0, 100000)) + self.assertIsNone(re.match(r".{%d,}?" % (MAXREPEAT - 1), string)) + self.assertRaises(re.error, re.compile, r".{%d}" % MAXREPEAT) + self.assertRaises(re.error, re.compile, r".{,%d}" % MAXREPEAT) + self.assertRaises(re.error, re.compile, r".{%d,}?" % MAXREPEAT) + + def run_re_tests(): from test.re_tests import tests, SUCCEED, FAIL, SYNTAX_ERROR if verbose: diff -r df9f8feb7444 Modules/_sre.c --- a/Modules/_sre.c Thu Jan 31 16:10:15 2013 +0200 +++ b/Modules/_sre.c Thu Jan 31 17:18:46 2013 +0200 @@ -524,7 +524,7 @@ Py_ssize_t i; /* adjust end */ - if (maxcount < end - ptr && maxcount != 65535) + if (maxcount < end - ptr && maxcount != SRE_MAXREPEAT) end = ptr + maxcount; switch (pattern[0]) { @@ -1139,7 +1139,7 @@ } else { /* general case */ LASTMARK_SAVE(); - while ((Py_ssize_t)ctx->pattern[2] == 65535 + while ((Py_ssize_t)ctx->pattern[2] == SRE_MAXREPEAT || ctx->count <= (Py_ssize_t)ctx->pattern[2]) { state->ptr = ctx->ptr; DO_JUMP(JUMP_MIN_REPEAT_ONE,jump_min_repeat_one, @@ -1225,7 +1225,7 @@ } if ((ctx->count < ctx->u.rep->pattern[2] || - ctx->u.rep->pattern[2] == 65535) && + ctx->u.rep->pattern[2] == SRE_MAXREPEAT) && state->ptr != ctx->u.rep->last_ptr) { /* we may have enough matches, but if we can match another item, do so */ @@ -1303,7 +1303,7 @@ LASTMARK_RESTORE(); if (ctx->count >= ctx->u.rep->pattern[2] - && ctx->u.rep->pattern[2] != 65535) + && ctx->u.rep->pattern[2] != SRE_MAXREPEAT) RETURN_FAILURE; ctx->u.rep->count = ctx->count; @@ -3042,7 +3042,7 @@ GET_ARG; max = arg; if (min > max) FAIL; - if (max > 65535) + if (max > SRE_MAXREPEAT) FAIL; if (!_validate_inner(code, code+skip-4, groups)) FAIL; @@ -3061,7 +3061,7 @@ GET_ARG; max = arg; if (min > max) FAIL; - if (max > 65535) + if (max > SRE_MAXREPEAT) FAIL; if (!_validate_inner(code, code+skip-3, groups)) FAIL; @@ -3938,6 +3938,12 @@ Py_DECREF(x); } + x = PyLong_FromUnsignedLong(SRE_MAXREPEAT); + if (x) { + PyDict_SetItemString(d, "MAXREPEAT", x); + Py_DECREF(x); + } + x = PyString_FromString(copyright); if (x) { PyDict_SetItemString(d, "copyright", x); diff -r df9f8feb7444 Modules/sre.h --- a/Modules/sre.h Thu Jan 31 16:10:15 2013 +0200 +++ b/Modules/sre.h Thu Jan 31 17:18:46 2013 +0200 @@ -16,9 +16,19 @@ /* size of a code word (must be unsigned short or larger, and large enough to hold a UCS4 character) */ #ifdef Py_USING_UNICODE -#define SRE_CODE Py_UCS4 +# define SRE_CODE Py_UCS4 +# if SIZEOF_SIZE_T > 4 +# define SRE_MAXREPEAT (~(SRE_CODE)0) +# else +# define SRE_MAXREPEAT ((SRE_CODE)PY_SSIZE_T_MAX + 1u) +# endif #else -#define SRE_CODE unsigned long +# define SRE_CODE unsigned long +# if SIZEOF_SIZE_T > SIZEOF_LONG +# define SRE_MAXREPEAT (~(SRE_CODE)0) +# else +# define SRE_MAXREPEAT ((SRE_CODE)PY_SSIZE_T_MAX + 1u) +# endif #endif typedef struct { -------------- next part -------------- diff -r 9c0cd608464e Lib/sre_compile.py --- a/Lib/sre_compile.py Thu Jan 31 16:11:04 2013 +0200 +++ b/Lib/sre_compile.py Thu Jan 31 17:14:59 2013 +0200 @@ -13,6 +13,7 @@ import _sre, sys import sre_parse from sre_constants import * +from _sre import MAXREPEAT assert _sre.MAGIC == MAGIC, "SRE module mismatch" diff -r 9c0cd608464e Lib/sre_constants.py --- a/Lib/sre_constants.py Thu Jan 31 16:11:04 2013 +0200 +++ b/Lib/sre_constants.py Thu Jan 31 17:14:59 2013 +0200 @@ -15,10 +15,6 @@ MAGIC = 20031017 -# max code word in this release - -MAXREPEAT = 65535 - # SRE standard exception (access as sre.error) # should this really be here? diff -r 9c0cd608464e Lib/sre_parse.py --- a/Lib/sre_parse.py Thu Jan 31 16:11:04 2013 +0200 +++ b/Lib/sre_parse.py Thu Jan 31 17:14:59 2013 +0200 @@ -15,6 +15,7 @@ import sys from sre_constants import * +from _sre import MAXREPEAT SPECIAL_CHARS = ".\\[{()*+?^$|" REPEAT_CHARS = "*+?{" @@ -505,10 +506,18 @@ continue if lo: min = int(lo) + if MAXREPEAT <= min <= sys.maxsize: + raise error("the repetition number is too large") if hi: max = int(hi) - if max < min: - raise error("bad repeat interval") + if max < min: + raise error("bad repeat interval") + if max >= MAXREPEAT: + if max <= sys.maxsize: + raise error("the repetition number is too large") + max = MAXREPEAT + if min > MAXREPEAT: + min = MAXREPEAT else: raise error("not supported") # figure out which item to repeat diff -r 9c0cd608464e Lib/test/test_re.py --- a/Lib/test/test_re.py Thu Jan 31 16:11:04 2013 +0200 +++ b/Lib/test/test_re.py Thu Jan 31 17:14:59 2013 +0200 @@ -1,4 +1,5 @@ -from test.support import verbose, run_unittest, gc_collect, bigmemtest, _2G +from test.support import verbose, run_unittest, gc_collect, bigmemtest, _2G, \ + cpython_only import io import re from re import Scanner @@ -883,6 +884,39 @@ self.assertEqual(n, size + 1) + def test_repeat_minmax_overflow(self): + # Issue #13169 + string = "x" * 100000 + self.assertEqual(re.match(r".{65535}", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{,65535}", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{65535,}?", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{65536}", string).span(), (0, 65536)) + self.assertEqual(re.match(r".{,65536}", string).span(), (0, 65536)) + self.assertEqual(re.match(r".{65536,}?", string).span(), (0, 65536)) + # 2**128 should be big enough to overflow both SRE_CODE and Py_ssize_t. + self.assertIsNone(re.match(r".{%d}" % 2**128, string)) + self.assertEqual(re.match(r".{,%d}" % 2**128, string).span(), + (0, 100000)) + self.assertIsNone(re.match(r".{%d,}?" % 2**128, string)) + self.assertRaises(re.error, re.compile, r".{%d,%d}" % (2**129, 2**128)) + + @cpython_only + def test_repeat_minmax_overflow_maxrepeat(self): + try: + from _sre import MAXREPEAT + except ImportError: + self.skipTest('requires _sre.MAXREPEAT constant') + if MAXREPEAT > sys.maxsize: + self.skipTest('requires _sre.MAXREPEAT <= sys.maxsize') + self.assertIsNone(re.match(r".{%d}" % (MAXREPEAT - 1), string)) + self.assertEqual(re.match(r".{,%d}" % (MAXREPEAT - 1), string).span(), + (0, 100000)) + self.assertIsNone(re.match(r".{%d,}?" % (MAXREPEAT - 1), string)) + self.assertRaises(re.error, re.compile, r".{%d}" % MAXREPEAT) + self.assertRaises(re.error, re.compile, r".{,%d}" % MAXREPEAT) + self.assertRaises(re.error, re.compile, r".{%d,}?" % MAXREPEAT) + + def run_re_tests(): from test.re_tests import tests, SUCCEED, FAIL, SYNTAX_ERROR if verbose: diff -r 9c0cd608464e Modules/_sre.c --- a/Modules/_sre.c Thu Jan 31 16:11:04 2013 +0200 +++ b/Modules/_sre.c Thu Jan 31 17:14:59 2013 +0200 @@ -517,7 +517,7 @@ Py_ssize_t i; /* adjust end */ - if (maxcount < end - ptr && maxcount != 65535) + if (maxcount < end - ptr && maxcount != SRE_MAXREPEAT) end = ptr + maxcount; switch (pattern[0]) { @@ -1132,7 +1132,7 @@ } else { /* general case */ LASTMARK_SAVE(); - while ((Py_ssize_t)ctx->pattern[2] == 65535 + while ((Py_ssize_t)ctx->pattern[2] == SRE_MAXREPEAT || ctx->count <= (Py_ssize_t)ctx->pattern[2]) { state->ptr = ctx->ptr; DO_JUMP(JUMP_MIN_REPEAT_ONE,jump_min_repeat_one, @@ -1218,7 +1218,7 @@ } if ((ctx->count < ctx->u.rep->pattern[2] || - ctx->u.rep->pattern[2] == 65535) && + ctx->u.rep->pattern[2] == SRE_MAXREPEAT) && state->ptr != ctx->u.rep->last_ptr) { /* we may have enough matches, but if we can match another item, do so */ @@ -1296,7 +1296,7 @@ LASTMARK_RESTORE(); if (ctx->count >= ctx->u.rep->pattern[2] - && ctx->u.rep->pattern[2] != 65535) + && ctx->u.rep->pattern[2] != SRE_MAXREPEAT) RETURN_FAILURE; ctx->u.rep->count = ctx->count; @@ -3072,7 +3072,7 @@ GET_ARG; max = arg; if (min > max) FAIL; - if (max > 65535) + if (max > SRE_MAXREPEAT) FAIL; if (!_validate_inner(code, code+skip-4, groups)) FAIL; @@ -3091,7 +3091,7 @@ GET_ARG; max = arg; if (min > max) FAIL; - if (max > 65535) + if (max > SRE_MAXREPEAT) FAIL; if (!_validate_inner(code, code+skip-3, groups)) FAIL; @@ -3979,6 +3979,12 @@ Py_DECREF(x); } + x = PyLong_FromUnsignedLong(SRE_MAXREPEAT); + if (x) { + PyDict_SetItemString(d, "MAXREPEAT", x); + Py_DECREF(x); + } + x = PyUnicode_FromString(copyright); if (x) { PyDict_SetItemString(d, "copyright", x); diff -r 9c0cd608464e Modules/sre.h --- a/Modules/sre.h Thu Jan 31 16:11:04 2013 +0200 +++ b/Modules/sre.h Thu Jan 31 17:14:59 2013 +0200 @@ -16,6 +16,11 @@ /* size of a code word (must be unsigned short or larger, and large enough to hold a UCS4 character) */ #define SRE_CODE Py_UCS4 +#if SIZEOF_SIZE_T > 4 +# define SRE_MAXREPEAT (~(SRE_CODE)0) +#else +# define SRE_MAXREPEAT ((SRE_CODE)PY_SSIZE_T_MAX + 1u) +#endif typedef struct { PyObject_VAR_HEAD -------------- next part -------------- diff -r e6cc582cafce Lib/sre_compile.py --- a/Lib/sre_compile.py Thu Jan 31 16:11:47 2013 +0200 +++ b/Lib/sre_compile.py Thu Jan 31 17:21:55 2013 +0200 @@ -13,6 +13,7 @@ import _sre, sys import sre_parse from sre_constants import * +from _sre import MAXREPEAT assert _sre.MAGIC == MAGIC, "SRE module mismatch" diff -r e6cc582cafce Lib/sre_constants.py --- a/Lib/sre_constants.py Thu Jan 31 16:11:47 2013 +0200 +++ b/Lib/sre_constants.py Thu Jan 31 17:21:55 2013 +0200 @@ -15,10 +15,6 @@ MAGIC = 20031017 -# max code word in this release - -MAXREPEAT = 65535 - # SRE standard exception (access as sre.error) # should this really be here? diff -r e6cc582cafce Lib/sre_parse.py --- a/Lib/sre_parse.py Thu Jan 31 16:11:47 2013 +0200 +++ b/Lib/sre_parse.py Thu Jan 31 17:21:55 2013 +0200 @@ -15,6 +15,7 @@ import sys from sre_constants import * +from _sre import MAXREPEAT SPECIAL_CHARS = ".\\[{()*+?^$|" REPEAT_CHARS = "*+?{" @@ -537,10 +538,18 @@ continue if lo: min = int(lo) + if MAXREPEAT <= min <= sys.maxsize: + raise error("the repetition number is too large") if hi: max = int(hi) - if max < min: - raise error("bad repeat interval") + if max < min: + raise error("bad repeat interval") + if max >= MAXREPEAT: + if max <= sys.maxsize: + raise error("the repetition number is too large") + max = MAXREPEAT + if min > MAXREPEAT: + min = MAXREPEAT else: raise error("not supported") # figure out which item to repeat diff -r e6cc582cafce Lib/test/test_re.py --- a/Lib/test/test_re.py Thu Jan 31 16:11:47 2013 +0200 +++ b/Lib/test/test_re.py Thu Jan 31 17:21:55 2013 +0200 @@ -1,4 +1,5 @@ -from test.support import verbose, run_unittest, gc_collect, bigmemtest, _2G +from test.support import verbose, run_unittest, gc_collect, bigmemtest, _2G, \ + cpython_only import io import re from re import Scanner @@ -980,6 +981,39 @@ self.assertEqual(re.findall(r"(?i)(a)\1", "aa \u0100"), ['a']) self.assertEqual(re.match(r"(?s).{1,3}", "\u0100\u0100").span(), (0, 2)) + def test_repeat_minmax_overflow(self): + # Issue #13169 + string = "x" * 100000 + self.assertEqual(re.match(r".{65535}", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{,65535}", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{65535,}?", string).span(), (0, 65535)) + self.assertEqual(re.match(r".{65536}", string).span(), (0, 65536)) + self.assertEqual(re.match(r".{,65536}", string).span(), (0, 65536)) + self.assertEqual(re.match(r".{65536,}?", string).span(), (0, 65536)) + # 2**128 should be big enough to overflow both SRE_CODE and Py_ssize_t. + self.assertIsNone(re.match(r".{%d}" % 2**128, string)) + self.assertEqual(re.match(r".{,%d}" % 2**128, string).span(), + (0, 100000)) + self.assertIsNone(re.match(r".{%d,}?" % 2**128, string)) + self.assertRaises(re.error, re.compile, r".{%d,%d}" % (2**129, 2**128)) + + @cpython_only + def test_repeat_minmax_overflow_maxrepeat(self): + try: + from _sre import MAXREPEAT + except ImportError: + self.skipTest('requires _sre.MAXREPEAT constant') + if MAXREPEAT > sys.maxsize: + self.skipTest('requires _sre.MAXREPEAT <= sys.maxsize') + self.assertIsNone(re.match(r".{%d}" % (MAXREPEAT - 1), string)) + self.assertEqual(re.match(r".{,%d}" % (MAXREPEAT - 1), string).span(), + (0, 100000)) + self.assertIsNone(re.match(r".{%d,}?" % (MAXREPEAT - 1), string)) + self.assertRaises(re.error, re.compile, r".{%d}" % MAXREPEAT) + self.assertRaises(re.error, re.compile, r".{,%d}" % MAXREPEAT) + self.assertRaises(re.error, re.compile, r".{%d,}?" % MAXREPEAT) + + def run_re_tests(): from test.re_tests import tests, SUCCEED, FAIL, SYNTAX_ERROR if verbose: diff -r e6cc582cafce Modules/_sre.c --- a/Modules/_sre.c Thu Jan 31 16:11:47 2013 +0200 +++ b/Modules/_sre.c Thu Jan 31 17:21:55 2013 +0200 @@ -492,7 +492,7 @@ Py_ssize_t i; /* adjust end */ - if (maxcount < (end - ptr) / state->charsize && maxcount != 65535) + if (maxcount < (end - ptr) / state->charsize && maxcount != SRE_MAXREPEAT) end = ptr + maxcount*state->charsize; switch (pattern[0]) { @@ -1109,7 +1109,7 @@ } else { /* general case */ LASTMARK_SAVE(); - while ((Py_ssize_t)ctx->pattern[2] == 65535 + while ((Py_ssize_t)ctx->pattern[2] == SRE_MAXREPEAT || ctx->count <= (Py_ssize_t)ctx->pattern[2]) { state->ptr = ctx->ptr; DO_JUMP(JUMP_MIN_REPEAT_ONE,jump_min_repeat_one, @@ -1195,7 +1195,7 @@ } if ((ctx->count < ctx->u.rep->pattern[2] || - ctx->u.rep->pattern[2] == 65535) && + ctx->u.rep->pattern[2] == SRE_MAXREPEAT) && state->ptr != ctx->u.rep->last_ptr) { /* we may have enough matches, but if we can match another item, do so */ @@ -1273,7 +1273,7 @@ LASTMARK_RESTORE(); if (ctx->count >= ctx->u.rep->pattern[2] - && ctx->u.rep->pattern[2] != 65535) + && ctx->u.rep->pattern[2] != SRE_MAXREPEAT) RETURN_FAILURE; ctx->u.rep->count = ctx->count; @@ -3037,7 +3037,7 @@ GET_ARG; max = arg; if (min > max) FAIL; - if (max > 65535) + if (max > SRE_MAXREPEAT) FAIL; if (!_validate_inner(code, code+skip-4, groups)) FAIL; @@ -3056,7 +3056,7 @@ GET_ARG; max = arg; if (min > max) FAIL; - if (max > 65535) + if (max > SRE_MAXREPEAT) FAIL; if (!_validate_inner(code, code+skip-3, groups)) FAIL; @@ -3942,6 +3942,12 @@ Py_DECREF(x); } + x = PyLong_FromUnsignedLong(SRE_MAXREPEAT); + if (x) { + PyDict_SetItemString(d, "MAXREPEAT", x); + Py_DECREF(x); + } + x = PyUnicode_FromString(copyright); if (x) { PyDict_SetItemString(d, "copyright", x); diff -r e6cc582cafce Modules/sre.h --- a/Modules/sre.h Thu Jan 31 16:11:47 2013 +0200 +++ b/Modules/sre.h Thu Jan 31 17:21:55 2013 +0200 @@ -16,6 +16,11 @@ /* size of a code word (must be unsigned short or larger, and large enough to hold a UCS4 character) */ #define SRE_CODE Py_UCS4 +#if SIZEOF_SIZE_T > 4 +# define SRE_MAXREPEAT (~(SRE_CODE)0) +#else +# define SRE_MAXREPEAT ((SRE_CODE)PY_SSIZE_T_MAX + 1u) +#endif typedef struct { PyObject_VAR_HEAD From report at bugs.python.org Thu Jan 31 16:26:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 15:26:21 +0000 Subject: [issue17034] Initialization of globals in stringobject.c and bytesobject.c In-Reply-To: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za> Message-ID: <1359645981.02.0.941591567332.issue17034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > The initializations to NULL should be guaranteed by the C standard. I don't sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 16:28:27 2013 From: report at bugs.python.org (Christoph Rauch) Date: Thu, 31 Jan 2013 15:28:27 +0000 Subject: [issue17090] io.TextIOWrapper does not handle UTF-8 encoded streams correctly Message-ID: <1359646107.71.0.993136506568.issue17090@psf.upfronthosting.co.za> New submission from Christoph Rauch: I have uncovered a strange behavior in io.TextIOWrapper which I think is a bug. #!/usr/bin/env python # encoding: utf-8 import csv import io raw_file = io.FileIO('utf-8-encoded.csv', 'rb') stream = io.BufferedReader(raw_file) stream = io.TextIOWrapper(stream, encoding="UTF-8") reader = csv.reader(stream, delimiter=";") cells = 0 for row in reader: # Cells should contain 4 Unicode characters. assert all([len(cell.decode('utf-8')) == 4 for cell in row]), row cells += len(row) assert cells == 210, cells This produces a not very useful: Traceback (most recent call last): File "utf8-textio-test.py", line 15, in for row in reader: UnicodeEncodeError: 'ascii' codec can't encode characters in position 1-4: ordinal not in range(128) The only way to let it *not* crash is to set encoding to ascii and errors to ignore, but this clears out all the characters with ord>128, clearly not useful as well, so I hope this behavior is not intended. I appended a file with which to test this problem. ---------- components: IO files: utf-8-encoded.csv messages: 181028 nosy: Christoph.Rauch priority: normal severity: normal status: open title: io.TextIOWrapper does not handle UTF-8 encoded streams correctly type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file28922/utf-8-encoded.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 16:37:25 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 31 Jan 2013 15:37:25 +0000 Subject: [issue17034] Use Py_CLEAR() in stringobject.c and bytesobject.c In-Reply-To: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za> Message-ID: <1359646645.0.0.897225060643.issue17034@psf.upfronthosting.co.za> Stefan Krah added the comment: Yes, it's guaranteed: 6.7.8 Initialization -------------------- 10) If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then: - if it has pointer type, it is initialized to a null pointer; - if it has arithmetic type, it is initialized to (positive or unsigned) zero; - if it is an aggregate, every member is initialized (recursively) according to these rules; - if it is a union, the first named member is initialized (recursively) according to these rules. I'm changing the title so that people don't get the impression that anything is wrong with the initialization. The Py_CLEAR() changes are fine of course. ---------- title: Initialization of globals in stringobject.c and bytesobject.c -> Use Py_CLEAR() in stringobject.c and bytesobject.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 16:37:41 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 31 Jan 2013 15:37:41 +0000 Subject: [issue17090] io.TextIOWrapper does not handle UTF-8 encoded streams correctly In-Reply-To: <1359646107.71.0.993136506568.issue17090@psf.upfronthosting.co.za> Message-ID: <1359646661.32.0.493838826663.issue17090@psf.upfronthosting.co.za> R. David Murray added the comment: As noted in the documentation, the csv module in 2.7 does not handle unicode. You'll have to switch to python3 if you want unicode support in csv. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 16:42:47 2013 From: report at bugs.python.org (Christoph Rauch) Date: Thu, 31 Jan 2013 15:42:47 +0000 Subject: [issue17090] io.TextIOWrapper does not handle UTF-8 encoded streams correctly In-Reply-To: <1359646107.71.0.993136506568.issue17090@psf.upfronthosting.co.za> Message-ID: <1359646967.38.0.400185693093.issue17090@psf.upfronthosting.co.za> Christoph Rauch added the comment: Thanks for the information. Will work around that. Miss-diagnosed the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 16:43:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 15:43:01 +0000 Subject: [issue17034] Use Py_CLEAR() in stringobject.c and bytesobject.c In-Reply-To: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za> Message-ID: <1359646981.57.0.461843027039.issue17034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 16:52:35 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 31 Jan 2013 15:52:35 +0000 Subject: [issue7225] fwrite() compiler warnings In-Reply-To: <1256692580.97.0.277746602553.issue7225@psf.upfronthosting.co.za> Message-ID: <1359647555.98.0.137068850016.issue7225@psf.upfronthosting.co.za> Ramchandra Apte added the comment: I'm pretty sure this is invalid now. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 17:02:17 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 31 Jan 2013 16:02:17 +0000 Subject: [issue16432] Template strings documentation in Python 3 refers to % substitution in present tense In-Reply-To: <1352323704.72.0.0858754286751.issue16432@psf.upfronthosting.co.za> Message-ID: <1359648137.1.0.718882013187.issue16432@psf.upfronthosting.co.za> Ramchandra Apte added the comment: > ... as it is not the preferred system. I prefer .format() but I don't think that's true for many people. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 17:58:07 2013 From: report at bugs.python.org (Armin Rigo) Date: Thu, 31 Jan 2013 16:58:07 +0000 Subject: [issue17091] thread.lock.acquire docstring bug Message-ID: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za> New submission from Armin Rigo: The docstring of thread.lock.acquire() (or _thread on Python 3) is bogus: it says that if called without argument, the return value is None; it is only if called with a "blocking" argument that it returns True or False. But since a long time it was always returning a boolean, never None. ---------- assignee: docs at python components: Documentation keywords: easy messages: 181035 nosy: arigo, docs at python priority: normal severity: normal status: open title: thread.lock.acquire docstring bug versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 17:58:16 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 31 Jan 2013 16:58:16 +0000 Subject: [issue4591] 32-bits unsigned user/group identifier In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za> Message-ID: <1359651496.64.0.884436633967.issue4591@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Are there any objections, nitpicks or suggestions? ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 18:12:52 2013 From: report at bugs.python.org (ddvento@ucar.edu) Date: Thu, 31 Jan 2013 17:12:52 +0000 Subject: [issue17092] Disable TIPC in configure Message-ID: <1359652372.04.0.314648330864.issue17092@psf.upfronthosting.co.za> New submission from ddvento at ucar.edu: This is related to Issue17085 and Issue1646 My system is a cluster Red Hat Enterprise Linux Server release 6.2 (Santiago) and it happens to have /usr/include/linux/tipc.h but probably tipc disabled in the kernel for some reasons which I ignore. There is little interest and no time from the sysadministrators to investigate TIPC, or to remove unneeded files or packages. When I configure and build Python 2.7.3, it seems to build correctly. However the test suite crashes as described in Issue17085. Therefore, I want to rebuild Python 2.7.3 with TIPC disabled. Unfortunately, configure seems to ignore all of the followings: ./configure --without-tipc ./configure --without-TIPC HAVE_LINUX_TIPC_H=0 ./configure HAVE_LINUX_TIPC_H=0 ./configure HAVE_LINUX_TIPC_H=0 (for the record, my other configure options are --enable-shared --with-system-expat --prefix=my-path) I also tried to manually editing config.status as follows: --- config.status.orig 2013-01-31 09:24:04.109311726 -0700 +++ config.status 2013-01-31 09:28:28.397660288 -0700 @@ -854,7 +854,7 @@ D["HAVE_SYS_RESOURCE_H"]=" 1" D["HAVE_NETPACKET_PACKET_H"]=" 1" D["HAVE_SYSEXITS_H"]=" 1" -D["HAVE_LINUX_TIPC_H"]=" 1" +D["HAVE_LINUX_TIPC_H"]=" 0" D["HAVE_SPAWN_H"]=" 1" D["HAVE_DIRENT_H"]=" 1" D["HAVE_TERM_H"]=" 1" then run it and check that pyconfig.h has #define HAVE_LINUX_TIPC_H 0 (which it did). Running make and make test after this, produces exactly the same issue as described in Issue17085. Is there a way to force configure to ignore TIPC? ---------- components: Build messages: 181037 nosy: ddvento at ucar.edu priority: normal severity: normal status: open title: Disable TIPC in configure versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 18:36:05 2013 From: report at bugs.python.org (Berker Peksag) Date: Thu, 31 Jan 2013 17:36:05 +0000 Subject: [issue16163] Wrong name in Lib/pkgutil.py:iter_importers In-Reply-To: <1349697246.97.0.772309039282.issue16163@psf.upfronthosting.co.za> Message-ID: <1359653765.76.0.514759348709.issue16163@psf.upfronthosting.co.za> Berker Peksag added the comment: Sorry for the delay and thanks for the suggestions Ezio and Nick. > Given the lack of proper tests for iter_importers, wouldn't adding a > proper test that returns something useful, rather than testing only > with a non-existent module be better (this test could be kept, maybe > converted to an assertRaises)? I've added a test for iter_importers(). > (Note: There's a series of patches from Chris to move the walk_packages > test to where it belongs in test_pkgutil, but they won't be applied until > after the final 3.2 maintenance release has happened.) Thanks for the info. These patches are in issue 15376, issue 15358, issue 15403 and issue 15415, right? ---------- Added file: http://bugs.python.org/file28923/issue16163_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 19:28:54 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 31 Jan 2013 18:28:54 +0000 Subject: [issue17092] Disable TIPC in configure In-Reply-To: <1359652372.04.0.314648330864.issue17092@psf.upfronthosting.co.za> Message-ID: <1359656934.32.0.813938210487.issue17092@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why would you disable TIPC? If TIPC crashes the test suite, you probably have a system bug. I would suggest you try to diagnose what happens exactly. (normally, the TIPC tests are skipped if the tipc kernel module isn't loaded) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 19:52:54 2013 From: report at bugs.python.org (ddvento@ucar.edu) Date: Thu, 31 Jan 2013 18:52:54 +0000 Subject: [issue17092] Disable TIPC in configure In-Reply-To: <1359656934.32.0.813938210487.issue17092@psf.upfronthosting.co.za> Message-ID: <510ABD8F.5070101@ucar.edu> ddvento at ucar.edu added the comment: Antoine, the exact reason why I want to disable TIPC in configure, is that either the test suite or the TIPC test case or both has/have a bug (not my system). Therefore I suggest that you re-post your comment in Issue17085, and I'll be happy to provide more details that would be off-topic here. However, regardless of my particular needs, disabling TIPC in configure is something useful for a variety of other reasons (e.g. one having a functional TIPC but not wanting to have it enabled in python), and therefore I asked it here. It is customary to have autotools being able to individually select packages that one wants or does not want to use. In fact ./configure --help reports the --without-PACKAGE option which does not work for TIPC and this is the bug of present Issue17092 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 20:05:25 2013 From: report at bugs.python.org (Berker Peksag) Date: Thu, 31 Jan 2013 19:05:25 +0000 Subject: [issue16555] Add es_cu to locale aliases In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za> Message-ID: <1359659125.79.0.18470644208.issue16555@psf.upfronthosting.co.za> Berker Peksag added the comment: > LGTM. Thanks for the review, ?ric. Do you have time to commit the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 21:08:47 2013 From: report at bugs.python.org (Michael Driscoll) Date: Thu, 31 Jan 2013 20:08:47 +0000 Subject: [issue2824] zipfile to handle duplicate files in archive In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za> Message-ID: <1359662927.91.0.552013959672.issue2824@psf.upfronthosting.co.za> Michael Driscoll added the comment: Whatever became of this? We just stumbled across this bug in our code at work where we accidentally put multiple files of the same name into the zip file and not only does it not overwrite the others, but when you go to access that file name, it grabs the first one that was put in. ---------- nosy: +michael.driscoll _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 21:57:32 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 31 Jan 2013 20:57:32 +0000 Subject: [issue17087] Improve the repr for regular expression match objects In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za> Message-ID: <1359665852.74.0.959258687838.issue17087@psf.upfronthosting.co.za> Ezio Melotti added the comment: #13592 is indeed the issue I was thinking about, but apparently that's about _sre.SRE_Pattern, so it's not the same thing. > Just showing group(0) should be helpful. Often the interesting group is group(1), so showing only group(0) seems a bit arbitrary. > And perhaps the number of groups. If we show only group(0), this might be useful as an indication that there are(n't) other groups. > If a string is really long, we can truncate it like reprlib does. That's certainly an option. FWIW I don't usually care about the start/end, and, if included, these values could be included as span=(3,12). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:00:58 2013 From: report at bugs.python.org (Catalin Iacob) Date: Thu, 31 Jan 2013 21:00:58 +0000 Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za> Message-ID: <1359666058.61.0.0290753110228.issue6972@psf.upfronthosting.co.za> Changes by Catalin Iacob : ---------- nosy: +catalin.iacob _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:06:41 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 31 Jan 2013 21:06:41 +0000 Subject: [issue17093] Make importlib.abc more inheritance-friendly Message-ID: <1359666401.55.0.375165619272.issue17093@psf.upfronthosting.co.za> New submission from Brett Cannon: ABCs, even though they are almost always at the bottom of an inheritance hierarchy, should still do the right thing in the face of being in the middle of an MRO. That means that they should call super() as appropriate. So for methods that return a value, blindly call super(). For methods that do not necessarily return anything (e.g. invalidate_caches()), check if super() as the method and it is callable and if that is true then make the super() call. This is not backwards-compatible as it is new semantics people will rely on, but neither is it a bug but a bad design decision on my part. ---------- components: Library (Lib) keywords: easy messages: 181044 nosy: brett.cannon priority: low severity: normal stage: test needed status: open title: Make importlib.abc more inheritance-friendly type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:06:51 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 31 Jan 2013 21:06:51 +0000 Subject: [issue17093] Make importlib.abc more inheritance-friendly In-Reply-To: <1359666401.55.0.375165619272.issue17093@psf.upfronthosting.co.za> Message-ID: <1359666411.81.0.410303991683.issue17093@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:39:23 2013 From: report at bugs.python.org (Stefan Ring) Date: Thu, 31 Jan 2013 21:39:23 +0000 Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames Message-ID: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za> New submission from Stefan Ring: After a fork, the list of thread states contains all the threads from before. It is especially unfortunate that, at least for me, it usually happens that threads created in the forked process reuse the same thread ids, and sys._current_frames will then return wrong stack frames for existing threads because the old entries occur towards the tail of the linked list and overwrite the earlier, correct ones, in _PyThread_CurrentFrames. The attached patch is certainly not the most complete solution, but it solves my problem. With Python 2.7.3 I get: Exception in thread Thread-6: Traceback (most recent call last): File "/usr/lib64/python2.7/threading.py", line 551, in __bootstrap_inner self.run() File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "test-fork-frames.py", line 24, in do_verify assert frame_from_sys is real_frame AssertionError With my patch applied, it passes silently. I can reproduce this on CentOS 6.3 x86_64 as well as Fedora 18 x86_64. ---------- components: Interpreter Core files: current-frames-cleanup.patch keywords: patch messages: 181045 nosy: Ringding priority: normal severity: normal status: open title: sys._current_frames() reports too many/wrong stack frames type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file28924/current-frames-cleanup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:40:35 2013 From: report at bugs.python.org (Stefan Ring) Date: Thu, 31 Jan 2013 21:40:35 +0000 Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames In-Reply-To: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za> Message-ID: <1359668435.8.0.504463161494.issue17094@psf.upfronthosting.co.za> Changes by Stefan Ring : Added file: http://bugs.python.org/file28925/test-fork-frames.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:42:58 2013 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 31 Jan 2013 21:42:58 +0000 Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like NFS) In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za> Message-ID: <1359668578.42.0.547663906709.issue17076@psf.upfronthosting.co.za> Thomas Wouters added the comment: Updated patch with test. ---------- Added file: http://bugs.python.org/file28926/shutil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:43:16 2013 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 31 Jan 2013 21:43:16 +0000 Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like NFS) In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za> Message-ID: <1359668596.66.0.424238859155.issue17076@psf.upfronthosting.co.za> Changes by Thomas Wouters : Removed file: http://bugs.python.org/file28898/shutil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:43:37 2013 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 31 Jan 2013 21:43:37 +0000 Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like NFS) In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za> Message-ID: <1359668617.34.0.088845734861.issue17076@psf.upfronthosting.co.za> Changes by Thomas Wouters : Removed file: http://bugs.python.org/file28926/shutil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:44:16 2013 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 31 Jan 2013 21:44:16 +0000 Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like NFS) In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za> Message-ID: <1359668656.17.0.520673028574.issue17076@psf.upfronthosting.co.za> Thomas Wouters added the comment: Now really updated the patch. ---------- Added file: http://bugs.python.org/file28927/shutil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 22:54:56 2013 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 31 Jan 2013 21:54:56 +0000 Subject: [issue17095] Modules/Setup *shared* support broken Message-ID: <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za> New submission from Thomas Wouters: At some point (probably in 3.2) the support for shared modules built using Modules/Setup was broken, for two reasons: - Python no longer considers 'foomodule.so' when looking for a module called 'foo', but Modules/makesetup still appends 'module.so' for a 'foo' module. - Python no longer considers Modules/ to be the exec_prefix (and instead uses what was loaded from the build-info .txt written by setup.py) but the build process still leaves these Modules/Setup-built shared modules in the Modules directory (and it doesn't know about the directory setup.py will make, so it can't really do anything else.) This patch fixes both problems, by making Modules/makesetup name shared library modules 'foo.so' and by adding the Modules subdirectory to sys.path (after the setup.py-provided directory) when running from the build directory. (The existing build process has no problem _installing_ the Modules/Setup-built extension modules, it's just Python that doesn't know how to find them.) ---------- components: Build files: getpath.diff keywords: patch messages: 181048 nosy: twouters priority: normal severity: normal status: open title: Modules/Setup *shared* support broken versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28928/getpath.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 23:52:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 31 Jan 2013 22:52:25 +0000 Subject: [issue17086] backport cross-build patches to the 2.7 branch In-Reply-To: <1359587420.86.0.11365762234.issue17086@psf.upfronthosting.co.za> Message-ID: <3YxxXm6gc5zPwt@mail.python.org> Roundup Robot added the comment: New changeset 8ee6d96a1019 by doko in branch '2.7': - Issue #17086: Backport the patches from the 3.3 branch to cross-build http://hg.python.org/cpython/rev/8ee6d96a1019 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 31 23:53:20 2013 From: report at bugs.python.org (Matthias Klose) Date: Thu, 31 Jan 2013 22:53:20 +0000 Subject: [issue17086] backport cross-build patches to the 2.7 branch In-Reply-To: <1359587420.86.0.11365762234.issue17086@psf.upfronthosting.co.za> Message-ID: <1359672800.99.0.601475131924.issue17086@psf.upfronthosting.co.za> Matthias Klose added the comment: now committed, watching the buildds ---------- stage: -> committed/rejected status: open -> pending type: -> enhancement _______________________________________ Python tracker _______________________________________